Sync With Active Directory


These are steps which you should follow to sync Windows Active Directory and 389 Directory Server .

Enabling TLS/SSL with Active Directory

With Microsoft Certificate Authority

Active Directory gets its server certificate automatically created/enrolled when a Microsoft Certificate Server is configured/installed for that domain in Enterprise Root CA mode.

(Optional) Use Microsoft ldap diagnostics gui Ldp from the AD Windows Server 2003 or AD Windows Server 2008 to test the ssl port 636

Note:

WORK IN PROGRESS: Exporting the ssl ca from the windows

Use the Microsoft Root Certification Authority Certificate from the Web Enrollment Site

On the active directory host command line option of ms certutil.exe

Test the yourhostname.pem file

  #!/bin/bash    
  # checkX509.sh     
  # the 1st arg is the cert file we shall test     
  # this expects a file format such as this 
  # -----BEGIN CERTIFICATE-----
  #UvNNuJz0GeQQxfAerIUv1hzGxvNsETnq5cF4TwTc+45QHh/k0defzMU2uRgkrhqZ
  #MORE RANDOM DATA encoded in a base64 
  #Rmd7Glb2AREcNjajLf+BHJDHWQmxLAyVdRGtJLYy0V2YCxv6AB86+cDobVn4Xpel
  #so1hPKxtCs2or0PUjYM=
  #-----END CERTIFICATE-----
  openssl base64 -d -in $1  | openssl x509 -text -noout -inform der    

On our Linux/Unix based 389 ldap server back up the database

cd /etc/dirsrv/slapd-hostname -s
mkdir nss.bak
cp *.db nss.bak
cd nss.bak

On our Linux/Unix based 389 ldap server: Import the Ad Ca into Fedora 389 key ring

certutil -d . -A -n "Windows Server AD CA cert" -t CT,, -a -i /path/to/ADca.pem

On our Linux/Unix based 389 ldap server: Verify the CA certificate

certutil -d . -L -n "Windows Server AD CA cert"

if this is good we can 1st make a backup of the db file , before the windows ca was added , and we can over write these files.

Now rerun the ldapsearch commands , see if they are successful, if so then the issues with ssl should be resolved.

With OpenSSL CA

<add openssl ca notes here>

With Red Hat Certificate Authority

These are some notes that describe how you should go about enabling TLS/SSL for an Active Directory Installation Using Red Hat Certificate System (CA).

Steps to follow for Windows 2000 Advanced Server:

With TinyCA2

([http://tinyca.sm-zone.net/]http://tinyca.sm-zone.net/)

These notes should help you go about enabling TLS/SSL for Active Directory Installation using certificates generated with the TinyCA2 Certificate Authority.

FYI

Steps to follow for Windows 2000 Advanced Server:

enjoy

Active Directory with any Other 3rd-Party Certificate Authority

Configuring PassSync

PassSync 1.1.4 supports 32-bit and 64-bit Windows Server 2003, 2008, and 2012.

Windows Server 2012 Notes

Installing PassSync

NOTE: If you are upgrading from Fedora PassSync to 389 PassSync, the installer will create a 389 branded folder under your program files folder and copy the files you need from there. The installer will _not_ remove the old Fedora Password Sync folder. You can remove this manually after install if the 389 one is working correctly.

NOTE: After installing, either new or upgrade, you will have to reboot the machine in order for the changes to take effect (unless you can figure out a way to make Active Directory/lsass use the passhook plugin without rebooting . . .)

PassSync should be installed on the Windows box where you have installed/configured Active Directory. Follow these steps:

Enabling TLS/SSL for PassSync

NOTE: PassSync will not work until TLS/SSL is configured. The passsync.log will contain errors about TLS/SSL initialization until TLS/SSL is properly configured, and the service will not start.

The following method assumes that you have some knowledge about using NSS based certificate and key management utilities like certutil/pk12util.

For detailed docs on these tools see [ http://www.mozilla.org/projects/security/pki/nss/tools/ here ].

More information about PassSync can be found here.

Follow these steps to set up certificates that Password Sync Service will use TLS/SSL to access the Directory Server:

On the 389 Directory Server, export the CA certificate.
cd /etc/dirsrv/slapd-instance_name    
certutil -d . -L -n "CA certificate" -a > dsca.crt    
# NOTE - it might not be called CA certificate - use certutil -d . -L to list your certs    
certutil -d . -L    
Certificate Nickname                                        Trust Attributes    
                                                            SSL,S/MIME,JAR/XPI    
CA certificate                                              CTu,u,u    
Server-Cert                                                 u,u,u    
...etc...    
On the Windows Active Directory Machine
NOTE:
password protect the database

If you want to password protect your key/cert db, you will need to use certutil.exe -d . -N to create a key/cert db with a password _before_ importing the CA cert.

starting over with ssl

If you want to start over, just simply remove the *.db files. You will need to provide the Cert Token password above. If you need to set the password, you can run the .msi again and use Modify mode, or use regedit and edit the registry - see below for the registry key.

Reboot Windows

PassSync will not work until Windows is rebooted. This is due to the way the passhook.dll Active Directory plug-in works.

PassSync Logging

The PassSync log file is in the file passsync.log in the C:\Program Files\389 Directory Server Synchronization folder.

The passhook log and data file are in your \windows\system32 folder - passhook.dat and passhook.log

The following registry settings are available to enable PassSync service logging.

Under HKLM->Software->PasswordSync, add string value “Log Level” and set it to “1”.

Enabling TLS/SSL With 389 Directory Server

Read this to get 389 Directory Server enabled in TLS/SSL mode.

Note: Use same CA to cut the ssl certs for windows active directory host and fedora 389 / rhds servers

Creating AD User with Replication Rights

You do not have to use Administrator or other system account for Windows Sync. You can instead create a regular user and assign specific rights to that user.

The page How to grant the “Replicating Directory Changes” permission for the Microsoft Metadirectory Services ADMA service account gives more information. The steps apply to any user, not just the Microsoft Metadirectory Services ADMA service account.

These instructions assume you are using the Server Manager application, or the Active Directory Domain Services and/or Active Directory Users and Groups snap-in to MMC.

That user should now be able to use the DirSync control. There is a python script that can be used to test to see if the user can use DirSync - see https://github.com/richm/scripts for the file dirsyncctrl.py. You will have to edit this file in the main() section to set your ad host, dn, etc.

For more information, see Polling for Changes Using the DirSync Control

Creating Sync Agreements WinSync

Note

If you want One Way Sync

One_Way_Active_Directory_Sync

Testing your Configuration

Test to make sure you can talk TLS/SSL from 389 Directory to AD

cite: qa script that will build an adWs2008r2 host vm with a windows ca and ca web services turned on

This is how you test to verify that the Windows side TLS/SSL is enabled properly:

 /usr/lib[64]/mozldap/ldapsearch -Z -P /path/to/dirsrv/cert8.db -h <AD/NT Hostname> -p <AD TLS/SSL port> 
 -D "<sync manager user>" -w < sync manager password> -s <scope>
 -b "<AD base>" "<filter>"

or, with openldap on RHEL6 or later, or on Fedora

 LDAPTLS_CACERTDIR=/path/to/slapd-INST ldapsearch -xLLL -ZZ -h <AD/NT Hostname>
  -D "<sync manager user>" -w <sync manager password> -s <scope>
 -b "<AD base>" "<filter>"

for example

 /usr/lib/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-myhostname/cert8.db -h ad.example.com 
 -p 636 -D "cn=sync manager,cn=users,dc=example,dc=com" 
 -w password -s base -b "cn=users,dc=example,dc=com" "objectclass=*"

openldap

 LDAPTLS_CACERTDIR=/path/to/slapd-myhostname ldapsearch -xLLL -ZZ -h ad.example.com
 -D "cn=sync manager,cn=users,dc=example,dc=com"
 -w password -s base -b "cn=users,dc=example,dc=com" "objectclass=*"

for example

 #!/bin/bash
      /usr/lib/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-hostname -s /cert8.db -h ad2003.example.com -p 636 -D "cn=sync manager,cn=users,dc=example,dc=com" -w password -s base -b "cn=users,dc=example,dc=com" "objectclass=*"         

openldap

 #!/bin/bash
 LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-hostname -s ldapsearch -xLLL -ZZ -h ad2003.example.com -D "cn=sync manager,cn=users,dc=example,dc=com" -w password -s base -b "cn=users,dc=example,dc=com" "objectclass=*"

If you did not create a sync manager (you should have!) you can use cn=administrator,cn=users,dc=example,dc=com.

If you begin to see errors when doing this search, you could optionally use the ssltap tool , which basically proxies requests - to troubleshoot.

testing ssl from the ldap server to the ad host

Troubleshooting

Windows Sync Plugin API

Windows_Sync_Plugin_API

POSIX Attributes

WinSync_Posix

Last modified on 1 March 2015