Account Policy Plugin combined with user policy and "passwordexp: off" impossible?

[Eugen Lamers]

We have the following scenario: 
We use a "global" password policy at cn=config where a customer of ours defines:

passwordexp: on
passwordmaxage:  7776000
passwordwarning: 7344000

We provide as default configuration "passwordMustChage: on" to force a new user to chage the initial password. In this setup a user whose password expired, i.e. also after this user is created and needs to change its initial password, cannot login to the account, but he can change the password.

The customer now wants a setup which prevents a user whose password expired from changing the password. A plugin "Account Policy Plugin" can therefore be activated by the customer, which uses the following configuration:

dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: yes
stateAttrName: non_existent_attribute
altStateAttrName: passwordExpirationTime
specattrname: acctPolicySubentry
limitattrname: accountInactivityLimit

As a consequence, the initial password change does not work anymore, thus the customer must change to "passwordMustChange: off". This would probably be acceptable.

A problem is, however, that a user account which has its own user password policy with "passwordexp: off" and "passwordmustchange: off" is affected by the plugin in such a way that the attribute passwordExpirationTime of the user itself is evaluated and the attribute passwordexp of the user password policy is ignored. That means, a user password policy for special user accounts without password expiration cannot be used in combination with the Account Policy Plugin. 
Can the plugin be configured to enable this possiblity or is there another way to achieve the desired behaviour?

[Simon Pichugin]

Hi Eugen,
if I understood correctly, the customer already has Password Policy set up
for common users which should not be able to change the password after the
expiration.

And the customer needs another policy for the special users which should be
able to change the password after expiration (or the expiration should be
disabled for them completely).

For that, the customer can configure Local Password Policy for the
particular subtree/user.
Please, check the section 20.4.2 here:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

Hope that helps,
Simon

On Wed, Sep 16, 2020 at 2:09 PM Eugen Lamers 
wrote:
> We have the following scenario:
> We use a "global" password policy at cn=config where a customer of ours
> defines:
>
> passwordexp: on
> passwordmaxage:  7776000
> passwordwarning: 7344000
>
> We provide as default configuration "passwordMustChage: on" to force a new
> user to chage the initial password. In this setup a user whose password
> expired, i.e. also after this user is created and needs to change its
> initial password, cannot login to the account, but he can change the
> password.
>
> The customer now wants a setup which prevents a user whose password
> expired from changing the password. A plugin "Account Policy Plugin" can
> therefore be activated by the customer, which uses the following
> configuration:
>
> dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: config
> alwaysrecordlogin: yes
> stateAttrName: non_existent_attribute
> altStateAttrName: passwordExpirationTime
> specattrname: acctPolicySubentry
> limitattrname: accountInactivityLimit
>
> As a consequence, the initial password change does not work anymore, thus
> the customer must change to "passwordMustChange: off". This would probably
> be acceptable.
>
> A problem is, however, that a user account which has its own user password
> policy with "passwordexp: off" and "passwordmustchange: off" is affected by
> the plugin in such a way that the attribute passwordExpirationTime of the
> user itself is evaluated and the attribute passwordexp of the user password
> policy is ignored. That means, a user password policy for special user
> accounts without password expiration cannot be used in combination with the
> Account Policy Plugin.
> Can the plugin be configured to enable this possiblity or is there another
> way to achieve the desired behaviour?
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]....

[Eugen Lamers]

Hi Simon,

thanx for your help. But it is rather the other way round: The customer already has the policy for special users that must not be forced to change the password. In addition, the customer now wants "normal" users to be completely locked out when the password has expired, only administrators may then be able to change the user's password and enable the user's login.

Eugen

[Simon Pichugin]

Hi Eugen,
okay, another option will be to define Local Account Policy for the users
you want to be locked after the expiration.

Check out this setup for Local Account Policy (CoS configuration):
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

And then, use the settings from this chapter to disable the user account
after the expiration:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

Sincerely,
Simon

On Thu, Sep 17, 2020 at 8:17 AM Eugen Lamers 
wrote:
> Hi Simon,
>
> thanx for your help. But it is rather the other way round: The customer
> already has the policy for special users that must not be forced to change
> the password. In addition, the customer now wants "normal" users to be
> completely locked out when the password has expired, only administrators
> may then be able to change the user's password and enable the user's login.
>
> Eugen
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]....

[Eugen Lamers]

Hi Simon,
does that mean that it is impossible to achieve the goal with the Account Policy Plugin or some other plugin? It could be that the plugin indeed is designed to achieve it but it could not because of bugs, or it simply is not designed to do this.
Your idea means to go the other way round. We have to check if that way which requires a higher configuration effort is acceptable. 
Thanks,
Eugen