From Colwiki.org

Contents 1 Domain Name Service 1.1 The /etc/resolv.conf file 1.2 Types of DNS servers 1.3 DNS Configuration Files 1.4 DNS zone files 1.4.1 Common Record Types 1.4.2 Zone parameters 2 Domain Host Configuration Protocol (DHCP) 3 LDAP 3.1 The Distinguished Name 3.2 OpenLDAP server configuration 3.2.1 Importing schemas 3.2.2 Database Definition 3.2.3 Client configuration files 3.2.4 Creating LDAP directories offline 3.3 TESTING 3.4 Creating LDAP Directories Online 4 LDAP Authentication Scheme 4.1 Server Configuration 4.2 Client Configuration

Domain Name Service

DNS assists in assigning an IP address to one or more names and assigning a name to an IP address. In Linux, this conversion is usually carried out by a special type of software known as bind. The machine that takes care of this conversion is called a name server. The names make up a hierarchical system in which each name component is separated by dots. The name hierarchy is, however, independent of the IP address hierarchy described above.

Consider a complete name, such as earth.example.com , written in the format hostname.domain. A full name, referred to as a fully qualified domain name (FQDN), consists of a hostname and a domain name (example.com). The latter also includes the top level domain or TLD (com). TLD assignment has become quite confusing for historical reasons. Traditionally, three letter domain names are used in the USA. In the rest of the world, the two-letter ISO national codes are the standard. In addition to that, longer TLDs were introduced in 2000 that represent certain spheres of activity (for example, .info, .name, .museum). In the early days of the Internet (before 1990), the file /etc/hosts was used to store the names of all the machines represented over the Internet. This quickly proved to be impractical in the face of the rapidly growing number of computers connected to the Internet. For this reason, a decentralized database was developed to store the hostnames in a widely distributed manner. This database, similar to the name server, does not have the data pertaining to all hosts in the Internet readily available, but can dispatch requests to other name servers.

The top of the hierarchy is occupied by root name servers. These root name servers manage the top level domains and are run by the Network Information Center (NIC). Each root name server knows about the name servers responsible for a given top level domain. Information about top level domain NICs is available at http://www.internic.net . DNS can do more than just resolve hostnames. The name server also knows which host is receiving e-mails for an entire domain—the mail exchanger (MX). For your machine to resolve an IP address, it must know about at least one name server and its IP address. Setting up a DNS Server

When a program needs to resolve a host name it uses a mechanism called a resolver. The resolver will first consult the /etc/nsswitch file (previously /etc/host.conf) and determine which method should be used to resolve host names (local files, name server, NIS, or ldap server)

The /etc/host.conf (or /etc/nsswitch.conf) file These files are scanned by the resolver. They indicate whether files, dns servers, ldap databases or nis servers should be consulted.

Example (/etc/nsswitch):

hosts:	files dns nis
networks: 	files

The first line indicates that files (here /etc/hosts) should be queried first and then a DNS server if this fails. The second line instructs to use the /etc/network file for network information. The /etc/hosts file

With a small number of networked computers it is possible to convert decimal IP numbers into names using the /etc/hosts file. The fields are as follows:

IP	machine	machine.domain	alias

Example /etct/hosts file:

192.168.1.233	io	 	      io.my.domain		
61.20.187.42	callisto		callisto.physics.edu

The /etc/resolv.conf file

If the resolver needs to use a domain name server (DNS) then it will consult the /etc/resolv.conf file for a list of available servers to query from. Hierarchical structure Name servers have a hierarchical structure. Depending on the location in the fully qualified domain name (FQDM) a domain is called top-level, second-level or third-level.

Example of Top Level Domains com Commercial organisations edu US educational institutions gov US government institutions mil US military institutions net Gateways and network providers org Non commercial sites uk UK sites

Types of DNS servers

Domains can be further divided into sbdomains. This limits the amount of information needed to administer a domain. Zones have a master domain name server (previously called a primary DNS) and one or several slave domain name servers (previously called secondary). Administration of a name server consists of updating the information about a particular zone. The master servers are said to be authoritative.

DNS Configuration Files

In old versions of BIND (prior to BIND version 8) the configuration file was /etc/named.boot. With BIND version 8 the /etc/named.conf file is used instead. One can use the named-bootconf.pl utility to convert old configuration files.

The /etc/named.boot file:

directory			/var/named
cache		.		named.ca
primary	myco.org		named.myco
primary	0.0.127.in-addr.arp	named.local
primary	1.168.192.in-addr.arp	named.rev

The first line defines the base directory to be used. The name.ca file will contain a list of DNS IP addresses for querying external addresses. The third line is optional and contains records for the local LAN. The two next entries are for reverse lookups.

In /etc/named.conf:

cache 		is replaced by hint 
secondary 	is replaced by slave
primary 	is replaced by master.

Applying these changes to BIND4 configuration files will generate BIND8 and BIND9 files such as the following. The /etc/named.conf file:

options 	{
		directory  “/var/named”;
};
zone 	“.” 	{
		type hint;
		file  “named.ca”;
};
zone “myco.org”	{
		type master;
		file “named.myco”;
};
zone “1.168.192.in-addr.arp” {
		type master;
		file “named.rev”;
};
zone  “0.0.127.in-addr.arpa” {
		type master;
		file   “named.local”;
};

DNS zone files

In this example the server is set as a caching-only server. All the zone files contain resource records.

Sample named.local zone file:

@       IN      SOA     localhost. root.localhost.  (
                                     2001022700 ; Serial
                                     28800      ; Refresh
                                     14400      ; Retry
                                     3600000    ; Expire
                                     86400 )    ; Minimum 
        IN      NS      localhost.
1       IN      PTR     localhost.

This is a very simple zone file but it gives us enough information to understand the basic mechanism of a name server.

The @ sign will resolve to the related zone declared in /etc/named.conf. This allows any zone file to be used as a template for further zones (see the exercises).

Common Record Types

NS	Specify the zones primary name server
PTR	Reverse mapping of IP numbers to hostnames
MX	Mail exchange record
A	Associate an IP address with a hostname
CNAME	Associate an alias with the host’s main name

Zone parameters

@ IN SOA Start Of Authority. Identifies the zone followed by options enclosed in brackets. serial Is manually incremented when data is changed. Secondary servers query the master server’s serial number. If it has changed, the entire zone file is downloaded refresh Time in seconds before the secondary server should query the SOA record of the primary domain. This should be at least a day. retry Time interval in seconds before attempting a new zone transfer if the previous download failed expire Time after which the secondary server discards all zone data if it contact the primary server. Should be a week at least minimum This is the ttl for the cached data. The default is one day (86400 seconds) but should be longer on stable LANs

Domain Host Configuration Protocol (DHCP)

WARNING!! You should not attempt to run a DHCP server unless you are certain not to interfere with the network you are currently using – The safest option for this section is to be totally isolated from the network and use a hub or a switch to connect the classroom together.

The basic communication process between a client workstation joining a TCP/IP network and the DHCP server is depicted below.

The DHCPDISCOVER request is sent using the broadcast 255.255.255.255 . The DHCP server can use two methods to allocate IP addresses:

1. A dynamic IP is assigned for a client host chosen from a range of IPs
2. A fixed IP is assigned for a specific host (identified using the MAC address, similar to bootp)

Since a single DHCP server can be used to administer IPs over several network, the dhcpd.conf configuration file is composed of global options followed by network sections:

Example network block:
subnet 10.0.0.0 netmask 255.0.0.0 {
....
}

In the next example we will assign both dynamic IP addresses and a fixed IP address:

subnet 10.0.0.0 netmask 255.0.0.0 {
	range 10.5.5.10 10.5.5.200;
 	host  proxy {
		hardware ethernet 00:80:C6:30:0A:7E;
                fixed-address 10.5.5.2;
        }
 }

For each subnet it is possible to give information on network services, such as

1. The default gateway
2. The DNS domain name and the NIS domain name
3. The DNS servers

In the subnet section above these directives would look like this:

	option routers                  10.254.254.254;
	option nis-domain               "nisdomain";
	option domain-name              "seafront.bar";
	option domain-name-servers      10.0.0.2;

The database of dynamically assigned IP addresses is stored in /var/lib/dhcp/dhcpd.leases

LDAP

LDAP stands for Lightweight Directory Access Protocol. The protocol allows access to data in a tree-like structure using attributes. LDAP can be thought of as a specialised database which handles trees. Since directories are also trees, navigating LDAP fields is like navigating a directory. Added to this LDAP has been designed mainly for optimal access. This clarifies the words Directory and Access. With this in mind let's see what characterises an LDAP database.

The Distinguished Name

An item in the database can be referenced using a unique Distinguished Name (dn). This is similar to a file's full path in a directory. Each intermediate subfolder is called a Relative Distinguished Name.

More Terminology

DIT	The Data Information Tree
DN	Distinguished Name
RDN	Relative Distinguished Name
LDIF	LDAP Data Interchange Format  

Attributes:

dc	Domain Component
cn	Common Name
c	Country 
l  	Location
o	Organisation 
ou 	Organisational Module
sn	Surname
st	State
uid 	User id 

OpenLDAP server configuration

The server is called slapd (Standalone LDAP daemon) and it's configuration file is:

/etc/openldap/slapd.conf

We will cover each section of this file in more detail

Importing schemas

There is an include clause in slapd.conf which tells the LDAP server which schemas should be loaded.We need at least the following:

include	/etc/openldap/schema/core.schema
include	/etc/openldap/schema/misc.schema
include                                                            /etc/openldap/schema/cosine.schema
include	/etc/openldap/schema/nis.schema
include                                                /etc/openldap/schema/inetorgperson.schema

Database Definition

Available DBMs (Database Managers) are ldbm or the more recent bdb. We will use bdb:

database	bdb

You need to specify the root or base for the LDAP directory, as well as the directory where the database file will be kept. This is done below;

suffix	 	“dc=example,dc=com”
directory	/var/lib/ldap/	

The following lines are only needed when modifying the LDAP server online. You can then specify an adminstrator username/password. Use the slappasswd to generate an encrypted hash:

rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}KiXS5htbnVEQp7OrjoteQZHHICs0krBO

Client configuration files

There are two configuration files called ldap.conf. Here is what they do:

• The /etc/ldap.conf file is used by the nss_ldap and pam_ldap modules
• The file /etc/openldap/ldap.conf is used by the tools ldapsearch and ldapadd

For example, to save time typing:

ldapsearch -b “dc=example,dc=com”  -x

you can add the next lines to /etc/openldap/ldap.conf

BASE    	dc=example, dc=com
HOST		127.0.0.1

So far we have configured slapd and the configuration file for ldapsearch in particular. Once we have populated an LDAP directory we will be able to test our setup by typing:

ldapsearch -x

Migrating System Files to LDAP There are two methods available to populate an LDAP directory.

• If the ldap daemon slapd is stopped, we can do an offline update using slapadd
• While slapd is running, it is possible to perform an online update using ldapadd or ldapmodify

We will also use migration tools which can be downloaded from: http://www.padl.com/OSS/MigrationTools.html

Creating LDAP directories offline

We are going to work in the directory containing the LDAP migration Perl scripts which we have downloaded from www.padl.com. Notice: Some distributions may include the migration tools with the LDAP server package.

You should have the following files:

migrate_automount.pl		migrate_base.pl
CVSVersionInfo.txt		migrate_common.ph
Make.rules			migrate_fstab.pl
MigrationTools.spec             		migrate_group.pl
README                          		migrate_hosts.pl
ads                            	 	migrate_netgroup.pl
migrate_netgroup_byhost.pl		migrate_aliases.pl              	
migrate_netgroup_byuser.pl		migrate_all_netinfo_offline.sh  
migrate_networks.pl		migrate_all_netinfo_online.sh   
migrate_passwd.pl			migrate_all_nis_offline.sh      
migrate_profile.pl			migrate_all_nis_online.sh       
migrate_protocols.pl		migrate_all_nisplus_offline.sh  
migrate_rpc.pl			migrate_all_nisplus_online.sh   
migrate_services.pl		migrate_all_offline.sh          
migrate_slapd_conf.pl		migrate_all_online.sh            

First edit migrate_common.ph and change the $DEFAULT_BASE variable to:

$DEFAULT_BASE = "dc=example,dc=com";

When migrating the /etc/passwd file one can either use shadow passwords or not. When using shadow passwords an added objectClass called shadowAccount is used in the LDAP record and there is no need to migrate the shadow password file.

We create our first LDIF file called base.ldif to serve as our root:

/migrate_base.pl > base.ldif

This flat file will be converted into bdb (or ldbm) files stored in /var/lib/ldap as follows:

slapadd -v < base.ldif

We next choose to migrate the password without shadow passwords as follows: pwunconv

./migrate_passwd.pl /etc/passwd passwd.ldif

The entries in passwd.ldif should look like this:

dn: uid=test,ou=People,dc=example,dc=com
uid: test
cn: test
objectClass: account
objectClass: posixAccount
objectClass: top
userPassword: {crypt}$1$FGrRfa0u$lo5XwA9xxssmjboNB2Z361
loginShell: /bin/bash
uidNumber: 505
gidNumber: 506
homeDirectory: /home/test

Now let's add this LDIF file to our LDAP directory:(remember that LDAP is stopped so we are still offline)

slapadd -v -l passwd.ldif  or
slapadd -v < passwd.ldif

NOTICE: Make sure all the files in /var/lib/ldap belong to user ldap

TESTING

Restart the LDAP server

/etc/init.d/ldap restart

Search all the entries in the directory:

ldapsearch -x 

If the ldap server does not respond, or the result from ldapsearch is empty, it is possible to show the content of the LDAP databases in /var/lib/ldap with the slapcat command.

Creating LDAP Directories Online

The LDAP server can be updated online, without having to shut the ldap service down. For this to work however we must specify a rootdn and a rootpw in /etc/openldap/slapd.conf.

The password is generated from the command line as follows

sldappasswd
New password:
Re-enter new password: 
{SSHA}XyZmHH1RlnSVXTj87UvxOAOCZA8oxNCT

We next choose the rootdn in /etc/openldap/slapd.conf to be

rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}XyZmHH1RlnSVXTj87UvxOAOCZA8oxNCT

The next line will update the LDAP entries

ldapmodify -f passwd.ldif -x -D “dc=example,dc=com” -W
Enter LDAP Password:

LDAP Authentication Scheme

Server Configuration

We assume that the LDAP server has been configured as above. The passwords in the LDAP directory can also be updated online with the ldappasswd command. The next line will update the password for user tux on the LDAP server.

ldappasswd  -D "cn=Manager,dc=example,dc=com"  -S -x -W  \ "uid=tux,ou=People,dc=example,dc=com"

The -S switch is used to configure a new password.

We assume that the IP address for the server is 10.0.0.1 and that the domain component is “dc=example,dc=com” You may allow users to change their passwords on the LDAP server as follows: 1. Copy the passwd PAM file /etc/share/doc/nss_ldap-version/pam.d/passwd to /etc/pam.d

2. Add the following access rule in /etc/openldap/slapd.conf

 access to attrs=userPassword 
 by self write
 by anonymous auth
 by * none

Client Configuration

The clients need to have the nss_ldap package installed (some distributions have a separate pam_ldap package with the PAM related modules and files). The following files and libraries are installed:

/etc/ldap.conf	 set the hostname and the domain component of the LDAP server used for authentications
/lib/libnss_ldap-2.3.2.so	 an ldap module for the NameService Switch
/lib/security/pam_ldap.so	 the PAM ldap module
/usr/lib/libnss_ldap.so	 a symbolic link to /lib/libnss_ldap-2.3.2.so
/usr/share/doc/nss_ldap-207/pam.d	 sample files for programs using PAM 

If we don't use SSL certificates then /etc/ldap.conf is as follows:

The /etc/ldap.conf file

host 10.0.0.1 
base dc=example,dc=com 
ssl no 
pam_password md5

Next in /etc/pam.d replace the file called login with /usr/share/doc/nss_ldap-207/pam.d/login. This will tell the authentication binary /bin/login to use the pam_ldap.so module. Finally the /etc/nsswitch.conf needs to have the following line:

passwd ldap files

Check the /var/log/ldap/ldap.log file on the server to follow the authentication process.

This work is licenced under a Creative Commons - By Attribution Licence - Share Alike License.