Hide Forgot
Created attachment 1141366 [details] Log from failed login Description of problem: Login after configuring aaa-ldap fails for one user but works for another. How reproducible: Always Steps to Reproduce: 1. Try to login with user Actual results: Login fails with "General command validation failure." Expected results: Successful login.
Created attachment 1141367 [details] Log from successful login
Login for the failing user works fine using the old example.local profile, for both user portal and admin portal, but for neither using example.local-new. Login for the working user works fine using both profiles and both portals.
Can you please also share your properties files? Also, can you please run following commands: $ ldapsearch -x -H ldap://example.local -D marcuss.admin -W -b DC=example,DC=local "(samAccountName=marcuss)" userPrincipalName $ ldapsearch -x -H ldap://example.local -D marcuss.admin -W -b DC=example,DC=local "(samAccountName=marcuss.admin)" userPrincipalName Most probably your issue is that marcus is using different domain suffix then user marcuss.admin. So you should use UPN to login properly with both users.
Thanks! And sorry for wasting your time! It was indeed the case that marcuss has an UPN of marcuss due to the user having a mailbox, but users without a mailbox like the marcuss.admin user have an UPN of <user>@example.local. When using marcuss as user name login works fine.
Hmm, on the other hand I don't see why the extension can't match the entered user name against the uid and/or SAMAccountName attributes? That worked fine using the old pre-3.5 LDAP authentication.
Yes, that worked with legacy manage-domains, but it doesn't work with aaa-ldap, because SAMAccountName supports max. 15 characters, so it was decided to use UPN usernames only, so we can support longer usernames.
Using UPN usernames is the only correct and standardized solution to support long usernames