shadow man Administrator's Guide
Red Hat Directory Server
Previous      Contents      Index      DocHome      Next     

Chapter 18   Windows Sync


The Windows Sync feature allows synchronization of adds, deletes and changes in groups, user entries, and their passwords between Red Hat Directory Server and both Microsoft Active Directory and Microsoft Windows NT 4.0 Server. It provides an efficient and effective way to maintain consistent directory information across the enterprise.

This chapter covers how to configure and use Windows Sync in the following sections:

About Windows Sync

The complete Windows Sync feature is implemented in three parts:

Figure 18-1 and Figure 18-2 show the relationship between Red Hat Directory Server and Active Directory and Windows NT4 Server primary domain controller (PDC), respectively.

Figure 18-1    Active Directory - Directory Server Synchronization Process

Figure 18-2    Windows NT4 Server - Directory Server Synchronization Process

Windows Sync is compatible with Directory Server's multi-master replication facilities. Figure 18-3 shows this arrangement:

Figure 18-3    Multi-Master Directory Server - Windows Domain Synchronization

How Windows Sync Works

Synchronization is configured and controlled by means of one or more synchronization agreements. These are similar in purpose to replication agreements and contain a similar set of information, including the host name and port number for the Windows server.

The Directory Server connects to its peer Windows server via LDAP and SSL to both send and retrieve updates.

The unit of synchronization is a subtree. A single Windows subtree can be synchronized to a single Directory Server subtree and vice versa. The Windows and Directory Server subtree DNs are specified in the sync agreement. All entries within the respective subtrees are candidates for synchronization, including entries that are not immediate children of the subtree root. However, any descendent container entries will need to be created separately by the administrator. Windows Sync never creates container entries itself.

Windows Sync provides some control over which entries are synchronized. This is intended to allow administrators to determine that only a subset of all the entries should be subject to synchronization and to give sufficient flexibility to support different deployment scenarios. Therefore, certain rules are applied to determine first if a particular entry should be synchronized and second if a given new entry should be created in the peer server.

Specifically, only entries with user or group object classes are synchronized from Windows to Directory Server. In addition, two flags with agreement scope allow the creation of new entries for newly found entries in the Windows server to be enabled or disabled. One flag controls new entry creation for users while the other controls new entry creation for groups. Similarly, only entries with the necessary object classes and attribute values in the Directory Server will be synchronized.

The Directory Server peer maintains a replication changelog, a database that records the modifications that have occurred. The changelog is used by Windows Sync to generate outbound changes made to the Windows server. Therefore, a changelog and the associated replica object must be configured in a Directory Server before it may run Windows Sync.

During normal operation, all the updates made to entries in the Directory Server that need to be sent to the Windows server are generated via the changelog. However, when the server is initially configured or after major changes to its content, it is necessary to initiate a resynchronization process. For resynchronization, the entire contents of synchronized subtree in the Directory Server is examined and, if necessary, sent to the Windows server. This is done without using the changelog.

Inbound changes, that is changes to entries in the Windows server, are found by using Active Directory's Dirsync search feature. Because there is no changelog to use, it is necessary to issue the Dirsync search periodically. The default interval is five minutes. The Dirsync search ensures that only those entries that have changed since the previous search are retrieved.

In the case of a server or where there have been major changes to its content, a Dirsync search that returns all entries (and not just recently changed entries) can be performed. This full synchronization is done whenever the administrator initiates resynchronization, as mentioned before. In some situations, waiting for the next scheduled Dirsync may cause data integrity problem. During this time, recent changes made on the Windows server will not be brought over to the Directory Server. In this case, the administrator can manually initiate an immediate Dirsync search (described in "Manually Initiating Synchronization").

In addition to the entry synchronization mechanisms discussed above, the Password Sync Service is needed to catch password changes made on the Windows server. Without the Password Sync Service, it would be impossible to have inbound password sync because passwords are hashed once stored in Active Directory, and the hashing function is incompatible with that used by Directory Server. Also, it is not possible to retrieve password values from a Windows server externally. Outbound passwords are synchronized along with other entry attributes using a special Directory Server facility for retaining the plaintext password values in the changelog.

Installing Sync Services

There are two services that can be installed on your Windows machine to synchronize more aspects of your Directory Server with a Windows server.

Prerequisites for NT4

Before any synchronization service can be installed on a Windows NT4 server, first make sure that three other programs or libraries are installed:

Installing and Configuring the Password Sync Service

Note  

For Windows NT4 servers, the Password Sync must be installed on a primary domain controller (PDC). Synchronization will not function properly on a non-PDC machine.



Note  

On Windows 2000, password complexity policies must be enabled in order for the password hook DLL to be triggered. By default, these policies are disabled. Refer to the appropriate Windows documentation for more information.



  1. Copy the PassSync.msi file that contains the Password Sync utility to the Windows machine.
  2. Double-click on the PassSync.msi file to install it.
    3. The Password Sync Setup window will appear. Hit "Next" to begin installing.
     
  3. Fill in the Directory Server hostname, secure port number, user name (such as cn=sync manager,cn=config), the certificate token (password), and the search base (e.g., ou=People,dc=example,dc=com).

    4. Note  

    This user must have write access to the userpassword attribute for all users in the synched Directory Server subtree.







    Hit "Next," then "Finish" to install Password Sync.
     
  4. Reboot the Windows machine to start Password Sync.

    5. Note  

    You must reboot the Windows machine. Without rebooting, the password hook DLL will not be enabled, and password synchronization will not function.



Password Sync is installed in C:\Program Files\Red Hat Directory Password Synchronization, and the passsync.exe is the only file in the installation directory.

The following .dlls are installed in C:\winnt\system32 and utilized by Password Sync:

passhook.dll

nsldap32v50.dll

nsldapssl32v50.dll    

libplc4.dll

nsldappr32v50.dll

nss3.dll

libnspr4.dll

ssl3.dll

libplds4.dll

softokn3.dll



The Password Sync Service runs as a Windows service, which means that it can be started, stopped, and controlled by the net start|stop command, the Services Control Panel applet, and other Windows Services management mechanisms.

Changed passwords are captured even if the Password Sync Service is not running. If the Password Sync Service is restarted, the password changes are sent to Directory Server immediately.

Reconfiguring the Password Sync Service

To reconfigure Password Sync:

  1. Open the Add/Remove Services panel.
  2. Find the Red Hat Directory Server Password Sync service in the list of programs.
  3. Click the Change button.
    4. This opens the configuration screens.
     

Setting Up SSL for the Password Sync Service

Next, set up certificates that Password Sync Service will use SSL to access the Directory Server:

  1. Download certutil.exe if you do not already have it installed on your machine. It is available from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/. See "Managing SSL and SASL", for more information on SSL.
  2. Create a new cert8.db and key.db using certutil.exe on the Password Sync machine.

    3. certutil.exe -d . -N

  3. On your Directory Server, export the server certificate using pk12util.

    4. pk12util -d . -P slapd-serverID  -o servercert.pfx -n Server-Cert

  4. Copy the exported certificate from the Directory Server to the Windows machine.
  5. Import the server certificate from the Directory Server into the new certificate database using pk12util.exe.

    6. pk12util.exe -d "C:\Program Files\Red Hat Directory Password Synchronization" -i servercert.pfx

  6. Give "trusted peer" status to the server.

    7. certutil.exe -d "C:\Program Files\Red Hat Directory Password Synchronization" -M -n Server-Cert -t "P,P,P"

    Note  

    If any Windows user accounts exist when you first install Password Sync, then the passwords for those user accounts cannot be synchronized until they are changed because Password Sync cannot de-encrypt a password once it has been encrypted.



Installing and Configuring the NT4 LDAP Service

For Windows NT4 servers, Windows Sync must be configured to a PDC, and all sync services must be installed on a PDC. Synchronization will not function properly on a non-PDC machine.

  1. Double click the ntds.msi file to install.
    2. This is downloaded into C:\Program Files\Red Hat Directory Synchronization.
     
  2. Open C:\Program Files\Red Hat Directory Synchronization\bin, and double-click on installuseresync.bat. This will set up the LDAP Service as a Windows service.
  3. Open C:\Program Files\Red Hat Directory Synchronization\conf. Modify the usersync.conf file to reflect the Directory Server port, SSL port, and hostname.
    4. The only required parameters are server.net.admin.password and server.db.partition.suffix.usersync. In the following code example, these parameters are in bold.
     
    server.net.admin.password sets the password of the account uid=admin,ou=system. This is the bind ID used by the Directory Server to send updates to the NT4 Server.
     
    server.db.partition.suffix.usersync sets the suffix for the NT4 Server, since NT4 Server does not use the same directory tree structure used by Directory Server. This can be set to the same suffix as the Directory Server to which you are synchronizing.
     
    After the service is installed and started the first time, the password can only be changed by an LDAP modify operation, not by editing the configuration file.
     
    #server.net.ldap.port=389
    #server.net.ldaps.port=636
    server.net.admin.password=password33
    javax.net.ssl.keyStore=c:\\keystore
    javax.net.ssl.keyStorePassword=password
    server.net.ldaps.enable=true
    server.db.partition.suffix.usersync=dc=example,dc=com
    # do not modify beyond this point
    server.schemas = org.apache.ldap.server.schema.bootstrap.CoreSchema org.apache.ldap.server.schema.bootstrap.CosineSchema org.apache.ldap.server.schema.bootstrap.ApacheSchema org.apache.ldap.server.schema.bootstrap.InetorgpersonSchema org.apache.ldap.server.schema.bootstrap.JavaSchema org.apache.ldap.server.schema.bootstrap.SystemSchema org.apache.ldap.server.schema.bootstrap.UsersyncSchema
    server.db.partitions=usersync
    server.db.partition.class.usersync=org.apache.ldap.server.NetAPI Partition
    server.db.partition.indices.usersync=ou objectClass
    server.db.partition.attributes.usersync.ou=usersync
    server.db.partition.attributes.usersync.objectClass=top organizationalUnit extensibleObject


    It is not necessary to set the port number. The defaults for both the regular and secure ports are used automatically. Only one port can be used by the LDAP Service; therefore, if you specify a port, you must specifiy either the regular port or the secure port, not both.
     
    If you use SSL, you must signal the service to use SSL by setting the following parameter and provide information for the keystore:
     

    server.net.ldaps.enable=true
    javax.net.ssl.keyStore=c:\\keystore
    javax.net.ssl.keyStorePassword=password

    The keystore information is set in the following step.
     
  4. To enable SSL, do the following.
    1. Create a self-signed certificate using Java keytool:
      2. C:\>keytool -genkey -alias ldap -keyalg RSA -validity 3650 -keystore c:\keystore
       
      Enter keystore password: password
      What is your first and last name?
      [Unknown]: directory.example.com
      What is the name of your organizational unit?
      [Unknown]:
      What is the name of your organization?
      [Unknown]: example.com
      What is the name of your City or Locality?
      [Unknown]: Boston
      What is the name of your State or Province?
      [Unknown]: MA
      What is the two-letter country code for this unit?
      [Unknown]: US
      Is CN=directory.example.com, OU=Unknown, O=example.com, L=Boston, ST=MA, C=US correct?
      [no]: yes
       
      Enter key password for <ldap>
      (RETURN if same as keystore password):
       
      Use the same password for the certificate and keystore.
       
      The first and last name field should be the fully qualified domain name of the machine running the NT4 LDAP Service. If a different value is entered as a security precaution, you must disable the "check hostname against name in certificate" option in your Directory Server SSL configuration.
       
    2. Export the CA certificate you created so that it can be imported into Directory Server.
      3. c:\>keytool -export -alias ldap -keystore c:\keystore -rfc -file c:\ca.cer
       
      Enter keystore password: password
      Certificate stored in file <ca.cer>
       
    3. Copy this file, ca.cer, to your Directory Server machine.
    4. Import the CA using the Console.
      5. In the Tasks tab, select Manage Certificates. Open the CA Certs tab, hit the "Install" button, and import the CA certificate from the directory where you copied it.
       
  5. Open the Services control panel, and right-click on User Sync Service. Select start.

The NT4 LDAP Service runs as a Windows Service, which means that it can be started, stopped, and controlled by the net start|stop command, the Services Control Panel applet, and other Windows Services management mechanisms.

Entry changes are not "stored" by the NT4 LDAP Service when the service is stopped, but the current state of the entries is synchronized automatically when the LDAP Service is restarted.

Uninstalling the Sync Services

To uninstall the Password Sync Service:

  1. Open the Add/Remove Programs utility.
  2. Select click remove to uninstall the Password Sync Service.
  3. If you configured SSL for the Password Sync, then the cert8.db and key3.db databases that were created were not removed when you uninstall Password Sync. Delete these files by hand.

To uninstall the NT4 LDAP Service:

  1. Open C:\Program Files\Red Hat Directory Synchronization\bin, and double-click on uninstalluseresync.bat.
  2. Open the Add/Remove Programs utility.
  3. Select click remove to uninstall the User Sync Service.

Configuring Windows Sync

Step 1: Configure SSL on the Directory Server

To configure the Directory Server to run in SSL. You can use the certutil utility to create self-signed certificates or obtain and install certificates to enable SSL; for more information, see chapter 11, "Managing SSL and SASL."

You should have the following things created and installed on both your Directory Server and your Windows sync peers:

Step 2: Configure SSL on Active Directory (Active Directory only).

To configure SSL on Active Directory, see the appropriate user documentation. It is not necessary to configure SSL for NT4 Server; SSL is enabled when configuring the NT4 LDAP Service.

Step 3: Install and Configure the Password Sync Service

Password Sync can be installed on any Windows machine to synchronize Windows passwords. Passwords can only be synchronized if both your Directory Server and Windows server are running in SSL, the sync agreement is configured over an SSL connection, and you have configured certificate databases for Password Sync to access. See "Installing and Configuring the Password Sync Service", for information on installing and configuring Password Sync.

Step 4: Configure the NT4 LDAP Service (Windows NT4 Server Only)

Install the LDAP Service on the Windows NT4 Server, set it up as a Windows service, and modify the configuration file for your Directory Server information. See "Installing and Configuring the NT4 LDAP Service", for more information.

Step 5: Select or Create the Sync Identity

The Windows user specified in the sync agreement, which the Directory Server will use to bind for sync operations, should be a member of the Domain Admins group (or have equivalent privileges). A member of this group has full privileges within the domain, but will not necessarily have privileges within other domains in the Active Directory deployment. This enhances security by limiting the extent that the Windows directory can be affected by the sync ID to only the synchronized subtree.

Tip  

It may be useful to lock this admin user from being able to logon to the domain from a physical location. The entry would be able to modify the directory entries, but no one could use that entry to gain access to the domain. Refer the Windows documentation for more information.



The user specified in the Password Sync and NT4 LDAP Services should be a a special user that has write access to entries and passwords but, for security reasons, should not be Directory Manager. Also, this user should not be under the synchronized subtree. For information on creating a special sync ID, see "Creating the Supplier Bind DN Entry".

Step 6: Create the Synchronization Agreement

To create a synchronization agreement:

  1. In the Directory Server Console, select the Configuration tab.
  2. In the left-hand navigation tree, right-click on the suffix to sync, and select New Synchronization Agreement. You can also highlight the suffix, and select Menu>Object>New Synchronization Agreement.
    3. This will start the Synchronization Agreement Wizard.
     
  3. In the two fields, supply a name and description of your synchronization agreement. Hit "Next."
  4. The second screen reads "Windows Sync Server Info." By default, your Directory Server hostname and port are visible at the top, under Supplier. At the very bottom of the screen, the name of the synched suffix, such as dc=example,dc=com, is displayed.




  5. In the middle of the screen are fields for your Windows domain information. Fill in the domain name and the domain controller.
  6. Select the checkbox(es) for the Windows entries you are going to synchronize.
  7. The Windows and Directory Server subtree information is automatically filled in; use the defaults to sync only users or change these as appropriate to sync groups or groups and users.
  8. Check the "Using encrypted SSL connection" checkbox. The use of SSL is recommended for security reasons. You must use SSL if you are going to synchronize passwords because Active Directory will refuse to modify passwords unless the connection is SSL protected.
  9. Fill in the authentication information in the "Bind as..." and "Password" fields with the sync manager information.
  10. The last screen is a summary of your synchronization agreement. If you decide to change anything at this point, you can use the back buttons to get to the appropriate screen. If you are satisfied with your agreement, click "Done."

When you have finished, an icon representing the synchronization agreement is displayed under the suffix. This icon indicates that your synchronization agreement is set up.

Step 6: Begin Synchronization

After the sync agreement is created, you need to begin the synchronization process. Select the sync agreement, right-click or open the Object menu, and select "Initiate re-synchronization." This will begin the synchronization process.

If synchronization stops for any reason, you can initiate resynchronization by selecting this from the sync agreement menu.

Using Windows Sync

After your Windows Sync service has been installed and configured, you can begin using it to synchronize your user and group entries on your Directory Server and Windows NT4 Server or Active Directory servers.

This section deals with how to move existing entries between servers, how to create and delete entries, and checking the status of synchronization.

Synchronized Entries

Special schema isapplied to entries in the Directory Server that are subject to synchronization. This schema isvery similar (but not identical) to that used by Netscape Directory Server 4.x NT Sync. Full schema details are available in Red Hat Directory Server Schema Reference.

Table 18-1 shows the attributes that are mapped between the Directory Server and Windows servers, and Table 18-2 shows the attributes that are the same between the Directory Server and Windows servers.


Table 18-1    User Entry Schema Mapping between Directory Server and Windows Servers


Directory Server

Active Directory

Windows NT4 Server

cn

name

usri_full_name

ntUserDomainId

sAMAccountName

ntUserHomeDir

homeDirectory

usri_home_dir

ntUserScriptPath

scriptPath

usri_script_path

ntUserLastLogon

lastLogon

usri_last_logon

ntUserLastLogoff

lastLogoff

usri_last_logoff

ntUserAcctExpires

accountExpires

usri_acct_expires

ntUserCodePage

codePage

usri_code_page

ntUserLogonHours

logonHours

usri_logon_hours

ntUserMaxStorage

maxStorage

usri_max_storage    

ntUserProfile

profilePath

usri_profile

ntUserParms

userParameters

usri_parms

ntUserWorkstations    

userWorkstations    

usri_workstations    




Table 18-2    User Entry Schema That Is the Same in Directory Server and Windows Servers


description

postOfficeBox

destinationIndicator

postalAddress

facsimileTelephoneNumber    

postalCode

givenName

registeredAddress

homePhone

sn

homePostalAddress

st

initials

street

l

telephoneNumber

mail

teletexTerminalIdentifier    

mobile

telexNumber

o

title

ou

userCertificate

pager

x121Address

physicalDeliveryOfficeName



When you create a Directory Server user from the Console (see "Creating Directory Entries"), there is an NT User tab in the New User dialog. Fill in this information to supply Windows attributes automatically.





You can add additional ntUser attributes either by using the Advanced button in the Console or by using ldapmodify; see "Modifying Entries Using ldapmodify".

Groups

Similar to user entires, group entries are synchronized if they have the ntGroup and mailgroup object classes. There are also two attributes that control creation and deletion of group entries in the Windows server: ntGroupCreateNewAccount and ntGroupDeleteAccount.

Group entries that are within the scope of the sync agreement will be synchronized in much the same way as user entries. In addition, the membership of groups is synchronized with the constraint that only those members that are also within the scope of the agreement are propagated. The result is that a group may contain members that are both within and without the scope of the agreement, but only the subset of members that are themselves within agreement scope are synchronized. The remaining members are left unchanged on both sides.

Table 18-3 shows the attributes that are mapped between the Directory Server and Windows servers, and Table 18-4 shows the attributes that are the same between the Directory Server and Windows servers.


Table 18-3    Group Entry Schema Mapping between Directory Server and Windows Servers


Directory Server

Active Directory

Windows NT4 Server

cn

name

ntGroupAttributes

groupAttributes

grpi_attributes

ntGroupId

cn
name
samAccountName

grpi_name

ntGroupType

groupType

uniqueMember

member

grpi_member




Table 18-4    Group Entry Schema that are directly mapped between Directory Server and Windows Servers


seeAlso

l

description

ou



Manually Initiating Synchronization

While synchronization always occurs based on the schedule set in the synchronization agreement, you can manually update the synchronized subtree.

A manual update synchronizes entries which have been changed since the last synchronization process. To perform an update manually:

  1. Go to the Configuration tab in the Console.
  2. Right-click on the synchronization agreement icon.
  3. Select "Send and Receive Updates Now" from the drop down menu.

To send a total update (resynchronizing every entry in the Directory Server and Windows server):

  1. Go to the Configuration tab in the Console.
  2. Right-click on the synchronization agreement icon.
  3. Select "Initiate re-synchronization" from the drop down menu.

This will not delete or overwrite your data on the sync peer; it sends and receives all updates and adds any new or modified Directory Server entries (such as a pre-existing Directory Server user that had the ntUser object class added to it).

The Need for Resynchronization

Entries are synchronized provided they are in the subtree configured with the sync agreement and able to be synchronized. There are some cases where an entry can be initially not subject to the agreement (for example, if it lacks the ntUser object class) but subsequently becomes subject to the agreement (if the ntUser object class is later added).

In cases like these, the Directory Server is not able to identify the entry's change in status with normal update processing, and it fails to create the corresponding entry in the Windows server (in the case that that entry does not already exist).

A resynchronization process recognizes and synchronizes such entries. Resynchronization need only be performed once to identify all previously-unsynched entries.

Checking Synchronization Status

You can check synchronization status

  1. Open the Status tab of the Console.
  2. Highlight the synchronization agreement to monitor.
    3. The relevant information appears in the right-hand pane.
     
  3. From the Status area, determine whether the last incremental and total updates were successful and when they occurred.

The total update time shows when the last resynchronization operation completed.

Modifying the Synchronization Agreement

It is possible to modify parts of the synchronization agreement after it has been created.

In the Configuration>Replication tab of the Directory Server Console, select the sync agreement icon from beneath the database. There are two tabs: Summary, and Connection.

Active Directory Schema Compatibility

Although Active Directory supports the same basic X.500 object classes as Directory Server, there are a few subtle incompatibilities of which administrators should be aware:

NT4-Specific Limitations

The NT4 LDAP Service attempts to reflect the NT4 NTLM user database (as accessed via the Net API) in LDAP. In general, this works well, but there are some fundamental incompatibilities between LDAP schema and the underlying data store. These incompatibilities are listed below:

Troubleshooting

If synchronization does not seem to be functioning properly, see the Windows event log and/or Directory Server error log for information on any potential problems.

You can also enable replication logging for more detailed information on synchronization to be recorded in the error logs:

  1. In the Console, click the Configuration tab, select Logs from the navigation menu on the right, and open the Error Log.
  2. Scroll down to error log level, and select Replication from the menu. Hit save.
    3. For complete information on error log levels, refer to Red Hat Directory Server Configuration, Command, and File Reference.
     

This will produce verbose logging from the sync code that can help in diagnosing problems.

Error 1 NTDS: javax.naming.NamingException: can't invoke ssl filter

There is a problem with the location of your keystore, the keystore filename, the path is not escaped correctly, or you have configured wrong keystore password in the usersync.conf file.

Error 2 NTDS: org.apache.ldap.common.exception.LdapConfigurationException: Failed to bind the LDAP protocol service to the service registry: (SOCKET, ldap, 0.0.0.0/0.0.0.0:389) [Root exception is java.net.BindException: Address already in use: bind]

The port you are attempting to use is already in use.

Error 3 NTDS: javax.naming.NamingException: ERROR: Admin password not set. Server not starting for security reasons.

It is mandatory to set a password for the admin account for the NT4 LDAP service. There is no default password.

Error 4 NT4 and Active Directory: The message box when creating the sync agreement indicates that the it cannot connect to Active Directory.

Make sure that the directory suffixes, Windows domain and domain host, and the administrator DN and password are correct. Also verify that the port numbers used for LDAPS is correct. If all of this is correct, make sure that Active Directory or teh Windows machine are running.

Error 5 NT4 and Active Directory: After synchronization, the status shows error 81.

One of the sync peer servers has not been properly configured for SSL communication. Examine the Directory Server access log file to see if the connection attempt was received by the Directory Server. You may also find helpful messages in the Directory Server's error log file.

To narrow down the source of the misconfiguration, try to establish an LDAPS connection to the Directory Server. If this connection attempt fails, check all values (port number, hostname, search base, and so forth) to see if any of these are the problem. If all else fails, reconfigure the Directory Server with a new certificate.

If the LDAPS connection is successful, it is likely that the misconfiguration is on the Windows server. Check that you have properly configured the NT4 LDAP Service and Password Sync for SSL and that the NT4 LDAP Service is running. Examine the Windows event log file for error messages.

Note  

A common problem is to fail to trust either your certificate authority when configuring Windows Sync service certificates or the Active Directory or NT4 Server certificate authority in the Directory Server.





Previous      Contents      Index      DocHome      Next     

© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002-2004 Netscape Communications Corporation, 2005 Red Hat, Inc. All rights reserved.
Read the Full Copyright and Third-Party Acknowledgments.


Last Updated June 09, 2008