We’re currently on track to switch our ticket system to Zammad and are finalising the last bits of configuration. However, there’s also an ongoing project to rebuild our Active Directory which leaves us with the following challenge:
Right now, we have our LDAP integration setup to use SamAccountName as login. This will be changed to use the UserPrincipalName after successful AD migration, however 99% of UPNs will be changed in the process. Due to everything being rebuilt in a completely new AD, object SIDs and GUIDs will also change. As far as I know, this would mean we lose all references to and from users.
I read in the following post, that it is possible to change the Zammad UUID to use something other than the Object GUID (Change LDAP-Integration UID value - #2 by MrGeneration) and was wondering if this solution could work or if there is another way to achieve the same result of not having every user duplicated and refernces being lost.
With the above post in mind my plan would be:
1. Right before AD migration, start a manual LDAP sync
2. Change Zammad UUID from ObjectGUID to object e-mail address (those will stay the same)
3. Manual LDAP sync
4. Complete AD migration
5. Manual LDAP sync
6. Change Zammad UUID from object e-mail adress to ObjectGUID
7. Change login from SamAccountName to UserPrincipalName
8. Manual LDAP sync
After a time of absence I’m back at this issue. I’ve tried getting the ldap settings with the rails command from the linked post but it seems that method is no longer working.
Setting.get(‘ldap_config’) returns => nil
Am I to understand that there’s no longer any possibility to adjust the value zammad uses as UID?
The LDAP Setting isn’t in use for quite a while (since Zammad supports several LDAP Sources to be exact).
Zammad generally can (re)recognize it’s users by the email address.
However, since it started supporting several LDAP sources, it also received some tracking stuff so it knows which user comes from what sources.
I don’t see how changing the UUID to mail address will have any useful impact to be honest.
Anyhow. It should be well enough to
disable LDAP sync of Zammad ( have a local password for your admin account as logging in won’t be possible …)
do whatever is neede dot switch your AD / LDAP
Then go to your rails console and adjust the UUID like so (replace test with the name of your LDAP conneciton…)
l = LdapSource.find_by(name: 'Test')
l.preferences['user_uid']= 'uid'
l.save!
Then restart the LDAP integration.
It should ™ be fine and work just as good as before. Allow the sync to finish and try to login with a user.
Bonus tip on that regard…
If you only habe your personal account which is the admin account, use a different password for the local password than the one from your LDAP so that you can tell that it is working (or not).
I tested the procedure as recommended with another domain but a user pretty much identical to mine, except for objectguid, sid and UPN.
I disabled LDAP sync, adjusted the settings, ran the commands and turned LDAP sync back on. That didn’t do it however, as every user sync failed.
I then disabled the sync again, ran the console commands to return the preferences to their previous state, restared the sync and it just worked. Zammad detected my user, even after the login and background id’s had changed.
For what it’s worth, I consider this matter solved. I’d be interested to know, however, why those commands resulted in the sync failing.
If you provide the production logs error entries that belong to the failing sync, we might have a chance to get into more detail. But with the provided information this will be impossible I am afraid.