Users with Expired Password can't Change their Password

[Marco Trucillo]

Hi, 

I have siteminder 12.8sp2.  I use an Active Directory (w2K12) as UserStore.  Active Directory has a password policy for expired password.
When passowrd expire in Active Directory the user  is redirected to  smpwservices.fcc with smauthreason = 19 and get a message that say that password is expired and must contact the administrator.

If I manually set for the user pwdLastSet attribute to 0 instead the user  is redirected to  smpwservices.fcc with smauthreason = 20 and get a form to change password.

I tried to set password policy even in siteminder (Disable user option it is not set and force password change option is set) but the behavior is the same. When user has password expired it will be redirected to  smpwservices.fcc with smauthreason = 19.
I tried also to use IAM password service but the result is the same.

In my your user directory configuration, I use a custom attribute for password Password Data. But the behavior is the same even if I delete this mapping. 

It seems that siteminder does not allow changing passwords when they expire in active directory.

1 what do you think ?

2 Where am I doing wrong ?

3 Is there a way to trigger password changes for expired passwords?

Thanks in advance
Marco 

[Uzi Cohen]

Hi Marco,
Do you have Enhanced Active Directory Integration (in policy-server-global-settings) enabled?

[Marco Trucillo]

Hi
Thanks for your answers

I read from documentation to enable Enhanced Active Directory Integration:

• Create the IgnoreADpwdLastSet registry key.

• Enable Enhanced Active Directory integration for the Policy Server.

I do not have IgnoreADpwdLastSet  in my sm.registry (my policy server is on linux)
I have checked  [X] Enable Enhanced Active Directory integration  in policy server from AdminUI

Thanks in advance
Marco

[Uzi Cohen]

I don't believe that you need to set the IgnoreADpwdLastSet parameter.
This parameter should be set only in the following conditions:

• The current Active Directory does not include the pwdLastSet attribute.
• Policy Server must not set the pwdLastSet attribute when the Force Password Change field is set in a user account.

Thanks,
Uzi

[Marco Trucillo]

Yes. I think you are right. 
But I don't know why with siteminder password service, user that have expired password (in active directory) can't change thery password.
In active directory the user *is not* disabled and is able to change his password when try to login to a windows workstation.
For those user with expired password if I try to set pwdLastSet attribute to 0  they can change password at first access to siteminder protected resource.

I tried to use also CA Identity Manager password service but the behavior is the same.  

[Uzi Cohen]

I'll need more information to help troubleshoot the issue...

- Are you saying that it fails to update the user's password even when the Enhanced AD integration is enabled? (did you restart the PS after changing this setting)
- Notice that because in some cases Policy Server will try to set additional AD attributes (like PwdLastSet), the user directory admin user needs to be a user with sufficient permissions to modify the user's info. Is the admin user dn you've specified in the user directory definition has enough permission?
- Are you using ldap over TLS/SSL (port 636)?
- Can you send the ps trace to see what happens there? (you will need to enable the LDAP and Directory Access trace components the data field and XPSConfig --> xTrace --> ds - https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/administrating/policy-server-tools/how-to-use-xtrace)

Uzi

[Marco Trucillo]

>I'll need more information to help troubleshoot the issue...
Thanks For your Support
>- Are you saying that it fails to update the user's password even when
>the Enhanced AD integration is enabled? (did you restart the
>PS after changing this setting)
Yes!

> Notice that because in some cases Policy Server will try to set additional AD attributes (like PwdLastSet),
>the user directory admin user needs to be a user >with sufficient permissions to modify the user's info. Is the admin
>user dn you've specified in the user directory definition has enough permission?

the user is memberOf AccountOperator. 

> Are you using ldap over TLS/SSL (port 636)?
Yes

>- Can you send the ps trace to see what happens there? [...]
OK. I will try that. But I have to wait for someone to expire the password. It is not possible to simulate it.

Many Thanks

Marco

[Patrick Dussault]

Hi Marco,

Just side note in that thread :

You mentioned :

"Is there a way to trigger password changes for expired passwords"

SiteMinder handles the status on the account state, not on the password
state. You added :

"When user has password expired it will be redirected to
smpwservices.fcc with smauthreason = 19. I tried also to use IAM
password service but the result is the same."

The account status should be set with a value that will triggered the
desired behavior and there are some limitation. In order to have full
control on the behavior, you should configure SiteMinder and Active
Directory in order to have only active policies about password and
account status managed by Siteminder.

ref.:

Policy Server :: Active Directory : Password Policies
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=48927

Further reading on the topic :

Integrating SSO with Microsoft Active directory
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=98912

I hope this helps,

Best Regards,
Patrick

[Marco Trucillo]

Hi Patrick,

>SiteMinder handles the status on the account state,
>not on the password state. You added :
OK

>The account status should be set with a value that will triggered the
>desired behavior and there are some limitation. In order to have full
>control on the behavior, you should configure SiteMinder and Active
>Directory in order to have only active policies about password and
>account status managed by Siteminder.

Ok. It is clear what you say. The fact is that I don't know * who * sets the "account status". Under windows the user who experiences this behavior has only the password expired. But the account is active. So much so that from windows can change the password expired by itself. So I think the account status is already being managed by siteminder. Where does siteminder take the information to give smauthreason = 19?

Thanks also for the references to the documentation! :) 

today I will do other tests

Thanks

Marco