Table of Contents (Subjected to Revision)
1.0 Background Information
1.1 Disclaimer
1.2 Pre-requisites (Hardware and Software)
2.0 Installation
2.1 FDS – Java Installation
2.2 Secure Certificate Generation for LDAP Components
2.3 Fedora Directory Base Server Installation
2.4 Importing SSL Certificates into Fedora Directory Server
2.5 Configuring SSL on the Fedora Directory Server
2.6 Fedora Directory Server - Points of Interest & Bugs
3.0 Binding Linux/Unix Machines, MAC OSX & Windows Clients to LDAP
3.1 Configuring Password Policy for all three Platforms
3.2 Binding Linux/Unix Machines to LDAP.
3.3 Binding Linux/Unix Machines to LDAPs.
3.4 Binding Mac OSX Machines to LDAP.
3.5 Binding Mac OSX Machines to LDAPs
3.6 Binding Windows boxes to LDAP/LDAPs
Fedora Directory Server 1.02 Installation
LDAP with SSL/NOSSL Enabled, Mac Support and Windows Syncing
1.0 Background Information
Fedora Directory Server Comprises of two parts, the LDAP server itself which is slapd like most Linux/Unix distribution (I will be referencing this component from now on as Directory Server in the rest of the document, to keep consistencies with Red Hat naming convention) and the LDAP remote Admin GUI interface (I will be referencing this component from now on as Administration Server to keep consistencies with Red Hat naming convention) which requires Java which is handy for people who are not adapt at manipulating the LDAP directory from the command line tools.
Originally the Fedora Directory Server is derived from Netscape Directory Server which Red Hat purchased and made it Open Source with several enhancements. I’ve had the Fedora Directory Server running over 7 Months now (With over 300 Machines both Linux and Macs OSX bind directly to it) so I can safely say its rock stable.
This is basically an idiot proof guide on how to configure Fedora Directory Server 1.02 with both SSL and NON-SSL connection enabled. This Guide will also detail how you bind your Linux Clients, Mac OSX Clients and Sync your Windows Active Directory with your Directory Server.
So in plain English, the Fedora Server will be the authentication server for all your Clients be it Linux / Unix, Mac OSX or Windows (Through Syncing the password from the Fedora Directory Server to Microsoft Active Directory)
1.1 Disclaimer
I have been asked to write a document how to get the Fedora Directory Server working, and this is basically the first revision of the document which should detail every aspect in the installation and configuring process. I’ll probably have to go through to fix the various spellings and grammatical errors. But overall it should outlay the basis how hot to get it going but I take no responsibility for it. A good system is a well tested system. If you have comments please feel free to contact me ashley@csse.uwa.edu.au.
1.2 Pre-requisites (Hardware and Software)
Java SDK (I recommend strongly using IBM java 1.4.x over Suns Java)
Linux / Unix Installation (Fedora Core 4 or Later)
Fedora Directory Server Binaries (At the Moment the binaries stands at 1.02)
Functional Linux Machine (My Machine for the purpose of illustration is called jhett.csse.uwa.edu.au and runs Fedora Core 4)
2.0 Installation
2.1 FDS – Java Installation
The first thing is to install IBM Java 1.4.x (The reason why I recommend using the IBM Java as opposed to Suns Java is it will work straight of instead of modifying scripts and adding files).
Ie I have it typically installed in /usr/java/IBMJava2-142
I also create a sym link to IBMJava2-142 called jdk, and I call the java binaries from /usr/java/jdk. The reason why I do if I ever update the Java, instead of re-linking the binaries ie for javac, java, jar etc, all I have to re-link is the directory /usr/java/jdk to current java I am using instead of each individual binaries.
Ie ln –s /usr/java/IBMJava2-142 /usr/java/jdk
Now I have physically installed java but does not necessary mean it’s the correct java that’s being called by default Operating System. With RedHat Enterprise, Fedora and other Linux / Unix distribution it comes with its own Java which you have replace as the default java.
In RedHat Enterprise / Fedora Core system, the default path of the java binaries are stored or linked from /usr/bin. By default /usr/bin is already in your search path thus acts as the default java binaries. You can verify where the java is being called by typing
[root@jhett /]# which java
/usr/bin/java
It reports it sourcing it from /usr/bin, typically for Java you have to replace / re-link the binaries jar, java, javac, javadoc & javah and linked them to your Java installation. So I would rename them then relink them.
mv /usr/bin/java /usr/bin/java.fc4
ln –s /usr/java/jdk/bin/java /usr/bin/java
And you do this for all the binaries I mentioned above, you should see something like this.
[root@jhett bin]# pwd
/usr/bin
[root@jhett bin]# ls -al |grep -i jdk
lrwxrwxrwx 1 root root 21 Jun 29 23:16 jar -> /usr/java/jdk/bin/jar
lrwxrwxrwx 1 root root 22 Jun 29 23:16 java -> /usr/java/jdk/bin/java
lrwxrwxrwx 1 root root 23 Jun 29 23:16 javac -> /usr/java/jdk/bin/javac
lrwxrwxrwx 1 root root 25 Jun 29 23:16 javadoc -> /usr/java/jdk/bin/javadoc
lrwxrwxrwx 1 root root 23 Jun 29 23:16 javah -> /usr/java/jdk/bin/javah
[root@jhett bin]#
Now there is a couple of variables which you need to set for JAVA ie JAVA_HOME (Tells java where it is), PATH (Add the java binaries to the current search path). It really depends on your shell (I use the export command or use the setenv)
export JAVA_HOME=/usr/java/jdk
export PATH=/usr/java/jdk/bin:$PATH
You may want to add it to your startup shell script instead of typing it out every time ie edit .bashrc for bash , .zshrc for zsh etc. You can verifiy if the variables has been set by typing env and looking if there is the variables JAVA_HOME been set, and /usr/java/jdk/bin variables been appended to the PATH variable.
Now verify that’s it the right java being called ie
[root@jhett /]# java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20050929 (SR3) (JIT enabled: jitc))
2.2 Secure Certificate Generation for LDAP Components
As I mentioned before, with Fedora Directory Server there are two components the Directory Server (LDAP backend) and Administration Server (remote Administration GUI interface). So we have to generate two sets of certificates one for secure Directory Server LDAP backend and one for the secure Administration Server connections. (You could use one certificate and share it between the two, but if one is compromise so is the other component)
If you don’t plan to use SSL connections you basically can skip this entire section.
You need to have openssl packages installed on your system before you can generate a certificate.
[root@jhett tmp]# rpm -qa |grep –i openssl
openssl-0.9.7f-7.10
openssl-devel-0.9.7f-7.10
openssl-perl-0.9.7f-7.10
These are the packages which are installed on my system. Now lets create the secure certificates I’ll create two directories one for Directory Server, and one for the Administration Server.
mkdir /tmp/ldap (Temp area for creating Directory Server backend certificates)
mkdir /tmp/admingui (Temp area for creating Admin Server certificates)
cd /tmp/ldap
Please note I’m only signing the certificates for 365 days, after that it will expire and you have to regenerate the certificates.
Generate your own Certificate Authority (CA) for LDAP Backend
[root@jhett ldap]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
................................................................................................................++
......................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key:dspassword1
Verifying - Enter pass phrase for ca.key: dspassword1
[root@jhett ldap]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (Should be dspassword1)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or
Province Name (full name) [Berkshire]:
Locality
Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:UWA-DS
Organizational Unit Name (eg, section) []:CSSE-DS
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Now you should of generated Certificate Authority File (ca.crt) and Certificate Authority Key File for LDAP Backend.
Generate a Server Key and request for Signing
[root@jhett ldap]# openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
............................................................................................................................................................................................................................++
..................................................................................................++
e is 65537 (0x10001)
Enter pass phrase for server.key: dspassword2
Verifying - Enter pass phrase for server.key: dspassword2
[root@jhett admingui]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (dspassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or
Province Name (full name) [Berkshire]:
Locality
Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:UWA-Admin
Organizational Unit Name (eg, section) []:CSSE-Admin
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
[root@jhett ldap]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: (dspassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or
Province Name (full name) [Berkshire]:
Locality
Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:UWA-DS-Server
Organizational Unit Name (eg, section) []:CSSE-DS-Server
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Sign the Certificate signing request that you’ve created with the self signed certificate authority for LDAP Backend.
[root@jhett ldap]# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=au/ST=Western Australia/L=Perth/O=UWA-DS-Server/OU=CSSE-DS-Server/CN=jhett.csse.uwa.edu.au/emailAddress=support@csse.uwa.edu.au
Getting CA Private Key
Enter pass phrase for ca.key: (should be dspassword1)
That’s all the certificate files you will need for the Directory Server LDAP Backend, now you will need to generate the certificate files for Administration Server which is essentially the same process.
cd /tmp/admingui
pwd
/tmp/admin/gui
Generate your own Certificate Authority (CA) for Server Administration
[root@jhett admingui]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
......................................................................................++
.....................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key: adminpassword1
Verifying - Enter pass phrase for ca.key: adminpassword1
[root@jhett admingui]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
.............................++
..++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:
[root@jhett admingui]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (adminpassword1)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or
Province Name (full name) [Berkshire]:
Locality
Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:UWA-Admin
Organizational Unit Name (eg, section) []:CSSE-Admin
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
[root@jhett admingui]#
Now you should of generated Certificate Authority File (ca.crt) and Certificate Authority Key File (ca.key) for Administration Server.
Generate a Server Key and request for Signing
[root@jhett admingui]# openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
.......++
....................................................++
e is 65537 (0x10001)
Enter pass phrase for server.key: (adminpassword2)
Verifying - Enter pass phrase for server.key: (adminpassword2)
[root@jhett admingui]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: (adminpassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or
Province Name (full name) [Berkshire]:
Locality
Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:UWA-Admin-Server
Organizational Unit Name (eg, section) []:CSSE-Admin-Server
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Sign the Certificate signing request that you’ve created with the self signed certificate authority for Administration Server.
[root@jhett admingui]# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=au/ST=Western Australia/L=Perth/O=UWA-Admin-Server/OU=CSSE-Admin-Server/CN=jhett.csse.uwa.edu.au/emailAddress=support@csse.uwa.edu.au
Getting CA Private Key
Enter pass phrase for ca.key: (adminpassword1)
Now we have basically generated two sets of self signed SSL certificates, one for Directory Server and the other for Administration Server. But these certificates needs to be converted to pkcs12 format for it to be used in the Fedora Directory Server. So we have to convert both sets to pkcs12 which then we can proceed to install the Fedora Directory Server.
[root@jhett ldap]# pwd
/tmp/ldap
[root@jhett ldap]# openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name "DS-Server-Cert"
Enter pass phrase for server.key: (dspassword2)
Enter Export Password: (dspassword3)
Verifying - Enter Export Password: (dspassword3)
[root@jhett ldap]# pwd
[root@jhett ldap]# openssl pkcs12 -export -in ca.crt -inkey ca.key -out ca.p12 -name "DS-Cert"
Enter pass phrase for ca.key: (dspassword1)
Enter Export Password: (dspassword4)
Verifying - Enter Export Password: (dspassword4)
And similarly for Administration Server
[root@jhett admingui]# pwd
/tmp/admingui
[root@jhett admingui]# openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name "Admin-Server-Cert"
Enter pass phrase for server.key: (adminpassword2)
Enter Export Password: (adminpassword3)
Verifying - Enter Export Password: (adminpassword3)
[root@jhett admingui]# openssl pkcs12 -export -in ca.crt -inkey ca.key -out ca.p12 -name "Admin-Cert"
Enter pass phrase for ca.key: (adminpassword1)
Enter Export Password: (adminpassword4)
Verifying - Enter Export Password: (adminpassword4)
Now basically you have your files in pkcs12 format which essentially contains the key and certificate in one file. Now don’t forget the export password or it will be next to useless. Now we can proceed to do Fedora Directory Server Installation
2.3 Fedora Directory Base Server Installation
Before proceeding you must of configured your Java and prepared the SSL certificates assuming you wan’t to use secure LDAP connections known as LDAPs. Now I have assumed you’ve download the binaries. As (In my case its fedora-ds-1.0.2-1.FC4.i386.opt.rpm), install it by using the command
rpm –ivh its fedora-ds-1.0.2-1.FC4.i386.opt.rpm
ie
[root@jhett /]# rpm -ivh fedora-ds-1.0.2-1.FC4.i386.opt.rpm
Preparing... ########################################### [100%]
1:fedora-ds ########################################### [100%]
Install finished. Please run /opt/fedora-ds/setup/setup to complete installation and set up the servers.
Now lets run the setup like it advised ie
[root@jhett / ]# /opt/fedora-ds/setup/setup
INFO Begin Setup . . .
It will do a tune analysis of your Linux system, typically you will see these messages.
WARNING: 512MB of physical memory is available on the system. 1024MB is recommended for best performance on large production system.
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.
I would advise you to make these changes to your systems especially if you are going to use it in a production environment. To cancel it and rectify the warning press ctrl-c, and do the following
echo 21600 >> /proc/sys/net/ipv4/tcp_keepalive_time (For 2.6.x Kernels)
Edit the file /etc/sysctl.conf and add the following lines
fs.file-max = 64000
Edit the file /etc/security/limits.conf and add the following lines
* soft nofile 1024
* hard nofile 1024
Put more Ram and install it (I’ve had it used up to a 1GB of ram at times but then again I do have a quite a few users on it)
Re-Run the installation the warning should of disappeared, pick Custom – lots of customization and note the details down especially the port numbers for LDAP connection and Administration port for Administration Server, admin and Directory Manager password as you will need them later on.
For My installations its as follows
Hostname to use (default: jhett.csse.uwa.edu.au) (Press enter for default)
Server user ID to use (default: nobody) (Press enter for default)
Server group ID to use (default: nobody) (Press enter for default)
Do you want to register this software with an existing with an existing
Fedora configuration directory server? [No] (Press enter for default -> No)
Do you want to use another directory to store your data? [No] (Press enter for default -> No)
Directory server network port [389]: (Press enter for default)
Directory server identifier [jhett]: (Press enter for default)
Fedora configuration directory server administrator ID [admin] (Press enter for default)
Password: adminpw1
The suffix is the root of your directory tree. You may have more than
one suffix.
Suffix [dc=csse, dc=uwa, dc=edu, dc=au]: (Press enter for default)
Directory Manager DN [cn=Directory Manager]: (Press enter for default)
Password: dspw1
Administration Domain [csse.uwa.edu.au]: (Press enter for default)
Do you want to install the sample entries? [No]: (Press enter for default)
Type the full path and filename, the word suggest, or the word none
[suggest]: (Press enter for default)
Do you want to disable schema checking? [No]: (Press enter for default)
Administration port [58509]: (Press enter for default)
IP address [ ]: (Press enter for default)
Run Administration Server as [root]: (Press enter for default)
Apache Directory [/usr/sbin/]: (Press enter for default)
Hostname to use (default: jhett.csse.uwa.edu.au)
Server user ID to use (default: nobody)
Server group ID to use (default: nobody)
Now that’s the basic Directory Server configured out of the box. But we will want to do quite a few things such as enable LDAPs secure connection, Password Policy Manager etc. The screen you should get should be similar to this shown below.
[slapd-jhett]: starting up server ...
[slapd-jhett]: Fedora-Directory/1.0.2 B2006.060.1951
[slapd-jhett]: jhett.csse.uwa.edu.au:389 (/opt/fedora-ds/slapd-jhett)
[slapd-jhett]:
[slapd-jhett]: [12/Jul/2006:10:56:43 +0800] - Fedora-Directory/1.0.2 B2006.060.1951 starting up
[slapd-jhett]: [12/Jul/2006:10:56:43 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests
Your new directory server has been started.
Created new Directory Server
Start Slapd Starting Slapd server configuration.
Success Slapd Added Directory Server information to Configuration Server.
Configuring Administration Server...
Setting up Administration Server Instance...
Configuring Administration Tasks in Directory Server...
Configuring Global Parameters in Directory Server...
You can now use the console. Here is the command to use to start the console:
cd /opt/fedora-ds
./startconsole -u admin -a http://jhett.csse.uwa.edu.au:58509/
INFO Finished with setup, logfile is setup/setup.log
[root@jhett fedora-ds]#
I like to mention that the Fedora Directory Server is self contained meaning that all its binaries and libraries are in the installation directory in the default directory /opt/fedora-ds. I would advise you to make a backup of it, so if you do something wrong ie screw up in configuring your SSL certificates your Fedora Directory Server will not come up and you have to start from scratch or debug it manually (Which I could but would be way longer then this current manual and besides its quicker this way)
So I would create a tarball of it ie.
tar cpfz /opt/fedora-ds.backup.tgz /opt/fedora-ds
This will create a tar gzip file in /opt/fedora-ds.backup.tgz. If it breaks for some reason all you have to do is stop the Fedora Directory Server, delete the Fedora Directory Server, and untar your backup fedora-ds.backup.tgz back into the directory and restart it ie
[root@jhett fedora-ds]# pwd
/opt/fedora-ds
[root@jhett fedora-ds]# ./stop-admin
[root@jhett fedora-ds]# cd slapd-jhett/
[root@jhett slapd-jhett]# ./stop-slapd
[root@jhett slapd-jhett]# cd /opt
[root@jhett opt]# rm -rf fedora-ds
[root@jhett opt]# tar xpfz fedora-ds.tgz
[root@jhett opt]# cd fedora-ds
[root@jhett fedora-ds]# cd slapd-jhett/
[root@jhett slapd-jhett]# ./start-slapd
[root@jhett slapd-jhett]# cd ..
[root@jhett fedora-ds]# ./start-admin
Remember there are two components to Fedora Directory Server, Directory Server which is slapd (LDAP backend) and the Administration Server (remote GUI administration). So you really should start Directory LDAP backend first before starting the Administration Server because the Administration Server uses the Directory Server for authentication so order does matter.
Keep this in mind to restart the Directory Server you use these commands which are pretty self explanatory. (Note the installation reference the directory with the machine hostname in my case its jhett just substitute accordingly)
/opt/fedora-ds/slapd-jhett/restart-slapd
/opt/fedora-ds/slapd-jhett/start-slapd
/opt/fedora-ds/slapd-jhett/stop-slapd
Similarly the Administration Server you use these commands.
/opt/fedora-ds/start-admin
/opt/fedora-ds/stop-admin
/opt/fedora-ds/restart-admin
You can verify the Directory Server backend is running by typing this, and you should see something similar to this.
[root@jhett fedora-ds]# ps -aux |grep -i slap
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.5/FAQ
nobody 9530 0.0 4.0 374444 19944 ? Sl 11:10 0:00 ./ns-slapd -D /opt/fedora-ds/slapd-jhett -i /opt/fedora-ds/slapd-jhett/logs/pid -w /opt/fedora-ds/slapd-jhett/logs/startpid
root 9685 0.0 0.1 3764 676 pts/1 R+ 11:14 0:00 grep -i slap
You can also verify the Admin Server is running by typing this, and again you should see something similar.
[root@jhett fedora-ds]# ps -aux |grep -i admin-serv
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.5/FAQ
root 9606 0.0 0.6 33628 3300 ? Ssl 11:10 0:00 /usr/sbin//httpd.worker -k start -d /opt/fedora-ds/admin-serv -f /opt/fedora-ds/admin-serv/config/httpd.conf
root 9607 0.0 0.3 33612 1704 ? S 11:10 0:00 /usr/sbin//httpd.worker -k start -d /opt/fedora-ds/admin-serv -f /opt/fedora-ds/admin-serv/config/httpd.conf
nobody 9610 0.0 1.0 569824 5184 ? Sl 11:10 0:00 /usr/sbin//httpd.worker -k start -d /opt/fedora-ds/admin-serv -f /opt/fedora-ds/admin-serv/config/httpd.conf
root 9696 0.0 0.1 3764 676 pts/1 R+ 11:16 0:00 grep -i admin-serv
[root@jhett fedora-ds]#
Now we have establish that LDAP backend slapd is working, and the remote admin GUI daemon is running we can connect to it.
[root@jhett fedora-ds]# pwd
/opt/fedora-ds
[root@jhett fedora-ds]# cd /opt/fedora-ds/
[root@jhett fedora-ds]# ./startconsole
Which then you should see something like in Figure 1.
Figure 1 – Fedora Management Console Login
You should know all these details, as they were noted down during the installation. Just substitute according. Once you have done that you can log in as the Directory Manager, which you should see Fedora Management console like in Figure 2.
Figure 2 – Fedora Management Console
2.4 Importing SSL Certificates into Fedora Directory Server
Notice its states it not running Secure Connection, and its just allows the normal non-secure LDAP connection though default port of 389, normally secure LDAP connections are though port 636.
Now we are going to enable the SSL connections but to this, we have to import the SSL certificates for both Directory Server and Administration Server. Close the Fedora Management Console for now.
Basically there are two set of Database files which store the SSL certificate, one for Directory Server and one for the Administration Server. These database file are usually stored in /opt/fedora-ds/alias ie
[root@jhett alias]# pwd
/opt/fedora-ds/alias
[root@jhett alias]# ls -al
total 344
drwxr-xr-x 2 nobody nobody 4096 Jul 12 10:56 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
-rw------- 1 nobody nobody 16384 Jul 12 10:56 secmod.db
-rw------- 1 nobody nobody 65536 Jul 12 10:56 slapd-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 10:56 slapd-jhett-key3.db
[root@jhett alias]#
As you can see only the LDAP backend slapd database file are initialise by default, for my piece of mind I usually re-initialise the db files for Directory and Administration Server.
Delete the LDAP backend database files and re-initialise them ie
[root@jhett alias]# cd /opt/fedora-ds/alias/
[root@jhett alias]# rm -rf *.db
[root@jhett alias]# ls -al
total 244
drwxr-xr-x 2 nobody nobody 4096 Jul 12 11:49 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
Now I’ve delete it, run the startconsole command again from earlier, which you should see this again as show in Figure 3.
Figure 3 – Fedora Management Console
Under the domain, then your Directory Server machine, then server group there is a link for Administration Server. Double Click on Administration Server, it will bring you a new window such as that in Figure 4.
Figure 4 – Administration Server
Now to initialise the Admin Server Certificates database, click on console -> security -> Manager Certificates, it will then prompt you for a password to set for access the certificate (adminserverpw1), it should create a new database certificate set for Administration Server and it should be empty for Server Certs, Revoked Certs but there are some default Certificate Authorities for CA Certs. Close that Windows, and close the Administration Window.
Now similarly for the Directory Server on the Fedora Directory Management Console, double click on the Directory Server (Under the domain, then your Directory Server machine, then server group there is a link for Directory Server) which should look like in Figure 5.
Figure 5 – Directory Server
To initialise the Directory Server Certificates database, click on console -> security -> Manager Certificates, it will then prompt you for a password to set for access the certificate (directoryserverpw1), it should create a new database certificate set for Directory Server and it should be empty for Server Certs, Revoked Certs but there are some default Certificate Authorities for CA Certs just like the Administration. Close that Windows, and close the Directory Server Window.
You can verify that the Certificate Database has been created by going to the /opt/fedora-ds/alias. As you can see, before there was only one file now its populated with several .db files for the Directory Server Components ie.
[root@jhett alias]# cd /opt/fedora-ds/alias
[root@jhett alias]# pwd
/opt/fedora-ds/alias
[root@jhett alias]# ls -al
total 428
drwxr-xr-x 2 nobody nobody 4096 Jul 12 13:26 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rw------- 1 nobody nobody 65536 Jul 12 12:06 admin-serv-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 12:11 admin-serv-jhett-key3.db
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
-rw------- 1 nobody nobody 16384 Jul 12 12:06 secmod.db
-rw------- 1 nobody nobody 65536 Jul 12 13:26 slapd-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 13:30 slapd-jhett-key3.db
[root@jhett alias]#
Directory Server comprises of slapd-jhett-cert8.db and slapd-jhett-key3.db, where Admin Server comprises of admin-serv-jhett-cert8.db and admin-serv-jhett-key3.db.
Now we have to import Secure Certificates we created earlier, we will import pkcs12 format of keys into database base file fro Directory Server and Admin Server by using the pk12util provided by the Fedora Directory Server.
The general command layout is shown below.
root@jhett bin]# pwd
/opt/fedora-ds/shared/bin
[root@jhett bin]# ./pk12util
Usage: pk12util-bin -i importfile [-d certdir] [-P dbprefix] [-h tokenname]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
[-v]
Usage: pk12util-bin -l listfile [-d certdir] [-P dbprefix] [-h tokenname]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
Usage: pk12util-bin -o exportfile -n certname [-d certdir] [-P dbprefix]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
[-v]
(Note the relatively where you execute the command when using the –d switch and check the prefix name of the db files when using the –p switch)
Now I’m going to insert the pkcs12 converted keys we generated earlier for Directory Server and Administration Server both into Certificate Database for Admin Server and Directory Server ie (Noticed that the files created are associated with your hostname of your machine so change it appropriately)
[root@jhett fedora-ds]# cd /opt/fedora-ds
[root@jhett fedora-ds]# pwd
/opt/fedora-ds
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/ldap/server.p12 -d alias -P admin-serv-jhett-
Enter Password or Pin for "NSS Certificate DB": (adminserverpw1)
Enter password for PKCS12 file: (dspassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/admingui/server.p12 -d alias -P admin-serv-jhett-
Enter Password or Pin for "NSS Certificate DB": (adminserverpw1)
Enter password for PKCS12 file: (adminpassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/admingui/server.p12 -d alias -P slapd-jhett-
Enter Password or Pin for "NSS Certificate DB": (directoryserverpw1)
Enter password for PKCS12 file: (adminpassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/ldap/server.p12 -d alias -P slapd-jhett-
Enter Password or Pin for "NSS Certificate DB": (directoryserverpw1)
Enter password for PKCS12 file: (dspassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
Now lets verify if the Certificate is imported, relaunch the console by running the startconsole command again.
Check the Administration Server, double click on it and then again click
console -> security -> Manager Certificates which again should be similar to Figure 6.
Figure 6 – Admin Server Certificate Manager
As you can see the Certificates we created earlier is imported into the Certificate Manager for Administration Server.
Now let us check the Directory Server, double click on it and then again click
console -> security -> Manager Certificates which you can see in Figure 7.
Figure 7 - Directory Server Certificate Manager
As you can see the Certificates we created earlier, is imported into the Certificate Manager for Directory Server.
Now although the certificate is imported they are not valid, so the Directory Server will not use it. You can verify the certificate is not valid on either the Directory Server or Admin Server by doing this.
Lets check the Directory Server, double click on it and then again click
console -> security -> Manager Certificates
or similarly
Lets check the Administration Server, double click on it and then again click
console->security->Manager Certificates
But if you look at the Server Certs, and click on any of the imported certificates you created, click detail. Now if you click under general, you will see that the certificate is has not been verified for any type of use and if you click on Certification Path, you will see it says “BROKEN_CERTIFICATE_CHAIN” as in Figure 8.
Figure 8 – NonValid Certificates
Now we have to make the Certificates we imported for the Directory Server and Administration Server valid. To do this all we have to import the Certificate Authority we created earlier for the two sets of certificates for Directory Server and Administration Server.
Lets make the Certificates imported into the Administration Server valid. To do this we run the startconsole and double click on the Administration Server, bringing up a new window. Click console -> Security -> Manage certificates.
Then click on CA Certs, and click install, you should see something similar to this in Figure 9.
Figure 9 – Step 1 of 4 Certificate Location
To make the Secure Certificates set generated for the Directory Server valid(Was generated/stored in /tmp/ldap), we need to install the Certificate Authority (/tmp/ldap/ca.crt) file that we generated for that set. Similary for the Secure Certificate set generated for the Administration Server (generated/stored in /tmp/admingui/ca.crt) we need to install the Certificate Authority (/tmp/admingui/ca.crt) to make that set valid.
In saying that, later we need to install the certificates for the Directory Server Set sy repeating the process of installing, by pointing the Certificate location for /tmp/ldap/ca.crt.
Now as we click next, you should see Figure 10.
Figure 10 - Step 2 of 4 Certificate Information
We click next again, you should see this in Figure 11
Figure 11 - Step 3 of 4 Certificate Install Wizard
Finally the last step, we click next and you should see this as in Figure 12.
Figure 12 - Step 4 of 4 Intended Purpose
Make sure you have both options ticked for Client Authentication and Server Authentication. (We can always un-tick it later), then click done. You should now see your CA certificate that you have imported appear under “CA Certs” tab.
Now if I click details on any Certificate Authority files we imported, you will see that it has all the details we put earlier when we generated the Certificates.
Now as you can see in Figure 13, in this particular case we are examining the Certificate Authority for Secure Certificate set of the Directory Server.
Figure 13 – Directory Server Certificate Authority File “Detail” tab
Now if we clicked on the “Server Certs” tab and re-examine the Server Cert generated for the Directory Server Set which is called DS-Server-Cert and click on detail and select the general tab. We can see now that the certificate is valid for SSL Server and Client use where as before it was not valid for any use as in Figure 14.
Figure 14 – Directory Server Certificate “General” tab
Similarly if we click on the Certification path it is no longer has a broken certificate chain as in Figure 15.
Figure 15 – Directory Server Certificate
“Certification Path” tab
Now you have to repeat this process to import the Certificate Authority to make the existing SSL certificates imported into the Directory Server / Admin Server valid this is dependent on which Certificate Authority file was signed off with.
Ie import
/tmp/ldap/ca.crt. -> Import in to Directory Server
/tmp/ldap/ca.crt. -> Import in to Administration Server
/tmp/admingui/ca.crt. -> Import in to Directory Server
/tmp/admingui/ca.crt. -> Import in to Administration Server
Now once you’ve imported , verify that the Certificates in your Server Certificate for Directory Server and Administration Server are valid. Once you have done that, I would recommend again you to do a backup of it.
tar cpfz /opt/fedora-ds.backup.sslimported.tgz /opt/fedora-ds
This is important, as if you screw up configuring the SSL, it may fail to come up. You can always restore it instead of redoing the steps from the instructions prior.
2.5 Configuring SSL on the Fedora Directory Server
Now we are going to configure SSL for the Directory Server and Administration Server, lets enable the SSL encryption connection for the Administration Server.
At the Fedora Management Console, double click on the Administration Server, click on configuration tab, then select encryption. Check the box for “Enable SSL for this server”, check the box “use the cipher family: RSA,” then pick the appropriate Certificate to use for encryption. In this case since it is the Administration Server, we should pick Admin-Server-Cert such as in Figure 16.
Figure 16 – Administration Server “Encryption” Tab
Similarly for the Directory Server, double click on the Directory Server at the Fedora Management Console, click on configuration tab, then select encryption. Check the box for “Enable SSL for this server”, check the box “use the cipher family: RSA”, then pick the appropriate Certificate to use for encryption which is DS-Server-Cert as show below
in Figure 17.
Figure 17 – Directory Server Encryption Settings
Once you’ve done that, the Directory Server indicates now LDAP connections on port 389 and LDAPs (Secure LDAP) connections on port 636.
Now we have enabled the encryption for the Directory Server and the Administration Server. We have to restart the service for both of them to enable the secure SSL connections.
/opt/fedora-ds/slapd-jhett/restart-slapd (To restart Directory Server)
/opt/fedora-ds/restart-admin (To restart Administration Server Server)
Now you would of noticed if you ever restarted the Directory and Administration Server any point in time prior to the SSL being enabled, you would not of been asked a password. After SSL is enabled to start and restart the service you need to enter the password to access the keys which you’ve imported previously ie adminserverpw1 for Administration Server and directoryserverpw1 for the Directory Server.
After restarting the services, the Administration Server, now can be bound via SSL connections and the LDAP can be connected via normal LDAP and Secure LDAP connections.
But currently the Administration Server is binding to the Directory Server via LDAP and not LDAPs. Now we have to rebind the Administration Server via LDAPs to the Directory Server.
Note when you run startconsole, because now you have made the Administration Server use SSL, you have to change the administration URL from http to https such as shown in Figure 18 to successfully login.
Figure 18 – Fedora Management Console Login via HTTPs
In the Fedora Management Console, double click on the Administration Server, now click on the configuration tab of the Administration Server, then select User DS tab, then configure the user DS.
LDAP Host and port: jhett.csse.uwa.edu.au:636
Enable Secure Connection
User Directory Subtree: dc=csse,dc=uwa,dc=edu,dc=au
Bind DN: cn=Directory Manager (Administrator Account used to change details)
Bind Password: XXXXXXXX
As shown in Figure 19
