Infos:
- Used Zammad version: 6.5.2-1763644373.1734c7f9.centos8
- Used Zammad installation type: I’m not sure
- Operating system: Windows 11 Pro
- Browser + version: Chrome
Expected behavior:
- My admin account stays active.
Actual behavior:
- For some reason my Zammad admin account keeps disabling itself. We sign in via Microsoft. We think that there might be some sort of sync that is disabling it but are unsure why that would be happening.
Steps to reproduce the behavior:
- I just sign in and start working under my admin account and then in a while it disables it and signs me out. Last time it happened it was enabled for 45 minutes and then was disabled.
Does anyone have any ideas of why this would be happening?
If I would have to guess:
You have the LDAP integration activated with role mappings. Your admin account is not showing up in the search result. You most likely do not assign signup roles to those that don’t appear in the search.
We are not using LDAP Role mapping. It’s something we would like to implement in future.
Our LDAP user filter is also pretty generic: “(objectClass=user)(samaccountname=)(!(samaccountname=$)))”
The admin account is in an OU with other accounts that do not display this behaviour. I checked and our BIND user does have read permissions on this account.
It’s pretty weird.
Is there any way we can use ‘httplog.where’ to search the ldap logs and see if that gives us a hint? I’m not familiar enough with the usage.
Looking over my account settings again I realized that Zammad was pointing to an AD location that my admin account used to be in. Once I changed that to the current AD location it stopped disabling the account.
Okay, I finally spotted our issue. Our baseDN does not include the ‘Admin’ OU. I tried to create a second LDAP source and have hit an issue. It seems you can no longer manually change the baseDN. You’re stuck to a short list of pre-configured values. Is this by design?