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.x Installation, Configuration & Client Binding

Initial Beta Revision – 26/07/2006 – Created by Ashley Chew (ashley@csse.uwa.edu.au)

  

 

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]:Western Australia

Locality Name (eg, city) [Newbury]:Perth

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]:Western Australia

Locality Name (eg, city) [Newbury]:Perth

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]:Western Australia

Locality Name (eg, city) [Newbury]:Perth

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]:Western Australia

Locality Name (eg, city) [Newbury]:Perth

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]:Western Australia

Locality Name (eg, city) [Newbury]:Perth

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

 

 

Figure 19 – Administration Server “User DS” configeration

 

Now basically save it quit the Administration Server, and quit Directory Server (If opened) and the Fedora Management console. Now again we have to restart the Admin Server.

 

/opt/fedora-ds/restart-admin (Enter your password to access its secure certificates), verify its still working ie by running the startconsole command and try logging in which should work.

 

Note that you only have a partial SSL connection between the Administration Server and the Directory Server. Now at the Fedora Console Management, run the Administration Server, click on the configuration tab then the configuration DS. Enable the Secure Connection which should swap it from port 389 to 636 and click save. Again quit the Administration Server, Directory Server (If opened) and the Fedora Management console and restart the Admin Server.

 

/opt/fedora-ds/restart-admin

 

Again run the startconsole command, if you check the configuration tabs for the administration server all options are checked for SSL its binding via LDAPs.

 

That’s Basically it, to installing and configuring a Fedora Directory LDAP server for LDAP and LDAPs connections.

 

2.6) Fedora Directory Server - Points of Interest & Bugs

 

Now if you have an Fedora Directory Server working normally via LDAP but as soon as you switch to bind via LDAPs and fails it was a bug with Fedora Directory Server, but it should have been rectified see this.

 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175170

 

Before you starting creating users, groups etc in your LDAP directory it’s a good idea to take a backup of it. As I’ve mentioned several times over, the Fedora Directory Server is self contained all you have to do is take a copy of the Directory /opt/fedora-ds ie such as creating a tar ball. All you have to do is basically stop the Directoy Server/ Administarion Server delete /opt/fedora-ds and untar the backup.

 

If you have problems don’t be afraid to check the logs. The Directory Server stores its logs /opt/fedora-ds/slapd-jhett/logs (Relative to your machine hostname). Ie if I wanted to see if the Directory Server is accepting both LDAP and LDAPs connection.

 

[root@jhett logs]# pwd

/opt/fedora-ds/slapd-jhett/logs

[root@jhett logs]# cat errors

        Fedora-Directory/1.0.2 B2006.060.1951

        jhett.csse.uwa.edu.au:636 (/opt/fedora-ds/slapd-jhett)

 

[14/Jul/2006:11:23:13 +0800] - Fedora-Directory/1.0.2 B2006.060.1951 starting up

[14/Jul/2006:11:23:15 +0800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

[14/Jul/2006:11:23:15 +0800] - Listening on All Interfaces port 636 for LDAPS requests

 

As you can see its binded to port 636 for LDAPs and 389 for LDAP connection etc. Similarly for Administration Server logs are keep in /opt/fedora-ds/admin-server/logs.

 

3.0 Binding Linux/Unix Machines, MAC OSX & Windows Clients to LDAP

 

Before we begin, binding Linux/Unix Machines, Mac OSX and Windows Client to LDAP server they are three majorly different platforms. And we have to employ the lowest co-dominator which will work with all three platforms. What I’m referring to the password schema support for the platforms.

 

The Fedora Directory Server supports a wide password schema format ie CLEAR, CRYPT, DES, MD5, SHA, SSHA etc and variations of the form which may not works on all platforms. Ie if a password was stored as a variation of MD5 which worked on Linux machine, may not work on Mac as it does not recognize the password format (Actually this is true about the Macs OSX as from 10.4.7, MD5 password from a LDAP server but I’m pretty sure MD5 works locally. And don’t even get me started with the Mac OSX LDAP server after all the grief I’ve been though) or vice versa.

 

3.1 Configuring Password Policy for all three Platforms

 

The common password format that works on all platforms is common crypt hash method, so before creating users on the system. I would force all users password to be stored in the crypt format thus if the machine be it linux / unix, windows or a Mac OSX binded to the LDAP directory the authentication will work.

 

And doing this even older machines ie such as Unix variants like Tru64 which does not support LDAP you can generate a NIS mappings from your LDAP server and bind it via NIS (Known as YP or formerly Yellow Pages).

 

To do this run, the Fedora Management Console, Launch the Directory Server. What we are going to do is set a Managed Password Policy for all Users in the LDAP Directory.

 

Now Click on the Directory tab, expand config, right click on plugins and select managed Password Policy and select For User which you should see something like this as show in Figure 20.

 

 

Figure 20 – Directory Server “User Password Policy”

 

Under the Passwords Tab, enable Create user level password policy. The one I’m most interested in is the Password Syntax. Enable the Check password syntax and for the encryption method select Unix crypt algorithm (CRYPT) and click save. You might want to change the Password syntax like character length, its also worth taking a look at account lockout if you want to lock accounts out if there is to many bad attempts.

From now on all accounts password will be stored in the Directory Server as a CRYPT format.

 

3.2 Binding Linux/Unix Machines to LDAP

 

The client system I’m using to bind to the LDAP directory is Fedora Core 4 system. Which is pretty straight forward, if you want to bind just via LDAP. Run the command setup and select Authentication configuration such as shown below in Figure 21

 

 

Figure 21 – Fedora Setup tools

 

Now you will be prompted now for how it will Authenticate, which you choose LDAP, Authentication all you really need is “Use LDAP authentication”, but I also have local users on the machine which use MD5 Passwords and Shadow passwords so I check those as well as shown in Figure 22.

 

 

Figure 22 – Authentication Configuration

 

Now it will ask you details about your LDAP Server settings. In my example the server is jhett.csse.uwa.edu.au and the Base DN is dc=csse,dc=uwa,dc=edu,dc=au

You only tick TLS if you have SSL enabled on your server as shown in figure 23(We are not  enabling the LDAP connection for the moment, LDAPs involves more work which requires manual intervention)

 

 

Figure 23 – LDAP Settings

 

If you unchecked TLS that’s fine. Your machine will only connect via normal LDAP connections and not LDAPs.

 

Else if you’ve checked TLS you will need to do further configuration to enable it to connect via LDAPs which are not enabled in the RedHat menu configuration which you have to do manually.

 

You probably asked what happens if I’m not using a RedHat Enterprise or RedHat Fedora Core distribution so I don’t have the authentification menu to do my configurations.

 

That’s okay read the next section which will detail what configurations files are modified to get LDAPs working which incidently tell you also what files to modify to get LDAP working as well.

 

This should work just about on any Linux/Unix configurations as the authentication menu will only really do the basic things, the more complex LDAPs requires all user to manually configure it.

 

3.3 Binding Linux/Unix Machines to LDAPs

 

First of all for your client LDAP machine to connect via LDAPs you need to have the Certificate Authority file installed on your client which was generated for the Directory Server to allow it to recognize that the SSL connection is valid.

 

So on your client lets you have to copy the file /tmp/ldap/ca.crt on the Fedora Direcotry server in my case the machine as called jhett.csse.uwa.edu.au . I’ll copy ca.crt onto my local machine into /etc/cert/ca.crt.

 

Now we have the Certificate Authority file stored locally on the client machine, now we have to tell the machine to use LDAP.

 

Previously you saw me using the setup then running the authentification menu to configure for LDAP. One of the files that authentification GUI menu edits for you is /etc/nsswitch.conf which governs several things one is the authentification lookup method, the field headings in this file is password, shadow and group.

For those who don’t have that GUI edit this file and change the field for password, shadow and group. You can also incorporate over services lookup from LDAP but that’s another story for another day.

 

 [root@jhett etc]# pwd

/etc

[root@jhett etc]# cat nsswitch.conf

#

# /etc/nsswitch.conf

#

# An example Name Service Switch config file. This file should be

# sorted with the most-used services at the beginning.

#

# The entry '[NOTFOUND=return]' means that the search for an

# entry should stop if the search in the previous entry turned

# up nothing. Note that if the search failed due to some other reason

# (like no NIS server responding) then the search continues with the

# next entry.

#

# Legal entries are:

#

#       nisplus or nis+         Use NIS+ (NIS version 3)

#       nis or yp               Use NIS (NIS version 2), also called YP

#       dns                     Use DNS (Domain Name Service)

#       files                   Use the local files

#       db                      Use the local database (.db) files

#       compat                  Use NIS on compat mode

#       hesiod                  Use Hesiod for user lookups

#       [NOTFOUND=return]       Stop searching if not found so far

#

 

# To use db, put the "db" in front of "files" for entries you want to be

# looked up first in the databases

#

# Example:

#passwd:    db files nisplus nis

#shadow:    db files nisplus nis

#group:     db files nisplus nis

 

passwd:     files ldap

shadow:     files ldap

group:      files ldap

 

#hosts:     db files nisplus nis dns

hosts:      files dns

 

# Example - obey only what nisplus tells us...

#services:   nisplus [NOTFOUND=return] files

#networks:   nisplus [NOTFOUND=return] files

#protocols:  nisplus [NOTFOUND=return] files

#rpc:        nisplus [NOTFOUND=return] files

#ethers:     nisplus [NOTFOUND=return] files

#netmasks:   nisplus [NOTFOUND=return] files

 

#bootparams: nisplus [NOTFOUND=return] files

 

ethers:     files

netmasks:   files

networks:   files

protocols:  files ldap

rpc:        files

services:   files ldap

 

netgroup:   files ldap

 

#publickey:  nisplus

 

automount:  files ldap

aliases:    files nis

 

Editing nsswitch.conf now tell your machine to use LDAP after it fails the local user accounts on the local machine. But you still have to tell the LDAP machine where to use SSL certificates and which LDAP server etc. The other file which the authentification GUI edit is /etc/ldap.conf (Some distribution store it in /etc/openldap/ldap.comf but neverless you just need to locate it and edit it)

 

The fields that we are interested in are host, base, nss_base_passwd, nss_base_shadow, nss_base_group, tls_cacertfile, tls_cacertdir and ssl which are in bold as indicated below.

The mapping between for nss_base_passwd, nss_base_shadow and nss_base_group shown in my configuration file are the default Fedora Directory Schema, you can remap them accordingly if you choose to change the schema along with other values you place in your LDAP.

 

[root@jhett etc]# cd /etc

[root@jhett etc]# pwd

/etc

[root@jhett etc]# cat ldap.conf

 

 

# @(#)$Id: ldap.conf,v 1.34 2004/09/16 23:32:02 lukeh Exp $

#

# This is the configuration file for the LDAP nameservice

# switch library and the LDAP PAM module.

#

# PADL Software

# http://www.padl.com

#

 

# Your LDAP server. Must be resolvable without using LDAP.

# Multiple hosts may be specified, each separated by a

# space. How long nss_ldap takes to failover depends on

# whether your LDAP client library supports configurable

# network or connect timeouts (see bind_timelimit).

host jhett.csse.uwa.edu.au

 

# The distinguished name of the search base.

base dc=csse,dc=uwa,dc=edu,dc=au

 

# Another way to specify your LDAP server is to provide an

# uri with the server name. This allows to use

# Unix Domain Sockets to connect to a local LDAP Server.

#uri ldap://127.0.0.1/

#uri ldaps://127.0.0.1/  

#uri ldapi://%2fvar%2frun%2fldapi_sock/

# Note: %2f encodes the '/' used as directory separator

 

# The LDAP version to use (defaults to 3

# if supported by client library)

#ldap_version 3

 

# The distinguished name to bind to the server with.

# Optional: default is to bind anonymously.

#binddn cn=proxyuser,dc=example,dc=com

 

# The credentials to bind with.

# Optional: default is no credential.

#bindpw secret

 

# The distinguished name to bind to the server with

# if the effective user ID is root. Password is

# stored in /etc/ldap.secret (mode 600)

#rootbinddn cn=manager,dc=example,dc=com

 

# The port.

# Optional: default is 389.

# port 389

 

# The search scope.

#scope sub

#scope one

#scope base

 

# Search timelimit

#timelimit 30

 

# Bind/connect timelimit

#bind_timelimit 30

 

# Reconnect policy: hard (default) will retry connecting to

# the software with exponential backoff, soft will fail

# immediately.

#bind_policy hard

 

# Idle timelimit; client will close connections

# (nss_ldap only) if the server has not been contacted

# for the number of seconds specified below.

#idle_timelimit 3600

 

# Filter to AND with uid=%s

#pam_filter objectclass=account

 

# The user ID attribute (defaults to uid)

#pam_login_attribute uid

 

# Search the root DSE for the password policy (works

# with Netscape Directory Server)

#pam_lookup_policy yes

 

# Check the 'host' attribute for access control

# Default is no; if set to yes, and user has no

# value for the host attribute, and pam_ldap is

# configured for account management (authorization)

# then the user will not be allowed to login.

#pam_check_host_attr yes

 

# Check the 'authorizedService' attribute for access

# control

# Default is no; if set to yes, and the user has no

# value for the authorizedService attribute, and

# pam_ldap is configured for account management

# (authorization) then the user will not be allowed

# to login.

#pam_check_service_attr yes

 

# Group to enforce membership of

#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com

 

# Group member attribute

#pam_member_attribute uniquemember

 

# Specify a minium or maximum UID number allowed

#pam_min_uid 0

#pam_max_uid 0

 

# Template login attribute, default template user

# (can be overriden by value of former attribute

# in user's entry)

#pam_login_attribute userPrincipalName

#pam_template_login_attribute uid

#pam_template_login nobody

 

# HEADS UP: the pam_crypt, pam_nds_passwd,

# and pam_ad_passwd options are no

# longer supported.

#

# If you are using XAD, you can set pam_password

# to racf, ad, or exop. Make sure that you have

# SSL enabled.

 

# Do not hash the password at all; presume

# the directory server will do it, if

# necessary. This is the default.

# pam_password clear

 

# Hash password locally; required for University of

# Michigan LDAP server, and works with Netscape

# Directory Server if you're using the UNIX-Crypt

# hash mechanism and not using the NT Synchronization

# service.

# pam_password md5

 

# Remove old password first, then update in

# cleartext. Necessary for use with Novell

# Directory Services (NDS)

# pam_password nds

 

# RACF is an alias for the above. For use with

# IBM RACF

# pam_password racf

 

# Update Active Directory password, by

# creating Unicode password and updating

# unicodePwd attribute.

# pam_password ad

 

# Use the OpenLDAP password change

# extended operation to update the password.

# pam_password exop

 

# Redirect users to a URL or somesuch on password

# changes.

#pam_password_prohibit_message Please visit http://internal to change your password.

 

# RFC2307bis naming contexts

# Syntax:

# nss_base_XXX          base?scope?filter

# where scope is {base,one,sub}

# and filter is a filter to be &'d with the

# default filter.

# You can omit the suffix eg:

# nss_base_passwd ou=People,

# to append the default base DN but this

# may incur a small performance impact.

#nss_base_passwd  ou=People,dc=example,dc=com?one

nss_base_passwd ou=People,dc=csse,dc=uwa,dc=edu,dc=au

#nss_base_shadow  ou=People,dc=example,dc=com?one

nss_base_shadow ou=People,dc=csse,dc=uwa,dc=edu,dc=au

#nss_base_group         ou=Group,dc=example,dc=com?on

nss_base_group  ou=Groups,dc=csse,dc=uwa,dc=edu,dc=au

#nss_base_hosts         ou=Hosts,dc=example,dc=com?one

#nss_base_services      ou=Services,dc=example,dc=com?one

#nss_base_networks      ou=Networks,dc=example,dc=com?one

#nss_base_protocols     ou=Protocols,dc=example,dc=com?one

#nss_base_rpc           ou=Rpc,dc=example,dc=com?one

#nss_base_ethers  ou=Ethers,dc=example,dc=com?one

#nss_base_netmasks      ou=Networks,dc=example,dc=com?ne

#nss_base_bootparams    ou=Ethers,dc=example,dc=com?one

#nss_base_aliases ou=Aliases,dc=example,dc=com?one

#nss_base_netgroup      ou=Netgroup,dc=example,dc=com?one

 

# attribute/objectclass mapping

# Syntax:

#nss_map_attribute      rfc2307attribute  mapped_attribute

#nss_map_objectclass    rfc2307objectclass      mapped_objectclass

 

# configure --enable-nds is no longer supported.

# NDS mappings

#nss_map_attribute uniqueMember member

 

# Services for UNIX 3.5 mappings

#nss_map_objectclass posixAccount User

#nss_map_objectclass shadowAccount User

#nss_map_attribute uid msSFU30Name

#nss_map_attribute uniqueMember msSFU30PosixMember

#nss_map_attribute userPassword msSFU30Password

#nss_map_attribute homeDirectory msSFU30HomeDirectory

#nss_map_attribute homeDirectory msSFUHomeDirectory

#nss_map_objectclass posixGroup Group

#pam_login_attribute msSFU30Name

#pam_filter objectclass=User

#pam_password ad

 

# configure --enable-mssfu-schema is no longer supported.

# Services for UNIX 2.0 mappings

#nss_map_objectclass posixAccount User

#nss_map_objectclass shadowAccount user

#nss_map_attribute uid msSFUName

#nss_map_attribute uniqueMember posixMember

#nss_map_attribute userPassword msSFUPassword

#nss_map_attribute homeDirectory msSFUHomeDirectory

#nss_map_attribute shadowLastChange pwdLastSet

#nss_map_objectclass posixGroup Group

#nss_map_attribute cn msSFUName

#pam_login_attribute msSFUName

#pam_filter objectclass=User

#pam_password ad

 

# RFC 2307 (AD) mappings

#nss_map_objectclass posixAccount user

#nss_map_objectclass shadowAccount user

#nss_map_attribute uid sAMAccountName

#nss_map_attribute homeDirectory unixHomeDirectory

#nss_map_attribute shadowLastChange pwdLastSet

#nss_map_objectclass posixGroup group

#nss_map_attribute uniqueMember member

#pam_login_attribute sAMAccountName

#pam_filter objectclass=User

#pam_password ad

 

# configure --enable-authpassword is no longer supported

# AuthPassword mappings

#nss_map_attribute userPassword authPassword

 

# AIX SecureWay mappings

#nss_map_objectclass posixAccount aixAccount

#nss_base_passwd ou=aixaccount,?one

#nss_map_attribute uid userName

#nss_map_attribute gidNumber gid

#nss_map_attribute uidNumber uid

#nss_map_attribute userPassword passwordChar

#nss_map_objectclass posixGroup aixAccessGroup

#nss_base_group ou=aixgroup,?one

#nss_map_attribute cn groupName

#nss_map_attribute uniqueMember member

#pam_login_attribute userName

#pam_filter objectclass=aixAccount

#pam_password clear

 

# Netscape SDK LDAPS

#ssl on

 

# Netscape SDK SSL options

#sslpath /etc/ssl/certs/cert7.db

 

# OpenLDAP SSL mechanism

# start_tls mechanism uses the normal LDAP port, LDAPS typically 636

#ssl start_tls

#ssl on

 

# OpenLDAP SSL options

# Require and verify server certificate (yes/no)

# Default is "no"

#tls_checkpeer yes

 

# CA certificates for server certificate verification

# At least one of these are required if tls_checkpeer is "yes"

#tls_cacertfile /etc/ssl/ca.cert

#tls_cacertdir /etc/ssl/certs

tls_cacertfile /etc/cacerts/ca.crt

tls_cacertdir /etc/cacerts

 

# Seed the PRNG if /dev/urandom is not provided

#tls_randfile /var/run/egd-pool

 

# SSL cipher suite

# See man ciphers for syntax

#tls_ciphers TLSv1

 

# Client certificate and key

# Use these, if your server requires client authentication.

#tls_cert

#tls_key

 

# Disable SASL security layers. This is needed for AD.

#sasl_secprops maxssf=0

 

# Override the default Kerberos ticket cache location.

#krb5_ccname FILE:/etc/.ldapcache

 

# SASL mechanism for PAM authentication - use is experimental

# at present and does not support password policy control

#pam_sasl_mech DIGEST-MD5

ssl start_tls

ssl on

 

 

That’s basically it, there was only one other problem that I cam across. Normal users don’t have the necessary previledges to do the look up in the LDAP information although they authenticated.

 

Ie when a user logs in, there is an error message saying something like this

 

id:cannot find name for user ID 10001

id:cannot find name for group ID 1002

id:cannot find name for group ID 1003

id:cannot find name for group ID 1003

 

This is solved by switching on nscd (You can turn nscd by running setup, select system services and turn on nscd). The service nscd binds as root but caches the information for the user.

 

3.4 Binding Mac OSX Machines to LDAP.

 

Like the Linux/Unix machines if you want to bind via Secure LDAP, you have to place the Certificate Root Authority File so it knows to trust the SSL connection. Again you have to copy /tmp/ldap/ca.crt to somewhere on the Mac and import it. In Mac OSX you have to use Keychain access. Its located in Finder->Applications->Utilities, run Keychain access and click show Keychains which should show you this in Figure 24.

 

 

Figure 24 – Keychain access

 

Go to X509Anchors, and select the import function and import the ca.crt ( Originally on jhett.csse.uwa.edu.au in the directory /tmp/ldap/ca.crt ). Now look at the certificate imported issued by jhett and click the trust settings.

 

 

Figure 25 – KeyChain Access Examining Certificate Authority

 

 Now set the trust settings for this certificate and set this to always trust as in Figure 26.

 

 

Figure 26 – Key Chain Access Examining Certificate Authority Trust Settings

 

I’ve also added repeated the process for importing the certificate for System and setting it to trust for the Login and System chain. I’m not quite sure which chain you meant to add it to the Mac (I’ll be revising this later).

 

Now we can bind the Mac OSX to LDAP, to do this we run Directory Access. First we are going to bind via LDAP first, then via Secure LDAPs.

 

Check the box for LDAPv3, click configure and click show options which you see something as in Figure 27.

 

 

Figure 27 – Directory Access with LDAP Bindings.

 

Now set the servername: jhett.csse.uwa.edu.au, check the box for Use for authentication then click manual as shown below in Figure 28.

 

 

Figure 28 – New LDAP Connection

 

Then you should be brought to a menu similar to this, for the connection menu check the box use LDAPv2 (I’m not quite sure why, I couldn’t get LDAPv3 working and had to check the box but if I enabled LDAPv3 with SSL for LDAPs connection it all works.   Fedora Directory Server is LDAPv3 Compliant. I’m finding lots of things which are not what I expected in a Mac) which you should see something again similar to Figure 29.

 

 

 

Figure 29 – LDAP Connection Configuration

 

 

 

Now Click on Search & Mapping tab, you should see something similar below in Figure 30 , the Search & Mappings creates the mapping between the information provided in the LDAP schema to the local information required by the local machines.

 

In this case for users and groups information we are only dealing with People and Group schema, on the Fedora Directory LDAP server which we have to remap. So for the “Access this LDAPv3 server using” pick CUSTOM.

 

 

 

Figure 30 – LDAP Search & Mappings Configuration

 

Now you have to add several Record Types which then you have to add attributes for these record types.  Then you have to map these record types and their corresponding attributes to the LDAP schema. As mentioned earlier, all we are dealing is User and Group Information so click add and pick Record Type and select Users then similarly click add and pick Record Type and pick Groups as in Figure 31.

 

 

Figure 31 – Users and Groups Record Type

 

First of all we need to configure Attribute Types, by adding some attributes then remap these attributes to the LDAP schema.

 

Attribute type for “Default Attribute Types” -> None

RecordName -> cn

CreationTimestamp -> createTimestamp

ModificationTimestamp -> modifyTimestamp

 

Ie Below I’ve click on the Default attribute Types, click add and selected Record Types and added RecordName. Then for the RecordName on the right click add and type add cn. You have to do this for the attributes mentioned above. If you mapped them you should see something like in Figure 32.

 

 

 

Figure 32 – Default Attributes Types Mapping

 

Attribute type for “Users”->  posixAccount, inetOrgPerson, shadowAccount

RecordName -> uid,cn

RealName -> cn

UniqueID -> uidNumber

PrimaryGroupID -> gidNumber

NFSHomeDirectory -> homeDirectory

Password -> userPassword

UserShell -> loginShell

Comment -> description

Change -> shadowLastChange

Expire -> shadowExpire

(Note if it has more then one value for that attribute it goes on a new line)

 

When Mapped you should see something like in Figure 33

 

 

Figure 33 – Users Mapping

 

If I expand the Users Type Record (Clicking the arrow) I get the expanded view as in Figure 34.

 

 

Figure 34 – Users Mapping Expanded

 

Now we mapped the Groups Attributes

 

Attribute type for “Groups”->  posixGroup

GroupMembership -> memberUid

Member -> memberUid

PrimaryGroupID -> gidNumber

 

When done and expanded the view like earlier with Users Type Record you get Figure

35.

 

 

Figure 35 – Groups Mappings Expanded

 

 

These values are not pulled from thin air, if you want to extend the schema you have to understand the Apple’s Directory Access Variable Schema and map accordingly, similarly with the Fedora Directory Server you have to read the schema layout.

 

Now you have basically configured the Mac OSX to bind via LDAP but you havn’t told it to use the LDAP configeration. To do then run Directory Access and click Authentication. Set it to Custom path and add your server to the Directory Domains /LDAPv3/jhett.csse.uwa.edu.au as seen in Figure 36.

 

 

Figure 36 – Directory Access Authentication

 

That’s basically it for binding via LDAP for Mac OSX.

 

 3.5 Binding Mac OSX Machines to LDAPs

 

 Now if you wanted to bind via LDAPs via SSL certificate. All you have to do is check a few boxes provided your client has imported the client certificate done earlier. Run Directory Access again, run Services -> LDAPv3 -> configure pick jhett. Then look at the Connection tab and check the box for “Encrypt using SSL” and “ignore server referrals” as seen in Figure 37.

 

 

Figure 37 – LDAPs Connection Configuration

 

Then similarly on the Security Tab, check the box for “Disable clear text passwords” and “Encrypt all packets (requires SSL or Kerberos)” as in Figure 38.

 

 

 

Figure 38 – LDAPs Security Mappings

 

That’s it for LDAPs connection for the Mac OSX.

3.6 Binding Windows boxes to LDAP/LDAPs

 

You can’t bind your Windows Client Directory to the LDAP Directory, but you can use your LDAP directory indirectly as your authentication server.

 

What the Fedora Directory Server provides is a Program called PassSync, which basically sync the password from the Directory Server to the Active Directory ( which you can get here http://directory.fedora.redhat.com/download/PassSync-1.msi ). All you have to do is install it and point it to the LDAP server.

 

You have to set the password policy on the Windows Server to none so it won’t interfere with the syncing process ie not accepted password because its too short. The password policy will be dictated by the LDAP server

 

(This Section is still to be updated in regards to Windows, I don’t have as much time on my hand to finish or test it as of yet?)