Windows Target Accounts are getting locked out upon on-boarding them to CA PAM.
What is the reason and how to avoid this issue?
Why are there 2 unsuccessful login attempts before a successful password change?
Release : 3.4.x, 4.0.x, 4.1.x
Component : PRIVILEGED ACCESS MANAGEMENT
The following can be confirmed:
- PAM, Active Directory Target Connector, Win2019 AD
- onboard a new AD User in PAM (username)
- specify "Use the following account to change password" pointing to an already synchronized Master Account (Administrator, Domain Administrator of the same AD)
- configure "Update both the Credential Manager Server and the target system"
- create a new random password using the key-ring in PAM
- upon OK observe the following in the catalina.out
...
INFO: Verifying credentials for account with username 'username'
...
Apr 21, 2020 4:33:35 AM com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager loginToActiveDirectoryServer
INFO: Failed authentication to Active Directory using distinguished name 'CN=username,CN=Users,DC=domain,DC=com' for account 'username' due to error '[LDAP: error code 49 - 80090308: LdapErr: DSID-0C09041C, comment: AcceptSecurityContext error, data 775, v4563]'
...
Apr 21, 2020 4:33:35 AM com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager bindUsingUserPrincipalName
INFO: Failed authentication to Active Directory using user principal name '[email protected]' due to error '[LDAP: error code 49 - 80090308: LdapErr: DSID-0C09041C, comment: AcceptSecurityContext error, data 775, v4563]'
...
INFO: Updating credentials for account with username 'username'
...
INFO: Derived the Distinguished Name (DN) 'CN=Administrator,CN=Users,DC=domain,DC=com' from the Target Account having ID '1004'
...
INFO: Successfully authenticated to Active Directory and set the last known good host to '192.0.2.2'
...
I.e.
FIRST PAM attempts to verify the specified credentials for the account, BEFORE Updating the credentials for the account using the master account.
The first attempt fails using the DN, then it retries the operation using the UPN of the user.
Since there are TWO failed logins, the user account lockout policy needs to be adjusted accordingly to not lock the user.
(i.e. in this particular scenario it would need to be >=3 )
You can avoid this issue by setting the correct current password of the new on-boarded target account in the first place while defining the Target Account in PAM.
Try to avoid "User must change password at next login" in the Windows if there is no privileged Master Account configured which is capable of changing the password accordingly.
Also make sure that your Master account in Active Directory has been delegated
"Create, Delete, Manage User Accounts"
privileges accordingly, should it not belong to the Domain Admins group anyway.