Solved Lessons learned - switching LDAP server - changed UID

[luckow]

I've started with some users created wiki pages in bookstack. Yesterday I've switched to an external LDAP server, deleted the Cloudron LDAP users and added them with the exact same username to the external LDAP server. Most of the installed apps had no problem with the "new" user from the external LDAP server and served the content created from the "old" Cloudron LDAP user to the new external LDAP user. But not bookstack.
Bockstack uses a UID as an identifier for the user.

Because of switching to a new LDAP server, the uid for the user switched. But because the username was the same, bookstack denied the new user (reason: same user with a different uid). Instead of reading the manual at https://www.bookstackapp.com/docs/admin/ldap-auth/ I've deleted the "old" user in bookstack and "created" a new one through a login to bookstack with the "new/old" username. Haha.The uid changed and all my former created content does not more belong to me. (Now it's labeled as: Deleted User updated page).

The correct workflow has to be:

• get the new uid from the "new/old" username
• add the new uid to the user account in bookstack
• every created content belongs to the "new" user

The only question is: how to get the uid from the "new" user?
The only place I know of is the UID form in Bookstack. But that is for the workflow the wrong place

Any hints where to find that kind of information?

[girish]

@fbartels Ah nice, I wasn't aware of LDAP_ID_ATTRIBUTE=uid . Looks like this was recent, I will fix the package to use username instead of uid.

On a side note, we have migrated all the Cloudron packages to use username as the LDAP id attribute instead of the usual uid. This was done because the common case (for Cloudron) is to move an app between Cloudrons and it's easier to export/import when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

[fbartels]

Hi @luckow,

I don't know bookstack, but my guess would be that the uid is defined/retrieved in:

# Set the property to use as a unique identifier for this user.
# Stored and used to match LDAP users with existing BookStack users.
# Prefixing the value with 'BIN;' will assume the LDAP service provides the attribute value as
# binary data and BookStack will convert the value to a hexidecimal representation.
# Defaults to 'uid'.
LDAP_ID_ATTRIBUTE=uid

Your chances are probably:

• get a shell in an ldap enabled app and get the uid values for your users and add a new attribute to your external ldap which holds this value (which means manual maintenance for other users since you need to create this value as well)
• see if you can update the database of bookstack to use the new uid instead of the old one per user.

@luckow said in Lessons learned - switching LDAP server - changed UID:

switched to an external LDAP server, deleted the Cloudron LDAP users

better would probably have been to use the external ldap feature of Cloudron. Afaik it would not update existing users, but then at least all new users in Cloudron be retrieved from the external ldap.

[girish]

@fbartels Ah nice, I wasn't aware of LDAP_ID_ATTRIBUTE=uid . Looks like this was recent, I will fix the package to use username instead of uid.

On a side note, we have migrated all the Cloudron packages to use username as the LDAP id attribute instead of the usual uid. This was done because the common case (for Cloudron) is to move an app between Cloudrons and it's easier to export/import when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

[fbartels]

@girish said in Lessons learned - switching LDAP server - changed UID:

when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

While using the username as a unique attribute has its upsides, it has also it's downsides. Generally what is exposed to the user (name, email, username) has the potential to change over time.

[girish]

@fbartels said in Lessons learned - switching LDAP server - changed UID:

While using the username as a unique attribute has its upsides, it has also it's downsides. Generally what is exposed to the user (name, email, username) has the potential to change over time.

Agreed. It's the main reason why we don't allow usernames to be changed on Cloudron. That said, we have hardly had people request usernames be changed. Usually, such things are never done in a corporate environment anyways. Existing email ids and user ids are maybe deactivated but not renamed.

edit: email on cloudron can be changed just not the username.

[fbartels]

@girish ah. I've never noticed that you cannot change the username on cloudron. This is a good enough countermeasure

[luckow]

Thank's for releasing an updated version of bookstack. Will try it out next week.

[luckow]

BTW: kind of same behaviour for nextcloud.
There is a UID in the user settings, which you can only see with /app/code/occ user:setting in the terminal.

And because I switched from internal Cloudron LDAP to an external LDAP I got a new UID for all my users. The strange behavior from nextcloud is:
Login with user:pass works. (the schema is firstname.lastname as username).
But internally nextcloud adds a _RANDOMNUMBER to it.
In my case a stephan.luckow is internally changed to stephan.luckow_3096

Problem is: all my calendar entries are based on stephan.luckow_3096 and not on stephan.luckow.