Oracle® Internet Directory Administrator's Guide 10g (9.0.4) Part Number B12118-01 |
|
Considerations for Integrating with Third-Party Directories , 4 of 11
Regardless of which directory is the central enterprise directory, the password can be stored in one or both directories. There are advantages and disadvantages to each option. This section contains these topics:
By reducing to one the number of points of possible attack, storing the password in only one directory can make the password more secure. Moreover, it eliminates synchronization issues when the password is modified.
On the other hand, storing the password in one directory provides a single point of failure for the entire network. If the directory that fails is a third-party one, then even though user footprints are available in Oracle Internet Directory, users cannot access Oracle components.
Moreover, although storing passwords in only the central directory eliminates any possible synchronization issues, it requires you to enable applications to authenticate users to that directory. This involves using the appropriate plug-ins. For example, if you are using Microsoft Active Directory as both the central enterprise directory and the central password store, then you must enable applications to authenticate users to Microsoft Active Directory. You do this by using an external authentication plug-in. A similar mechanism is supported for authentication against SunONE Directory Server.
If you decide to store the password in both directories, then passwords need to be synchronized, ideally in real-time.
In Oracle Internet Directory 10g (9.0.4), passwords are not synchronized in real time, but according to a schedule. This can mean an observable delay between the time the password is changed in the central directory and the time that the change is recorded in the other directory. In deployments with Oracle Internet Directory as the central directory, password values are synchronized on a regular basis from Oracle Internet Directory to the connected directory. This synchronization requires you to enable both the password policy of the realm and reversible encryption.
See Also:
|
In general, password values are hashed. If both directories use the same hashing algorithm, then the hashed values can be synchronized as they are. For example, suppose that you have an environment in which SunONE Directory Server and Oracle Internet Directory are integrated. Both of these directories support common hashing algorithms. Now, if the passwords are hashed and stored in SunONE Directory Server by using a hashing technique supported by Oracle Internet Directory, then synchronizing them from SunONE Directory Server to Oracle Internet Directory is the same as with any other attribute.
However if both directories do not support same hashing algorithm, then passwords must be synchronized in cleartext format only. For security reasons, password synchronization is possible with Oracle Internet Directory only in SSL Mode 2--that is, server-only authentication.
If Oracle Internet Directory is the source of truth, and if the hashing algorithm it supports is not supported by the other directory, then synchronization is still possible through SSL mode 2 (sslmode=2
) when reversible password encryption is enabled.
If Microsoft Active Directory is the source of truth, then, when a password is modified in Microsoft Active Directory, a plug-in intercepts the password changes and stores the modified password in a new attribute, preferably in an encrypted form. That attribute can then be synchronized to Oracle Internet Directory. A similar process is required if Oracle Internet Directory is the central enterprise directory and central password store.
See Also:
The following chapters for more detailed information about password synchronization:
The following chapter for information about plug-ins: |
|
![]() Copyright © 1999, 2003 Oracle Corporation. All Rights Reserved. |
|