We have two user directories (Active Directory 2012 r2) where expired password is not captured by siteminder. When user types in correct password active directory logs does not show any calls to AD. When I set pwdLastSet to 0 at that point of time password expiration gets caught and user is properly redirected.
Enhance AD integration is active. Two other active directories are working fine.
12.52 sp1 cr1
Has anybody come across this issue?
In order for Siteminder to force password change, it needs to check what is the last time that password has been changed and compare to the password policy that configured.
pwdLastSet is AD attribute (https://msdn.microsoft.com/en-us/library/ms679430(v=vs.85).aspx) and Siteminder didn't make use of that attribute.
In your user directory configuration, what is the user attribute that you configured for Password Data? Siteminder make use of data (encrypted) in this attribute to compare the password expire.
Do you have Siteminder password policy configured?
The "Enhanced Active Directory Integration" feature allows the LDAP Namespace on a User Directory to be able to read Active Directory specific attributes which are not commonly accepted in the LDAP spec. These values can be read natively by the AD Namespace.
The 'userAccountControl' and "ms-DS-User-Account-Control-Computed" attributes are read from the user object in the user store during authentication. These attributes would have used a value of (8388608) in the attribute along with whatever other settings (e.g. Normal Account), to designate an expired password.
Siteminder should be managing the account expiration in the Password Data field as well. A user disabled in Siteminder is not disabled in AD. However a person disable in AD should respected and Siteminder should prevent that user from logging on. In this case, Siteminder should honor the user status from 'userAccountControl'.
Active Directory 2008 has several user and domain attributes that are specific to the Windows network operating system (NOS). The LDAP standard does not require these user and domain attributes. If Password Services is enabled, enable Enhanced Active Directory Integration using the Administrative UI. This option improves the integration between the user management feature of the Policy Server and Password Services with AD by synchronizing AD user attributes with CA SiteMinder® mapped user attributes.
Thanks Chris and Kar. It looks like we have hit the known limitations under enhanced active directory integration.
The non working user directory has it's root configured as an OU (e.g. OU=***,DC=***,DC=***), working user directory is configured as DC=***,DC=***. It looks like since pwdMaxAge and some other properties are properties of default DN they are not available at OU level and SM fails read them and then fails to redirect user for expired password. As soon as I changed non-working directory to default DN pwd expired redirection started working. Eventually I found following line in Admin guide
Here is a line: In the Root field, enter the default Windows domain’s DN as the user directory root. For example:dc=WindowsDomain,dc=comNote: If the Root field is set to another value, AD-specific features may not work.
I swear I saw more information somewhere yesterday night but can't seem to find it today.
I am wondering if I can modify schema at OU level and manually set pwdMaxAge will SM be able to read this.
Also BTW setting password policy-password max age to 90 days has no effect. Pwd policy seem to play no role in redirection based on expired password.