Password Policies
|
3/1/2006 Password policies in Netware seem unneccessarily complicated. Perhaps this is because I only want to install the bare necessities, and some of the options in regards to passwords forces you to install too much crap! Or perhaps it's because I really want to make sure that I don't compromise any security. It seems that there are two ways to do this, at least if you want to shell out more money - NAM and IDM2, with NAM being the older method. Read this article for some pros and cons. There may in fact be a plain old IDM that is free, but I didn't search around too much. Read this if you're interested in IDM. You will need either NAM or IDM (one of these is also known as DirXML (which can be installed for free via the DirXML Starter Pack)), which you will need if you wish to synchronize with passwords in Active Directory or NT Server). For the record, I do not care about synchronizing with Windows. The only place we use Windows accounts is on our Exchange Server, and those account names don't even match the Netware names (nor do I want them to)! Universal Password lets you enforce password policies once it is enabled, and comes with base Netware. It appears to store the password in reversible encryption using an RSA public/private keypair (3DES). I do not know the key size. When you change the NDS password, it modifes the Universal Password (at least that's what I read in a forum post by a Netware SysOp) and the Simple Password, if enabled (which it isn't for us). Everything is also modifed when you modify the Universal Password. When you modify the Simple Password, however, nothing else is updated. The reason I am weary to believe that changing the NDS password will change everything else is that you cannot use a < v4.9 version of the Netware client to change password. It will only change the NDS password, causing what they call password drift, since the UP will not be changed and therefore become unsynchronized. See this diagram for different scenarios that either synchronize or don't. In fact, the only way that changing an NDS password will synchronize the UP is if you do so from a NMAS enabled client (again, this must also be a client >v4.9). As someone recently told me, and obviously he is right, if you were to change the NDS password with an NDS only utility, such as the old SETPASS utility, it sends the new password in hashed form. Therefore, there is no way for the server to know what this password is in plain text. UP requres NMAS (or rather, UP is part of NMAS), which in turn places
its configuration and policies in the Security container off of the
tree. UP also uses NICI for its encryption, and in turn, NICI uses an
SDI Domain Key, a cryptographic key that can be shared across multiple
servers. I first checked to make sure that my server (which is also
my SDI Domain Key Server) met certain requirements:
To ensure that the keys are adequately protected, ensure that access to the SYS:\novell\nici directory in the filesystem is restricted. To deploy Universal Password, log into iManager. In the left-hand menu, click on Passwords -> Password Policies. Click New and then type a name, description, and password change message ("you must now change your password in accordance with the policies," for example). On step 2, make sure you check yes and "Enable the Advanced Password Rules" for Universal Password. You will then be presented with a nice set of rules. :) I chose not to enable the "Forgotten Password" feature. I applied this to our main container, right under the tree. Once I clicked done, I clicked on "Policy Assignments" and pulled up a random user.. sure enough, the new policy showed up for that user! Note that applying a policy to a container, all users in that container will inherit it. It will be inherited by subcontainers as well IF that container is the root of the partition. If you want the policy to be the default for all users in the tree, assign it to the "Login Policy Object," which is in the Security Container just below the root of the tree. This is, in fact, where I ended up applying our policy. NMAS seems to be touchy about when it filters your password policy down to user objects to which it applies (to their NDS password restrictions, that is - which you see from a user's property page). If you change the policy that is already applied to a user, it does not update that user to reflect the new policy UNTIL the Universal Password is changed again for that user. (at first I thought I was changing the NDS rather than the UP for tha tuser, since I was changing it from ConsoleOne on Linux (hence, pre-4.9 client), but the policy did NOT update when I tried changing it with the old SETPASS utility under DOS, which of course is pure NDS) is changed again. It also does not apply the new policy when you change the destination to which the policy is applied (such as moving it from the container to the Login Policy Object).
Also, don't be fooled by all the stuff about upper and lowercase letters, however. NDS is NOT CASE SENSITIVE! The ONLY way to force case-sensitivity is to check the "Remove the NDS password when setting Universal Password" option in the policy, which forces the user to authenticate with UP (or, possibly Simple Password?). However, this means that NMAS will be required to log in, thereby also preventing the use of any client older than v4.9 (as well as all DOS client versions). This is because all clients that use NDS convert the password to all uppercase before hashing it. Since the password policy is still enforced with regard to upper and lowercase when you set the password through UP, one can only deduce that the password is stored with case sensitivity in UP simultaneously with case insensitivity (all uppercase) in NDS. I have read somewhere, however, that passwords have become case sensitive with the introduction of eDirectory v8.8. How this works if the clients are converting to uppercase, I don't know. But it's worth a shot. Here is what the Password Policy Help says on the matter:
Because of this case sensitivity fiasco, I went back and removed those restrictions from our policy. Instead, I forced people to use a lot of numbers. :( Case sensitivity is still checked when authenticating through the Windows Netware Client (which uses the UP), but not from older clients that are using NDS, and not from web interfaces, such as iManager. Note that If authenticating with LDAP over SSL, and password is not a simple bind (encrypted), Simple Password will need to be enabled. :(
I also wanted to turn on Intruder Detection, which can lock out a given account after too many failed login attempts, to help thwart brute forcing and hacking of passwords. This is done at the Container and can be done either from iManager (Click on View Objects, select the Container, and select Modify Objects. This only seems to work in IE) or ConsoleOne. At any rate, you must go into the properties of the object and, under General, select Intruder Detection. I checked the Detect Intruders box as well as Lock Account After Detection, and of course set the various values associated with them. Voila!
If your users have trouble changing passwords after installing UP and/or
setting a password policy (such as getting a password history
full message), see
this message thread. It seems that there is a not-so-obvious interaction
between the number of password stored in the history list and the number
of days to store a password in the history list:
*** Netware 6.5 does not seem to come with a SETPASS.EXE utility anymore. I needed a way to change the password from the DOS command line, however, so I dug out this old utility from Netware 4.1 and gave it a shot. It changed the password just fine (both NDS and Universal password).. however, it completely sidestepped any rules that I had for creating a password (i.e., I had set the required password length to 8 characters, but it had let me change it to a 4-character password! And it did it in both NDS and UP!). |