Active Directory Password Security
Novell Cool Solutions: Feature
By Patrice Clement
Digg This -
Posted: 1 Oct 2001
Updated: Comments About this Article
Have you ever created a new user and gotten a blank password on the AD account? Many people who encounter that consider it to be a huge security hole, and have written most eloquently about it. Here's a typical scenario:
- In ConsoleOne, create a new user in some container.
- Make sure the box to "Add this user to an Active Directory Domain" is NOT checked.
- Fill in password at account creation time.
- Allow NDS replicas to sync up.(Watch NDS trace or you can see user in pop up in C1 pointed to the copy of eDir on the AD box.) Then go ahead and click into the user object's properties.
- On the user's Domain page, add the user to a Domain, and a group (like Domain Users). Apply those changes.
- Wait for NDS to sync, and for DirXML events to happen. In a few short moments you'll see the user pop in to the AD MMC console.
- Try to login as the user from a workstation.
- You will pass the authentication step for NDS (naturally!) but then will be prompted for another password for the AD Domain.
The password already in the user object is not transmitted to the AD DOMAIN, but rather the user is created in AD and the user CAN authenticate to AD with A BLANK PASSWORD! Now on the good side, it DOES require you to change it immediately, and if you change it to a password that is the same as the NDS password, you can then log in with one name and password. But that's after you already login with a BLANK PASSWORD.
This is actually working as designed. Here's why it has to happen that way:
The very first thing to understand is that passwords are stored in NDS after having been encrypted through a one way encryption algorithm. This means that it is not possible to decrypt the password once it has been stored in NDS (or at least, it should not be in theory. If it turns out to be possible, that would be because of a bad one way encryption algorithm).
In this scenario, the reason you are ending up with a blank password on the AD account, is because you disabled the synchronization of the user account during its creation. If you would check the "Add this user to an Active Directory Domain" option, then you would end up with the same password in AD and NDS. On the other hand, if you do not check this box, the user is only created in NDS and the password is encrypted. From that moment on, we are not able to retrieve the clear text password anymore because we cannot decrypt it. Since AD is using a different encryption algorithm than NDS to encrypt the passwords, we have to know the clear text password to be able to re-encrypt it into AD with the correct algorithm. That means that when you decide to synch this user into AD later on, we have no other choice than create a user in AD with a blank password. The next time the password is changed, it will be detected by NAM and the new password will be stored in both AD and NDS using their respective encryption algorithm.
The reason why "one-way" encryption algorithms are used is because they are much stronger than normal encryption algorithms since, by design, there is no decryption possible. This allow for a much more secure implemention of the authentication mechanism of NDS.
In other words, this is not due to a "poor" design of the Novell Account Management for Windows 2000 product but rather it is due to the security of the mechanisms used to encrypt passwords in NDS.
The best way to avoid this problem all together is to synch the users in AD during their creation in NDS (by checking the "Add this user to an Active Directory Domain" box).
There are 3 basic encryption algorithms in wide use in directories today, RSA which eDirectory uses, MD5 (UNIX), and DES. I don't know what Microsoft uses in AD; I assume some form of DES or whatever Kerberos uses. The specific encryptions do not matter for this comment/suggestion.
To solidly entrench eDirectory into the "Center of Universe", why not add attributes to eDirectory to store the encrypted passwords for any type of encryption that is needed for a particular site. For example: in my environment I may choose to store an MD5 encrypted password and a Kerberos encrypted password in addition to the Novell used RSA encrypted password. Now the DirXML plug-in for Active Directory can choose to sync the correct encrypted string into AD or whatever the target directory is.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com