A Forum reader asked the following question:
We have the Universal Password set up in our tree but my question is this. If I turn on complex passwords, when do they take effect – immediately, or at the user’s next password expiration, when they have to change the password?
It is also my understanding that once the complex password is set, the only attributes that are valid in the user object restrictions view (ConsoleOne) are Password expiration date and grace logins. Is this correct? My understanding is that for the password policy, whatever containers are assigned to the universal password policy apply to the complex passwords – they are basically one policy. Is this also correct?
And finally, should I want some users to not be affected by the universal password and complex password? Then I could create a new container and move those users to that container, making sure that this new container is not assigned the password policy or universal password (part of the password policy).
And here’s the response from Aaron Burgemeister …
The proper way to “override” a policy applied generally (not to a user specifically) is to apply another policy directly to the user. Policies are read on the user, the direct-parent container, the partition root (of the user), and the Login Policy.Security object in that order. Only those four places are considered, ever.
Also note that those passwords can take effect on a login when an NMAS-enabled client is in use (you should be on 4.91 SP2 for maximum happiness with Universal Password (UP)). It works something like this:
1) An NMAS-enabled login takes place (Novell client on Windows or Linux).
2) The server sees UP coming from the client and tries to check same in eDirectory, but there isn’t one.
3) The server has an older (legacy) NDS password and checks it.
4) If the password (NDS) was correct, the server actually sets up the UP for you right
then. That way you don’t need to have all users’ passwords expired just to make UP work … just have them login).
5) If in this case the current password does not meet the complexity requirements for the password policy, the user will be prompted to change the password.
Tada … all in sync.
Also note that the expiration interval and expiration time attributes are properly synchronized with the UP settings, if you are on semi-new code. (You CANNOT see these settings per user, which is why we sync those other attributes for your convenience). Security Services 2.0.1 comes with NMAS 3.1 and does
this properly. Additionally, those attributes are the only ones used if you don’t have your clients all updated to an NMAS-installed-and-enabled client. (Version 4.9x has these by default unless you changed things on installation.)
Finally, UP policies take precedence when an NMAS-based login (see above) is used. The ONLY time that the old NDS attributes can trump the NMAS stuff is if the NDS stuff is more restrictive. My favorite example is of one’s manager. As the IT person, you have smart policies in place for UP that expire passwords every XX days. Your manager comes and says their password needs to be changed but they don’t want to, and they have always just had you push out the expiration date (made NDS’s attributes less restrictive). This has always worked. With UP this will no longer work. On the flip side, you have a user who you are going to force to change passwords. Usually you do this by setting their expiration to sometime in the past. This will still work with UP, because the NDS attribute is more restrictive. The expiration interval is updated for your convenience, but since it only takes effect on a password change, NMAS will change it then anyway.