These are steps which you should follow to sync Windows Active Directory and 389 Directory Server .
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.
Cite: Windows Server 200{0,3} How to troubleshoot LDAP over TLS/SSL connection problems
NOTE This major section is being worked on , and is not ready for production.
Option (Command line On Windows Active Directory Host)
certutil -ca.cert ad2003.pem > ad2003.pem
Copy the exported certificate from the Active Directory Server to the Linux machine (e.g. scp, ftp, samba mount, etc.)
CA cert[0]:
-----BEGIN CERTIFICATE-----
MIIEbTCCA1WgAwIBAgIQWY5vERlj14ZHZbdBb27daTANBgkqhkiG9w0BAQUFADBF
MRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTEV
MBMGA1UEAxMMQ2FGb3JXaW4yMDAzMB4XDTEyMDgyMjAyNDE1OFoXDTE3MDgyMjAy
NDkyMVowRTETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB2V4
YW1wbGUxFTATBgNVBAMTDENhRm9yV2luMjAwMzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAIjb5rgmg4xL3IgiocX0TmQrWFff8JdkMiQJ7KfGnxH7dLjC
st8LrYxSOCQtV9Z5+phv2WEF1EfWyM4211Ha7Mupai4Jc6oWRCW/TSr0QwjSuR/8
3yI1GCX2/mZnhY1xRGfEKkzIadoNROkFQJsNXomBrmf6bSqWqFn/Uy7QlcPwv0/4
wwgMiaVXd1FcEJhfdrFSkEfh8jXnJm4pVb2kWfZMiJGFVaQLsbT33zesBkVnV8T5
qV7AvYcPxqAtW+iVKU4z83BQJiM9r6tgKGOJ2ukd9tzF87nLP+8qmJUiqq8S7akD
yoOFb10OTKJMdxWVO3VqACC9pwEPdimzSR3UuHMCAwEAAaOCAVcwggFTMAsGA1Ud
DwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQGetEhuOzmK8DmepF/
tMNYIcPToTCCAQAGA1UdHwSB+DCB9TCB8qCB76CB7IaBsmxkYXA6Ly8vQ049Q2FG
b3JXaW4yMDAzLENOPWFkMjAwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy
dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1leGFtcGxlLERD
PWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnSGNWh0dHA6Ly9hZDIwMDMuZXhhbXBsZS5jb20v
Q2VydEVucm9sbC9DYUZvcldpbjIwMDMuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0G
CSqGSIb3DQEBBQUAA4IBAQBL5rd9e5G7bhx7MN0ViKYmd9WPeWIJX5zSsXFVHbaR
W09KllrOsAumWdq9myzcQUwn4h1oCREVxMu5wIXvfTImapUD0nbSeKd+Cn6NTEXA
qGWC8xXSHbuHc2gUil48tsrrf73ycvzaGAKe88qIwWJIhzoa1o1v95lOYt4Ivq+H
3yI1GCX2/mZnhY1xRGfEKkzIadoNROkFQJsNXomBrmf6bSqWqFn/Uy7QlcPwv0/4
wwgMiaVXd1FcEJhfdrFSkEfh8jXnJm4pVb2kWfZMiJGFVaQLsbT33zesBkVnV8T5
qV7AvYcPxqAtW+iVKU4z83BQJiM9r6tgKGOJ2ukd9tzF87nLP+8qmJUiqq8S7akD
yoOFb10OTKJMdxWVO3VqACC9pwEPdimzSR3UuHMCAwEAAaOCAVcwggFTMAsGA1Ud
DwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQGetEhuOzmK8DmepF/
tMNYIcPToTCCAQAGA1UdHwSB+DCB9TCB8qCB76CB7IaBsmxkYXA6Ly8vQ049Q2FG
b3JXaW4yMDAzLENOPWFkMjAwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy
dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1leGFtcGxlLERD
PWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnSGNWh0dHA6Ly9hZDIwMDMuZXhhbXBsZS5jb20v
Q2VydEVucm9sbC9DYUZvcldpbjIwMDMuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0G
CSqGSIb3DQEBBQUAA4IBAQBL5rd9e5G7bhx7MN0ViKYmd9WPeWIJX5zSsXFVHbaR
W09KllrOsAumWdq9myzcQUwn4h1oCREVxMu5wIXvfTImapUD0nbSeKd+Cn6NTEXA
qGWC8xXSHbuHc2gUil48tsrrf73ycvzaGAKe88qIwWJIhzoa1o1v95lOYt4Ivq+H
mfZvsp690FGyAaLYxupKcPIBkLKcfl6CH9ze8ylpN2wC0gP+rZU/fPu7owsjLxNL
tXeOELbCMqka+zjkuEEwbXEbnlgWNRvfCh25EfxKDXxwiNQLMRAGF7inDqmk+x7p
S7jFlm2DyoDkzcKia/Dq1ZywwUfpo++H/xEsZI8KAbJ4
-----END CERTIFICATE-----
EncodeToFile returned The file exists. 0x80070050 (WIN32: 80)
CertUtil: -ca.cert command FAILED: 0x80070050 (WIN32: 80)
CertUtil: The file exists.
Now Edit the *.pem file from windows Remove all before
REMOVE _> CA cert[0]:
-----BEGIN CERTIFICATE-----
KEEP THIS DATA
-----END CERTIFICATE-----
REMOVE AFTER HERE
EncodeToFile returned The file exists. 0x80070050 (WIN32: 80)
CertUtil: -ca.cert command FAILED: 0x80070050 (WIN32: 80)
CertUtil: The file exists.
#!/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
cd /etc/dirsrv/slapd-hostname -s
mkdir nss.bak
cp *.db nss.bak
cd nss.bak
certutil -d . -A -n "Windows Server AD CA cert" -t CT,, -a -i /path/to/ADca.pem
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.
<add openssl ca notes here>
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:
Keep the Windows 2000 Advanced Server Install CD handy.
([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:
Keep the Windows 2000 Advanced Server Install CD handy.
Restart the AD server
Open a terminal
openssl s_client -connect optimusvm4.sfbay.redhat.com:636 -showcerts -CAfile /path/to/cacert.pem
enjoy
PassSync 1.1.4 supports 32-bit and 64-bit Windows Server 2003, 2008, and 2012.
There is a problem with the certutil command:
.\certutil.exe –d . –A –n "DS CA cert" -t CT,, -a –i C:\dsca.crt
The CT,, needs to be quoted for powershell:
.\certutil.exe –d . –A –n "DS CA cert" -t "CT,," -a –i C:\dsca.crt
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:
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:
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...
open a CMD window and cd to the Password Sync installation directory.
cd "C:\Program Files\389 Directory Password Synchronization"
Import the CA certificate from the Directory Server into the new certificate database.
certutil.exe -d . -A -n "DS CA cert" -t "CT,," -a -i \path\to\dsca.crt
# note - if the above fails with Bad Database, you will have to do this first:
certutil.exe -d . -N # just press Enter/Return when prompted for a password
Verify the CA certificate
certutil.exe -d . -L -n "DS CA cert"
Reboot the Windows machine - PassSync will not begin working until after a reboot due to the way the AD passhook.dll plug-in works
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.
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.
PassSync will not work until Windows is rebooted. This is due to the way the passhook.dll Active Directory plug-in works.
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”.
Read this to get 389 Directory Server enabled in TLS/SSL mode.
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
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.
On your rhds/389 server
openssl s_client -connect ad2003.example.com:636
On the ad box / or a machine on the active Directory Domain.
openssl.exe s_client -connect ad2003.example.com:636
Compare the output, as it could be the ad domain already has a MS ca installed, and any host in the domain will have the Active Directory Ca already installed in the key ring. Also check the ssl cert that is download with checkX509.sh tool to see the ssl Certification Chain and who cut this x509 ssl cert.
| ./checkX509.sh ad2003.example.com.pem.txt | grep -v :ca: | grep -i CA |