| Identity Management GuideChapter 9. Identity: Integrating with Microsoft Active Directory Through SynchronizationIdentity Management uses active synchronization to integrate user data stored in an Active Directory domain and the user data stored in the IdM domain. Critical user attributes, including passwords, are synchronized between the services. The capability to sync Active Directory and IdM domains is inherent when an IdM server is first installed. The synchronization process is configured by creating agreements between the IdM server and the Active Directory domain controller. This chapter describes how to configure synchronization, how to configure Active Directory for integration with IdM, and how to configure Windows systems within the Active Directory domain to be aware of the IdM domain. 9.1. About Active Directory and Identity ManagementWithin the IdM domain, information is shared among servers and replicas by copying that information, reliably and predictably, between the data masters (servers) and other data masters. This process is replication. A similar process can be used to share data between the IdM domain and a Microsoft Active Directory domain. This is synchronization. Synchronization is the process of copying data back and forth between Active Directory and Identity Management. Synchronization is defined in an agreement between an IdM server and an Active Directory domain controller. The sync agreement defines all of the information required to identify sync-able user entries (like the subtree to synchronize and requisite object classes in the user entries) as well as defining how account attributes are handled. The sync agreements are created with default values which can be tweaked to meet the needs of a specific domain. When two servers are involved in synchronization, they are called peers. Synchronization is most commonly bi-directional. Information is sent back and forth between the IdM domain and the Windows domain in a process that is very similar to how IdM servers and replicas share information among themselves. It is possible to configure synchronization - or certain data areas - to only sync one way. That is uni-directional synchronization. To prevent the risk of data conflicts, synchronization is configured between one Identity Management server and one Active Directory domain controller. The Identity Management server propagates changes back to the IdM domain, while the domain controller propagates changes back to the Windows domain. There are some key features to IdM synchronization: A synchronization operation runs every five minutes. Synchronization can only be configured with one Active Directory domain. Multiple domains are not supported. Synchronization can only be configured with one Active Directory domain controller. However, it is possible to have a list of failover Active Directory domain controllers. Likewise, there can be a list of failover IdM servers to keep synchronization uninterrupted. Only user information is synchronized. Both user attributes and passwords can be synchronized. While modifications are bi-directional (going both from Active Directory to IdM and from IdM to Active Directory), creating or adding accounts are only uni-directional, from Active Directory to Identity Management. New accounts created in Active Directory are synchronized over to IdM automatically. However, user accounts created in IdM must also be created in Active Directory before they will be synchronized. Account lock information is synchronized by default, so a user account which is disabled in one domain is disabled in the other. Password synchronization changes take effect immediately.
When Active Directory users are synchronized over to IdM, certain attributes (including Kerberos and POSIX attributes) will have IPA attributes are automatically added to the user entries. These attributes are used by IdM within its domain. They are not synchronized back over the corresponding Active Directory user entry. Some of the data in synchronization can be modified as part of the synchronization process. For examples, certain attributes can be automatically added to Active Directory user accounts when they are synced over to the IdM domain. These attribute changes are defined as part of the synchronization agreement and are described in Section 9.4.3, "Changing the Behavior for Syncing User Account Attributes". 9.2. About Synchronized AttributesIdentity Management synchronizes a subset of user attributes between IdM and Active Directory user entries. Any other attributes present in the entry, either in Identity Management or in Active Directory, are ignored by synchronization. Most POSIX attributes are not synchronized. Although there are significant schema differences between the Active Directory LDAP schema and the 389 Directory Server LDAP schema used by Identity Management, there are many attributes that are the same. These attributes are simply synchronized between the Active Directory and IdM user entries, with no changes to the attribute name or value format. User Schema That Are the Same in Identity Management and Windows Servers Some attributes have different names but still have direct parity between IdM (which uses 389 Directory Server) and Active Directory. These attributes are mapped by the synchronization process. Table 9.1. User Schema Mapped between Identity Management and Active Directory | Identity Management | Active Directory |
|---|
| cn | name | | nsAccountLock | userAccountControl | | ntUserDomainId | sAMAccountName | | ntUserHomeDir | homeDirectory | | ntUserScriptPath | scriptPath | | ntUserLastLogon | lastLogon | | ntUserLastLogoff | lastLogoff | | ntUserAcctExpires | accountExpires | | ntUserCodePage | codePage | | ntUserLogonHours | logonHours | | ntUserMaxStorage | maxStorage | | ntUserProfile | profilePath | | ntUserParms | userParameters | | ntUserWorkstations | userWorkstations |
9.2.1. User Schema Differences between Identity Management and Active DirectoryEven though attributes may be successfully synced between Active Directory and IdM, there may still be differences in how Active Directory and Identity Management define the underlying X.500 object classes. This could lead to differences in how the data are handled in the different LDAP services. This section describes the differences in how Active Directory and Identity Management handle some of the attributes which can be synchronized between the two domains. 9.2.1.1. Values for cn AttributesIn 389 Directory Server, the cn attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Identity Management cn attribute is synchronized, then, only one value is sent to the Active Directory peer. What this means for synchronization is that,potentially, if a cn value is added to an Active Directory entry and that value is not one of the values for cn in Identity Management, then all of the Identity Management cn values are overwritten with the single Active Directory value. One other important difference is that Active Directory uses the cn attribute as its naming attribute, where Identity Management uses uid. This means that there is the potential to rename the entry entirely (and accidentally) if the cn attribute is edited in the Identity Management. If that cn change is written over to the Active Directory entry, then the entry is renamed, and the new named entry is written back over to Identity Management. 9.2.1.2. Values for street and streetAddressActive Directory uses the attribute streetAddress for a user's postal address; this is the way that 389 Directory Server uses the street attribute. There are two important differences in the way that Active Directory and Identity Management use the streetAddress and street attributes, respectively: In 389 Directory Server, streetAddress is an alias for street. Active Directory also has the street attribute, but it is a separate attribute that can hold an independent value, not an alias for streetAddress. Active Directory defines both streetAddress and street as single-valued attributes, while 389 Directory Server defines street as a multi-valued attribute, as specified in RFC 4519.
Because of the different ways that 389 Directory Server and Active Directory handle streetAddress and street attributes, there are two rules to follow when setting address attributes in Active Directory and Identity Management: The synchronization process maps streetAddress in the Active Directory entry to street in Identity Management. To avoid conflicts, the street attribute should not be used in Active Directory. Only one Identity Management street attribute value is synced to Active Directory. If the streetAddress attribute is changed in Active Directory and the new value does not already exist in Identity Management, then all street attribute values in Identity Management are replaced with the new, single Active Directory value.
9.2.1.3. Constraints on the initials AttributeFor the initials attribute, Active Directory imposes a maximum length constraint of six characters, but 389 Directory Server does not have a length limit. If an initials attribute longer than six characters is added to Identity Management, the value is trimmed when it is synchronized with the Active Directory entry. 9.2.1.4. Requiring the surname (sn) AttributeActive Directory allows person entries to be created without a surname attribute. However, RFC 4519 defines the person object class as requiring a surname attribute, and this is the definition used in Directory Server. If an Active Directory person entry is created without a surname attribute, that entry will not be synced over to IdM since it fails with an object class violation. 9.2.2. Active Directory Entries and RFC 2307 AttributesWindows uses unique, random security IDs (SIDs) to identify users. These SIDs are assigned in blocks or ranges, identifying different system user types within the Windows domain. When users are synchronized between Identity Management and Active Directory, Windows SIDs for users are mapped to the Unix UIDs used by the Identity Management entry. Another way of saying this is that the Windows SID is the only ID within the Windows entry which is used as an identifier in the corresponding Unix entry, and then it is used in a mapping. When Active Directory domains interact with Unix-style applications or domains, then the Active Directory domain may use Services for Unix or IdM for Unix to enable Unix-style uidNumber and gidNumber attributes. This allows Windows user entries to follow the specifications for those attributes in RFC 2307. However, the uidNumber and gidNumber attributes are not actually used as the uidNumber and gidNumber attributes for the Identity Management entry. The Identity Management uidNumber and gidNumber attributes are generated when the Windows user is synced over. The uidNumber and gidNumber attributes defined and used in Identity Management are not the same uidNumber and gidNumber attributes defined and used in the Active Directory entry, and the numbers are not related. 9.3. Setting up Active Directory for SynchronizationSynchronizing user accounts alone is enabled within IdM, so all that is necessary is to set up a sync agreement ( Section 9.4.2, "Creating Synchronization Agreements"). On the Windows server, it is necessary to create the user that the IdM server will use to connect to the Active Directory domain. Grant the sync user account Replicating directory changes rights to the synchronized Active Directory subtree. Replicator rights are required for the sync user to perform synchronization operations. Add the sync user as a member of the Account Operator and Enterprise Read-Only Domain controller groups. It is not necessary for the user to belong to the full Domain Admin group.
9.4. Managing Synchronization Agreements9.4.1. Trusting the Active Directory and IdM CA CertificatesBoth Active Directory and Identity Management use certificates for server authentication. For the Active Directory and IdM SSL server certificates to be trusted by each other, both servers need to trust the CA certificate for the CA which issued those certificates. This means that the Active Directory CA certificate needs to be imported into the IdM database, and the IdM CA certificate needs to be imported into the Active Directory database. On the Active Directory server, download the IdM server's CA certificate from http://ipa.example.com/ipa/config/ca.crt. Install the IdM CA certificate in the Active Directory certificate database. This can be done using the Microsoft Management Console or the certutil utility. For example: certutil -installcert -v -config "ipaserver.example.com\Example Domain CA" c:\path\to\ca.crt For more details, see the Active Directory documentation. Export the Active Directory CA certificate. In My Network Places, open the CA distribution point. For example, the location on Windows Server 2003 is C:\WINDOWS\system32\certsrv\CertEnroll\. Double-click the security certificate file (.crt file) to display the Certificate dialog box. On the Details tab, click Copy to File to start the Certificate Export Wizard. Click Next, and then select Base-64 encoded X.509 (.CER). Specify a suitable directory and file name for the exported file. Click Next to export the certificate, and then click Finish.
Copy the Active Directory certificate over to the IdM server machine. Download the IdM server's CA certificate from http://ipa.example.com/ipa/config/ca.crt. Copy both the Active Directory CA certificate and the IdM CA certificate into the /etc/openldap/cacerts/ directory. Update the hash symlinks for the certificates. cacertdir_rehash /etc/openldap/cacerts/ Edit the /etc/openldap/ldap.conf file, and add the information to point to and use the certificates in the /etc/openldap/cacerts/ directory. TLS_CACERTDIR /etc/openldap/cacerts/TLS_REQCERT allow
9.4.2. Creating Synchronization AgreementsSynchronization agreements are created on the IdM server using the ipa-replica-manage connect command because it creates a connection to the Active Directory domain. The options to create the synchronization agreement are listed in Table 9.2, "Synchronization Agreement Options". Remove any existing Kerberos credentials on the IdM server. $ kdestroy Use the ipa-replica-manage command to create a Windows synchronization agreement. This requires the --winsync option. If passwords will be synchronized as well as user accounts, then also use the --passsync option and set a password to use for Password Sync. The --binddn and--bindpwd options give the username and password of the system account on the Active Directory server that IdM will use to connect to the Active Directory server. $ ipa-replica-manage connect --winsync --binddn cn=administrator,cn=users,dc=example,dc=com --bindpw Windows-secret --passsync secretpwd --cacert /etc/openldap/cacerts/windows.cer adserver.example.com -v When prompted, enter the Directory Manager password. Table 9.2. Synchronization Agreement Options | Option | Description |
|---|
| --winsync | Identifies this as a synchronization agreement. | | --binddn | Gives the full user DN of the synchronization identity. This is the user DN that the IdM LDAP server uses to bind to Active Directory. This user must exist in the Active Directory domain and must have replicator, read, search, and write permissions on the Active Directory subtree. | | --bindpw | Gives the password for the sync user. | | --passsync | Gives the password for the Windows user account which is involved in synchronization. | | --cacert | Gives the full path and file name of the Active Directory CA certificate. This certificate is exported in Section 9.4.1, "Trusting the Active Directory and IdM CA Certificates". | | --win-subtree | Gives the DN of the Windows subtree containing the users to synchronize. The default value is cn=Users,$SUFFIX. | | AD_server_name | Gives the hostname of the Active Directory domain controller. |
9.4.3. Changing the Behavior for Syncing User Account AttributesWhen the sync agreement is created, it has certain default behaviors defined for how the synchronization process handled the user account attributes during synchronization. The types of behaviors are things like how to handle lockout attributes or how to handle different DN formats. This behavior can be changed by editing the synchronization agreement. The list of attribute-related parameters are in Table 9.3, "Synced Attribute Settings". The sync agreement exists as a special plug-in entry in the LDAP server and each attribute behavior is set through an LDAP attribute. To change the sync behavior, use the ldapmodify command to modify the LDAP server entry directly. For example, account lockout attributes are synchronized between IdM and Active Directory by default, but this can be disabled by editing the ipaWinSyncAcctDisable attribute. (Changing this means that if an account is disabled in Active Directory, it is still active in IdM and vice versa.) [jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w passworddn: cn=ipa-winsync,cn=plugins,cn=configchangetype: modifyreplace: ipaWinSyncAcctDisableipaWinSyncAcctDisable: nonemodifying entry "cn=ipa-winsync,cn=plugins,cn=config" Table 9.3. Synced Attribute Settings | Parameter | Description | Possible Values |
|---|
| General User Account Parameters | | | ipaWinSyncNewEntryFilter | Sets the search filter to use to find the entry which contains the list of object classes to add to new user entries. | The default is (cn=ipaConfig). | | ipaWinSyncNewUserOCAttr | Sets the attribute in the configuration entry which actually contains the list of object classes to add to new user entries. | The default is ipauserobjectclasses. | | ipaWinSyncHomeDirAttr | Identifies which attribute in the entry contains the default location of the POSIX home directory. | The default is ipaHomesRootDir. | | ipaWinSyncUserAttr | Sets an additional attribute with a specific value to add to Active Directory users when they are synced over from the Active Directory domain. If the attribute is multi-valued, then it can be set multiple times, and the sync process adds all of the values to the entry. This only sets the attribute value if the entry does not already have that attribute present. If the attribute is present, then the entry's value is used when the Active Directory entry is synced over. | ipaWinSyncUserAttr: attributeName attributeValue | | ipaWinSyncUserFlatten | Sets whether to normalize the DN of Active Directory entries to conform with the IdM directory structure. In IdM, all users are stored under the cn=users,cn=accounts,$SUFFIX entry, but Active Directory can have more branches in its directory, which can result in DNs like cn=John Smith,ou=Development,ou=Engineering,cn=users,dc=example,dc=com. Flattening the DN discards any additional intervening organizational units in the Active Directory DN and creating a simple DN on the IdM side. Any ou attributes are stored in the IdM user entry. | true | false | | ipaWinSyncForceSync | Sets whether to check existing IdM users which match an existing Active Directory user should be automatically edited so they can be synchronized. If an IdM user account has a uid parameter which is identical to the samAccountName in an existing Active Directory user, then that account is not synced by default. This attribute tells the sync service to add the ntUser and ntUserDomainId to the IdM user entries automatically, which allows them to be synchronized. | true | false | | User Account Lock Parameters | | | ipaWinSyncAcctDisable | Sets which way to synchronize account lockout attributes. It is possible to control which account lockout settings are in effect. For example, to_ad means that when account lockout attribute is set in IdM, its value is synced over to Active Directory and overrides the local Active Directory value. By default, account lockout attributes are synced from both domains. | both (default) to_ad to_ds none
| | ipaWinSyncInactivatedFilter | Sets the search filter to use to find the DN of the group used to hold inactivated (disabled) users. This does not need to be changed in most deployments. | The default is (&(cn=inactivated)(objectclass=groupOfNames)). | | ipaWinSyncActivatedFilter | Sets the search filter to use to find the DN of the group used to hold active users. This does not need to be changed in most deployments. | The default is (&(cn=activated)(objectclass=groupOfNames)). | | Group Parameters | | | ipaWinSyncDefaultGroupAttr | Sets the attribute in the new user account to reference to see what the default group for the user is. The group name in the entry is then used to find the gidNumber for the user account. | The default is ipaDefaultPrimaryGroup. | | ipaWinSyncDefaultGroupFilter | Sets the search filter to map the group name to the POSIX gidNumber. | The default is (&(gidNumber=*)(objectclass=posixGroup)(cn=groupAttr_value)). | | Realm Parameters | | | ipaWinSyncRealmAttr | Sets the attribute which contains the realm name in the realm entry. | The default is cn. | | ipaWinSyncRealmFilter | Sets the search filter to use to find the entry which contains the IdM realm name. | The default is (objectclass=krbRealmContainer). |
9.4.4. Changing the Synchronized Windows SubtreeCreating a synchronization agreement automatically sets the two subtrees to use as the synchronized user database. In IdM, the default is cn=users,cn=accounts,$SUFFIX, and for Active Directory, the default is CN=Users,$SUFFIX. The value for the Active Directory subtree can be set to a non-default value when the sync agreement is created by using the --win-subtree option. After the agreement is created, the Active Directory subtree can be changed by using the ldapmodify command to edit the nsds7WindowsReplicaSubtree value in the sync agreement entry. Get the name of the sync agreement, using ldapsearch. This search returns only the values for the dn and nsds7WindowsReplicaSubtree attributes instead of the entire entry. [jsmith@ipaserver ~]$ ldapsearch -xLLL -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com -b cn=config objectclass=nsdswindowsreplicationagreement dn nsds7WindowsReplicaSubtreedn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=confignsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com... 8< ... Modify the sync agreement [jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -W -p 389 -h ipaserver.example.com <<EOF dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsds7WindowsReplicaSubtree nsds7WindowsReplicaSubtree: cn=alternateusers,dc=example,dc=com EOF modifying entry "cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
The new subtree setting takes effect immediately. If a sync operation is currently running, then it takes effect as soon as the current operation completes. 9.4.5. Configuring Uni-Directional SyncBy default, all modifications and deletions are bi-directional. A change in Active Directory is synced over to Identity Management, and a change to an entry in Identity Management is synced over to Active Directory. This is essentially an equitable, multi-master relationship, where both Active Directory and Identity Management are equal peers in synchronization and are both data masters. However, there can be some data structure or IT designs where only one domain should be a data master and the other domain should accept updates. This changes the sync relationship from a multi-master relationship (where the peer servers are equal) to a master-consumer relationship. This is done by setting the oneWaySync parameter on the sync agreement. The possible values are fromWindows (for Active Directory to Identity Management sync) and toWindows (for Identity Management to Active Directory sync). For example, to sync changes from Active Directory to Identity Management: [jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -p 389 -h ipaserver.example.comdn: cn=ipa-winsync,cn=plugins,cn=configchangetype: modifyadd: oneWaySynconeWaySync: fromWindows Enabling uni-directional sync does not automatically prevent changes on the un-synchronized server, and this can lead to inconsistencies between the sync peers between sync updates. For example, uni-directional sync is configured to go from Active Directory to Identity Management, so Active Directory is (in essence) the data master. If an entry is modified or even deleted on the Identity Management, then the Identity Management information is different then the information and those changes are never carried over to Active Directory. During the next sync update, the edits are overwritten on the Directory Server and the deleted entry is re-added. 9.4.6. Deleting Synchronization AgreementsSynchronization can be stopped by deleting the sync agreement which disconnects the IdM and Active Directory servers. In the inverse of creating a sync agreement, deleting a sync agreement uses the ipa-replica-manage disconnect command and then the hostname of the Active Directory server. Delete the sync agreement. # ipa-replica-manage disconnect adserver.example.com Remove the Active Directory CA certificate from the IdM server database: # certutil -D -d /etc/dirsrv/slapd-EXAMPLE.COM/ -n "Imported CA"
9.4.7. Winsync Agreement FailuresThis can occur if the wrong Active Directory CA certificate was specified when the agreement was created. This creates duplicate certificates in the IdM LDAP database (in the /etc/dirsrv/slapd-DOMAIN/ directory) with the name Imported CA. This can be checked using certutil: $ certutil -L -d /etc/dirsrv/slapd-DOMAIN/Certificate Nickname Trust AttributesSSL,S/MIME,JAR/XPICA certificate CTu,u,CuImported CA CT,,CServer-Cert u,u,uImported CA CT,,C To resolve this issue, clear the certificate database: # certutil -d /etc/dirsrv/slapd-DOMAIN-NAME -D -n "Imported CA" This deletes the CA certificate from the LDAP database. "Windows PassSync entry exists, not resetting password" This is not an error. This message occurs when an exempt user, the Password Sync user, it not being changed. The Password Sync user is the operational user which is used by the service to change the passwords in IdM. 9.5. Managing Password SynchronizationPassword synchronization is configured separately from Windows Synchronization. 9.5.1. Setting up the Windows Server for Password SynchronizationTo synchronize passwords requires that Active Directory be running in SSL and that the Password Sync Service be installed on each Active Directory domain controller. The Password Sync Service records password changes and synchronizes them, over a secure connection, to the IdM entry. Install the Microsoft Certificate System in Enterprise Root Mode. Active Directory will then automatically enroll to retrieve its SSL server certificate. Make sure that the Active Directory password complexity policies are enabled so that the Password Sync service will run. Run secpol.msc from the command line. Select . Open , and then open . Enable the Password must meet complexity requirements option and save.
If SSL is not already enabled, set up SSL on the Active Directory server. Setting up LDAPS is explained in more detail in the Microsoft knowledgebase at http://support.microsoft.com/kb/321051. Install a certificate authority in the Windows Components section in Add/Remove Programs. Select the Enterprise Root CA option. Reboot the Active Directory server. If IIS web services are running, the CA certificate can be accessed by opening http://servername/certsrv. Set up the Active Directory server to use the SSL server certificate. Create a certificate request .inf, using the fully-qualified domain name of the Active Directory as the certificate subject. For example: ;----------------- request.inf ----------------- [Version] Signature="$Windows NT$ [NewRequest]Subject = "CN=ad.server.example.com, O=Engineering, L=Raleigh, S=North Carolina, C=US"KeySpec = 1 KeyLength = 2048 Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ;----------------------------------------------- Generate the certificate request. certreq -new request.inf request.req Submit the request to the Active Directory CA. For example: certreq -submit request.req certnew.cer If the command-line tool returns an error message, then use the Web browser to access the CA and submit the certificate request. If IIS is running, then the CA URL is http://servername/certsrv. Accept the certificate request. For example: certreq -accept certnew.cer Make sure that the server certificate is present on the Active Directory server. In the menu, click , then click and . Import the CA certificate from Directory Server into Active Directory. Click Trusted Root CA, then Import, and browse for the Directory Server CA certificate.
Reboot the domain controller.
9.5.2. Setting up Password SynchronizationInstall the Password Sync Service on every domain controller in the Active Directory domain in order to synchronize Windows passwords. Download the PassSync.msi file from the Red Hat Enterprise Linux channels, and save it to the Active Directory machine. There are two PassSync packages available, one for 32-bit Windows servers and one for 64-bit. Make sure to select the appropriate packages for your Windows platform. Double-click the PassSync.msi file to install it. The Password Sync Setup window appears. Hit Next to begin installing. Fill in the information to establish the connection to the IdM server. The IdM server connection information, including the hostname and secure port number. The username of the system user which Active Directory uses to connect to the IdM machine. This account is configured automatically when sync is configured on the IdM server. The default account is uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com. The password set in the --passsync option when the sync agreement was created. The search base for the people subtree on the IdM server. The Active Directory server connects to the IdM server similar to an ldapsearch or replication operation, so it has to know where in the IdM subtree to look for user accounts. The user subtree is cn=users,cn=accounts,dc=example,dc=com. The certificate token is not used at this time, so that field should be left blank.
Hit Next, then Finish to install Password Sync. Import the IdM server's CA certificate into the Active Directory certificate store. Download the IdM server's CA certificate from http://ipa.example.com/ipa/config/ca.crt. Copy the IdM CA certificate to the Active Directory server. Install the IdM CA certificate in the Password Sync database. For example: cd "C:\Program Files\Red Hat Directory Password Synchronization"certutil.exe -d . -A -n "IPASERVER.EXAMPLE.COM IPA CA" -t CT,, -a -i ipaca.crt
Reboot the Windows machine to start Password Sync. The Windows machine must be rebooted. Without the rebooting, PasswordHook.dll is not enabled, and password synchronization will not function.
The first attempt to synchronize passwords, which happened when the Password Sync application is installed, will always fail because of the SSL connection between the Directory Server and Active Directory sync peers. The tools to create the certificate and key databases is installed with the .msi. 9.5.3. Exempting Active Directory Users from Password SynchronizationThe passwords in password change operations are still subject to the password policy settings, such as password expiration times. For example, in IdM every password change requires an immediate password reset. While normal user passwords need to be subject to password policies, administrative passwords should be exempt from any password rules. A list of user DNs can be set in the password synchronization configuration that are exempted from the password policy. The Directory Manager password is always exempt from password policy. Edit the password synchronization entry, cn=ipa_pwd_extop,cn=plugins,cn=config, and add the passSyncManagersDNs attribute with the name of the user. This attribute is multi-valued. For example: $ ldapmodify -x -D "cn=Directory Manager" -w secret -h ldap.example.com -p 389dn: cn=ipa_pwd_extop,cn=plugins,cn=configchangetype: modifyadd: passSyncManagersDNspassSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com |
| |
