LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services

Sun ONE Identity Synchronization for the Windows Technology

The Netscape Directory Server 4.1x software provided a facility for synchronizing user account data between a Windows NT Primary Domain Controller (PDC) and the directory. The technology was later bundled into the Sun ONE Meta-directory product. Since this technology was introduced, Microsoft has standardized on user authentication based on their Active Directory (AD) technology. While there might be some enterprises still using the old LAN manger style authentication service for which PDCs were based, most have switched to the new AD technology.

To interoperate in an AD environment, the Active Directory Connector for the Sun ONE Meta-directory Server was introduced. This product synchronizes user profile data for AD to the directory and from the directory to AD. This allows user information such as email addresses, phone numbers , and so on, to be shared between the Sun ONE Directory Server and AD. However, the AD Connector does not support password synchronization.

As an adjunct to Sun ONE Directory Server 5.2 software, the Sun ONE Identity Synchronization for the Windows (ISW) software was introduced. With the addition of this product and underlying technology, user passwords can be synchronized between Windows environments and the Solaris OE. This section describes this product and gives an overview of how it is configured and managed. Because of the complexity of the implementation, only an overview is presented. Full details can be found in the product documentation.

ISW Product Overview

The ISW 1.0 software provides bidirectional synchronization of passwords between Windows directories. This includes both Windows 2000 AD and the NT Security Access Manager (SAM) registry. If passwords are updated on the Sun ONE Directory Server software, they can be propagated to the Windows environment without the addition of software on the Windows system. If you want to update passwords in a Windows NT directory and have the passwords propagated to the Sun ONE Directory Server software, software must be added to the Windows system. No additional software is required to synchronize with AD.

The ISW 1.0 software is implemented primarily as a set of connectors. There is a connector for AD and one for NT SAM. The connectors can be used to connect to more than one controller or domain. To protect the passwords, transfers are made over an encrypted TLS/SSL LDAP channel. Not all passwords need to be synchronized. The administrator has the ability to specify a list of users who will have their passwords synchronized. Attributes other than userPassword can be synchronized.

A core component of ISW 1.0 is the Sun ONE Message Queue (MQ) that implements the Java Message Service (JMS). The Sun ONE MQ software provides secure and reliable message transfers. This is key because you need to protect the integrity of passwords and do not want password changes to be lost. The Sun MQ software establishes a trust between connectors and ensures that all password update messages are delivered. Another benefit of this approach is ease of system administration.

Deployment Scenarios

The ISW 1.0 software provides a great deal of flexibility. You can deploy unidirectional or bidirectional password synchronization between the Sun ONE Directory Server software and Windows 2000 AD, or between Sun ONE Directory Server software and Windows NT SAM. To understand how these deployment scenarios work, it is helpful to examine how passwords are propagated.

Keep in mind, that for password synchronization to work, updates need to be captured in clear text before they are committed to the directory. This is because passwords are stored in a one-way hash, so once committed cannot be reversed . Windows directories support different hashing algorithms than Sun ONE Directory Server software, so it is not sufficient to simply copy over the hashed version of the password. The directory must be able to capture the password in the clear so it can be hashed .

The following sections describe how password transfers occur with different scenarios.

Scenario 1 Sun ONE Directory Server Software to Windows 2000 Active Directory

Assuming the user's password is changed from the Secured LDAP Client:

  1. A user makes a password change by running the Solaris OE passwd(1) command.

  2. The new password is passed to the directory as a text string over an encrypted TLS/SSL connection.

  3. The Sun ONE Directory Server plug-in detects the change then sends it to the Sun ONE MQ over an encrypted connection. The directory database is updated.

  4. The Sun ONE MQ sends the password update message to the AD connector.

  5. The AD connector sends the password change to the Windows 2000 AD server, where it is committed.

  6. The Sun ONE MQ updates the appropriate log files.

Scenario 2 Windows 2000 Active Directory to Sun ONE Directory Server Software

Assuming the user password is changed from a Windows client:

  1. The password change is sent to the AD, controller where it is committed.

  2. The AD Connector detects a password change by monitoring the AD change log.

  3. The AD Connector sends a password change event notification to the Sun ONE Directory Server Connector.

  4. The corresponding user password in the directory is marked as invalid.

  5. The user logs into a Secured LDAP Client

  6. The Sun ONE Directory Server software plug-in detects an attempted login with a password marked invalid.

  7. The Sun ONE Directory Server software plug-in sends the password to the AD Connector.

  8. The AD Connector attempts to log into the AD Controller using the password sent to it.

  9. If the login is successful, the user is authenticated and the directory is updated with the new password.

Scenario 3 Windows NT SAM to Sun ONE Directory Server Software

In this scenario, a Change Detector DLL is installed on the Windows NT PDC.

  1. The user makes a password change on a Windows client.

  2. The Windows client sends the password change to the Windows PDC.

  3. The DLL installed on the PDC detects the change and intercepts it before it is committed to the SAM.

  4. The intercepted password is sent to the Sun ONE Directory Server software over an encrypted connection, where it is committed to the directory.

Administration Issues

The ISW 1.0 software is very flexible, offering several deployment options. Because of this flexibility, there are several administration decisions that need to be made. These include:

  • Defining what user account entries look like.

  • Deciding which users will have their passwords synchronized.

  • Implementing either unidirectional or bidirectional synchronization.

  • Creating Connector/Sun ONE MQ trust relationships.

  • Configuring directories or domains that are to be synchronized.

  • Automating the initial population of directories.

Conclusion

The ISW 1.0 software is a sophisticated and comprehensive solution for creating a unified login between the Solaris OE and Windows environments. Providing password synchronization between these two disparate environments is not a trivial task. Security must be maintained at all components and the synchronization must be performed reliably.

One could almost write an entire book based on the ISW 1.0 software. What was presented here is just an overview and a guide to get started. It is strongly recommended that experienced consulting services be enlisted before using this product in production mode.

Related

Категории