I've been reading the Password Policy section of the Admin Guide. I am currently at this portion of the setup (the default policy is set up)
You can create additional policy objects as needed.
There are two ways password policy can be applied to individual objects:
1. The pwdPolicySubentry in a user's object - If a user's object has a pwdPolicySubEntry attribute specifying the DN of a policy object, then the policy defined by that object is applied.
2. Default password policy - If there is no specific pwdPolicySubentry set for an object, and the password policy module was configured with the DN of a default policy object and if that object exists, then the policy defined in that object is applied.
When trying to add the pwdPolicySubentry attribute, I receive the following: "According to the schema attribute pwdPolicySubentry is not allowed."
First, can someone explain the meaning of #2. The way, that I read that is that if the "pwdPolicySubentry" is not available, and the policy was created.then the policy is applied. Is that correct?
My policy looks like:
dn: cn=default,ou=pwpolicies,dc=example,dc=ldap
objectClass: top
objectClass: organizationalRole
objectClass: pwdPolicy
cn: default
pwdAttribute: 2.5.4.35
pwdAllowUserChange: TRUE
pwdExpireWarning: 14
pwdLockout: TRUE
pwdLockoutDuration: 300
pwdMaxAge: 15552000
pwdMaxFailure: 5
pwdFailureCountInterval: 0
pwdMinAge: 1
pwdMinLength: 9
pwdMustChange: TRUE
Thanks in advance.
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Humanitarian Assistance and Disaster Relief (HADR) Systems
244 Wood St
Lexington, MA 02420
Email: mailto:john.borresen@ll.mit.edu john.borresen@ll.mit.edu
Borresen, John - 0444 - MITLL wrote:
When trying to add the pwdPolicySubentry attribute, I receive the following: "According to the schema attribute pwdPolicySubentry is not allowed."
It works for me.
Which component does produce this error message? Which OpenLDAP version are you using? Did you add the ppolicy schema? Did you active slapo-ppolicy in the database (section)?
First, can someone explain the meaning of #2. The way, that I read that is that if the "pwdPolicySubentry" is not available, and the policy was created.then the policy is applied. Is that correct?
Yes, the policy in the pwdPolicy entry referenced by ppolicy_default is applied if you don't specify a specific pwdPolicy entry in attribute 'pwdPolicySubentry'.
Ciao, Michael.
Thanks Michael;
I am using OpenLDAP v 2.4.43 Yes, the policy schema is loaded Yes, the overlay is active in the olcDatabase={1}bdb # {0}ppolicy, {1}bdb, config dn: olcOverlay={0}ppolicy,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=default,ou=pwpolicies,dc=example,dc=ldap olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE
John D. Borresen (Dave) Ph: (781) 981-1609 Email: john.borresen@ll.mit.edu
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Thursday, December 17, 2015 11:46 AM To: Borresen, John - 0444 - MITLL; openldap-technical Subject: Re: Attribute pwdPolicySubentry
Borresen, John - 0444 - MITLL wrote:
When trying to add the pwdPolicySubentry attribute, I receive the
following:
"According to the schema attribute pwdPolicySubentry is not allowed."
It works for me.
Which component does produce this error message? Which OpenLDAP version are you using? Did you add the ppolicy schema? Did you active slapo-ppolicy in the database (section)?
First, can someone explain the meaning of #2. The way, that I read that
is
that if the "pwdPolicySubentry" is not available, and the policy was created.then the policy is applied. Is that correct?
Yes, the policy in the pwdPolicy entry referenced by ppolicy_default is applied if you don't specify a specific pwdPolicy entry in attribute 'pwdPolicySubentry'.
Ciao, Michael.
Btw, I am seeing that error, when attempting to add the attribute "pwdPolicySubentry" to a specific user.
John D. Borresen (Dave) Ph: (781) 981-1609 Email: john.borresen@ll.mit.edu
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Thursday, December 17, 2015 11:46 AM To: Borresen, John - 0444 - MITLL; openldap-technical Subject: Re: Attribute pwdPolicySubentry
Borresen, John - 0444 - MITLL wrote:
When trying to add the pwdPolicySubentry attribute, I receive the
following:
"According to the schema attribute pwdPolicySubentry is not allowed."
It works for me.
Which component does produce this error message? Which OpenLDAP version are you using? Did you add the ppolicy schema? Did you active slapo-ppolicy in the database (section)?
First, can someone explain the meaning of #2. The way, that I read that
is
that if the "pwdPolicySubentry" is not available, and the policy was created.then the policy is applied. Is that correct?
Yes, the policy in the pwdPolicy entry referenced by ppolicy_default is applied if you don't specify a specific pwdPolicy entry in attribute 'pwdPolicySubentry'.
Ciao, Michael.
Borresen, John - 0444 - MITLL wrote:
Btw, I am seeing that error, when attempting to add the attribute "pwdPolicySubentry" to a specific user.
With which client are you trying this? Could you try to reproduce with ldapmodify command-line and post *exactly* what you're doing?
As said: It works for me.
Without having further details it's hard to tell what's wrong in your installation.
Ciao, Michael.
El 17/12/15 a las 19:19, Borresen, John - 0444 - MITLL escribió:
Btw, I am seeing that error, when attempting to add the attribute "pwdPolicySubentry" to a specific user.
I had this same problem when I make changes to this attribute with client Apache Directory Studio. Anyway, that change is done, so I didn't care about it.
I haven't tried to make it directly with ldapmodify.
Interesting! I was able to add it via command-line with ldapadd. But, when viewing it in Apache Directory Studio, it still didn't show up -- that is until I enabled Operational Attributes.
But...it appears to have been loaded for one user. Good!
Thanks
John D. Borresen (Dave)
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Angel L. Mateo Sent: Friday, December 18, 2015 2:13 AM To: openldap-technical@openldap.org Subject: Re: Attribute pwdPolicySubentry
El 17/12/15 a las 19:19, Borresen, John - 0444 - MITLL escribió:
Btw, I am seeing that error, when attempting to add the attribute "pwdPolicySubentry" to a specific user.
I had this same problem when I make changes to this attribute with client Apache Directory Studio. Anyway, that change is done, so I didn't care about it.
I haven't tried to make it directly with ldapmodify.
-- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337
Borresen, John - 0444 - MITLL wrote:
Interesting! I was able to add it via command-line with ldapadd. But, when viewing it in Apache Directory Studio, it still didn't show up -- that is until I enabled Operational Attributes.
Attribute 'pwdPolicySubentry' is somewhat special because it's not referenced by any object class. You can simply add it to any entry.
Apache Directory Studio is schema-aware and likely it implements a client-side schema check which failed. Although my web2ldap has also full schema support it deliberately does not implement client-side schema checks for this very reason (guiding instead of enforcing).
BTW: That's why I asked in my first response: "Which component does produce this error message?"
Ciao, Michael.
Thanks for your help Michael!
John D. Borresen (Dave) Ph: (781) 981-1609 Email: john.borresen@ll.mit.edu
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Friday, December 18, 2015 2:56 PM To: Borresen, John - 0444 - MITLL; openldap-technical@openldap.org Subject: Re: Attribute pwdPolicySubentry
Borresen, John - 0444 - MITLL wrote:
Interesting! I was able to add it via command-line with ldapadd. But,
when
viewing it in Apache Directory Studio, it still didn't show up -- that is until I enabled Operational Attributes.
Attribute 'pwdPolicySubentry' is somewhat special because it's not referenced by any object class. You can simply add it to any entry.
Apache Directory Studio is schema-aware and likely it implements a client-side schema check which failed. Although my web2ldap has also full schema support it deliberately does not implement client-side schema checks for this very reason (guiding instead of enforcing).
BTW: That's why I asked in my first response: "Which component does produce this error message?"
Ciao, Michael.
Michael Ströder wrote:
Borresen, John - 0444 - MITLL wrote:
Interesting! I was able to add it via command-line with ldapadd. But, when viewing it in Apache Directory Studio, it still didn't show up -- that is until I enabled Operational Attributes.
Attribute 'pwdPolicySubentry' is somewhat special because it's not referenced by any object class. You can simply add it to any entry.
It is an operational attribute, so by definition, it can be added to any entry.
Apache Directory Studio is schema-aware and likely it implements a client-side schema check which failed. Although my web2ldap has also full schema support it deliberately does not implement client-side schema checks for this very reason (guiding instead of enforcing).
BTW: That's why I asked in my first response: "Which component does produce this error message?"
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
Borresen, John - 0444 - MITLL wrote:
Interesting! I was able to add it via command-line with ldapadd. But, when viewing it in Apache Directory Studio, it still didn't show up -- that is until I enabled Operational Attributes.
Attribute 'pwdPolicySubentry' is somewhat special because it's not referenced by any object class. You can simply add it to any entry.
It is an operational attribute, so by definition, it can be added to any entry.
But 'pwdPolicySubentry' is the only attribute typically set by a LDAP client in opposite to all other operational attributes like 'createTimestamp' etc.
So it's special for schema-aware LDAP GUI clients.
Ciao, Michael.
In my opinion, the pwdPolicySubentry attribute should be read-only generated by the server.
We had made the error in Sun Directory Server to allow customers to set it manually, and it was very confusing that the attribute served 2 roles : a way to find the pwd policy entry applicable for the entry, and a way to set a different or new policy for an account.
In OpenDJ ( and all other servers from the same code base) we use 2 different attributes. That separation made it easier to handle for applications and administrators.
My 2 cents
Ludo
That makes sense. An even smarter system would use the administrative model to handle password policies.
Le samedi 19 décembre 2015, ludovic.poitou@gmail.com a écrit :
In my opinion, the pwdPolicySubentry attribute should be read-only generated by the server.
We had made the error in Sun Directory Server to allow customers to set it manually, and it was very confusing that the attribute served 2 roles : a way to find the pwd policy entry applicable for the entry, and a way to set a different or new policy for an account.
In OpenDJ ( and all other servers from the same code base) we use 2 different attributes. That separation made it easier to handle for applications and administrators.
My 2 cents
Ludo
Emmanuel Lecharny wrote:
That makes sense. An even smarter system would use the administrative model to handle password policies.
Yes.
Le samedi 19 décembre 2015, <ludovic.poitou@gmail.com mailto:ludovic.poitou@gmail.com> a écrit :
In my opinion, the pwdPolicySubentry attribute should be read-only generated by the server.
Agreed. That's how it always should have worked, but since we didn't have a real subEntry implementation, this is what we got.
We had made the error in Sun Directory Server to allow customers to set it manually, and it was very confusing that the attribute served 2 roles : a way to find the pwd policy entry applicable for the entry, and a way to set a different or new policy for an account. In OpenDJ ( and all other servers from the same code base) we use 2 different attributes. That separation made it easier to handle for applications and administrators.
Makes sense.
My 2 cents Ludo-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com http://www.iktek.com
Am Sat, 19 Dec 2015 18:29:32 +0000 schrieb Howard Chu hyc@symas.com:
Emmanuel Lecharny wrote:
That makes sense. An even smarter system would use the administrative model to handle password policies.
Yes.
Le samedi 19 décembre 2015, <ludovic.poitou@gmail.com mailto:ludovic.poitou@gmail.com> a écrit :
In my opinion, the pwdPolicySubentry attribute should beread-only generated by the server.
Agreed. That's how it always should have worked, but since we didn't have a real subEntry implementation, this is what we got.
We had made the error in Sun Directory Server to allowcustomers to set it manually, and it was very confusing that the attribute served 2 roles : a way to find the pwd policy entry applicable for the entry, and a way to set a different or new policy for an account.
In OpenDJ ( and all other servers from the same code base) weuse 2 different attributes. That separation made it easier to handle for applications and administrators.
Makes sense.
My 2 cents
This thread should be moved to ldapext@ietf.org
-Dieter
Otoh, making it user modifiable was a mistake and broke the rfc specification, which says it's a NO-USER-MODIFIABLE attribute.
Le samedi 19 décembre 2015, ludovic.poitou@gmail.com a écrit :
In my opinion, the pwdPolicySubentry attribute should be read-only generated by the server.
We had made the error in Sun Directory Server to allow customers to set it manually, and it was very confusing that the attribute served 2 roles : a way to find the pwd policy entry applicable for the entry, and a way to set a different or new policy for an account.
In OpenDJ ( and all other servers from the same code base) we use 2 different attributes. That separation made it easier to handle for applications and administrators.
My 2 cents
Ludo
openldap-technical@openldap.org
-
Angel L. Mateo -
Borresen, John - 0444 - MITLL -
Dieter Klünter -
Emmanuel Lecharny -
Howard Chu -
ludovic.poitou＠gmail.com -
Michael Ströder