|
||
  Metadirectories: Keeping User Info in Sync January 25, 1999 | ||
|
|
Password Sync: A Directory Sync Headache On the surface, synchronizing directory attributes seems to be a relatively simple task: Just locate the right information in the source directory and copy it to the appropriate schema attribute in each destination. Of course, this involves a certain amount of translation--particularly if each directory stores and interprets common information differently. (For instance, is a phone number's area code surrounded by brackets?) But passwords are a relatively simple attribute--just a short text string. Unfortunately, password synchronization is one of the main headaches of any directory-synchronization solution. While a password is simple, the method in which it is stored and interpreted in each directory is not. In fact, most directories don't store passwords at all. Instead, they store a one-way hash of the user's password. This is simply a block of unintelligible binary data, and cannot be reverse-engineered to produce the original information (the password that the user entered). When logging into most systems (including Windows NT, NetWare and virtually all forms of Unix), the password the user enters is hashed by the server and then compared with the hash stored in the directory. If the hash of the user's response matches the stored hash from the directory, the user is successfully logged in. This approach is secure because the integrity of the hashing algorithm guarantees that the hash is not reversible, and that there is no way to reverse-engineer the original password--other than through trial and error (this is the brute-force attack employed by password-hacking utilities such as "crack"). While this approach presents a convenient way to protect users' passwords, it also poses a problem when synchronizing directories. Since each application or NOS has its own password storage and hashing algorithms, it is effectively impossible to copy passwords from one directory to another (unless both directories use the same hashing algorithm). Thus, password synchronization must often be handled outside normal directory synchronization. The password sync problem can be handled in two ways: an external password changing service, or a piece of code that wraps itself around an OS's password-change function to capture the user's plain text password before it is hashed. In the first instance, the user must change his or her password through an external service (for instance, a Web page). The new password is then propagated to each directory while still in plain text. With the second method, a wrapper around the Win32 function (in the case of a Windows desktop) that handles password changes intercepts the plain text password before it is hashed, and then propagates the information to each managed user directory or password file. Neither of these alternatives are elegant solutions to the password problem, but exist as the only currently available alternatives.
While some products, such as NetVision's Synchronicity, include a small password utility that not only lets users change their passwords, but also lets helpdesk operators reset users' passwords, Zoomit Corp.'s Zoomit VIA Server enables password changes by updating the user's password attribute in the metadirectory. It handles this task either through its Compass utility, a Web interface or an LDAP-modify command. |
|
Page 1 | 2 | 3 | 4 | 5 | Next Page |
 Print This Page E-mail this URL |
