Bookstack: Change LDAP External Authentication ID from distinguishedName to objectGUID

[jk-95]

For Bug Reports

• BookStack Version v0.18.5
• PHP Version: 7.0.22-0
• MySQL Version: 14.14

Expected Behavior

To have the ability to change user's External Authentication ID from distinguishedName to objectGUID when using LDAP authentication with Microsoft AD.

Current Behavior

Currently when a user is moved to a different OU in AD their distinguishedName will change and BookStack will throw this error when that user tries to log in A user with the email [email protected] already exists but with different credentials.. The fix is to repoint the user's External Authentication ID from the old distinguishedName to the new one.

If objectGUID was used instead this issue wouldn't occur as the user's objectGUID doesn't change when moving OUs or renaming the account etc.

Steps to Reproduce

Register a user in BookStack using LDAP authentication - note the user's External Authentication ID is their distinguishedName in AD. Move the user to a different OU in AD - their distinguishedName will have changed so they can no longer sign in to BookStack. When they try to sign in they get the following error; A user with the email [email protected] already exists but with different credentials.. The fix is to repoint the user's External Authentication ID from the old distinguishedName to the new one.

[ssddanbrown]

Hi @JamesKetley, Thanks for reporting this issue.

BookStack will try to use a uid LDAP attribute and will fall back to using dn if a uid is not provided. This can be seen here.

I have double checked this behaviour via my OpenLDAP setup. Unfortunately I do not have an AD instance available for me to test against. It would be ideal of someone could check if AD provides a uid attribute and, if not, what the alternative would be.

[timconner]

@ssddanbrown The best attribute for Active Directory would be objectGUID as JamesKetley mentioned. That attribute remains unchanged throughout the lifetime of the account in Active Directory.

A lot of LDAP authentication systems will have a toggle for specifying that the target LDAP is Active Directory which will allow for the subtle differences.

[ellisgeek]

@ssddanbrown Unfortunately AD does not populate the uid attribute and does not support entryUUID either. I agree with @timconner that having a toggle for Active Directory would be the best solution as there are annoying subtle differences like this.

Alternatively checking for objectGUID after uid and before distinguishedName would work.

[FMCUSystemAdmins]

Register a user in BookStack using LDAP authentication - note the user's External Authentication ID is their distinguishedName in AD. Move the user to a different OU in AD - their distinguishedName will have changed so they can no longer sign in to BookStack. When they try to sign in they get the following error; A user with the email [email protected] already exists but with different credentials.. The fix is to repoint the user's External Authentication ID from the old distinguishedName to the new one.

Inadvertently experienced this, can confirm same behavior and fix. Agree with using of objectGUID attribute instead of DN.

[ssddanbrown]

Thanks for the confirmation everyone.

Would probably be best to make this configurable instead of a toggle, so it can adjust for all systems, then we can update the AD sample in the docs to include this with objectGUID set as the option.

Since this should be fairly straightforward, and since it's effected a few people, I've marked this to be part of v0.28.

[ssddanbrown]

This is now in master, to be part of the next feature release (v0.28).
As of that release you'll be able to set the following in your .env file:

LDAP_ID_ATTRIBUTE=objectGUID

Note that changing this parameter could affect existing LDAP logins since the stored ID's will no longer match up. After changing you may want to go through your users and alter the stored "External Authentication Ids". If you have many users it will probably be easiest to do this directly via the database. It's the external_auth_id column of the users table that you'd need to change.

[joaomezzari]

If I just change the parameter and don't change anything else, the users that use the DN as the ID won't be able to login?

[ssddanbrown]

@joaomezzari If you're referring to existing users that already have a DN as their external_auth_id value, then likely yes, They either won't be able to login and be shown an "Email already in use" warning or they may be shown a view to set their email which will end up as a new account. I think that can occur if LDAP is not providing an email address for the user.

[joaomezzari]

@ssddanbrown Yes, that's the behaviour if the email field in AD is not populated. Thanks for the feedback.

[joaomezzari]

Hello,
I changed the parameter in the .env file to LDAP_ID_ATTRIBUTE=objectGUID and changed the user external authentication ID to the matching objectGUID value in AD, but the user can't login to Bookstack. It doesn't throw any error, it just returns to the login page.

New users are created normally using the objectGUID attribute if it's the first login.

[finnwessel]

Did you try to set the SAML2_DUMP_USER_DETAILS=true to see what your IDP returns?
Maybe there is more info in the log file.

Edit:
Thought this was like the problem I had without recognizing its about LDAP...

[ssddanbrown]

@finnwessel That option is only for SAML, not for LDAP.

[ssddanbrown]

@joaomezzari Are those new users, that are created with the objectGUID, able to login again upon the first login? Any formatting differences in their external auth id compared to the one you're manually entering?

[joaomezzari]

@ssddanbrown It seems that it's not possible to login again after the first one. I checked and the external authentication ID is very strange, actually:

Obviously, this is not the objectGUID that this user have in AD.

[ssddanbrown]

Hi @joaomezzari,
That's really odd, I've opened #1872 so I don't lose track of things on this closed issue and so that others can see it if they're experiencing the same thing.

I'll have a think about how this can be debugged and I'l respond on that new issue.