- Joined
- Jan 24, 2006
- Location
- South Dakota
This is a repost so that I could add a section for client connectivity
HowTo: Sync Active Directory with 389 Server
Our example will have 3 computers, w2k8-ad.stratus.local (192.168.122.233), 389.stratus.local (192.168.122.250), client.stratus.local (192.168.122.33).
This HowTo assumes that you already have an Active Directory server configured and running (in our case w2k8-ad) with DNS services.
Step 1: Setup your networking
You will want to setup your network with something similar
to this
Step 2: Setup the 389 repository and install
The following is the command to run in order to install the EPEL repo which has the 389 server components. NOTE: the instructions for this repository on directory.fedoraproject.org/wiki/Download are incorrect.
NOTE: As they update the epel-release package, the link will become invalid. If you have a web browser handy, navigate to the URL (minus the RPM) and find the name of the rpm manually.
Once the repository is configured you will want to run the following commands (as root):
Step 3: Setup the initial configuration
While there are different guides out there to help walk through setting up the 389 server, it may be best to setup a user for this process (as recommended by several guides). As the 389 server was previously called the Fedora Directory Server, we will call our user fds:
Run the following command:
IMPORTANT NOTE: in order for this process to complete successfully your hostname must be resolvable as well as reverse resolvable. I.e. <nslookup 389.stratus.local> and <nslookup 192.168.122.250> both need to return successful records
This will walk you through the setup process:
Step 4: Working with the 389-console
Now that the server is running, run the following to launch the graphical interface:
Enter the following:
User ID: cn=Directory Manager
Password: <your password>
administration URL: http://localhost:9830
Click the + sign beside your hostname, and then again on the Server Group to reveal the Directory Server option. Highlight it, and click the “Open” button.
You will be greeted by this screen:
Step 5: Create a Sync user
Click the Directory Tab, highlight the “config” entry Right click and highlight “New” and then “User”
You will see the following screen.
NOTE: you may call this user whatever you wish, just remember what the “User ID:” is.
Step 6: Windows Sync agreement
This has a few “mini” parts. The first is to enable replication. In the “Configuration” tab, highlight Replication, check the “Enable Changelog” box and then click “Use Default”. Click “Save”
Next, highlight “userRoot”, check the “Enable Replica” box and scroll down to the place where it says “Enter a new Supplier DN:”. This is refering to the sync user we created earlier. Enter your sync user like so:
uid=SMaster,cn=config
Click add, and then save
Right click on the “userRoot” and click “New Windows Sync Agreement”. You will be greeted with the following screen.
Enter your information. This is mostly aesthetic, as this only affects what the directory server displays for the sync agreement.
After clicking next, fill in the following information:
NOTE: you do not have to bind as Administrator, but this requires your Active Directory system administrators to provide you with the appropriate “cn=” users.
NOTE 2: I have run into problems with users who have no Surname having some of their group memberships stripped in a domain which has been upgraded from 2000 -> 2003 -> 2008. If you experience this in your TEST environment try setting the bind user to a non-privileged user and then setting their security access to "Replicating Directory Changes" to allow (This is found by enabling Advanced Features, then right clicking on your domain and clicking properties and then going to the security tab. If your user is not in the list, add it and then grant it the permission to Replicate Directory Changes
After clicking next, the system may pause for a moment while it tests the information you have provided. If it is successful you will see a summary of the sync agreement. At this point you will be able to sync users and groups but NOT passwords.
Step 7: Setup an ACL for PassSync
In the Directory Server window, click on the Directory tab. Highlight your domain (in this case its' called “stratus”), right click and select
“Set Access permissions”. NOTE: this can also be achieved by pressing ctrl + L
Select “New” from the right hand menu. In some cases you will see a the following (see the screen shot directly below).
Enter an appropriate ACL name and then click “Edit Manual”. Replace the contents with the following:
Click “Ok”. You should now see a “PassSync” option listed in the ACL list. Click “Ok” to close that screen.
Step 8: Run the following script
Step 9: Configure SSL for the 389 Server
In the Directory Server window,
highlight your local host entry. (In this case its 389.stratus.local:389). On the right side of the screen, select the Encryption tab. Check the boxes which say “Enable SSL for this server” as well as “use this cipher family: RSA”. In the drop down box you should be able to select “Server-Cert”. Under “Client Authentication” make sure that both “Allow client authentication” and “Use SSL in Console”. Click “Save”
Step 9B: Create a pin with password to enable unattended start
If you choose to skip this step, your server will not come back up unless someone is there to put in the SSL token at the CLI. To allow for unattended restarts you must create a pin.txt
This password is stored in clear text within the password file, so its usage represents a significant security risk. Do not use a password file if the server is running in an unsecured environment.
The password file must be in the same directory where the other key and certificate databases for Directory Server are stored. In our case it is /etc/dirsrv/slapd-389. The file should be named pin.txt.
Include the token name and password in the file, such as Token:mypassword. For example:
Internal (Software) Token:<your password>
The PIN file should be owned by the Directory Server user and set to read-only by the Directory Server user, with no access to anyone other user (mode 0400).
Step 10: Install the PassSync service on the AD Server
Download the PassSync and install it on the Active Directory server. You will need to fill out the form before PassSync will start syncing passwords with your directory server.
**NOTE: This step can be misconfigured and the users and groups will still be imported properly without passwords
**NOTE 2: the log file for PassSync can be found C:\Program Files\389 Directory Password Synchronization\passync.log
Step 11: Copy the Server-Cert to Windows AD and import it
The server cert you just created on your 389/ldap server will be located /etc/dirsrv/slapd-389/servercert.p12. Copy this over to the Windows Server and import it with the following commands:
# run this on the w2k8 server in C:\Program Files\(Red Hat| 389) Directory Password Synchronization
After the Server-Cert has been installed, you will need to reboot the AD server in order for PassSync to work properly within the AD structure. Additionally it is not a bad idea to reboot the 389 server at the same time. NOTE: you will need to start the dirsrv after the reboot as we have not setup a “pin”. After running service dirvsrv start, you will be prompted for the password which you created for the Server-Cert.
Step 12: Initiate a full sync.
NOTE: While the PassSync service on the Windows server starts with the computer, I have found that it may take a few minutes before it has managed to collect the data from AD. If you don't want to wait, I have found that restarting the service should allow PassSync to scrape the data from AD.
In the “Configuration” tab of the Directory Server window, if you have not already, expand “Replication”, and then “userRoot”. Right click on your domain, and click “Initiate Full Re-Synchronization”. In the Directory tab, expand your domain and highlight people. You should now see your Active Directory users in your directory server.
You should see stars in the password field if the sync has worked properly. In order for these users to be enabled in ldap you have to Enable Posix User Attributes. Set the UID and GUID, as well as the Home Directory and login shell.
And that should be it, you should now have Active Directory syncing with the Directory server. Linux/Unix clients would then authenticate as OpenLDAP clients against the Directory server. See HowTOL Setup LDAP Server and Clients for more information on client authentication with the directory server
HowTo: Sync Active Directory with 389 Server
Our example will have 3 computers, w2k8-ad.stratus.local (192.168.122.233), 389.stratus.local (192.168.122.250), client.stratus.local (192.168.122.33).
This HowTo assumes that you already have an Active Directory server configured and running (in our case w2k8-ad) with DNS services.
Step 1: Setup your networking
You will want to setup your network with something similar
to this
Step 2: Setup the 389 repository and install
The following is the command to run in order to install the EPEL repo which has the 389 server components. NOTE: the instructions for this repository on directory.fedoraproject.org/wiki/Download are incorrect.
Code:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpmNOTE: As they update the epel-release package, the link will become invalid. If you have a web browser handy, navigate to the URL (minus the RPM) and find the name of the rpm manually.
Once the repository is configured you will want to run the following commands (as root):
Code:
yum clean all
yum install 389-ds -yWhile there are different guides out there to help walk through setting up the 389 server, it may be best to setup a user for this process (as recommended by several guides). As the 389 server was previously called the Fedora Directory Server, we will call our user fds:
Code:
useradd fds
Code:
setup-ds-admin.plThis will walk you through the setup process:
Code:
[root@postfix Desktop]# setup-ds-admin.pl
=========================================================================
This program will set up the 389 Directory and Administration Servers.
It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
- Press "Enter" to choose the default and go to the next screen
- Type "Control-B" then "Enter" to go back to the previous screen
- Type "Control-C" to cancel the setup program
Would you like to continue with set up? [yes]: yes
=========================================================================
Your system has been scanned for potential problems, missing patches, etc. The following output is a report of the items found that need to be addressed before running this software in a production environment.
389 Directory Server system tuning analysis version 10-AUGUST-2007.
NOTICE : System is x86_64-unknown-linux2.6.32-220.el6.x86_64 (4 processors).
NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds (120 minutes). This may cause temporary server congestion from lost client connections.
WARNING: There are only 1024 file descriptors (hard limit) available, which limit the number of simultaneous connections.
WARNING: There are only 1024 file descriptors (soft limit) available, which limit the number of simultaneous connections.
WARNING : The warning messages above should be reviewed before proceeding.
Would you like to continue? [no]: yes
=========================================================================
Choose a setup type:
1. Express
Allows you to quickly set up the servers using the most common options and pre-defined defaults. Useful for quick evaluation of the products.
2. Typical
Allows you to specify common defaults and options.
3. Custom
Allows you to specify more advanced options. This is recommended for experienced server administrators only.
To accept the default shown in brackets, press the Enter key.
Choose a setup type [2]: <PRESS ENTER>
=========================================================================
Enter the fully qualified domain name of the computer on which you're setting up server software. Using the form <hostname>.<domainname>
\Example: eros.example.com.
To accept the default shown in brackets, press the Enter key.
Warning: This step may take a few minutes if your DNS servers can not be reached or if DNS is not configured correctly. If you would rather not wait, hit Ctrl-C and run this program again with the following command line option to specify the hostname:
General.FullMachineName=your.hostname.domain.name
Computer name [389.stratus.local]: <PRESS ENTER>
=========================================================================
The servers must run as a specific user in a specific group. It is strongly recommended that this user should have no privileges on the computer (i.e. a non-root user). The setup procedure will give this user/group some permissions in specific paths/files to perform server-specific operations.
If you have not yet created a user and group for the servers, create this user and group using your native operating system utilities.
System User [nobody]: fds
System Group [nobody]: fds
=========================================================================
Server information is stored in the configuration directory server. This information is used by the console and administration server to configure and manage your servers. If you have already set up a configuration directory server, you should register any servers you set up or create with the configuration server. To do so, the following information about the configuration server is required: the fully qualified host name of the form <hostname>.<domainname>(e.g. hostname.example.com), the port number (default 389), the suffix, the DN and password of a user having permission to write the configuration information, usually the configuration directory administrator, and if you are using security (TLS/SSL). If you are using TLS/SSL, specify the TLS/SSL (LDAPS) port number (default 636) instead of the regular LDAP port number, and provide the CA certificate (in PEM/ASCII format).
If you do not yet have a configuration directory server, enter 'No' to be prompted to set up one.
Do you want to register this software with an existing
configuration directory server? [no]: <PRESS ENTER>
=========================================================================
Please enter the administrator ID for the configuration directory server. This is the ID typically used to log in to the console. You will also be prompted for the password.
Configuration directory server
administrator ID [admin]: <PRESS ENTER>
Password:
Password (confirm):
=========================================================================
The information stored in the configuration directory server can be separated into different Administration Domains. If you are managing multiple software releases at the same time, or managing information about multiple domains, you may use the Administration Domain to keep them separate.
If you are not using administrative domains, press Enter to select the default. Otherwise, enter some descriptive, unique name for the administration domain, such as the name of the organization responsible for managing the domain.
Administration Domain [stratus.local]: <PRESS ENTER>
=========================================================================
The standard directory server network port number is 389. However, if you are not logged as the superuser, or port 389 is in use, the default value will be a random unused port number greater than 1024. If you want to use port 389, make sure that you are logged in as the superuser, that port 389 is not in use.
Directory server network port [389]: <PRESS ENTER>
=========================================================================
Each instance of a directory server requires a unique identifier. This identifier is used to name the various instance specific files and directories in the file system, as well as for other uses as a server instance identifier.
Directory server identifier [389]: <PRESS ENTER>
=========================================================================
The suffix is the root of your directory tree. The suffix must be a valid DN. It is recommended that you use the dc=domaincomponent suffix convention. For example, if your domain is example.com, you should use dc=example,dc=com for your suffix. Setup will create this initial suffix for you, but you may have more than one suffix. Use the directory server utilities to create additional suffixes.
Suffix [dc=stratus, dc=local]: <PRESS ENTER>
=========================================================================
Certain directory server operations require an administrative user. This user is referred to as the Directory Manager and typically has a bind Distinguished Name (DN) of cn=Directory Manager. You will also be prompted for the password for this user. The password must be at least 8 characters long, and contain no spaces. Press Control-B or type the word "back", then Enter to back up and start over.
Directory Manager DN [cn=Directory Manager]: <PRESS ENTER>
Password:
Password (confirm):
=========================================================================
The Administration Server is separate from any of your web or application servers since it listens to a different port and access to it is restricted.
Pick a port number between 1024 and 65535 to run your Administration Server on. You should NOT use a port number which you plan to run a web or application server on, rather, select a number which you will remember and which will not be used for anything else.
Administration port [9830]: <PRESS ENTER>
=========================================================================
The interactive phase is complete. The script will now set up your servers. Enter No or go Back if you want to change something.
Are you ready to set up your servers? [yes]: yesStep 4: Working with the 389-console
Now that the server is running, run the following to launch the graphical interface:
Code:
389-console
Enter the following:
User ID: cn=Directory Manager
Password: <your password>
administration URL: http://localhost:9830
Click the + sign beside your hostname, and then again on the Server Group to reveal the Directory Server option. Highlight it, and click the “Open” button.
You will be greeted by this screen:
Step 5: Create a Sync user
Click the Directory Tab, highlight the “config” entry Right click and highlight “New” and then “User”
You will see the following screen.
NOTE: you may call this user whatever you wish, just remember what the “User ID:” is.
Step 6: Windows Sync agreement
This has a few “mini” parts. The first is to enable replication. In the “Configuration” tab, highlight Replication, check the “Enable Changelog” box and then click “Use Default”. Click “Save”
Next, highlight “userRoot”, check the “Enable Replica” box and scroll down to the place where it says “Enter a new Supplier DN:”. This is refering to the sync user we created earlier. Enter your sync user like so:
uid=SMaster,cn=config
Click add, and then save
Right click on the “userRoot” and click “New Windows Sync Agreement”. You will be greeted with the following screen.
Enter your information. This is mostly aesthetic, as this only affects what the directory server displays for the sync agreement.
After clicking next, fill in the following information:
Fill in the password box.
NOTE: you do not have to bind as Administrator, but this requires your Active Directory system administrators to provide you with the appropriate “cn=” users.
NOTE 2: I have run into problems with users who have no Surname having some of their group memberships stripped in a domain which has been upgraded from 2000 -> 2003 -> 2008. If you experience this in your TEST environment try setting the bind user to a non-privileged user and then setting their security access to "Replicating Directory Changes" to allow (This is found by enabling Advanced Features, then right clicking on your domain and clicking properties and then going to the security tab. If your user is not in the list, add it and then grant it the permission to Replicate Directory Changes
After clicking next, the system may pause for a moment while it tests the information you have provided. If it is successful you will see a summary of the sync agreement. At this point you will be able to sync users and groups but NOT passwords.
Step 7: Setup an ACL for PassSync
In the Directory Server window, click on the Directory tab. Highlight your domain (in this case its' called “stratus”), right click and select
“Set Access permissions”. NOTE: this can also be achieved by pressing ctrl + L
Select “New” from the right hand menu. In some cases you will see a the following (see the screen shot directly below).
Enter an appropriate ACL name and then click “Edit Manual”. Replace the contents with the following:
Code:
(targetattr = "*")
(version 3.0;
acl "PassSync";
allow (all)
(userdn = "ldap:///uid=SMaster,cn=config")
;)
Click “Ok”. You should now see a “PassSync” option listed in the ACL list. Click “Ok” to close that screen.
Step 8: Run the following script
Code:
#!/bin/bash
mkdir /etc/dirsrv/cert
cd /etc/dirsrv/cert
#This echo statement is actually putting the word “password” (without the quotes) in a temporary password file to help
#automate the process. This will be the password for your certificate. Change this as appropriate
echo "password" > /tmp/pwdfile
export PATH=/usr/bin/:$PATH
touch noise.txt
cd /etc/dirsrv/slapd-389
#Associate the password with the certificates which will be generated in the current directory
certutil -N -d . -f /tmp/pwdfile
#Generate a CA certificate for the 389 server
certutil -S -n "CA certificate" -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d . -z /etc/dirsrv/cert/noise.txt -f /tmp/pwdfile -2
#anwsers are Y, <enter accepting defaults>, Y
#This builds the server cert
certutil -S -n "Server-Cert" -s "cn=389.stratus.local" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d . -z /etc/dirsrv/cert/noise.txt -f /tmp/pwdfile
#This exports the cacert in case you need it
pk12util -d . -o cacert.p12 -n "CA certificate"
#This exports the server-cert which you will need on the windows AD
pk12util -d . -o servercert.p12 -n Server-Cert
#This exports the CA cert for ldap clients
certutil -L -d . -n "CA certificate" -a > cacert.asc
#This places the cacert in the ldap directory so you can test the user database locally
cp cacert.asc /etc/openldap/cacerts/
cacertdir_rehash /etc/openldap/cacerts/
#This sets up /etc/pam_ldap.conf, again client related config... This is optional on the server itself
file=`cat > /etc/pam_ldap.conf <<EOF
host 192.168.122.250
base dc=stratus,dc=local
bindpw password
rootbinddn cn=Directory Manager,dc=stratus,dc=local
ssl start_tls
ssl on
tls_cacertfile /etc/openldap/cacerts/cacert.asc
EOF`
#Import the CA Cert into the 389 server
cd /etc/dirsrv/admin-serv
certutil -A -d . -n "CA certificate" -t "CT,," -a -i /etc/dirsrv/slapd-389/cacert.asc
service dirsrv-admin restartStep 9: Configure SSL for the 389 Server
In the Directory Server window,
highlight your local host entry. (In this case its 389.stratus.local:389). On the right side of the screen, select the Encryption tab. Check the boxes which say “Enable SSL for this server” as well as “use this cipher family: RSA”. In the drop down box you should be able to select “Server-Cert”. Under “Client Authentication” make sure that both “Allow client authentication” and “Use SSL in Console”. Click “Save”
Step 9B: Create a pin with password to enable unattended start
If you choose to skip this step, your server will not come back up unless someone is there to put in the SSL token at the CLI. To allow for unattended restarts you must create a pin.txt
This password is stored in clear text within the password file, so its usage represents a significant security risk. Do not use a password file if the server is running in an unsecured environment.
The password file must be in the same directory where the other key and certificate databases for Directory Server are stored. In our case it is /etc/dirsrv/slapd-389. The file should be named pin.txt.
Include the token name and password in the file, such as Token:mypassword. For example:
Internal (Software) Token:<your password>
The PIN file should be owned by the Directory Server user and set to read-only by the Directory Server user, with no access to anyone other user (mode 0400).
Step 10: Install the PassSync service on the AD Server
Download the PassSync and install it on the Active Directory server. You will need to fill out the form before PassSync will start syncing passwords with your directory server.
**NOTE: This step can be misconfigured and the users and groups will still be imported properly without passwords
**NOTE 2: the log file for PassSync can be found C:\Program Files\389 Directory Password Synchronization\passync.log
Step 11: Copy the Server-Cert to Windows AD and import it
The server cert you just created on your 389/ldap server will be located /etc/dirsrv/slapd-389/servercert.p12. Copy this over to the Windows Server and import it with the following commands:
# run this on the w2k8 server in C:\Program Files\(Red Hat| 389) Directory Password Synchronization
Code:
cd C:\Program Files\389 Directory Password Synchronization
certutil.exe -d . -N
pk12util.exe -d . -i servercert.p12
certutil.exe -d . -M -n Server-Cert -t "P,P,P"Step 12: Initiate a full sync.
NOTE: While the PassSync service on the Windows server starts with the computer, I have found that it may take a few minutes before it has managed to collect the data from AD. If you don't want to wait, I have found that restarting the service should allow PassSync to scrape the data from AD.
In the “Configuration” tab of the Directory Server window, if you have not already, expand “Replication”, and then “userRoot”. Right click on your domain, and click “Initiate Full Re-Synchronization”. In the Directory tab, expand your domain and highlight people. You should now see your Active Directory users in your directory server.
You should see stars in the password field if the sync has worked properly. In order for these users to be enabled in ldap you have to Enable Posix User Attributes. Set the UID and GUID, as well as the Home Directory and login shell.
And that should be it, you should now have Active Directory syncing with the Directory server. Linux/Unix clients would then authenticate as OpenLDAP clients against the Directory server. See HowTOL Setup LDAP Server and Clients for more information on client authentication with the directory server
Last edited:
