LDAP Authentication Fails with Error 531 Despite Successful LDAPS Connectivity and User Discovery (CloudStack 4.22.1.0)

[anirudh09041]

LDAP Authentication Fails with Error 531 Despite Successful LDAPS Connectivity and User Discovery (CloudStack 4.22.1.0)

Environment

• Apache CloudStack Version: 4.22.1.0

• Deployment: Three Management Servers in HA configuration

• LDAP Provider: Microsoft Active Directory

• Protocol: LDAPS

• LDAP Port: 636

Active Directory Configuration

• Domain: corp.a10networks.com

• Base DN: DC=corp,DC=a10networks,DC=com

• Domain Controller: SJ-SV2-DC2.corp.a10networks.com

• Bind Principal: cloudstack-ldap@corp.a10networks.com

• Username Attribute: sAMAccountName

• First Name Attribute: givenname

• Last Name Attribute: sn

• Email Attribute: mail

• LDAP Provider: microsoftad

The LDAP server has been added through the CloudStack UI with the following details:

• Host: SJ-SV2-DC2.corp.a10networks.com

• Port: 636

LDAP Truststore Configuration

The CA certificate was imported into a Java JKS truststore.

Truststore location:

/etc/cloudstack/management/cloudstack-ldap-truststore.jks

CA certificate location:

/etc/cloudstack/management/cloudstack-root-ca.crt

The truststore was distributed across all three management servers.

• Truststore type: JKS

• Alias: corp-sj-dc01-ca

• Ownership: root:cloud

• Permissions: 640

The truststore is readable by the CloudStack service user on all three management servers.

LDAP Global Settings

The following settings have been configured:

Setting | Value -- | -- ldap.basedn | DC=corp,DC=a10networks,DC=com ldap.bind.principal | cloudstack-ldap@corp.a10networks.com ldap.provider | microsoftad ldap.username.attribute | sAMAccountName ldap.firstname.attribute | givenname ldap.lastname.attribute | sn ldap.email.attribute | mail ldap.user.object | user ldap.group.object | groupOfUniqueNames ldap.group.user.uniquemember | member ldap.user.memberof.attribute | memberOf ldap.read.timeout | 100000 ldap.request.page.size | 1000 ldap.search.group.principle | CN=cloudstack-users,OU=Security-Group,OU=Groups,OU=US-HQ,DC=corp,DC=a10networks,DC=com ldap.truststore | /etc/cloudstack/management/cloudstack-ldap-truststore.jks

The LDAP truststore password and bind password have been configured but are intentionally not included here.

Tests Performed

1. LDAPS Connectivity and Certificate Validation

Successfully connected to the Domain Controller using:

SJ-SV2-DC2.corp.a10networks.com:636

Certificate validation using the CA certificate was successful.

2. LDAP Bind Using the Service Account

Successfully authenticated using:

cloudstack-ldap@corp.a10networks.com

3. LDAP User Discovery

A search against the configured base DN successfully returned multiple Active Directory users.

Initially, a group restriction was configured using an AD group that contained only one direct member.

After discussing this with our IT team, a new AD group was created:

CN=cloudstack-users,OU=Security-Group,OU=Groups,OU=US-HQ,DC=corp,DC=a10networks,DC=com

The group was configured in ldap.search.group.principle.

CloudStack now successfully discovers two users through the Add LDAP Account interface:

• akaushal

• tdhake

4. Independent Authentication Test Using My AD Account

I also tested LDAP authentication independently using my own AD credentials:

ldapsearch -LLL -x \
  -H ldaps://SJ-SV2-DC2.corp.a10networks.com:636 \
  -o TLS_CACERT=/etc/cloudstack/management/cloudstack-root-ca.crt \
  -D 'akaushal@corp.a10networks.com' \
  -W \
  -b 'DC=corp,DC=a10networks,DC=com' \
  '(&(objectCategory=person)(objectClass=user)(sAMAccountName=akaushal))' \
  dn sAMAccountName userPrincipalName

This command completed successfully and returned:

dn: CN=Anirudh Kaushal,OU=Users,OU=IND,DC=corp,DC=a10networks,DC=com
sAMAccountName: akaushal
userPrincipalName: akaushal@a10networks.com

This confirms that the supplied AD credentials are accepted by the Domain Controller and that the user can be searched successfully.

Current Issue

Despite successful LDAP connectivity, service-account binding, user discovery and independent authentication testing, I am unable to log in to CloudStack using my AD credentials.

I have attempted login using both:

• akaushal

• akaushal@a10networks.com

The UI returns:

Error 531: Failed to authenticate user akaushal in domain 1;

please provide valid credentials.

The LDAP user has also been added/discovered through the Add LDAP Account interface.

The CloudStack domain selected for login is ROOT (domain ID 1).

Questions for the Community

1. Is there any additional configuration required for Microsoft Active Directory authentication in CloudStack 4.22.1.0, beyond configuring the LDAP server, bind principal, base DN and truststore?

2. Does CloudStack expect the LDAP username to be supplied as sAMAccountName, userPrincipalName, or another format during authentication?

3. Is there any additional mapping or configuration required between an LDAP-discovered user and a CloudStack account to enable authentication?

4. Could the ldap.group.object setting (groupOfUniqueNames) cause authentication issues with Microsoft Active Directory, even though user discovery works?

5. Are there any known issues in CloudStack 4.22.1.0 that could cause Error 531 when LDAP connectivity and user discovery are successful?

I would appreciate any guidance on which component or configuration I should investigate next.

Thank you.

[anirudh09041]

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.