GitHub user anirudh09041 added a comment to the discussion: LDAP Authentication Fails with Error 531 Despite Successful LDAPS Connectivity and User Discovery (CloudStack 4.22.1.0)
Resolved. The issue wasn’t LDAPS, the bind, or the truststore. The AD user had never been imported into CloudStack. Root cause: The users were only discovered in the Add LDAP Account wizard, so no CloudStack account/user existed. For a domain that isn’t linked to an LDAP group/OU, the LDAP authenticator only authenticates users that already exist in CloudStack with source LDAP. Otherwise it fails, and the UI shows the generic Error 531. Why the import failed at first: The wizard’s LDAP Group field was pre-filled. When that field is non-empty, the UI calls importLdapUsers with the group and ignores the users selected in the table. That call hung. After clearing the field, the UI called ldapCreateAccount for the selected user instead. Fix: Clear the LDAP Group field in Add LDAP Account. Select the user, choose the domain and role, and click Add. Log in with the sAMAccountName only (akaushal, not the UPN). Notes: The UI showed a 504 from the reverse proxy in front of the management servers, but the account was created server-side. Verify in cloud.user (source = LDAP) before retrying. Login now takes about 5 seconds. ldap.group.object=groupOfUniqueNames is OpenLDAP-style. For AD it should be group if you use group-based import. Thanks to everyone who looked at this. I left out the cause of the slow import call because we didn’t pin it down. If you find it later, add one line about it. GitHub link: https://github.com/apache/cloudstack/discussions/14577#discussioncomment-19391376 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
