mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Change LDAP External Authentication ID from distinguishedName to objectGUID #500
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jk-95 on GitHub (Nov 14, 2017).
Originally assigned to: @ssddanbrown on GitHub.
For Bug Reports
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 user@domain.com 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 user@domain.com 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 commented on GitHub (Nov 19, 2017):
Hi @JamesKetley, Thanks for reporting this issue.
BookStack will try to use a
uidLDAP attribute and will fall back to usingdnif auidis 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
uidattribute and, if not, what the alternative would be.@timconner commented on GitHub (Mar 4, 2018):
@ssddanbrown The best attribute for Active Directory would be
objectGUIDas 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 commented on GitHub (Jun 26, 2018):
@ssddanbrown Unfortunately AD does not populate the
uidattribute and does not supportentryUUIDeither. 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
objectGUIDafteruidand beforedistinguishedNamewould work.@FMCUSystemAdmins commented on GitHub (Jun 20, 2019):
Inadvertently experienced this, can confirm same behavior and fix. Agree with using of objectGUID attribute instead of DN.
@ssddanbrown commented on GitHub (Aug 27, 2019):
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
objectGUIDset 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 commented on GitHub (Dec 16, 2019):
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:
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_idcolumn of theuserstable that you'd need to change.@joaomezzari commented on GitHub (Dec 23, 2019):
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 commented on GitHub (Dec 23, 2019):
@joaomezzari If you're referring to existing users that already have a DN as their
external_auth_idvalue, 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 commented on GitHub (Dec 23, 2019):
@ssddanbrown Yes, that's the behaviour if the email field in AD is not populated. Thanks for the feedback.
@joaomezzari commented on GitHub (Feb 4, 2020):
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 commented on GitHub (Feb 5, 2020):
Did you try to set the
SAML2_DUMP_USER_DETAILS=trueto 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 commented on GitHub (Feb 5, 2020):
@finnwessel That option is only for SAML, not for LDAP.
@ssddanbrown commented on GitHub (Feb 5, 2020):
@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 commented on GitHub (Feb 5, 2020):
@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 commented on GitHub (Feb 5, 2020):
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.