My pwd-storage-scheme (global-policy) is currently set to CRYPT, I am now required to change this to SHA.
Most of my clients are Solaris, with a few RHEL (different flavors).
What is the best way to make the above change?
What effects, if any, will this have on my UNIX clients?
Also, my pwd-compat-mode is set to "DS6-migration-mode", and I need to change this to "DS6-mode", would this cause any issues for me?
I only have DS6 servers in my environment, no DS5 at all, and no other DS servers, although at some point I may wish to sync with AD.
(Unix) Crypt is a one-way function, so plain text password is required to generate the SHA hash.
You can change the password storage scheme to SHA, but passwords will be stored with SHA when users update their passwords. To speed up the process, you can configure password expiration or force users to change their passwords. Note that users with passwords stored in crypt format will still be able to authenticate even if password storage scheme is set to SHA. Said differently, different password storage schemes can cohabit across existing entries. Over time, every password will be stored with the configured password storage scheme as users update passwords.
Ds6 password policy mode introduces new operational attributes in user entries. These new attr are generated when passwords are changed, so to have a fully featured password policy based on ds6-mode, you should 1/ move to migration mode 2/ have users update their passwords 3/ switch to ds6 mode . This admin action relates somehow to the switch CRYPT/SHA that already requite password changes.
Note that there is a tool provided with ODSEE11gr2 that generates the appropriate operational password policy attr w/o requiring users to change their password. This might be an alternate solution if you have the right to use that version.
I was looking for reassurance that my environment wasn't going to blow up, and after all of my changes to the desired settings, all is still working as it was prior to my changes.
I had previously made these changes to a lab master, while still in DS5 compat mode, and none of my users were able to login in.
One final thing, although I've made my changes, none of my users are able to change their own password. (they weren't prior neither)
I was hoping that the changes I had made would allow this, but it did not.
Do I have to create an ACI that allows users to change their own passwords? If so, what should it look like?
I can't think of 2 reasons that would prevent users from changing their own password:
- The password policy assigned to them don't allow password change (see pwdAllowUserChange(5dsat) (Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference)
- They don't have write access on userPassword as change operation is still subject to access control. In general in this case, users are granted seft modification with an aci similar to this
aci: (targetattr = "userPassword") ( version 3.0; acl "allow
userpassword self modification"; allow (write) userdn = "ldap:///self";)
Hope this helps
My password policies do allow changes, well at least my newly created one does, and it is assigned to my username.
I have one ACI which prohibits userPassword write (see below), but I have another one, identical to yours, that allows self-modification.
(target="ldap:///dc=sub,dc=top,dc=com")(targetattr = "shadowLastChange||shadowMin|| shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||userPassword") (version 3.0; acl LDAP_Naming_Services_deny_non_admin_shadow_access;deny (write,read,search,compare) userdn != "ldap:///cn=admin,ou=profile,dc=sub,dc=top,dc=com";)
I had thought of removing userPassword from the ACI above, but if I do, wouldn't that allow all else to see each others password fields? Is there a way to rewrite the above, but add in yours?
Many thanks once more.
Found my issue, not all of my masters contain the same ACI's!
After succeeding on one master, I looked at the ACI's on that master, and compared it to another, which were vastly different (the one not working contained the ACI I noted above, another did not).
Now on to trying to figure out how to sync my ACI's to each other, in the easiest way possible; time for a new thread.
I've encountered an issue somewhat related to this thread.
Since I've changed my password storage schema from MD5 to SHA (will be SSHA later), I can no longer authenticate onto my NIS clients. My NIS clients are bound to NIS masters that are reloading their data from N2L/NISLDAPMapping services, in case this matters.