Saturday, 28 June 2014

IP Addressing Scheme



 

Introduction

The number of machines in your network and need to support, will affect several decisions you will need to make. Some organizations require only a small network of serveral dozen standalone machines located on one floor of a single building. In other organizations, you may need to set up a network with more than 1000 hosts spanning several buildings. In cases where you will need to support a large number of hosts, it may require you to further divide your network into subdivisions called subnets. The size of your prospective network will affect the:
  • Network class you apply for
  • Network number you receive
  • IP addressing scheme you use for your network

Parts of an IP Address

Any TCP/IP network will require a unique network number and every host on a TCP/IP network will require a unique IP address. Before registering your networking and obtaining a network number, it is critical that you understand how IP address are constructured.
An IP address is a 32-bit number that uniquely identifies a network interface on a machine. IP addresses are typically written in decimal digits, formatted as four 8-bit fields separated by periods. Each 8-bit field represents a byte of the IP address. This form of representing the bytes of an IP address is often referred to as the dotted-decimal format.
The bytes of an IP address can be further classified into two parts: the network part and the host part. The example below shows the components of the Class B network 192.168.1.100.
192.168.1.100
------- -----
  |       |___ (host part)
  |
  |____ (network part)

Network Part

This part specifies the unique number assigned to your particualr network. It is also the part that identifies the class of network assigned. In the above example, the network part takes up two bytes of the IP address, namely 192.168.

Host Part

This is the part of the IP address that you assign to each host, and uniquely identifies each host on your network. Note that for each host on your network, the network part of the address will be the same, but the host part must be different.

Subnet Number (optional)

Many local area networks (LANs) with a large number of hosts will be divided into subnets. If you choose to divide your network into subnets, you need to assign a subnet number for the subnet. You can maximize the efficiency of IP address space by using some of the bits from the host number part of the IP address as a network identifier. When used as a network identifier, the specified part of the address becomes the subnet number. You create a subnet number using a subnet mask, which is a bit mask that selects the network and subnet parts of an IP address.

Network Classes

The first step in planning for IP addressing on your network is to determine which network class is appropriate for your network. After you have done this, you can trake the critical second step - obtaining the network number from the interNIC addressing authority.
Currently, there are three classes of TCP/IP networks. Each class uses the 32-bit IP address space differently, providing more or fewer bits for the network part of the address. These classes are Class A, B and Class C.

Class A Network Numbers

A Class A network number uses the first 8 bits of the IP address as its "network part". The remaining 24 bits comprise the host part of the IP address. (See below)
bits  0           7-8         15-16        23-24         31
      +------------+------------+------------+------------+
      |  Network   |                Host                  |
      |   Part     |                Part                  |
      +------------+------------+------------+------------+
The values are assigned to the first byte of Class A network numbers fall within the range 0-127. Consider for example the IP address 68.8.1.100. The value 68 in the first byte indicates that the host is on a Class A network. The InterNIC assigns only the first byte of a Class A number. Use of the remaining three bytes is left to the discretion of the owner of network number. Only 127 Class A networks can exist. Each one of these numbers can accomodate up to 16,777,214 hosts.

Class B Network Numbers

A Class B network number consists of the first 16 bits for the network number and 16 bits for host numbers. The first byte of a Class B network number is in the range 128-191. Take for example the IP address 132.168.1.100, the first two bytes, 132.168, are assigned by the InterNIC, and comprise the network address. The last two bytes, 1.100, make up the host part of the address, and is assigned at the discretion of the owner of the network number. (See below)
bits  0           7-8         15-16        23-24         31
      +------------+------------+------------+------------+
      |         Network         |           Host          |
      |          Part           |           Part          |
      +------------+------------+------------+------------+
Class B is typically assigned to organizations with many hosts on their network.

Class C Network Numbers

A Class C network uses 24 bits for the network part and 8 bits for the host part. Class C network numbers are appropriate for networks with few hosts - the maximum being 254. A Class C network number occupies the first three bytes of an IP address. Only the fourth byte is assigned at the discretion of the network number owner. (See below)
bits  0           7-8         15-16        23-24         31
      +------------+------------+------------+------------+
      |                Network               |     Host   |
      |                 Part                 |     Part   |
      +------------+------------+------------+------------+
The first bytes of a class C network number covers the range 192-223. The second and third each cover the range 1-255. A typical Class C address might be 192.98.1.100. The first three bytes, 192.98.1, form the network number. The final byte in this example, 100, is the host number.

Administering Network Numbers

If you organization has been assigned more than on network number, or uses, subnets, appoint a centralized authority within your organization to assign network numbers. That authority should maintain control of a pool of assigned network numbers, assigning network, subnet, and host numbers as required. To prevent problems, make sure that duplicates or random network numbers do not exist in your organization.

Designing You IP Addressing Scheme

After receiving your network number, you can then start planning how you will assign the host parts of the IP address.
The table below (Division of IP Address Space) shows the division of the IP address space into network and host address spaces. For each Class, "range" specifies the range of decimal values for the first byte of the network number. "Network Address" indicates the number of bytes of the IP address that are dedicated to the network part of the address, with each byte represented by xxx. "Host Address" indicates the number of bytes dedicated to the host part of the address. For example, in a Class A network address, the first byte is dedicated to the network, and the last three are dedicated to the host. The opposite is true for a Class C network.
Division of IP Address Space
+--------------------------------------------------------+
| Class    Range      Network Address   Host Address     |
|--------------------------------------------------------|
|   A      0-127      xxx               xxx.xxx.xxx      |
|   B      128-191    xxx.xxx           xxx.xxx          |
|   C      192-223    xxx.xxx.xxx       xxx              |
+--------------------------------------------------------+
The numbers in the first byte of the IP address define whether the network is Class A, B, or C and are always assigned by the InterNIC. The remaining three byes have a range from 0-255. The numbers 0 and 255 are reserved; you can assign the numbers 1-254 to each byte depending on the network number assigned to you.
The following table shows which bytes of the IP address are assigned to you and the range of numbers within each byte that are available for you to assign to your hosts.
Range of Available Numbers
+-----------------------------------------------------------------------+
| Class    Byte 1 Range    Byte 2 Range    Byte 3 Range   Byte 4 Range  |
|-----------------------------------------------------------------------|
|   A      0-127           1-254           1-254          1-254         |
|                                                                       |
|   B      128-191         Pre-assigned    1-254          1-254         |
|                          by Internet                                  |
|                                                                       |
|   C      192-223         Pre-assigned    Pre-assigned   1-254         |
|                          by Internet     by Internet                  |
+-----------------------------------------------------------------------+

How IP Addresses Apply to Network Interfaces

Before connecting a host to the network, a computer must have at least one network interface. Each network interface must have its own IP address. The IP address that you give to a host is assigned to its network interface, sometimes referred to as the primary network interface. If you add a second network interface to the machine, it must have its own unique IP address. Adding a second network interface changes the function of a machine from a host to a router. If you add a second network interface to a host and disable routing, the host is then considered a multihomed host.

Wednesday, 25 June 2014

Routing Protocol Selection Guide - IGRP, EIGRP, OSPF, IS-IS, BGP





Overview
The purpose of routing protocols is to learn of available routes that exist on the enterprise network, build routing tables and make routing decisions. Some of the most common routing protocols include IGRP, EIGRP, OSPF, IS-IS and BGP. There are two primary routing protocol types although many different routing protocols defined with those two types. Link state and distance vector protocols comprise the primary types. Distance vector protocols advertise their routing table to all directly connected neighbors at regular frequent intervals using a lot of bandwidth and are slow to converge. When a route becomes unavailable, all router tables must be updated with that new information. The problem is with each router having to advertise that new information to its neighbors, it takes a long time for all routers to have a current accurate view of the network. Distance vector protocols use fixed length subnet masks which aren't scalable. Link state protocols advertise routing updates only when they occur which uses bandwidth more effectively. Routers don't advertise the routing table which makes convergence faster. The routing protocol will flood the network with link state advertisements to all neighbor routers per area in an attempt to converge the network with new route information. The incremental change is all that is advertised to all routers as a multicast LSA update. They use variable length subnet masks, which are scalable and use addressing more efficiently.

Interior Gateway Routing Protocol (IGRP)
Interior Gateway Routing Protocol is a distance vector routing protocol developed by Cisco systems for routing multiple protocols across small and medium sized Cisco networks. It is proprietary which requires that you use Cisco routers. This contrasts with IP RIP and IPX RIP, which are designed for multi-vendor networks. IGRP will route IP, IPX, Decnet and AppleTalk which makes it very versatile for clients running many different protocols. It is somewhat more scalable than RIP since it supports a hop count of 100, only advertises every 90 seconds and uses a composite of five different metrics to select a best path destination. Note that since IGRP advertises less frequently, it uses less bandwidth than RIP but converges much slower since it is 90 seconds before IGRP routers are aware of network topology changes. IGRP does recognize assignment of different autonomous systems and automatically summarizes at network class boundaries. As well there is the option to load balance traffic across equal or unequal metric cost paths.

Characteristics
  • Distance Vector
  • Routes IP, IPX, Decnet, Appletalk
  • Routing Table Advertisements Every 90 Seconds
  • Metric: Bandwidth, Delay, Reliability, Load, MTU Size
  • Hop Count: 100
  • Fixed Length Subnet Masks
  • Summarization on Network Class Address
  • Load Balancing Across 6 Equal or Unequal Cost Paths ( IOS 11.0 )
  • Update Timer: 90 seconds
  • Invalid Timer: 270 seconds
  • Holddown Timer: 280 seconds
  • Metric Calculation = destination path minimum BW * delay (usec)
  • Split Horizon

Enhanced Interior Gateway Routing Protocol (EIGRP)
Enhanced Interior Gateway Routing Protocol is a hybrid routing protocol developed by Cisco systems for routing many protocols across an enterprise Cisco network. It has characteristics of both distance vector routing protocols and link state routing protocols. It is proprietary which requires that you use Cisco routers. EIGRP will route the same protocols that IGRP routes (IP, IPX, Decnet and Appletalk) and use the same composite metrics as IGRP to select a best path destination. As well there is the option to load balance traffic across equal or unequal metric cost paths. Summarization is automatic at a network class address however it can be configured to summarize at subnet boundaries as well. Redistribution between IGRP and EIGRP is automatic as well. There is support for a hop count of 255 and variable length subnet masks.

Convergence
Convergence with EIGRP is faster since it uses an algorithm called dual update algorithm or DUAL, which is run when a router detects that a particular route is unavailable. The router queries its neighbors looking for a feasible successor. That is defined as a neighbor with a least cost route to a particular destination that doesn't cause any routing loops. EIGRP will update its routing table with the new route and the associated metric. Route changes are advertised only to affected routers when changes occur. That utilizes bandwidth more efficiently than distance vector routing protocols.

Autonomous Systems
EIGRP does recognize assignment of different autonomous systems which are processes running under the same administrative routing domain. Assigning different autonomous system numbers isn't for defining a backbone such as with OSPF. With IGRP and EIGRP it is used to change route redistribution, filtering and summarization points.

Characteristics
  • Advanced Distance Vector
  • Routes IP, IPX, Decnet, Appletalk
  • Routing Advertisements: Partial When Route Changes Occur
  • Metrics: Bandwidth, Delay, Reliability, Load, MTU Size
  • Hop Count: 255
  • Variable Length Subnet Masks
  • Summarization on Network Class Address or Subnet Boundary
  • Load Balancing Across 6 Equal or Unequal Cost Paths (IOS 11.0)
  • Hello Timer: 5 seconds on Ethernet / 60 seconds on Non-Broadcast
  • Holddown Timer: 15 seconds on Ethernet / 180 seconds on Non-Broadcast
  • Metric Calculation = destination path minimum BW * delay (msec) * 256
  • Split Horizon
  • LSA Multicast Address: 224.0.0.10
Open Shortest Path First (OSPF)
Open Shortest Path First is a true link state protocol developed as an open standard for routing IP across large multi-vendor networks. A link state protocol will send link state advertisements to all connected neighbors of the same area to communicate route information. Each OSPF enabled router, when started, will send hello packets to all directly connected OSPF routers. The hello packets contain information such as router timers, router ID and subnet mask. If the routers agree on the information they become OSPF neighbors. Once routers become neighbors they establish adjacencies by exchanging link state databases. Routers on point-to-point and point-to-multipoint links (as specified with the OSPF interface type setting) automatically establish adjacencies. Routers with OSPF interfaces configured as broadcast (Ethernet) and NBMA (Frame Relay) will use a designated router that establishes those adjacencies.

Areas
OSPF uses a hierarchy with assigned areas that connect to a core backbone of routers. Each area is defined by one or more routers that have established adjacencies. OSPF has defined backbone area 0, stub areas, not-so-stubby areas and totally stubby areas. Area 0 is built with a group of routers connected at a designated office or by WAN links across several offices. It is preferable to have all area 0 routers connected with a full mesh using an Ethernet segment at a core office. This provides for high performance and prevents partitioning of the area should a router connection fail. Area 0 is a transit area for all traffic from attached areas. Any inter-area traffic must route through area 0 first. Stub areas use a default route injected from the ABR to forward traffic destined for any external routes (LSA 5,7) to the area border router. Inter-area (LSA 3,4) and intra-area (LSA 1,2) routing is as usual. Totally Stubby areas are a Cisco specification that uses a default route injected from the ABR for all Inter-area and external routes. The Totally Stubby area doesn't advertise or receive external or Inter-area LSA's. The Not-So-Stubby area ABR is a transit area that will import external routes with type 7 LSA and flood them to other areas as type 5 LSA. External routes aren't received at that area type. Inter-area and intra-area routing is as usual. OSPF defines internal routers, backbone routers, area border routers (ABR) and autonomous system boundary routers (ASBR). Internal routers are specific to one area. Area border routers have interfaces that are assigned to more than one area such as area 0 and area 10. An autonomous system boundary router has interfaces assigned to OSPF and a different routing protocol such as EIGRP or BGP. A virtual link is utilized when an area doesn't have a direct connection to area 0. A virtual link is established between an area border router for an area that isn't connected to area 0, and an area border router for an area that is connected to area 0. Area design involves considering geographical location of offices and traffic flows across the enterprise. It is important to be able to summarize addresses for many offices per area and minimize broadcast traffic.

Convergence
Fast convergence is accomplished with the SPF (Dijkstra) algorithm which determines a shortest path from source to destination. The routing table is built from running SPF which determines all routes from neighbor routers. Since each OSPF router has a copy of the topology database and routing table for its particular area, any route changes are detected faster than with distance vector protocols and alternate routes are determined.

Designated Router
Broadcast networks such as Ethernet and Non-Broadcast Multi Access networks such as Frame Relay have a designated router (DR) and a backup designated router (BDR) that are elected. Designated routers establish adjacencies with all routers on that network segment. This is to reduce broadcasts from all routers sending regular hello packets to its neighbors. The DR sends multicast packets to all routers that it has established adjacencies with. If the DR fails, it is the BDR that sends multicasts to specific routers. Each router is assigned a router ID, which is the highest assigned IP address on a working interface. OSPF uses the router ID (RID) for all routing processes.

Characteristics
  • Link State
  • Routes IP
  • Routing Advertisements: Partial When Route Changes Occur
  • Metric: Composite Cost of each router to Destination (100,000,000/interface speed)
  • Hop Count: None (Limited by Network)
  • Variable Length Subnet Masks
  • Summarization on Network Class Address or Subnet Boundary
  • Load Balancing Across 4 Equal Cost Paths
  • Router Types: Internal, Backbone, ABR, ASBR
  • Area Types: Backbone, Stubby, Not-So-Stubby, Totally Stubby
  • LSA Types: Intra-Area (1,2) Inter-Area (3,4), External (5,7)
  • Hello Timer Interval: (10 seconds for Ethernet / 30 seconds for Non-Broadcast)
  • Dead Timer Interval: 40 seconds for Ethernet / 120 seconds for Non-Broadcast)
  • LSA Multicast Address: 224.0.0.5 and 224.0.0.6 (DR/BDR) Don't Filter!
  • Interface Types: Point to Point, Broadcast, Non-Broadcast, Point to Multipoint, Loopback
Integrated IS-IS
Integrated Intermediate System - Intermediate System routing protocol is a link state protocol similar to OSPF that is used with large enterprise and ISP customers. An intermediate system is a router and IS-IS is the routing protocol that routes packets between intermediate systems. IS-IS utilizes a link state database and runs the SPF Dijkstra algorithm to select shortest paths routes. Neighbor routers on point to point and point to multipoint links establish adjacencies by sending hello packets and exchanging link state databases. IS-IS routers on broadcast and NBMA networks select a designated router that establishes adjacencies with all neighbor routers on that network. The designated router and each neighbor router will establish an adjacency with all neighbor routers by multicasting link state advertisements to the network itself. That is different from OSPF, which establishes adjacencies between the DR and each neighbor router only. IS-IS uses a hierarchical area structure with level 1 and level 2 router types. Level 1 routers are similar to OSPF intra-area routers, which have no direct connections outside of its area. Level 2 routers comprise the backbone area which connects different areas similar to OSPF area 0. With IS-IS a router can be an L1/L2 router which is like an OSPF area border router (ABR) which has connections with its area and the backbone area. The difference with IS-IS is that the links between routers comprise the area borders and not the router. Each IS-IS router must have an assigned address that is unique for that routing domain. An address format is used which is comprised of an area ID and a system ID. The area ID is the assigned area number and the system ID is a MAC address from one of the router interfaces. There is support for variable length subnet masks, which is standard with all link state protocols. Note that IS-IS assigns the routing process to an interface instead of a network.

Characteristics
  • Link State
  • Routes IP, CLNS
  • Routing Advertisements: Partial When Routing Changes Occur
  • Metric: Variable Cost (default cost 10 assigned to each interface)
  • Hop Count: None (limited by network)
  • Variable Length Subnet Masks
  • Summarization on Network Class Address or Subnet Boundary
  • Load Balancing Across 6 Equal Cost Paths
  • Hello Timer Interval: 10 seconds
  • Dead Timer Interval: 30 seconds
  • Area Types: Hierarchical Topology similar to OSPF
  • Router Types: Level 1 and Level 2
  • LSP Types: Internal L1 and L2, External L2
  • Designated Router Election, No BDR
Border Gateway Protocol (BGP)
Border Gateway Protocol is an exterior gateway protocol, which is different from the interior gateway protocols discussed so far. The distinction is important since the term autonomous system is used somewhat differently with protocols such as EIGRP than it is with BGP. Exterior gateway protocols such as BGP route between autonomous systems, which are assigned a particular AS number. AS numbers can be assigned to an office with one or several BGP routers. The BGP routing table is comprised of destination IP addresses, an associated AS-Path to reach that destination and a next hop router address. The AS-Path is a collection of AS numbers that represent each office involved with routing packets. Contrast that with EIGRP, which uses autonomous systems as well. The difference is their autonomous systems refer to a logical grouping of routers within the same administrative system. An EIGRP network can configure many autonomous systems. They are all managed by the company for defining route summarization, redistribution and filtering. BGP is utilized a lot by Internet Service Providers (ISP) and large enterprise companies that have dual homed internet connections with single or dual routers homed to the same or different Internet Service Providers. BGP will route packets across an ISP network, which is a separate routing domain that is managed by them. The ISP has its own assigned AS number, which is assigned by InterNIC. New customers can either request an AS assignment for their office from the ISP or InterNIC. A unique AS number assignment is required for customers when they connect using BGP. There are 10 defined attributes that have a particular order or sequence, which BGP utilizes as metrics to determine the best path to a destination. Companies with only one circuit connection to an ISP will implement a default route at their router, which forwards any packets that are destined for an external network. BGP routers will redistribute routing information (peering) with all IGP routers on the network (EIGRP, RIP, OSPF etc) which involve exchange of full routing tables. Once that is finished, incremental updates are sent with topology changes. The BGP default keepalive timer is 60 seconds while the holddown timer is 180 seconds. Each BGP router can be configured to filter routing broadcasts with route maps instead of sending/receiving the entire internet routing table.

Characteristics
  • Path Vector
  • Routes IP
  • Routing Advertisements: Partial When Route Changes Occur
  • Metrics: Weight, Local Preference, Local Originated, As Path, Origin Type, MED
  • Hop Count: 255
  • Variable Length Subnet Masks
  • Summarization on Network Class Address or Subnet Boundary
  • Load Balancing Across 6 Equal Cost Paths
  • Keepalive Timer: 60 seconds
  • Holddown Timer: 180 seconds
  • Designated Router: Route Reflector
BGP Routing Table Components
  • Destination IP Address / Subnet Mask
  • AS-Path
  • Next Hop IP Address

Tuesday, 24 June 2014

LDAP SERVER Introduction & Configurations


Introduction

As times change and servers become cheap, an enterprise can easily have 500+ UNIX servers. Using LDAP to synchronize Users, Groups, Hosts, Mounts, and others across an enterprise can greatly reduce the administrative overhead.
This tutorial explains how you can set up centralised LDAP authentication for a network, covering the setting of the server. Whilst based on CentOS 6.4, it may also apply to other versions.
Lightweight Directory Access Protocol (LDAP) is a network protocol for accessing and manipulating information stored in a directory.
The protocol is well-suited to serving information that must be highly available and accessible, but does not change frequently. Common applications include:
  • Centralization of user and group information as part of Single Sign On (SSO).
  • Authenticate users in a web application.
  • Create a shared address directory for mail agents.
OpenLDAP Software is a free, open source implementation of the LDAP. Developed by the OpenLDAP Project.

Prerequisites

  • It is assumed you have already installed Linux with networking enabled and, although not mandatory but advised, configured a static IP.

Disable SElinux

Be aware that by disabling SELinux you will be removing a security mechanism on your system.
SElinux takes a long time to learn and configure, and when there is another job to do – it is simply an obstruction. Disabling remains the best option until the selinux-policy maintainers and other package maintainers can actually create a working solution between them.
I haven’t tried installing with selinux enabled so I don’t know if this is really necessary but I think phpldapadmin won’t work properly otherwise.
As we need to run lots of commands on the LDAP server, it’s easier to to this as root.
  • If you’re not yet root, become so.
[user@server ~]$ su -
  • Check the status of SELinux
[root@server ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted

  • Disable SELinux
[root@localhost ~]# vi /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – No SELinux policy is loaded.
SELINUX=disabled # change enforcing to disabled
# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# mls – Multi Level Security protection.
SELINUXTYPE=targeted

  • Restart the server
[root@localhost ~]# reboot
  • Check SELinux status again
[root@localhost ~]# sestatus
SELinux status: disabled

Configure the Firewall

  • Add the following to your iptables configuration to allow access through firewall.
[root@server ~]# vi /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

  • Restart the iptables service.
[root@server ~]# service iptables restart
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]

  • Confirm configuration
[root@server ~]# iptables -L
CHAIN INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldap
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldaps
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
...

  • If you dont need the firewall, you could just stop the service.
[root@server ~]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]

[root@server ~]# service iptables status
iptables: Firewall is not running.

  • Stop Firewall on startup
[root@server ~]# chkconfig iptables off

Installation

  • Install the required packages.
[root@server ~]# yum install openldap-servers openldap-clients pam_ldap nss-pam-ldapd autofs
openldap-servers: This package contains the slapd (LDAP server), additional backends, configuration files, schema definitions required for operation, and database maintenance tools.
openldap-clients: This package contains ldap command-line (ldapsearch, ldapadd etc)
pam_ldap: is a module for Linux-PAM that authenticates PAM-enabled services to LDAP.
nss-pam-ldapd: uses a directory server to look up name service information (users, groups, etc.) on behalf of a lightweight nsswitch module.
autofs: is a daemon which automatically mounts filesystems when you use them, and unmounts them later when you are not using them. This can include network filesystems, CD-ROMs, floppies, and so forth.

Backend configuration

  • There is an all-powerful root LDAP user which will populate our directory. Rather than publishing this password in cleartext with in the configuration file, we want to encrypt it. To do so, we run the slappasswd command, which will encrypt our password and return the value. We need to copy that into {2\}bdb.ldif file
  • Copy the output of slappasswd command into a new file called ldappassword
    [root@server ~]# slappasswd | tee ldappassword
    New password: ****
    Re-enter new password: ****
    {SSHA}2Gv8HLL8SB5pMTbMB3b5AFAE4A5sDPPE

  • Open and edit the ldappassword file
    [root@server ~]# vi ldappassword
    New password: # remove this line
    Re-enter new password: # remove this line
    olcRootPW: {SSHA}2Gv8HLL8SB5pMTbMB3b5AFAE4A5sDPPE # add olcRootPW: before the password

  • Copy the content of a ldappassword to {2}bdb.ldif
    [root@server ~]# cat ldappassword >> /etc/openldap/slapd.d/cn\=config/olcDatabase={2\}bdb.ldif
  • Open and edit the bdb file
    [root@server ~]# vi /etc/openldap/slapd.d/cn\=config/olcDatabase={2\}bdb.ldif
    ...
    olcDatabase: {2}bdb
    olcSuffix: dc=my-domain,dc=com
    olcAddContentAcl: FALSE
    olcLastMod: TRUE
    olcMaxDerefDepth: 15
    olcReadOnly: FALSE
    olcRootDN: cn=Manager,dc=my-domain,dc=com
    olcRootPW: {SSHA}2Gv8HLL8SB5pMTbMB3b5AFAE4A5sDPPE # cut this line from the end of the document
    # to below olcRootDN: (yy and p commands in vi)
    olcSyncUseSubentry: FALSE
    olcMonitoring: TRUE
    ...

  • Remove the ldappassword file
    [root@server ~]# rm ldappassword
    rm: remove regular file 'ldappassword'? y

Berkeley DataBase

Previously, OpenLDAP was previously managed via a single configuration file (/etc/openldap/slapd.conf), however these days the configuration for LDAP is stored inside the LDAP server itself! As such, the configuration is done by editing LDIF files under the /etc/openldap/slapd.d/ directory.
For the purposes of this how to, our domain is company.local and our LDAP server is server.company.local – replace this with your server details instead!
  • Configure the database
[root@server ~]# vi /etc/openldap/slapd.d/cn\=config/olcDatabase={2\}bdb.ldif
In this file substitute “dc=my-domain,dc=com” with your domain, in this example I’ll use dc=company,dc=local
olcSuffix: dc=my-domain,dc=com
Would be changed to read:
olcSuffix: dc=company,dc=local
Here’s a vi expression that substitutes them quickly (you can also change them manually):
:%s/dc=my-domain,dc=com/dc=company,dc=local/g
To allow users to modify their passwords, you will have to add the
following after the last
olcDbIndex line, again replace the
domain name with yours.


...
olcDbIndex: loginShell pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUID pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcAccess: to attrs=userPassword by self write by anonymous auth by
dn.base="cn=Manager,dc=company,dc=local" write by * none # This is all one line
olcAccess: to * by self write by dn.base="cn=Manager,dc=company,dc=local" write by * read
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
...

Monitoring privileges

  • Configure the monitoring privileges
[root@server ~]# vi /etc/openldap/slapd.d/cn\=config/olcDatabase={1\}monitor.ldif
Substitute the default domain name. This will set the root account of your LDAP Server, I use Manager for my account name.
Once again, use Vim to replace the required entry.
:%s/cn=manager,dc=my-domain,dc=com/cn=Manager,dc=company,dc=local/g
Or replace it yourself.

Basic LDAP configuration

Back at the terminal, copy a default DB_CONFIG file which sets cache and tuning options for the Berkley database backend (this also needs to be writeable by the ldap user).
  • Copy default config file to /var/lib/ldap.
[root@server ~]# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
  • Change the ownership of /var/lib/ldap to ldap.ldap
[root@server ~]# chown -R ldap:ldap /var/lib/ldap/

Logging

OpenLDAP supports very detailed and configurable logging with its loglevel directive.
  • Create a folder to store log files in
[root@server ~]# mkdir /var/log/slapd
[root@server ~]# chmod 755 /var/log/slapd/
[root@server ~]# chown ldap:ldap /var/log/slapd/

  • Redirect all log files through rsyslog
[root@server ~]# vi /etc/rsyslog.conf
...
# Save boot messages also to boot.log
local7.*                     /var/log/boot.log
local4.*                     /var/log/slapd/slapd.log
...

  • Restart the rsyslog service
[root@server ~]# service rsyslog restart
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]

Start the service

  • Start the LDAP service
[root@server ~]# service slapd start
Starting slapd: [ OK ]

  • Test the config file
[root@server ~]# slaptest -u
config file testing succeeded

  • Tell CentOS to start the LDAP server on bootup.
[root@server ~]# chkconfig slapd on

TLS encryption

By default, LDAP communications between client and server applications are not encrypted. This means that it would be possible to use a network monitoring device or software and view the communications traveling between LDAP client and server computers. This is especially problematic when an LDAP simple bind is used because credentials (username and password) is passed over the network unencrypted. This could quickly lead to the compromise of credentials.
Because we are using LDAP for authentication across a network, we want to encrypt the traffic.
  • Make a directory to hold the certificates
[root@server ~]# mkdir /etc/openldap/cacerts
  • Next, we need to tell LDAP where to find the certificate and key for encryption (which we will create in a later step).
[root@server ~]# ldapmodify -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=config
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/cacerts/server.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/cacerts/server.key
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

  • Enable LDAP Secure (LDAPS).
[root@server ~]# vi /etc/sysconfig/ldap
...
# Run slapd with -h "... ldap:/// ..."
# yes/no, default: yes
SLAPD_LDAP=yes

# Run slapd with -h "... ldapi:/// ..."
# yes/no, default: yes
SLAPD_LDAPI=yes

# Run slapd with -h "... ldaps:/// ..."
# yes/no, default: no
SLAPD_LDAPS=yes # uncomment and change from no to yes
...

Generating Certificates

  • Now that we have told LDAP to run on secure port we need to generate SSL keys and configure the LDAP service to use them!
[root@server ~]# cd /etc/pki/tls/certs
[root@server ~]# make server.key
umask 77 ; \
/usr/bin/openssl genrsa -aegs128 2048 > server.key
Generating RSA private key, 2048 bit long modulus
.................................................+++
.......................+++
e is 65537 (0x10001)
Enter pass phrase: ****
Verifying - Enter pass phrase: ****
[root@server ~]# openssl rsa -in server.key -out server.key
Enter pass phrase for server.key: ****
writing RSA key
[root@server ~]# make server.csr
umask 77 ; \
/usr/bin/openssl req -utf8 -new -key server.key -out server.csr
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.
-----
# The following is just an example. You should enter your own responses.
Country Name (2 letter code) [XX]: EE
State or Province Name (full name) []: Tartu
Locality Name (eg, city) [Default City]: Tartu
Organization Name (eg, company) [Default Company Ltd]: Company
Organizational Unit Name (eg, section) []: Section
Common Name (eg, your name or your server's hostname) []: server.company.local
Email Address []: user@company.local

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: ****
An optional company name []: company
[root@server ~]# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650
Signature ok
subject=/C=EE/ST=Tartu/L=Tartu/O=Company/OU=Section/CN=server.company.local/emailAddress=user@company.local
Getting Private key

  • Give permissions to files and move them to /etc/openldap/cacerts/
[root@server ~]# chmod 400 server.*
[root@server ~]# cp /etc/pki/tls/certs/server.* /etc/openldap/cacerts/
[root@server ~]# chown ldap. /etc/openldap/cacerts/*

  • Test LDAP by performing a search
[root@server ~]# ldapsearch -x -b "dc=company,dc=local"
# extended LDIF
#
# LDAPv3
# base dc=company,dc=local with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

Configure the overlays

Overlays are dynamically configurable modules that provide additional functionality to OpenLDAP.

Sudo

Sudo allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command and per-host basis.
  • Copy the sudo Schema into the LDAP schema repository
[root@server ~]# cp -f /usr/share/doc/sudo-1.8.6p3/schema.OpenLDAP /etc/openldap/schema/sudo.schema
  • Restore file default SELinux security contexts.
[root@server ~]# restorecon /etc/openldap/schema/sudo.schema
  • Create a conversion folder and file for sudo schema
[root@server ~]# mkdir /etc/sudoWork
[root@server ~]# echo "include /etc/openldap/schema/sudo.schema" > /etc/sudoWork/sudoSchema.conf

  • Convert the Schema to LDIF file
[root@server ~]# slapcat -f /etc/sudoWork/sudoSchema.conf -F /tmp/ -n0 -s "cn={0}sudo,cn=schema,cn=config" > /etc/sudoWork/sudo.ldif
  • Remove invalid data.
[root@server ~]# sed -i "s/{0}sudo/sudo/g" /etc/sudoWork/sudo.ldif
  • Remove last 8 (invalid) lines.
[root@server ~]# head -n-8 /etc/sudoWork/sudo.ldif > /etc/sudoWork/sudo2.ldif
  • Load the schema ldif into the LDAP server
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/sudoWork/sudo2.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
Adding new entry "cn=sudo,cn=schema,cn=config"

  • Add index to sudoers db
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: olcDatabase={2}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: sudoUser eq
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={2}bdb,cn=config"

AutoFS

Autofs is used for automatically mounting directories on an as-needed basis. Auto-mounts are mounted only as they are accessed, and are unmounted after a period of inactivity. Because of this, automounting NFS/Samba shares conserves bandwidth and offers better overall performance compared to static mounts via fstab. Read more about mounting directories here.
  • Copy the autofs Schema into the LDAP schema repository
[root@server ~]# cp -f /usr/share/doc/autofs-5.0.5/autofs.schema /etc/openldap/schema/autofs.schema
  • Restore file default SELinux security contexts.
[root@server ~]# restorecon /etc/openldap/schema/autofs.schema
  • Create a conversion folder and file for autofs schema
[root@server ~]# mkdir /etc/sudoWork2/
[root@server ~]# echo "include /etc/openldap/schema/core.schema" > /etc/sudoWork2/autofsSchema.conf
[root@server ~]# rpm -ql autofs | grep -i schema | sed 's/^/include /g' >> /etc/sudoWork2/autofsSchema.conf

  • Convert the Schema to LDIF file
[root@server ~]# slapcat -f /etc/sudoWork2/autofsSchema.conf -F /tmp/ -n0 -s "cn={1}autofs,cn=schema,cn=config" > /etc/sudoWork2/autofs.ldif
  • Remove invalid data.
[root@server ~]# sed -i "s/{1}autofs/autofs/g" /etc/sudoWork2/autofs.ldif
  • Remove last 8 (invalid) lines.
[root@server ~]# head -n-8 /etc/sudoWork2/autofs.ldif > /etc/sudoWork2/autofs2.ldif
  • Load the schema ldif into the LDAP server
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/sudoWork2/autofs2.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=autofs,cn=schema,cn=config"

Modules area

[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap/ # /usr/lib/openldap/ if 32 bit OS
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module{0},cn=config"

Auditlog overlay

The Audit Logging overlay can be used to record all changes on a given backend database to a specified log file. Changes are logged as standard LDIF, with an additional comment header giving the timestamp of the change and the identity of the user making the change.
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=module{0},cn=config
changetype:modify
add: olcModuleLoad
olcModuleLoad: auditlog.la

dn: olcOverlay=auditlog,olcDatabase={2}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/log/slapd/auditlog.log
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"
adding new entry "olcOverlay=auditlog,olcDatabase={2}bdb,cn=config"

Password Policy overlay

The key abilities of the password policy overlay are as follows:
  • Enforce a minimum length for new passwords.
  • Make sure passwords are not changed too frequently.
  • Cause passwords to expire, provide warnings before they need to be changed, and allow a fixed number of 'grace' logins to allow them to be changed after they have expired.
  • Maintain a history of passwords to prevent password re-use.
  • Prevent password guessing by locking a password for a specified period of time after repeated authentication failures.
  • Force a password to be changed at the next authentication.
  • Set an administrative lock on an account.
  • Support multiple password policies on a default or a per-object basis.
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=module{0},cn=config
changetype:modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

dn: olcOverlay=ppolicy,olcDatabase={2}bdb,cn=config
olcOverlay: ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE
olcPPolicyDefault: cn=ppolicy,ou=ldapconf,dc=company,dc=local
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"
adding new entry "olcOverlay=ppolicy,olcDatabase={2}bdb,cn=config"

Dynamic group overlay

Groups are a quick way of giving users common access to certain features or functionality within an LDAP directory. Groups can be configured statically (each member has to be invidually defined and subsequently maintained if their status or group membership changes) or dynamically whereby groups can be created using an LDAP search. This can be very efficient where memership of groups is extremely large or constantly changing.
[root@server ~]# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=module{0},cn=config
changetype:modify
add: olcModuleLoad
olcModuleLoad: dynlist.la

dn: olcOverlay=dynlist,olcDatabase={2}bdb,cn=config
olcOverlay: dynlist
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcDlAttrSet: groupOfURLs memberURL
EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"

adding new entry "olcOverlay=dynlist,olcDatabase={2}bdb,cn=config"

Populating LDAP with sample users and groups

We should now have a basic LDAP server running, configured for our domain. However we do not have any users or groups configured yet. Now we need to set up our base, authentication and group files.
Data is entered into the LDAP server via plain text LDIF (LDAP Data Interchange Format) files.

Basic directory tree

We need to create a template which creates the base structure of our directory (company.local), which we will import into LDAP database first.
The following section outlines a basic directory tree that is intended to be very compatible with POSIX accounts (for use on *nix systems), address books, and classic accounts (for web applications). This configuration is a starting point; the applications of LDAP are virtually limitless.
The LDAP directory manipulation tools support a standard file format know as LDAP Directory Interchange Format (LDIF). We will use this format to create the initial directory structure.
Start by creating a file base.ldif:
[root@server ~]# vi /etc/openldap/schema/base.ldif
dn: dc=company,dc=local
objectClass: top
objectClass: organization
objectClass: dcObject
o: Mikamis Ldapserver
dc: company

# Create the ou=ldapconf container.
# This container will later be used for autofs, sudo and password policy to name a few.
dn: ou=ldapconf,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: LDAPconf

Now that we have the base for our LDAP structure, we can import that information into our LDAP database (use the password you created above):
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/base.ldif
Enter LDAP Password: ******
adding new entry "dc=company,dc=local"

adding new entry "ou=ldapconf,dc=company,dc=local"

If you saw the above, then it worked! If you get an error about authentication issues stop the service and start it again.

Password Policy

Create a LDIF file with following content:
[root@server ~]# vi /etc/openldap/schema/passwordpolicy.ldif
dn: cn=ppolicy,ou=ldapconf,dc=company,dc=local
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: ppolicy
pwdAttribute: 2.5.4.35
# AllowUserChange controls whether users are allowed to change their own passwords.
pwdAllowUserChange: TRUE
# If the value of CheckQuality is 1 and the supplied password is in cleartext
# then a user supplied function if defined - will be called to check the password quality.
pwdCheckQuality: 1
# MaxAge defines the maximum time - in seconds - a password is valid
pwdMaxAge: 7776002
# ExpireWarning controls whether and when a warning message of password expiration will be returned
# on a bind attempt - in seconds
pwdExpireWarning: 1209600
# FailureCountInterval controls when the count of consecutive password failures is reset.
pwdFailureCountInterval: 30
# GraceAuthNLimit defines the number of times a user is allowed to log in using an expired password.
pwdGraceAuthNLimit: 5
# InHistory controls the number of passwords that are stored in a list of previously used passwords.
# New password is checked against the history list and rejected if present.
pwdInHistory: 4
# Lockout controls the action taken when an account has had more consecutive failed bind attempts
# with invalid passwords than is defined by pwdMaxFailure
pwdLockout: TRUE
# LockoutDuration controls how long an account remains locked.
pwdLockoutDuration: 900
# MaxFailure controls how many consecutive password failures are allowed
# before the action defined by pwdLockout is taken.
pwdMaxFailure: 5
# MinLength controls the minimum length of the password supplied. Shorter passwords will be rejected.
pwdMinLength: 6
# If MustChange the attribute value is TRUE
# then the user MUST change their password when the account is unlocked.
pwdMustChange: FALSE
# If SafeModify value is TRUE the user will be asked for a password when modifying the password value.
pwdSafeModify: FALSE

To import the policy run the following command:
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/passwordpolicy.ldif
Enter LDAP Password: ****
Adding new entry "cn=ppolicy,ou=ldapconf,dc=company,dc=local"

Sudoers configuration

Create a LDIF file with following content:
[root@server ~]# vi /etc/openldap/schema/sudoers.ldif
# Create the sudoers ou to hold our sudoers configuration.
dn: ou=sudoers,ou=ldapconf,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: sudoers

dn: cn=defaults,ou=sudoers,ou=ldapconf,dc=company,dc=local
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOptions
# sudo will run the command in a minimal environment containing the basic variables.
sudoOption: env_reset
# sudo will ignore "." or "" (both denoting current directory) in the PATH environment variable.
sudoOption: ignore_dot
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.
sudoOption: !mail_no_user
# syslog is being used for logging and defaults to auth.
sudoOption: syslog=auth
# Number of minutes that can elapse before sudo will ask for a passwd again.
sudoOption: timestamp_timeout=10
# root is allowed to run sudo too. Disabling this prevents users from “chaining” sudo commands
sudoOption: !root_sudo

dn: cn=sysadmin,ou=sudoers,ou=ldapconf,dc=company,dc=local
objectClass: top
objectClass: sudoRole
cn: sysadmin
sudoCommand: ALL
sudoHost: ALL
# users must authenticate themselves before they may run commands.
sudoOption: !authenticate
sudoRunAs: root
sudoUser: %sysadmin

syslog is being used for logging and defaults to auth.
Now we can add it to our LDAP server.
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/sudoers.ldif
Enter LDAP Password: ****
Adding new entry "ou=sudoers,ou=ldapconf,dc=company,dc=local"

Adding new entry "cn=defaults,ou=sudoers,ou=ldapconf,dc=company,dc=local"

Adding new entry "cn=sysadmin,ou=sudoers,ou=ldapconf,dc=company,dc=local"

AutoFS configuration

Create a LDIF file with following content:
[root@server ~]# vi /etc/openldap/schema/autofs.ldif
# Create the container for autofs configs.
dn: ou=autofs,ou=ldapconf,dc=company,dc=local
ou: AutoFS
objectClass: top
objectClass: organizationalUnit
description: Automount maps

# Create the auto.master map container.
dn: ou=auto.master,ou=autofs,ou=ldapconf,dc=company,dc=local
ou: auto.master
objectClass: top
objectClass: automountMap

# Create the /home mountpoint.
dn: cn=/home,ou=auto.master,ou=autofs,ou=ldapconf,dc=company,dc=local
cn: /home
objectClass: top
objectClass: automount
automountInformation: ldap:ou=auto.home,ou=autofs,ou=ldapconf,dc=company,dc=local rsize=8192,wsize=8192

# Create the auto.home map container.
dn: ou=auto.home,ou=autofs,ou=ldapconf,dc=company,dc=local
ou: auto.home
objectClass: top
objectClass: automountMap

# Create the value for the auto.home map.
dn: cn=/,ou=auto.home,ou=autofs,ou=ldapconf,dc=company,dc=local
objectClass: automount
objectClass: top
cn: /
automountInformation: nfs.company.local:/home/

To import the configuration run the following command:
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/autofs.ldif
Enter LDAP Password:
Adding new entry "ou=autofs,ou=ldapconf,dc=company,dc=local"

Adding new entry "ou=auto.master,ou=autofs,ou=ldapconf,dc=company,dc=local

Adding new entry "cn=/home,ou=auto.master,ou=autofs,ou=ldapconf,dc=company,dc=local"

Adding new entry "ou=auto.home,ou=autofs,ou=ldapconf,dc=company,dc=local"

Adding new entry "cn=/,ou=auto.home,ou=autofs,ou=ldapconf,dc=comapny,dc=local"

Adding new groups

Let's now add a few groups. We will create the following groups :
  • ldapuser: static group to group all users together.
  • all: dynamic group to group all users together.
  • sysadmin: dynamic group to group all system administrators togehter.
Of course, I encourage you to change this group list to fit your organization's needs. Create another LDIF file with the following data.
If a UID is defined in the LDAP directory and also on the local system, unexpected behaviors can result. To avoid collisions between local UIDs and the UIDs of users defined in the LDAP directory, it is generally advisable to assign UIDs to LDAP users in a non-standard range such as 5000-10000 (local UIDs start at 1000 by default).
[root@server ~]# vi /etc/openldap/schema/groups.ldif
# This container will be used to store all groups in.
dn: ou=groups,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: groups

# Container for static groups
dn: ou=posixgroups,ou=groups,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: posixGroups

# Central group for static UNIX users
dn: cn=ldapuser,ou=posixgroups,ou=groups,dc=company,dc=local
objectClass: top
objectClass: posixGroup
cn: ldapuser
gidNumber: 10000

# Container for dynamic groups
dn: ou=accessgroups,ou=groups,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: accessgroups

# Central group for dynamic UNIX users
dn: cn=all,ou=accessgroups,ou=groups,dc=company,dc=local
objectClass: groupOfURLs
cn: all
memberURL: ldap:///ou=people,dc=company,dc=local??one?(gidNumber=10000)

# Dynamic group for sysadmin users
dn: cn=sysadmin,ou=accessgroups,ou=groups,dc=company,dc=local
objectClass: groupOfURLs
cn: sysadmin
memberURL: ldap:///ou=people,dc=company,dc=local??one?(description=sysadmin)

  • Import the Groups to the LDAP server
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/groups.ldif
Enter LDAP Password: ****
Adding new entry "ou=groups,dc=company,dc=local"

Adding new entry "ou=posixgroups,ou=groups,dc=company,dc=local"

Adding new entry "cn=ldapuser,ou=posixgroups,ou=groups,dc=company,dc=local"

Adding new entry "ou=accessgroups,ou=groups,dc=company,dc=local"

Adding new entry "cn=all,ou=accessgroups,ou=groups,dc=company,dc=local"

Adding new entry "cn=sysadmin,ou=accessgroups,ou=groups,dc=company,dc=local"

Adding a new user

To add a user, simply create an ldif file with contents like so:
[root@server ~]# vi /etc/openldap/schema/people.ldif
dn: ou=people,dc=company,dc=local
objectClass: top
objectClass: organizationalUnit
ou: people

dn: uid=mihkel,ou=people,dc=company,dc=local
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
cn: Mihkel M
gidNumber: 10000
homeDirectory: /home/mihkel
sn: mihkel
uid: mihkel
uidNumber: 5000
userPassword: password
description: sysadmin
gecos: Mihkel M
loginShell: /bin/bash
shadowLastChange: 15861
shadowMax: 90
shadowWarning: 14

  • Import the user(s) to the LDAP server.
[root@server ~]# ldapadd -x -W -D "cn=Manager,dc=company,dc=local" -f /etc/openldap/schema/people.ldif
Enter LDAP Password:
adding new entry "ou=people,dc=company,dc=local"

adding new entry "uid=mihkel,ou=people,dc=company,dc=local"

LDAP server replication

LDAP services can quickly become a critical dependency of core services such as authentication, authorization, and mail. High availability is important in such scenarios. The availability of LDAP services can be greatly improved with redundant LDAP servers.
Redundancy in OpenLDAP is effected with a master-slave replication scheme. The master is the authoritative source of information about the LDAP directory. Each slave replicates the information in the master and serves it to clients on request.
(tutorial not yet ready)

OpenLDAP autoinstall script

(tutorial not yet ready)

phpLDAPadmin

phpLDAPadmin is a web-based LDAP client. It provides easy, multi-language administration for your LDAP server. Its hierarchical tree-viewer and advanced search functionality make it intuitive to browse and administer your LDAP directory. Since it is a web application, this LDAP browser works on many platforms, making your LDAP server easily manageable from any location.
  • Install wget
[root@server ~]# yum install wget
  • Add EPEL repository from Fedora project.
[root@server ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

[root@server ~]# rpm -Uvh epel-release-6-8.noarch.rpm

  • Install phpldapadmin
[root@server ~]# yum install phpldapadmin
  • Disable automatic login mechanism
[root@server ~]# vi +398 /etc/phpldapadmin/config.php
# Uncomment the following (line 397)
$servers->setValue('login','attr','dn');
# Comment out the following (line 398)
//$servers->setValue('login','attr','uid');

  • Setup HTTPD service
[root@server ~]# chkconfig httpd on
[root@server ~]# service httpd restart

  • Log in to phpLDAPadmin
http://localhost/ldapadmin
un: cn=Manager,dc=company,dc=local
pw: (Password you entered in slappasswd earlier)