Password Policy Problem in DS 6.1
This is going to be a lengthy post so bear with me..... ;-)
We ran Sun DS 5.2 with a custom password policy defined for over a year. The password policy was assigned to users utilizing the passwordPolicySubentry attribute, this was done because we did not want to use the global policy to prevent affecting application accounts, etc.. The password policy enforced things such as maximum age, minimum length, password history, etc. We have an in-house developed password service, that uses a privileged user account to allow users to change their passwords, reset their passwords, manage their security q&a (used for password resets), etc. The privileged user is not: Directory Manager, a member of any administrators groups. The user simply has write privileges to userPassword and all the other pertinent attributes for ALL users.
This worked great until we upgraded to DS 6.1. Testing against all types of modes for password policy (compatibility mode, migration mode, 6 mode) I have come to the conclusion that as soon as I give the privileged user an ACI to allow it to write to userpassword, the password policy is ingored. This seems to be allowed because our password policy is configured to allow Administrators to bypass the policy (passwordRootdnMayBypassModsChecks = on). However, the password service privileged account is NOT part of any administrators groups.
PASSWORD IN HISTORY TEST:
Here's access log output (I've edited out the IPs):
[13/Jul/2007:15:34:13 -0400] conn=128 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from IP:4712 to IP
[13/Jul/2007:15:34:13 -0400] conn=128 op=0 msgId=1 - BIND dn="uid=pwsguy,ou=People,o=sene.ca" method=128 version=2
[13/Jul/2007:15:34:13 -0400] conn=128 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=pwsguy,ou=people,o=sene.ca"
[13/Jul/2007:15:34:13 -0400] conn=128 op=1 msgId=2 - MOD dn="uid=scarter,ou=People,o=sene.ca"
[13/Jul/2007:15:34:13 -0400] conn=128 op=1 msgId=2 - RESULT err=0 tag=103 nentries=0 etime=0
[13/Jul/2007:15:34:13 -0400] conn=128 op=2 msgId=3 - UNBIND
[13/Jul/2007:15:34:13 -0400] conn=128 op=2 msgId=-1 - closing from IP:4712 - U1 - Connection closed by unbind client -
[13/Jul/2007:15:34:14 -0400] conn=128 op=-1 msgId=-1 - closed.
Here's erro log output:
[13/Jul/2007:15:34:13 -0400] - INFORMATION - Operation - conn=128 op=1 msgId=2 - Ignoring userpassword validation error:"password in history". Entry"uid=scarter, ou=People, o=sene.ca".
PASSWORD TOO SHORT TEST:
Access log:
[13/Jul/2007:15:34:17 -0400] conn=129 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from IP:4713 to IP
[13/Jul/2007:15:34:17 -0400] conn=129 op=0 msgId=1 - BIND dn="uid=pwsguy,ou=People,o=sene.ca" method=128 version=2
[13/Jul/2007:15:34:17 -0400] conn=129 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=pwsguy,ou=people,o=sene.ca"
[13/Jul/2007:15:34:17 -0400] conn=129 op=1 msgId=2 - MOD dn="uid=scarter,ou=People,o=sene.ca"
[13/Jul/2007:15:34:17 -0400] conn=129 op=1 msgId=2 - RESULT err=0 tag=103 nentries=0 etime=0
[13/Jul/2007:15:34:17 -0400] conn=129 op=2 msgId=3 - UNBIND
[13/Jul/2007:15:34:17 -0400] conn=129 op=2 msgId=-1 - closing from IP:4713 - U1 - Connection closed by unbind client -
[13/Jul/2007:15:34:19 -0400] conn=129 op=-1 msgId=-1 - closed.
Error Log:
[13/Jul/2007:15:34:17 -0400] - INFORMATION - Operation - conn=129 op=1 msgId=2 - Ignoring userpassword validation error:"Password too short" (and 1 others). Entry"uid=scarter, ou=People, o=sene.ca".
The results of the testing you see here is on a vanilla installation and instance of DS 6 using the Global Password Policy and Sun's sample data.
I'm in the process of opening a support call with Sun on this but if someone has run into and resolved this issue, it would be of great help to hear about the solutions.
[4215 byte] By [
kamiljdka] at [2007-11-27 10:33:36]
# 1
In DS6, a password modify by other-than-self is considered an administrative change. The motivation for this change is to allow deployments to avoid using Directory Manager for routine administration. The motivation for the simple test (other-than-self) is the difficulty in otherwise determining which entries are administrators.
You are correct that this behavior has changed compared to DS5, where, by default, only changes by the Directory Manager DN were considered administrative changes. DS5.2p4 introduced a policy configuration attribute (passwordNonRootMayResetUserpwd) to enable the DS6 behavior.
Can you modify your self-service application to use the LDAP Proxied Authorization Control v2 (http://www.ietf.org/rfc/rfc4370.txt)? It is available in at least the LDAP C SDK and can be invoked from the DSRK6 ldapmodify command: ldapmodify -D <administrative_account> -Y <user_account>
# 2
Thanks solaris1. I just coded this in Java, we use the Netscape Java SDK 4.1, and it works.
I have read the RFC (http://tools.ietf.org/id/draft-behera-ldap-password-policy-09.txt) which is referred to in the 6.1 DS EE Migration Guide (p. 72) but nowhere do I find mentioned the change from DM is root to everyone can be root. Why is this not documented properly? If I missed the documentation on this, please point it out.
This also raises the issue of performance, for applications such as our password self service tool, because our password service keeps its own "operational" attributes that need to be updated when the password is changed/reset. Using proxied authentication, we end up having to do 2 modify calls instead of the 1 we currently do. This is not a good move.
Message was edited by:
kamiljdk
# 3
The Internet-Draft (not an RFC yet) is intended to propose a general purpose Password Policy mechanism for LDAP and does not discuss specific implementations such as ours.
The change from requiring Directory Manager to perform certain password policy actions, to any user with specific access privileges to perform these actions was in fact introduced in DS 5.2patch4.
This was configurable with the passwordNonRootMayResetUserpwd attribute.
But you're correct, it looks like the change has not been properly documented. I could not find any reference to it in our doc except in the man page (5dsat) which states that the attribute is obsolete and will be removed in future versions of DSEE. <http://docs.sun.com/app/docs/doc/820-0384/6nc4k4st5?a=view>
As for the performance issue with your applications, I am not sure I understand the issue.
But an "operational" attribute is something managed by the server, not by an application.
I do understand that you want to maintain "State information" when the password is changed or reset, but I fail to understand why now you need 2 modify whereas before you could do only one.
Regards,
Ludovic.
# 4
> The Internet-Draft (not an RFC yet) is intended to
> propose a general purpose Password Policy mechanism
> for LDAP and does not discuss specific
> implementations such as ours.
>
> The change from requiring Directory Manager to
> perform certain password policy actions, to any user
> with specific access privileges to perform these
> actions was in fact introduced in DS 5.2patch4.
> This was configurable with the
> passwordNonRootMayResetUserpwd attribute.
Funny enough, I did notice passwordNonRootMayResetUserpwd when editing password policies in DS 6.1. The even funnier thing is that I couldn't change its value. I'm guessing it was there for replication compatibility, whatever, why even display it in an editable text box if it can't be updated?
>
> But you're correct, it looks like the change has not
> been properly documented. I could not find any
> reference to it in our doc except in the man page
> (5dsat) which states that the attribute is obsolete
> and will be removed in future versions of DSEE.
> <http://docs.sun.com/app/docs/doc/820-0384/6nc4k4st5?a
> =view>
>
> As for the performance issue with your applications,
> I am not sure I understand the issue.
> But an "operational" attribute is something managed
> by the server, not by an application.
This is why I enclosed operational in quotes, because they are application attributes so in essence they are just user attributes.
> I do understand that you want to maintain "State
> information" when the password is changed or reset,
> but I fail to understand why now you need 2 modify
> whereas before you could do only one.
I will need to issue 2 modify calls because:
1. Issue the change password mod with proxy authorization as the user for whom the password is being changed
2. If 1 succeeds, issue the mod for password service tracking attributes ("operational") as the admin user (who has rights to access those attributes)
>
> Regards,
>
> Ludovic.
IMO, the change to move away from single root is not a good idea. It may simplify things, attempt to offload some management issues but in the end, some difficulty in managing user's credentials is what adds that extra layer of security. User password management now jumps into the arena of ACIs which, although a necessary evil, are a pain in the neck and this issue only adds to the pile.
# 5
> Funny enough, I did notice
> passwordNonRootMayResetUserpwd when editing password
> policies in DS 6.1. The even funnier thing is that I
> couldn't change its value. I'm guessing it was there
> for replication compatibility, whatever, why even
> display it in an editable text box if it can't be
> updated?
Looks like a bug...
> > But an "operational" attribute is something
> managed
> > by the server, not by an application.
>
> This is why I enclosed operational in quotes, because
> they are application attributes so in essence they
> are just user attributes.
>
> > I do understand that you want to maintain "State
> > information" when the password is changed or
> reset,
> > but I fail to understand why now you need 2 modify
> > whereas before you could do only one.
> I will need to issue 2 modify calls because:
> 1. Issue the change password mod with proxy
> authorization as the user for whom the password is
> being changed
> 2. If 1 succeeds, issue the mod for password service
> tracking attributes ("operational") as the admin user
> (who has rights to access those attributes)
Got it.
> >
> > Regards,
> >
> > Ludovic.
>
> IMO, the change to move away from single root is not
> a good idea. It may simplify things, attempt to
> offload some management issues but in the end, some
> difficulty in managing user's credentials is what
> adds that extra layer of security. User password
> management now jumps into the arena of ACIs which,
> although a necessary evil, are a pain in the neck and
> this issue only adds to the pile.
userPassword access is already governed by ACIs.
A user must have SELF write access to his own userPassword.
Admins must have write access to others userPassword in order to change them.
root (Directory Manager) bypasses all ACIs BUT prevents from being able to really AUDIT who is changing the data in Directory Server. When there are several admins, enterprises need to have the ability to audit who is doing what.
Regards,
Ludovic.
# 6
> userPassword access is already governed by ACIs.
> A user must have SELF write access to his own
> userPassword.
> Admins must have write access to others userPassword
> in order to change them.
> root (Directory Manager) bypasses all ACIs BUT
> prevents from being able to really AUDIT who is
> changing the data in Directory Server. When there are
> several admins, enterprises need to have the ability
> to audit who is doing what.
Good point and 1 I've considered. I guess I'm a little biased to look at it from the perspective of our environment where we have custom apps managing DS data (password self service for users, ldap account manager for help desk staff). These apps look after auditing at the user level as opposed to leaving it up to DS.
Thanks for your input.
Here's some Java code, in case others are looking at this same issue.
....
String dn = "user dn";
String password = "da password";
LDAPConnection con = null;
try
{
// you need ldap v3 for control support
con = ld.connect (3, "server",389, "proxy authorized admin user dn","password");
LDAPProxiedAuthControl proxiedAuthControl = new LDAPProxiedAuthControl(dn, true);
LDAPConstraints cons = new LDAPConstraints();
cons.setServerControls (proxiedAuthControl);
// change the password as the user for whom the password is being changed to make sure the password policy is enforced
con.modify (dn,new LDAPModification (LDAPModification.REPLACE, new LDAPAttribute ("userpassword", password)), cons);
// update some password self service tool tracking attributes as the admin user
con.modify (dn,new LDAPModification (LDAPModification.REPLACE, new LDAPAttribute ("passwordChangedFromIP", "ip address")));
}
catch (Exception e)
{
e.printStackTrace ();
}
finally
{
// clean up
}
....
>
> Regards,
>
> Ludovic.
# 7
I have opened a CR to have the change documented in the migration guide:
6581725 Migration guide is missing description of change to administrative password reset classification
Thanks for pointing out this omission. Also, could you please identify where you see the checkbox for passwordNonRootMayResetUserpwd ? I do not have a DSCC available and do not see the property in the dsconf get-server-prop output, but would like to open a CR to get it fixed.
If you think the additional state maintained by your password self-service application is of general interest, could you please describe it here so we can consider it for future versions of DS6?
# 8
> I have opened a CR to have the change documented in
> the migration guide:
>
> 6581725 Migration guide is missing description of
> change to administrative password reset
> classification
Let's hope it gets done ;-)
>
> Thanks for pointing out this omission. Also, could
> you please identify where you see the checkbox for
> passwordNonRootMayResetUserpwd ? I do not have a DSCC
> available and do not see the property in the dsconf
> get-server-prop output, but would like to open a CR
> to get it fixed.
This I actually saw not in the Password Policies tab, which brings up a policy for editing in a pwd policy editor, but while editing the entry itself, from the Entry Management -> Browse -> Edit page.
The other thing I have noticed is the fact that any existing password policies, such as our custom ones, do not have the ldapSubentry objectclass value added when imported into DS6. This causes the Password Policies tab to not pick them up for editing.
>
>
> If you think the additional state maintained by your
> password self-service application is of general
> interest, could you please describe it here so we can
> consider it for future versions of DS6?
Here's some proprietary data that we populate:
1. security question and answer - for password resets
2. account activation code - only good for the password service (not a password), this allows us to create accounts, using our custom ldap account manager, that do not have access to anything other than the password service, which forces: the acceptance of our acceptable use policy, creation of a strong first password and security Q&A, exposes the user to what they are going to have to deal with once every 45 days ;-)
3. password change time - in local time - this is redundant because of pwdChangedTime, but we've kept it around for the time being
# 9
> > I have opened a CR to have the change documented
> in
> > the migration guide:
> >
> > 6581725 Migration guide is missing description of
> > change to administrative password reset
> > classification
>
> Let's hope it gets done ;-)
It is now in the review draft for DS 6.2, so there is hope.
>
> >
> > Thanks for pointing out this omission. Also,
> could
> > you please identify where you see the checkbox for
> > passwordNonRootMayResetUserpwd ? I do not have a
> DSCC
> > available and do not see the property in the
> dsconf
> > get-server-prop output, but would like to open a
> CR
> > to get it fixed.
>
> This I actually saw not in the Password Policies tab,
> which brings up a policy for editing in a pwd policy
> editor, but while editing the entry itself, from the
> Entry Management -> Browse -> Edit page.
>
Ok. I probably should have made the attribute NOT-USER-MODIFIABLE in the 6.x schema, although I'm not sure what sort of side effects would arise in a mix of 5.x and 6.x DSAs.
> The other thing I have noticed is the fact that any
> existing password policies, such as our custom ones,
> do not have the ldapSubentry objectclass value added
> when imported into DS6. This causes the Password
> Policies tab to not pick them up for editing.
SunDS uses ldapsubentry as the structural object class for the password policy configuration entries (passwordPolicy, pwdPolicy, sunPwdPolicy... are auxilary object classes). What is the structural object class of the (5.x?) entries you are importing?
> >
> >
> > If you think the additional state maintained by
> your
> > password self-service application is of general
> > interest, could you please describe it here so we
> can
> > consider it for future versions of DS6?
> Here's some proprietary data that we populate:
> 1. security question and answer - for password
> resets
>
> 2. account activation code - only good for the
> password service (not a password), this allows us to
> create accounts, using our custom ldap account
> manager, that do not have access to anything other
> than the password service, which forces: the
> acceptance of our acceptable use policy, creation of
> a strong first password and security Q&A, exposes the
> user to what they are going to have to deal with once
> every 45 days ;-)
Though useful, those do seem like application specific attributes. Or at least would require quite a bit more code to implement in DS.
>
> 3. password change time - in local time - this is
> redundant because of pwdChangedTime, but we've kept
> it around for the time being
Note that in 6.x, pwdChangedTime will only be updated when a policy is enabled that requires it: namely, expiration or min-time-between-changes.
--
Scott
