Oracle® Fusion Middleware Installation and Configuration Guide for Identity Synchronization for Windows 6.0 11g Release 1 (11.1.1.7.0) Part Number E28963-01 |
|
|
PDF · Mobi · ePub |
This chapter provides important information about configuring security for your deployment. The information is organized as follows:
Note:
This chapter assumes that you are familiar with the basic concepts of public-key cryptography and Secure Sockets Layer (SSL) protocol, and that you understand the concepts of intranet, extranet, Internet security, and the role of digital certificates in an enterprise. If you are new to these concepts, please refer to the security-related appendixes of the Managing Servers with iPlanet Console 5.0 manual.
Passwords are sensitive information; therefore, Identity Synchronization for Windows takes security precautions to ensure that user and administrative password credentials used to access the directories being synchronized are not compromised.
This section covers the following security methodologies:
This security approach aims to prevent the following events from taking place:
An eavesdropper intercepting a clear text password over the network
An attacker manipulating a connector to change a user's password to a value of their choosing, which is equivalent to capturing the user's clear text password
An attacker gaining access to a privileged component of Identity Synchronization for Windows
An unprivileged user recovering a password from a file stored on disk.
An intruder recovering a password from a hard disk that was removed from one of the components of the system. This could be a password being synchronized, or it could be a system password that is used to access a directory.
To protect sensitive information while it is stored in the product's configuration directory and while it is transferred over the network, Identity Synchronization for Windows uses a configuration password. You (the administrator) specify a configuration password when you install Core, and you must provide this password when you open the Console or run the Identity Synchronization for Windows installation program.
Note:
The system manager must access the configuration password before passing it to the connector; consequently, the system manager stores this password in its initialization file.
File system access controls prevent non-privileged users from accessing the system manager's initialization file. The Identity Synchronization for Windows installation program does not enforce a password policy for this password.
To increase security when you select a configuration password, see Hardening Your Security.
You can configure Identity Synchronization for Windows to use LDAP over SSL everywhere that components use LDAP. All access to Message Queue is protected with SSL.
You must use SSL between the Active Directory Connector and Active Directory when you are synchronizing from Directory Server to Active Directory.
By default, connectors configured to use SSL will accept any SSL certificate that the server (i.e. Directory Server or Active Directory) returns — which includes untrusted, expired, and invalid certificates. All network traffic between the connector and server will be encrypted, but the connector will not detect a server that is impersonating the true Active Directory or Directory Server.
To force the connector to accept only trusted certificates, use the Console to enable the Require trusted SSL certificates option on the Specify Advanced Security Options panel of the Directory Source Configuration wizard (see Creating an Active Directory Source). After enabling this option, you must add the appropriate CA certificates to the connector's certificate database as reported by idsync certinfo
.
A 3DES key generated from the configuration password is used to secure all sensitive information in the product's configuration directory. With the exception of log messages, all messages to the Message Queue are encrypted with per-topic 3DES keys. Messages sent between connectors and subcomponents are encrypted with per session 3DES keys. The Directory Server Plug-in encrypts all user password changes with a 3DES key.
SSL and 3DES Keys Protection Summary summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.
Table 8-1 Protecting Sensitive Information Using Network Security
Use this Protection Method | Between the Following Information Types: |
---|---|
LDAP over SSL (optional) |
|
|
SSL and 3DES Keys Protection Summary contains an overview of the security features discussed in this section.
Figure 8-1 Security Overview for Identity Synchronization for Windows
Identity Synchronization for Windows uses Message Queue's access control to prevent unauthorized access to message subscription and publishing, allowing each connector to trust messages that it receives.
Unique username and passwords known only to Message Queue and to the connector are provided to access the Message Queue broker. Each message sent over the Message Queue is encrypted with a per topic 3DES key, which protects the message contents and prevents outsiders who do not know the topic key from sending meaningful messages. These measures prevent (a) an attacker from sending falsified password synchronization messages to connectors and (b) an attacker from impersonating a connector and receiving actual password updates.
Note:
By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns. See Hardening Your Security for more information to enhance Message Queue certificate validation and other Message Queue-related security issues.
Privileged credentials are required by the connectors to change passwords in Active Directory and the Directory Servers being synchronized. These privileged credentials are encrypted before they are stored in the product's configuration directory.
Persistent Storage Protection Summary summarize how Identity Synchronization for Windows protects sensitive information that is stored on disk.
Table 8-2 Persistent Storage Protection
Persistent Storage | Confidential Information | Protection |
---|---|---|
Product's Configuration Stored in a Configuration Directory Server |
Credentials for accessing the directories and per Message Queue topic 3DES keys are stored in the product's configuration directory. |
All sensitive information stored in the product's configuration directory is encrypted with a 3DES key that is generated from the configuration password. See Hardening Your Security for recommendations to further protect the product's configuration directory. |
Directory Server Retro Changelog |
The Directory Server Plug-in captures password changes and encrypts them before writing them to the Directory Server Retro Changelog. |
The Directory Server Plug-in encrypts all user password changes with a 3DES key that is unique to each deployment. |
Message Queue Broker Persistent Storage |
The Message Queue broker stores password synchronization messages sent between all connectors. |
With the exception of log messages, all persisted messages are encrypted with per-topic 3DES keys. |
Message Queue Broker Directory Credentials |
The Message Queue broker authenticates users against the product's configuration directory. It connects to the configuration directory using the directory administrative user name and password provided during Core installation. |
The directory password is stored in a passfile, which is protected with file system access controls. |
System Manager Boot File |
The system manager's boot file contains information for accessing the configuration. This includes the configuration password and the directory administrative user name and password provided during Core installation. |
This file is protected with file system access controls. |
Connectors and Central Logger Boot Files |
Each connector as well as the central logger have an initial configuration file with credentials for accessing the Message Queue. |
These files are protected with file system access controls. |
Directory Server Plug-in Boot Configuration |
The Plug-in's configuration, stored in |
The |
NT Password Filter DLL and NT Change Detector Boot Configuration |
The NT subcomponent's configuration, which is stored in the Windows registry, includes credentials for connecting to the connector. |
If access to the PDCs registry is not secure, these registry keys can be protected with access controls. |
Windows Connector's Object Cache |
Windows connectors store hashed user passwords in the connector's object cache. |
The passwords are not stored in the clear but encrypted with MD5 hashes. These database files are protected with file system access controls. (see Hardening Your Security |
This section depicts potential security weaknesses in the current release of the product and recommendations as to how to extend and harden security outside the product's default configuration. It includes the following:
The configuration password is used to protect sensitive configuration information but the installation program does not enforce any password policy for this password; be sure that this password follows some strict guidelines choose a complex password that is not easily guessed and follow standard policy guidelines for strong passwords.
For example, it should be at least eight characters long, include upper case letters, lower case letters, and non-alphanumeric characters. It should not include your name, initials, or dates.
To access the Directory Server where the product's configuration directory resides, your credentials must be in the Configuration Administrators group. However, if you need to create credentials other than admin for any reason, consider the following:
The installation program requires you to provide credentials for a user stored in the Console administrative subtree. However, the Core installation program will not expand users other than admin into "uid=admin,ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
". Therefore, you must specify the entire DN during Core installation.
Create a user in:
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
Add the new credentials to the Configuration Administrators group.
Set ACIs to allow only this user or all users in the Configuration Administrators group to access the Directory Server where the product's configuration directory is stored.
Specify entire DN during Core installation.
For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Administrator's Guide for Oracle Directory Server Enterprise Edition
By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns.
To override this setting and force Message Queue clients to validate the Message Queue broker's certificate, edit:
Add the following to the JVM arguments of each process in Watchlist.properties
:
-Djavax.net.ssl.trustStore=
keystore_path-DimqSSLIsHostTrusted=false
Restart the Identity Synchronization for Windows daemon or service.
The javax.net.ssl.trustStore
property should point to a JSEE keystore that trusts the broker certificate, for example, /etc/imq/keystore
can be used on the machine where Core was installed because this is the same keystore used by the broker.
By default, the Message Queue broker uses a self-signed SSL certificate. To install a different certificate, use the keytool
utility that ships with Java to modify the broker's keystore (/var/imq/instances/isw-broker/etc/keystore
on Solaris, /var/opt/sun/mq/instances/isw-broker/etc/keystore
on Linux, and mq_installation_root /var/instances/isw-broker/etc/keystore
on Windows 2000). The alias of the certificate must be imq
.
By default, the Message Queue uses dynamic ports for all services except for its port mapper. To access the broker trough a firewall or restrict the set of hosts that can connect to the broker, the broker should use fixed ports for all services.
This can be achieved by setting the imq.
service_name protocol_type .port
broker configuration properties. Refer to the Sun Java System Message Queue Administration Guide for more information.
The system manager accepts any certificate when connecting to the product's configuration directory over SSL; the Message Queue broker accepts any certificate when connecting to the product's configuration directory over SSL. Currently, there is no way to make either the system manager or the Message Queue broker validate the product's configuration directory SSL certificates.
When Core is installed, the process of adding information to the Directory Server where the product's configuration directory is stored does not include adding any access control information. To restrict access to only configuration Administrators, the following ACI can be used:
(targetattr = "*") (target = "ldap://ou=IdentitySynchronization, ou=Services,dc=example,dc=com") (version 3.0;acl "Test";deny (all) (groupdn != "ldap://cn=Configuration Administrators, ou=Groups, ou=TopologyManagement, o=NetscapeRoot");)
For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Administrator's Guide for Oracle Directory Server Enterprise Edition
Deployments connecting to Directory Servers using replication follow the same rules identified in Security Overview. This section gives an example replicated configuration and explains how to enable use of SSL in this configuration.
Note:
For an overview of planning, deploying, and securing replicated configurations see Appendix D, "Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows"
Securing Replicated Configurations lists the configuration components requiring CA certificates and identifies which certificates are required where.
Table 8-3 Securing Replicated Configurations
Component | Required CA certificates |
---|---|
Preferred Directory Server Replicated Master |
Active Directory System |
Secondary Directory Server Replicated Master |
Active Directory System |
Read-only Directory Server Hub(s) |
Preferred Directory Server Replicated Master Secondary Directory Server Replicated Master |
Directory Server Connector |
Preferred Directory Server Replicated Master Secondary Directory Server Replicated Master |
Active Directory System |
Replicated configuration shows Identity Synchronization for Windows installed in an MMR configuration, where there are two replicated Directory Server masters with multiple Directory Server read-only hubs or consumers. Each Directory Server has a Plug-in and there is only one Directory Server Connector, one Active Directory system, and one Active Directory Connector.
When the Directory Server source is configured for SSL, you must make sure that both the preferred and secondary Directory Server certificates are trusted by the replica Directory Server. This is true for every Directory Server Plug-in of type other
that you install on a system with a Directory Server hub or read-only replica.
Note:
Directory Server Plug-ins have access to the same CA certificates as its associated Directory Server.
The above diagram is specific to two Directory Server masters. But you can extended this to contain multiple masters.
Use the idsync certinfo
utility to determine what certificates are required based on the current Identity Synchronization for Windows SSL settings. Execute idsync certinfo
to retrieve information about what certificates are required in each certificate database.
Note:
You must be sure that when you are configuring the Directory Server source for SSL, both the preferred and secondary Directory Server source certificates are trusted by the replica Directory Server for all Directory subcomponents or Plug-ins.
If Identity Synchronization for Windows tries to establish SSL connections (with the trust all certificates setting enabled), and the server's hostname does not match the hostname provided in the certificate presented by the server during the SSL negotiation phase, the Identity Synchronization for Windows Connector will refuse to establish the connection.
The directory source hostname in the Identity Synchronization for Windows configuration must always match the hostname embedded in the certificate used by that directory source.
Arguments describes the arguments you can use with the idsync certinfo
subcommand.
Table 8-4 certinfo Arguments
Argument | Description |
---|---|
|
Specifies the configuration directory hostname. This argument defaults to the values specified during Core installation. |
|
Specifies the configuration directory LDAP port number. (Default is 389) |
|
Specifies the configuration directory bind distinguished name (DN). This argument defaults to the values specified during Core installation. |
|
Specifies the configuration directory bind password. The - value reads the password from standard input ( |
-s rootsuffix |
Specifies the configuration directory rootsuffix. Where rootsuffix is a distinguished name such as |
|
Specifies the configuration password. The - value reads the password from standard input ( |
The following example uses idsync certinfo
to search for system components designated to run under SSL communications. The results of this example identifies two connectors (CNN101 and CNN100) and provides instructions as to where to import the appropriate CA certificate.
:\Program Files\Sun\MPS\isw- hostname\bin idsync certinfo -h CR-hostname -p 389 -D "cn=Directory Manager" -w dirmanager -s dc=example,dc=com -q password Connector: CNN101 Certificate Database Location: C:\Program Files\Sun\MPS\isw- hostname\etc\CNN101 Get 'Active Directory CA' certificate from Active Directory and import into Active Directory Connector certificate db for server ldaps::/ hostname.example.com:636 Connector: CNN100 Certificate Database Location: C:\Program Files\Sun\MPS\isw- hostname\etc\CNN100 Export 'Directory Server CA' certificate from Directory Server certificate db and import into Directory Server Connector certificate db ldaps://hostname.example.com:636 Export 'Active Directory CA' certificate from Active Directory Server hostname.example.sun.com:389 and import into Directory Server Server certificate db for server ldaps://hostname.example.com:638 SUCCESS
Follow these steps to enable SSL in a Directory Server using a self-signed certificate.
Note:
These abbreviated procedures are for your convenience. Refer to the Administrator's Guide for Oracle Directory Server Enterprise Edition for more information.
Refer to the following procedure to enable SSL in Directory Server:
Create a DS instance
/opt/SUNWdsee/ds6/bin/dsadm create -p
non-ldap-port
-P
ldap-secure-port
<
DS-server-root
>/slapd-<
hostname
>
Start the instance
/opt/SUNWdsee/ds6/bin/dsadm start <
DS-server-root
>/slapd-<
hostname
>
Create a self-signed certificate
/opt/SUNWdsee/ds6/bin/dsadm add-selfsign-cert -S "cn=<
machine name with domain
>,O=<
preferred root suffix
>"/<
DS-server-root
>/slapd-<
hostname
>/<
certificate name
>
Where S = Create an individual certificate and add it to database, the second variable represents the path of Directory Server instance and the last variable is for the certificate alias.
Set the server properties to this certificate
/opt/SUNWdsee/ds6/bin/dsconf set-server-prop -p
non-ldap-port
ssl-rsa-cert-name:<
certificate name
>
Restart the DS
/opt/SUNWdsee/ds6/bin/dsadm restart /<
DS-server-root
>/slapd-<
hostname
>/
Now stop the DS and remove the default certificate (this ensures that the above generated certificate will be the default certificate)
/opt/SUNWdsee/ds6/bin/dsadm stop /<
DS-server-root
>/slapd-<
hostname
>/
Now remove the default certificate
/opt/SUNWdsee/ds6/bin/dsadm remove-cert /<
DS-server-root
>/slapd-<
hostname
>/ defaultCert
where the first variable represents the slapd-path and the second variable represents the alias of the certificate. In case you want to export the above default certificate, following is the command
/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<
any path
>/slapd-cert.export /<
DS-server-root
>/slapd-<
hostname
>/ <
original default cert alias
>
where o=output file (/<
any path
>/slapd-cert.export
), the second variable represents the slapd-path and the third variable represents the certificate alias.
Ensure that you have enabled SSL in Directory Server. To export the Directory Server certificate to a temporary file so that you can import it into the certificate database of the Directory Server Connector, issue the following command:
<ISW-server-root>\shared\bin\certutil.exe -L -d .
-P slapd-hostname- -n server-cert -a \> C:\s-cert.txt
ISW-server-root is the path where ISW-hostname directory is present.
These examples are run in the alias
directory immediately below the server root. Otherwise, Directory Server will not find the certificate database.
dsadm
command on Solaris platform)Ensure that you have enabled SSL in Directory Server. To retrieve the CA certificate issue the following command:
/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<any path> /slapd-cert.export /<DS-server-root>/slapd-<hostname>/ <original default cert alias>
Identity Synchronization for Windows automatically retrieves Active Directory SSL certificates over SSL and imports them into the Connector's certificate database using the same credentials you provided for the Connector.
However; if an error occurs (for example, invalid credentials or no SSL certificates were found), you can retrieve an Active Directory CA certificate and add it to the Connector certificate database. See the following sections for instructions:
If an error occurs, you can use certutil
(a program that ships with Windows 2000/2003) or LDAP to retrieve an Active Directory certificate, as described in the following sections.
Note:
The certutil
command discussed in this section is not the same as the certutil
command that ships with the Directory Server and discussed previously in this publication.
Execute the following search against Active Directory:
ldapsearch -h CR-hostname -D administrator_DN -w administrator_password -b "cn=configuration,dc=put,dc=your,dc=domain,dc=here" "cacertificate=*"
Where the administrator_DN might look like:
cn=administrator,cn=users,dc=put,dc=your,dc=domain,dc=here
In this example, the domain name is: put.your.domain.name.here.
Several entries will match the search filter. You probably need the entry using cn=Certification Authorities, cn=Public Key Services
in its DN.
Open a text editor and cut the first value of the first CA certificate attribute (it should be a base64 encoded text block). Paste that value (text block) into the text editor (only the value). Edit the contents, so that none of the lines start with white space.
Add-----BEGIN CERTIFICATE-----
before the first line and -----END CERTIFICATE-----
after the last line. See the following example:
-----BEGIN CERTIFICATE----- MIIDvjCCA2igAwIBAgIQDgoyk+Tu14NGoQnxhmNHLjANBgk qhkiG9w0BAQUFADCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG 9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U EAxMLUmVzdGF1cmFudHMwHhcNMDIwMTExMDA1NDA5WhcNMT IwMTExMDA1OTQ2WjCBjjEeMBwGCSqGSIb3DQEJARYPYmVyd G9sZEBzdW4uY29tMQswCQYDVQQGEwJVUELMAkGA1UECBMCV FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U EAxMLUmVzdGF1cmFudHMwXDANBgkqhkiG9w0BAQEFAANLAD BIAkEAyekZa8gwwhw3rLK3eV/12St1DVUsg31LOu3CnB8cM HQZXlgiUgtQ0hm2kpZ4nEhwCAHhFLD3iIhIP4BGWQFjcwID AQABo4IBnjCCAZowEwYJKwYBBAGCNxQCBAYeBABDAEEwCwY DVR0PBAQDAgFGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBB YEFJ5Bgt6Oypq7T8Oykw4LH6ws2d/IMIIBMgYDVR0fBIIBK TCCASUwgdOggdCggc2GgcpsZGFwOi8vL0NOPVJlc3RhdXJh bnRzLENOPWRvd2l0Y2hlcixDTj1DRFAsQ049UHVibGljJTI wS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZm lndXJhdGlvbixEQz1yZXN0YXVyYW50cyxEQz1jZW50cmFsL RPXN1bixEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGl vblBvaW50ME2gS6BJhkdodHRwOi8vZG93aXRjaGVyLnJlc3 RhdXJhbnRzLmNlbnRyYWwuc3VuLmNvbS9DZXJ0RW5yb2xsL 1Jlc3RhdXJhbnRzLmNybDAQBgkrBgEEAYI3FQEEAwIBADAN BgkqhkiG9w0BAQUFAANBAL5R9R+ONDdVHWu/5Sd9Tn9dpxN 8oegjS88ztv1HD6XSTDzGTuaaVebSZV3I+ghSInsgQbH0gW 4fGRwaI BvePI4= -----END CERTIFICATE-----
Save the certificate into a file (such as ad-cert.txt
).
You can then import that file (for example, ad-cert.txt
) into a certificate database. Continue to the next section, Adding Active Directory Certificates to the Connector's Certificate Database
Use this procedure only if you enabled SSL for the Active Directory Connector after installing the Connector or if invalid credentials were provided during installation.
On the machine where the Active Directory Connector is installed, stop the Identity Synchronization for Windows service/daemon.
Retrieve the Active Directory CA certificate using one of the following methods:
Assuming the Active Directory Connector has connector ID CNN101 (see logs/central/
error.log
for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the certificate file:
If the certificate was retrieved using certutil
, type:
<ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert -t C,, -i \cacert.bin
If the certificate was retrieved using LDAP, type:
<ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert \
-t C,, -a -i \ad-cert.txt
ISW-server-root is the path where ISW-hostname directory is present
On Solaris, the certificate can be imported using the dsadm
command in the following manner:
/opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root>/slapd-<hostname>/ ad-ca-cert cacert.bin
where ad-ca-cert
is the name of the certificate assigned after the import and cacert.bin
is the certificate about to be imported
Restart the Identity Synchronization for Windows service/daemon.
Note:
Because the Directory Server certutil.exe
is installed automatically when you install Directory Server, you will not be able to add a CA certificate to a connector installed on a machine with no Directory Server.
At a minimum, you must install the Sun Java System Server Basic Libraries and Sun Java System Server Basic System Libraries from the Directory Server package on the server where the Active Directory Connector is installed. (You do not have to install the Administration Server or Directory Server components.)
In addition, be sure to select the JRE subcomponent from the Console (to ensure your ability to uninstall).
Note:
Make sure that you have enabled SSL in Directory Server.
Retrieve the Active Directory CA certificate using one of the following methods:
Stop Directory Server.
Import cacert.bin
into the <DS-server-root>\slapd-hostname\alias
folder on Windows and for Solaris and Linux import it into <DS-server-root>/slapd-hostname/alias
directory.
On the machine where Directory Server is installed, import the Active Directory CA certificate as follows:
If the certificate was retrieved using certutil
, type:
<ISW_server_root>\shared\bin\certutil.exe -A -d . -P slapd-hostname- -n ad-ca-cert -t C,, -i \cacert.bin
If the certificate was retrieved using LDAP, type:
<ISW_server_root>\shared\bin\certutil.exe -A -d . -P slapd-hostname- -n ad-ca-cert -t C,, -a -i \ad-cert.txt
ISW-server-root is the path where ISW-hostname directory is present
If the certificate was retrieved using the dsadm
command (on Solaris), type:
/opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root> /slapd-<hostname>/ ad-ca-cert cacert.bin
Where ad-ca-cert
is the name of the certificate assigned after the import and cacert.bin
is the certificate about to be imported
Start Directory Server.
If you enable SSL communication between the Directory Server Plug-in and Active Directory, then you must add the Active Directory CA Certificate to the certificate database of each Directory Server master.
On the machine where the Directory Server Connector is installed, stop the Identity Synchronization for Windows service/daemon.
Retrieve the Directory Server CA certificate.
Assuming the Directory Server Connector has connector ID CNN100 (see logs/example/
error.log
for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the cacert.bin
file:
<ISW_server_root>\shared\bin\certutil.exe -A -d . -n ds-cert -t C,, -i C:\s-cert
ISW-server-root
is the path where ISW-hostname
directory is present.
Restart the Identity Synchronization for Windows service/daemon.