Bluespice MediaWiki LDAP connection fails

texas-aggie · January 19, 2018, 12:35am

I’ve stepped through a few iterations of removing the docker image, mysql clean up, and clearing /etc/bluespice of configs and older WikiSysop password in hopes of getting a clean install that would connect to LDAP and permit user login.

As it stands now, even the WikiSysop user is denied access using the local domain (to by-pass LDAP.)

I suspect the extended period of time it takes for the Tomcat8 instance to fully start creates a collision in the script and leaves some pieces out during the initial install. The github repo shows the bash wait commented out. Again, just suspecting that’s the issue.

Perhaps the Bluespice team can comment and provide some steps into identifying the issue.

ljonka · January 23, 2018, 10:05am

Hello texas-aggie,

in most cases the login will fail when the ldap servers ip has changed but not updated in ucs ldap dc (Domain->Ldap Directory->computers->dc->domaincontroller master). The ip should be checked 3x times to be valid and equal to your ucs domain servers ip. (This happens when your server receive a new ip from some external dhcp server, ucs does not recognize this change and leaves the ip on the first ip given)

To disable/debug ldap login and activate the local login, ssh access is needed. Try the steps discribed above please, if needed, i will describe the next debug steps here.

Best regards.

texas-aggie · January 23, 2018, 2:46pm

All LDAP/DC systems are deployed with static addressing (IPv4). Are you suggesting the address is invalid in the UCS settings or the Docker Image where Bluespice/MediaWiki reside?

ljonka · January 23, 2018, 2:53pm

The bluespice docker image uses the ldap settings given by ucs, so it should be set right in ucs.

To see how the config settings are used, checkout this link (getenv() and file_get_contents()): https://github.com/hallowelt/mediawiki/blob/REL1_27_univention/settings.d/060-LDAPUnivention.php

It is possible to debug directly from within the bluespice docker image by entering the vm with “univention-app shell bluespice”

Refer to /var/www/html/bluespice within the docker image to debug the installation

texas-aggie · January 26, 2018, 2:01am

Here’s what the log is kicking out (repeatedly):

2018-01-26 01:51:48 blues-38649806 bluespice: 2.1.0 Allowing the local domain, adding it to the list.
2018-01-26 01:51:48 blues-38649806 bluespice: 2.1.0 Entering strict.
2018-01-26 01:51:48 blues-38649806 bluespice: 2.1.0 Returning false in strict().
2018-01-26 01:51:48 blues-38649806 bluespice: 2.1.0 Entering getCanonicalName
2018-01-26 01:51:48 blues-38649806 bluespice: 2.1.0 Username is an IP, not munging.

Not very helpful for me - I can usually track things down with decent logging info, but this might as well be in German.

texas-aggie · January 26, 2018, 5:28pm

Restarted the container and logs showing something more telling:

2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Username is: MediaWiki default
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Munged username: Mediawiki default
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering allowPasswordChange
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 No domain found, returning invaliddomain
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering allowPasswordChange
2018-01-26 17:15:52 blues-38649806 bluespice: 2.1.0 Entering getDomain

Appears the container isn’t getting the host environmental attributes correctly passed for LdapAuth to work correctly.

What’s the next step troubleshooting step here?

ljonka · January 29, 2018, 10:56am

It should be possible to ping the given LDAP Master Server from within the docker container.

To do so, try the following steps:

Login into ucs over ssh
login into docker container over “univention-app shell bluespice”
active full shell support with “export TERM=xterm”
ping the ldap master server with: “ping $LDAP_MASTER”

Does the connection work properly here?

texas-aggie · January 29, 2018, 2:51pm

A most satisfying and qualified, ‘Yes!’

@blues-38649806:/# ping $LDAP_MASTER
PING ucs-9410.snipped.com (10.0.1.236): 56 data bytes
64 bytes from 10.0.1.236: icmp_seq=0 ttl=64 time=0.124 ms
64 bytes from 10.0.1.236: icmp_seq=1 ttl=64 time=0.139 ms

texas-aggie · January 31, 2018, 2:39am

An additional item that’s relevant: bluespice: 2.1.0 Failed to bind as cn=blues-38649806,cn=memberserver,cn=computers,dc=bpisys-tx,dc=com

It does exist in the Directory. How does this factor into the authentication process and is there a passcode - perhaps /etc/master.secret?

jkonrad · March 8, 2018, 1:03pm

Hello texas-aggie,

there is a problem with the LDAP Port.
You have to edit a file in the bluespice docker image.

Login into ucs over ssh
login into docker container over univention-app shell bluespice
active full shell support with export TERM=xterm
nano /var/www/html/bluespice/settings.d/060-LDAPUnivention.php

and add this line at the end:

$wgLDAPPort = array( getenv('LDAP_MASTER') => 7389);

i hope this helps

we will release an update soon

texas-aggie · March 13, 2018, 9:49pm

Thank you! I’ll install, test, and update my experience. Looks like it was just missing the secure port stanza.

onomant · April 26, 2018, 3:26pm

Hello,

i have the same issue here, tried to ping -like described- works.
The port-line was already set in the config file.

The behavior is the same (logs…) like described above.
All versions (UCS+Bluespice) are latest.

I checked the IPs in LDAP-DC… this fits.

Are there any other workarounds?

Thanks and greetings

texas-aggie · April 26, 2018, 6:56pm

You didn’t mention if you’re running 4.2 or 4.3.

I actually removed Bluespice prior to the upgrade to 4.3.x. After the upgrade to 4.3.x, I installed Bluespice. It’s working with the latest build and UCS 4.3.x.

onomant · April 26, 2018, 10:48pm

Hi,

it was before installation and still is:
UCS-Version
4.3-0 errata21 (Neustadt)
UMC-Version
10.0.5-1A~4.3.0.201804181755

And for Bluespice its version 2.27.2-ucs.3

jkonrad · April 30, 2018, 1:05pm

Hi onomant,

can you contact me by email or phone (both on our website hallowelt.com), please?

best regards,
Josef Konrad

chrissi · July 8, 2018, 12:21pm

Hi all,

here the same error as scripted above. All previous checks are successful, but no login.

UCS 4.3-1errata145
BlueSpice 2.27.2-ucs.3

Any ideas?

Thanks for help in advance.

jkonrad · July 10, 2018, 8:28am

Hi Chrissi,

can you check the file /etc/machine.secret for everyone can read?
If not, please change file mode to 644.

best regards,
Josef Konrad

hpz · July 11, 2018, 2:57pm

Hi,
i had the same problem and the file had the wrong permissions.
Changing /etc/machine.secret to 644 solves the problem!

thanks!

gulden · July 12, 2018, 9:49am

Hello,

which /etc/machine.secret do you refer to? There is one on the UCS system and one inside the BlueSpice container. I assume, you refer to the one in the container, right?

Best regards,
Nico

hpz · July 12, 2018, 1:53pm

yes, the file in the blue spice container had the wrong permissions.