Kerberos, LDAP and NFS

Recently I took a project to setup a SSO (Single Sign On) System for a small lab. We had a set of 25 computers, each with the following configuration:

• i3 processors (two cores)
• 500 GB HDD
• 4GB RAM

We had to install Fedora 19 in each of these machines, along with some standard softwares.

The Incremental Model:

1st architecture:

1 Server, the master server, who shall be thus referred to as cnl.cnl.net. (cnl stands for computer networks lab, for the more inquisitive readers). cnl.net is the realm/ring that we label all the computers in the lab with.

Day 1:

Setting up Server, DHCP Hostname.

1. We setup a single server, a Debian OS. (We do that because of an innate bias towards Debian OS, also due to over familiarity with using Ubuntu. :P)
2. We configure the servers dhcp client name (Note that all the machines in the lab are dhcp clients, including our Kerberos server, LDAP Server). for this we need to make changes in /etc/hosts file.
3. We decide to name the realm cnl.net . (A better extension would have been cnl.lab, but that is something we are going to ignore).
4. Hence the name assigned to the server ends with cnl.net. The hostname is now cnl.cnl.net. (This can be checked using the command hostname -f )

Setting up the Kerberos Server.
                                                                               
I followed this to setup the Kerberos Server. Its pretty much self explanatory. Few changes :

1. During installation of krb5-admin-server ,  there are a few default realm names, passwords, and principal users that are asked for. They are also self explanatory, just keep in mind to end the hostname with cnl.net.
2. My /etc/krb5.conf file looks like this: 

 [realms]
CNL.NET = {
kdc = cnl.cnl.net:88
admin_server = cnl.cnl.net:749
default_domain = cnl.net
}

[domain_realm]
.cnl.net = CNL.NET

[libdefaults]
default_realm = CNL.NET
dns_lookup_realm = false
dns_lookup_kdc = false

[kdc]
profile = /etc/krb5kdc/kdc.conf

[logging]
default = FILE:/var/log/kerberos/krb5libs.log
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmind.log

Kerberos Architecture defines AS and TGS as two separate entities. In our setup, they are the same host : cnl.cnl.net.

Troubleshooting and Testing The server:

principal :  any identity that asks for a ticket is called a principal [READ THIS]. For our usage, we setup the following principals.

1. harshal/admin@cnl.net
2. shehbaz@cnl.net.

format of a principal:

primary/instance@REALM

Note that for shehbaz, the default non-admin instance is taken.

some useful krb server commands:

server# kadmin -p krbadmin/admin
kadmin: listprincs
kadmin: addprinc root/admin
kadmin: addprinc shehbaz

Kerberos testing

Create ticket
server# kinit shehbaz Password for shehbaz@CNL.NET:

Verify ticket

server# klist
# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: shehbaz@CNL.NET
Valid starting Expires Service principal 09/01/11 00:56:58 09/01/11 10:56:58 krbtgt/CNL.NET@CNL.NET renew until 09/02/11 00:56:53

Day 2

1. Options to install Fedora on the Client Machine are here.
2. copy the /etc/krb.conf file from the server to the client machine.


Installing Kerberos clients for Debian and Fedora. 

Setting up LDAP

Running into a lot of issues right now. Messed up slapd configuration files. restoration took a lot of effort.
[TODO] Read up on ldap before trying to configure it.

Day 3 

Continuing with LDAP. Reading this and this to configure LDAP.

LDAP terminologies given here                         
                                                  

Day 4

Sweet Success!! :D

After a lot of reading, understood a bit of LDAP structure. Refer this this and this for a more detailed understanding.

Heres are some interesting things that one should know:

1. LDAP is basically a database in the form of a tree, just like a phonebook or yellow-pages.
2. It is a database structure optimized for reads rather than writes, so you basically make lots of searches and less number of additions/deletions/modifications. 
3. Three things: schema , objectclass , attributes :
   schema is the template on which the entries (actual physical elements of the database are configured). these are located in /etc/ldap/schema folder. these are of three types : structural, abstract, and auxillary.
   objectclass is a label on the schema. first node in the tree is top. other objectclasses inherit top and have other child objectclasses.
   attributes are properties of the objectclass, some are mandatory, while others are optional.                        
4. Main operations performed on an ldap database ldapadd, ldapsearch, ldapmodify.

NOTE :

1. There are a lot of objectclasses already available (defined in ldap), like person, organization etc.
2. slapd.conf is outdated, now they use OLC (Online control) (cn=config) file for ldap support. Though support for slapd.conf is still supported.

ldapadd

ldapadd -H ldap://cnl.cnl.net -x -D "cn=admin,dc=cnl,dc=net" -f demo.ldif -w <password>

My sample demo.ldif file:

dn: ou=admin,dc=cnl,dc=net
objectclass:top
objectclass: organizationalUnit
ou: admin

dn: ou=student,dc=cnl,dc=net
objectclass: top
objectclass: organizationalUnit
ou: student

dn: cn=harshal,ou=admin,dc=cnl,dc=net
objectclass: top
objectclass: person
objectclass: organizationalPerson
sn: Muknak
cn: Harshal Muknak
ou: admin

dn: cn=shehbaz,ou=student,dc=cnl,dc=net
objectclass: top
objectclass: person
objectclass: organizationalPerson
sn: Jaffer
cn: Shehbaz Jaffer
ou: student

NOTE that I did not have to add any schema definitions for creating the ldap directory structure (i.e. adding objectclass). I have used inbuilt schemas like person and organizationalUnit.

For LDAP Clients, on Fedora use this.

 

Day 6

Setting up NFSv4.

/etc/exports file:

/media/student        *(rw,nohide,no_root_squash,no_subtree_check,sync,fsid=0)

mount command:

sudo mount -v -t nfs4 192.168.10.150:/ /home/student

alternatively, for mounting on boot, add this to the end of /etc/fstab of the client:

192.168.10.150:/ /home/students nfs4 defaults       0 0

Note that the ip mentioned is the server IP. We mounted the whole '/' directory, however, only /media/student (the mountable directory on the server) gets mounted.

Follow the above statements as-is, or you will get lots of issues (No route to host etc).

Installing Fedora 19 using LiveUSB

I am trying to install Fedora 19 on one of the hosts. There are a lot of issues that I ran into, which I have documented here.

1. Creating A Live USB using Unetbootin

I am using a Debian Wheezy to create a Fedora 19 bootable USB. Unetbootin for Debian Wheezy has support for building only Fedora 16 x86_64 OS, but we are proceeding with choosing Fedora 16 x86_64 option and installing a Fedora 19 disk Image.

Errors:

After creating the Live USB, on boot the computer gives the following message:

No DEFAULT or UI configuration directive found!
boot:

To correct this, I formatted the pendrive using gparted   and created a FAT32 filesystem.

Install packages:

sudo apt-get install gparted dosfstools

Run gparted

sudo gparted

select the USB from devices menu (/dev/sdb in my case). and create a FAT32 filesystem for my USB.

Run unetbootin

sudo unetbootin

Select the appropriate Fedora 19 x86_64 iso image and install it on USB Image.

Live USB is ready.

The Fedora Setup

After choosing the Run Default option from UnetBootin Screen, I divided the fedora partitions into 3 parts:

Label	Type	Mount Point	Size
LinuxLocalFolder	ext4	/	380 GB
WindowsLocalFolder	ext4	/var	40GB
root	/home	ext4	20GB
Swap Space	swap	swap	20GB

LVM (Logical Volume Mount)

Something new, unlike previous Primary Partitions (4 in number ) and countless Logical Partitions, Fedora 19 gives us LVM, where we can just assign each partition the label LVM, and Fedora itself configures what to take as a primary partition and what to take as a logical partition.