Configuring SSL Connection

1. Make sure SSL is enabled in Active Directory. Learn how to enable LDAP SSL in Active Directory.

2. Export a base-64 encoded SSL certificate from your Active Directory Server.

3. Make sure SSL is enabled in 389 Directory Server. Learn how to enable LDAP SSL in 389 Directory Server.

4. Install the exported SSL certificate into 389 Directory Server.

Testing SSL Connection

1. Type the command below to test if you can do a plain LDAP connection to your Active Directory server. You’ll be asked for the password of the user account you specified in the -D option.

/usr/lib/mozldap/ldapsearch -b "dc=acme,dc=local" 
-h server.acme.local -R 
-D "cn=fds,cn=users,dc=acme,dc=local" 
-w - "objectclass=*"

Replace the value after -b with your search base, the value after -h with your server hostname and the value after -D with the distinguished name of a user account having read/write access to your Active Directory server.

2. Type the command below to test if you can do an SSL enabled LDAP connection to your Active Directory server.

/usr/lib/mozldap/ldapsearch -b "dc=acme,dc=local" 
-h server.acme.local -R 
-D "cn=fds,cn=users,dc=acme,dc=local" 
-w - -Z -P /etc/dirsrv/slapd-mail "objectclass=*"

Replace the value after -P with the settings path of your 389 Directory server.

If the two test above succeeds, you can use SSL connection to synchronize with Active Directory.

Troubleshooting

If the output from the test above contains

• Invalid credentials
  

  Check the distinguished name of the user account after the -D option and the bind password for it. To check the distinguished name, type the command below.

  /usr/lib/mozldap/ldapsearch -b "dc=acme,dc=local" -h server 
  -R -D "ACME\fds" -w - "samaccountname=fds" DN
  

  Replace the value ACME with your own domain and fds with your own user name. It will output the distinguished name of the user name you specified.

• TCP connection reset by peer
  

  Check the host name you specified after -h. If the host name is correct, check the firewall.

• security library: bad database
  

  Make sure SSL is enabled in 389 Directory Server. And check the path you specified after -P.

• Encountered end of file
  

  After configuring SSL in Active Directory, you probably did not reboot your Active Directory server. Reboot your AD server to complete the changes and try the test again.

• Peer’s Certificate has expired
  

  Make sure the system clock is synchronized in the Linux server and the Active Directory server. And the check the certificate, it may indeed be expired.

• Peer’s certificate issuer has been marked as not trusted by the user
  

  Check the trust setting you specified in the certificate of the 389 Directory server. Making connections to other servers should be checked.

Users

The Last Name is required in 389 Directory Server so make sure all users have it in Active Directory.

User Passwords

The Active Directory user passwords can only be replicated to 389 Directory Server by installing the PassSync utility to capture password changes before they are stored in a hashed format. This is the only way to get the user’s password from Active Directory.

The PassSync utility does not work in the 64 bit versions of Windows Server. It also stores the passwords used to authenticate with 389 Directory Server and the certificate database unencrypted in the registry.

Organizational Units

Organizational Units, like Accounting, Domain Controllers, Engineering and Sales and Marketing in the screen shot, are not automatically synchronized. Every time you create a new one in Active Directory, you need to manually create the same in Fedora Directory Server to synchronize its contents.

Containers

Containers, like Computers, ForeignSecurityPrincipals, and Users in the screen shot, is similar to the Organizational Unit but uses a different distinguished name.

It uses CN=name instead of OU=name for its relative distinguished name.

To create an organizational unit with the same naming convention, you have to extend the FDS schema.

You can use the setupusers.sh script to create the Users organizational unit for you. Just type in ./setupusers.sh “dc=acme,dc=local” to automatically create the Users container in FDS. Replace “dc=acme,dc=local” with your own base DN.

Configuring the User Permission

The 389 Directory Server sync user account should be given permission to update the password field. In our example, it is uid=SMaster,cn=config. You can create a sync user account using this article.

1. Launch the 389 Management Console.

2. Click the + sign corresponding to your server. Next, click the + sign corresponding to Server Group and click Directory Server. Finally, click the Open button in the Directory Server page.

3. Click the Directory tab and click the folder corresponding to your domain. Next, right click that same folder and click Set Access Permissions.

4. In the Manage Access Control window, click New.

5. In the Edit ACI window, click Edit Manually.

6. Change the value of the ACI to the one below. Click Ok when you are done.

(targetattr = "*") 
(version 3.0;
acl "PassSync";
allow (all)
(userdn = "ldap:///uid=SMaster,cn=config")
;)

userdn should correspond to your sync user account.

7. Finally, click Ok.

Installing PassSync

PassSync should be installed in every Windows domain controller in your domain. You can download the PassSync installer here.

1. Launch the PassSync installer and click Next.

2. Fill up the Password Synchronization Information page and click Next. Below are the description of the fields. Specify in Cert Token the password you plan to assign to the certificate database when you create it later. The password should be at least 8 characters long, and should contain at least one non-alphabetic character.

 

Host Name

389 Directory Server host name

Port Number

389 Directory Server SSL port number

User Name

User account in 389 Directory Server

Password

Password of user account

Cert Token

Certificate database password

Search Base

389 Directory Server base DN

The settings above will be stored in the registry located in the HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync path.

3. Click Next in the Ready to Install page.

4. Finally, click Finish.

Creating the Certificate Database

1. Export the 389 Directory Server certificate using the command below. Execute the command in the /etc/dirsrv/slapd-xxx directory where xxx corresponds to your directory server identifier. Copy the output file servercert.p12 to your target Windows Server.

pk12util -d . -o servercert.p12 -n Server-Cert -k pwdfile.txt

pwdfile.txt contains the certificate database password created by the setupssl2.sh script. Use -K password to provide your own password if you manually configured SSL in 389 Directory Server.

2. In the Windows Server, create the certificate database and load the 389 Directory Server certificate into it using the commands below. Before executing the commands below, change the Command Prompt’s current directory to the installation directory of PassSync, usually at “C:\Program Files\Red Hat Directory Password Synchronization”.

certutil -d . -N
pk12util -d . -i servercert.p12
certutil -d . -M -n Server-Cert -t "P,P,P"

Testing PassSync

1. Restart the Password Synchronization service.

2. Reset a user password and check if it synchronizes with 389 Directory Server.

If you encounter any problems, check the log file at C:\Program Files\Red Hat Directory Password Synchronization\passsync.log

Active Directory User Accounts in Linux

The Active Directory user accounts can be integrated into Linux in such a way that the AD user accounts appears as if they are native user accounts of Linux. There are two ways to accomplish this

1. Using Identity Management for Unix/Services For Unix
   Identity Management for Unix is available in Windows 2003 R2 and above while Services For Unix is supported on Windows NT 4.0 and above. IMU/SFU requires more effort to implement but provides more control over user accounts.
2. Using Samba
   Samba on the other hand is easier to implement due to its template based nature but gives less control over user accounts. In Samba, everyone belongs to the same group and uses the same login shell.

Active Directory Network Services in Linux

Active Directory includes Kerberos authentication and an LDAP-like Directory services which you can utilize in the various network services of Linux. Below is a sample diagram of Linux network services which can use Active Directory.

Here are the links on how to implement them.

Postfix

• How to install Postfix
• Active Directory accounts and mailbox location
• Active Directory mailbox quota
• Active Directory distribution list
• Dovecot SASL authentication

Dovecot

• How to install Dovecot
• Kerberos authentication
• LDAP authentication

SquirrelMail

• How to install SquirrelMail
• Auto update the full name and email address
• Active Directory address book
• Change Active Directory password

389 Directory Server

• How to install 389 Directory Server
• Synchronize with Active Directory

Squid Proxy Server

• How to install Squid Proxy Server
• Integrate with Active Directory

Samba

• How to install Samba

Launching the 389 Management Console

1. Launch the 389 Management Console.

2. Click the + sign corresponding to your server. Next, click the + sign corresponding to Server Group and click Directory Server. Finally, click the Open button in the Directory Server page.

Creating the Sync User Account

The sync user account will be used by the replication plugin to update the 389 Directory Server. For security reason, it should not be part of the synchronized sub tree.

1. Click the Directory tab and click the config folder. Next, right click config, select New and click User.

2. Fill in the First Name, Last Name, Common Name, User ID, Password and Confirm Password fields. Click OK when you are done.

3. Note down the distinguished name of the newly created user located in the bottom part of the window.

Configuring Replication

The configuration below is for one way synchronization only, from Active Directory to 389 Directory Server. If you need two way synchronization, select Single Master or Multiple Master as the Replica Role and specify a numeric value for Replica ID (ex. 1) instead of using the default which is Dedicated Consumer.

1. Click the Configuration tab and click the Replication folder. In the Supplier Settings page, check Enable Changelog and click the Use default button. Click Save when you are done.

2. Click the + sign corresponding to Replication and click userRoot. Check Enable Replica.

3. Type in the distinguished name of sync user account (uid=SMaster,cn=config in the example above) into the Enter a new Supplier DN field and press Add. Click Save when you are done.

Creating a Windows Sync Agreement

To synchronize with Active Directory, you need an Active Directory user account. In the sample below, the fds user account (cn=fds,dc=acme,dc=local) has been created in Active Directory specifically for that purpose. Learn how to create a new user account in Windows Server.

1. Right click userRoot and click New Windows Sync Agreement.

2. In the Agreement Name window, fill in the Name and Description fields and click Next.

3. Fill in the Windows Sync Server Info form and click Next when you are done. See the sample values below.

 

Windows Domain Information

Windows Domain Name

acme.local

Sync New Windows Users

On

Sync New Windows Groups

On

Windows Subtree

dc=acme,dc=local

DS Subtree

dc=acme,dc=local

Domain Controller Host

server.acme.local

Port Num

389

Connection

Using encrypted SSL connection

Off

Bind as

cn=fds,dc=acme,dc=local

Password

secret

If you prefer to enable encrypted SSL connection, you need to install an SSL certificate in 389 Directory Server.

If you want the password changes on 389 Directory Server to replicate into the Active Directory Server you need the following

• A working Single Master/Multiple Master replication
• Encrypted SSL connection should be enabled
• The bind account (fds in the example above) must have permission to reset user password. The easiest way to accomplish this is to make the bind account a member of Domain Admins.

If you want the password changes on Active Directory Server to replicate into the 389 Directory Server, see Synch Active Directory Password to FDS.

4. Review the settings in the Summary window and click Done.

Starting the Synch Process

1. Right click the newly created agreement and click Initiate Full Re-synchronization.

2. Click the Status tab and click the Replication Status to check if the replication has completed.

3. Click the Error Logs under the Logs folder to check for any synch errors.

Check out Active Directory and 389 Directory Server Synchronization Issues for some of the problems you might encounter while implementing this.

Before starting, you need to setup Identity Management for UNIX. If you are using Windows Server prior to 2003 R2, you can use Services for Unix 3.5 which can be downloaded from here.

Setup and Configure LDAP User Information

It is recommended to an Active Directory enabled DNS server, this will ensure that the LDAP lookups and Kerberos authentication will work properly. Also, provide a user account dedicated for the LDAP authentication.

1. Click System, select Administration and click Authentication. This will launch the Authentication Configuration window.

2. Check Enable LDAP Support and click the Configure LDAP button.

3. Fill in the LDAP Search Base DN and LDAP Server fields. Click Ok when you are done.

4. Click the Options tab and check Local authorization is sufficient for local users and Create home directories on the first login. Click Ok when you are done.

4. Edit the file /etc/ldap.conf and add the following lines below.

binddn user account
bindpw password for binddn
nss_map_objectclass posixAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute homeDirectory unixHomeDirectory

nss_map_attribute uid msSFU30Name
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell

If you are not using an Active Directory enabled DNS server, you need to add the line referrals no to make this work.

5. Type in getent passwd in a terminal window. You should see your Active Directory user accounts.

6. Type in getent group in a terminal window. You should see your Active Directory groups.

Setup and Configure Kerberos Authentication

The Kerberos network authentication protocol requires the clocks of the involved machines to be synchronized or at least the difference is less than 5 minutes.

1. Launch the Authentication Configuration window. Click the Authentication tab and check the Enable Kerberos Support. Next, click the Configure Kerberos button.

2. In the Kerberos Settings window, fill in the Realm, clear out KDC and Admin Servers and check the Use DNS to locate KDCs for realms. Realm is usually your domain name capitalized, capitalization is important. KDC is your Active Directory server. Click Ok when you’re done.

To make sure that your KDC can be automatically located, type in the command host -t any _kerberos._tcp.acme.local in a terminal window. Replace acme.local with your own realm. If it replies “_kerberos._tcp.acme.local has SRV record …” then it works. This should work if you are using an Active Directory enabled DNS server. Otherwise, you need to manually fill in the KDC field above. You can specify more than one KDC by separating each server with a comma or space.

3. Test Kerberos by typing in kinit username in a terminal window. If you need help in making sense of the kinit error messages, check out Test the Kerberos Authentication.

That’s it, you should now be able to login using Active Directory user accounts.

The version of sudo that comes with RHEL/CentOS 5 does not work with non local user accounts. While this is not yet fixed, use the sudo rpm package for Fedora 8.

Installing Identity Management for UNIX

1. Click Start, select Control Panel, and click Add or Remove Programs.

2. Click Add/Remove Windows Components. Next, select the Active Directory Services component and click Details.

3. Check Identity Management for UNIX and click OK. Click Next to begin installation.

Using Identity Management for UNIX

Launch the Active Directory Users and Computers tool. When you open the property of a user or group, you should see the new UNIX Attributes tab. You can use it to set the attributes that will be used in a Unix computer.

To make managing accounts even easier, the tool automatically increments the User ID and Group ID so you do not have to keep track of the last ID assigned. And it checks for duplicate IDs so you do not have to worry about accidentally reusing IDs.

Remember to follow the naming conventions in Unix. Although you can use spaces when you name a user or group, you will not be able to use later it in Unix.

Group property

User property

To issue a certificate for a web server, make sure you have all of the items below.

• Domain administrator account
• Internet Explorer
• Windows server installed with Microsoft Certificate Services. Learn how to install Microsoft Certificate Services in Windows 2003 Server.

1. Launch Internet Explorer and connect to your Certificate Services server. The URL is http://server/certsrv, replace server with the name of your server. Next, click Request a certificate.

2. In the Request a Certificate page, click submit an advanced certificate request.

3. In the Advanced Certificate Request page, click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file or submit a renewal request by using a base-64-encoded PKCS#7 file.

4. In the Submit a Certificate Request or Renewal Request page, paste the content of the request file into the Base-64-encoded certificate request box. Select Web Server in the Certificate Template and click Submit.

5. In the Certificate Issued page, select Base 64 encoded and click Download certificate.