Bluespice MediaWiki LDAP connection fails

Apps & App Center
#1

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.

#2

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.

#3

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?

#4

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

#5

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.

#6

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?

#7

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?

1 Like
#8

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

#9

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?

#10

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

#11

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

#12

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

#13

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.

#14

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

#15

Hi onomant,

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

best regards,
Josef Konrad

#16

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.

#17

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

#18

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

thanks!

#19

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

#20

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

Mastodon