View source

From Colwiki.org

for Setting up Basic Networking Services: DNS, DHCP and LDAP
You do not have permission to do that, for the following reason:
The action you have requested is limited to users in the group user.
You can view and copy the source of this page:
{{Outcomes|Upon completion of this module you will be able to: 
*Understand DNS, DHCP and Lightweight Directory Services (LDAP) plus be able to Install and Configure  DNS, DHCP and LDAP
}}
 
{{Terminology|
*Master Zone DNS:	The master zone includes all hosts from your network and a DNS server master zone stores up-to-date records for all the hosts in your domain.
*Slave Zone DNS:	A slave zone is a copy of the master zone. The slave zone DNS server obtains its zone data with zone transfer operations from its master server. The slave zone DNS server responds authoritatively for the zone as long as it has valid The Domain Name System
*DHCP	Dynamic Host Configuration Protocol (DHCP) is a network application protocol used by devices (DHCP clients) to obtain configuration information for operation in an Internet Protocol network. This protocol reduces system administration workload, allowing devices to be added to the network with little or no manual intervention.
*LDAP	The Lightweight Directory Access Protocol, is an application protocol for querying and modifying directory services running over TCP/IP.A directory is a set of objects with attributes organized in a logical and hierarchical manner. A simple example is the telephone directory, which consists of a list of names (of either persons or organizations) organized alphabetically, with each name having an address and phone number associated with it.
}}

=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

 
{{Reading|From the SuSE Linux Enterprise Server (Installation and Administration Document) read Pg 631 – 637 on DNS Implementation on SUSE Linux}}

=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.

[[Image:Dhcp.png]] 

The DHCPDISCOVER request is sent using the broadcast 255.255.255.255 . The DHCP server can use two methods to allocate IP addresses:
#A dynamic  IP is assigned for a client host chosen from a range of IPs
#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 
#The default gateway 
#The DNS domain name and the NIS domain name
#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 
 
{{Reading|
From the SuSE Linux Enterprise Server (Installation and Administration Document) read Pg 637 – 653 on DHCP Implementation on SUSE Linux}}

=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.

[[Image:Ldapdn.png]]

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.

 
{{Reading|From the SuSE Linux Enterprise Server (Installation and Administration Document) read Pg 663 – 697 on LDAP Implementation on SUSE Linux}}


{{Summary|In this module you learned some of the backbone services required of Linux in any organization.The LDAP Service is critical where you would like to maintain a central point of authentication for all your users in the system. DNS and DHCP Services are very critical for the management of the Local Area Network.}}
 

{{Assignment|You should by now have installed webmin (www.webmin.com ), you are required to use Webmin interface to configure a working DNS, DHCP and LDAP server. Note the webmin options that you will need to specify or change.
Post your results to this manual website in www.colwiki.org}}

[[Image:somerights20.png]] This work is licenced under a [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons - By Attribution  Licence - Share Alike] License.
Templates used on this page:
Return to Setting up Basic Networking Services: DNS, DHCP and LDAP.
Retrieved from "http://colwiki.org/Setting_up_Basic_Networking_Services:_DNS%2C_DHCP_and_LDAP"
View source

From Colwiki.org

Views

Personal tools

Navigation

News & Events

Community

download

Search

Toolbox
