ISCDHCP

From HerzbubeWiki
Jump to: navigation, search

Debian packages

The following Debian packages need to be installed

isc-dhcp-server


References

The following man pages are sufficient to configure DHCP

dhcpd.conf
dhcp-options


Configuration

The interfaces to listen on are configured in

/etc/defaults/isc-dhcp-server

The configuration is stored in

/etc/dhcp/dhcpd.conf

Global options look like this:

# Whether DNS is updated dynamically, and if so, what method/style should be used
ddns-update-style none;
# List an external time server if you don't have your own server
#option time-servers time.euro.apple.com;
# 1 day (24 * 3600 seconds)
default-lease-time 86400;
# 7 days
max-lease-time 604800;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

What remains is the part where we actually give out IP addresses:

# Share options in the 192.168.1.0 subnet
group {
  option domain-name "lan.herzbube.ch";
  option domain-name-servers 192.168.1.11 212.101.0.10, 212.101.4.253;
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
  option routers 192.168.1.11;
  option smtp-server 192.168.1.11;
  option time-servers 192.168.1.11;

  # Provide 48 dynamic addresses between 64 and 111
  subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.64 192.168.1.111;
    authoritative; # the server is authoritative
  }

#  # aka hyperion
#  host technocore {
#    fixed-address 192.168.1.1;
#    hardware ethernet :::::;
#  }

#  host mirkwood {
#    fixed-address 192.168.1.2;
#    # Busmaster ethernet card 10/100 MBit/s
#    hardware ethernet 00:C0:26:60:01:A1;
#  }

  host isengard {
    fixed-address 192.168.1.3;
    hardware ethernet 00:05:02:71:EC:AB;
  }

  host moria {
    fixed-address 192.168.1.4;
    hardware ethernet 00:30:65:ef:74:8e;
  }

#  host imladris {
#    fixed-address 192.168.1.5;
#    hardware ethernet :::::;
#  }

#  host osgiliath {
#    # Override the router setting. If we don't do this, and ifup on
#    # osgiliath acquires a DHCP lease, ifup will add a default route
#    # to 192.168.1.6 because it thinks this is the default gateway.
#    # Because osgiliath ***IS*** 192.168.1.6, and the default route
#    # therefore points back to itself, normal routing to the outside
#    # world via ADSL no longer works. Effectively, the default route
#    # to 192.168.1.6 conflicts with the other (correct) default route
#    # to 192.168.0.1.
#    option routers 192.168.0.1;

#    fixed-address 192.168.1.6;
#    # Integrated ethernet controller 3Com
#    hardware ethernet 00:26:54:0C:52:06

#    fixed-address 172.16.13.57;
#    # National Semiconductor ethernet card
#    hardware ethernet 00:40:F4:38:E6:FA

#    fixed-address 192.168.2.1;
#    # Integrated ethernet controller nVidia
#    hardware ethernet 00:0C:6E:32:65:91;

#    fixed-address 192.168.3.1;
#    # Busmaster DEC ethernet card 10/100 MBit/s
#    hardware ethernet 00:C0:26:60:01:A1;
#  }

  host fornost {
    hardware ethernet 00:00:e8:88:ab:80;
    fixed-address 192.168.1.7;
  }

  host tharbad {
    hardware ethernet 00:0d:93:b1:eb:c2;
    fixed-address 192.168.1.8;
  }

  host nargothrond {
    hardware ethernet 00:17:f2:cd:5d:09;
    fixed-address 192.168.1.9;
  }

  host nindalf {
    hardware ethernet 10:9a:dd:5d:bb:eb;
    fixed-address 192.168.1.10;
  }

#  host pelargir {
#    # Override the router setting. For details see the comments above
#    # in the entry for osgiliath.
#    option routers 192.168.0.1;

#    fixed-address 192.168.1.11;
#    # Integrated gigabit ethernet controller (Intranet wired connections)
#    hardware ethernet 34:15:9e:2e:ca:38

#    fixed-address 192.168.0.2;
#    # Fast ethernet-over-USB controller (Internet uplink)
#    hardware ethernet 00:24:32:01:a7:83
#  }

  host laserjet1300n {
    hardware ethernet 00:30:6e:d0:e4:20;
    fixed-address 192.168.1.126;
  }
}  # end group

# Share options in the 192.168.2.0 subnet
group {
  option domain-name "wifi.herzbube.ch";
  option domain-name-servers 192.168.2.6 212.101.0.10, 212.101.4.253;
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.2.255;
  option routers 192.168.2.6;
  option smtp-server 192.168.2.6;
  option time-servers 192.168.2.6;

  # Provide 48 dynamic addresses between 64 and 111
  subnet 192.168.2.0 netmask 255.255.255.0 {
    range 192.168.2.64 192.168.2.111;
    authoritative; # the server is authoritative
  }

#  host osgiliath {
#    fixed-address 192.168.2.1;
#    # Integrated ethernet controller nVidia
#    hardware ethernet 00:0C:6E:32:65:91;
#  }

  host landroval {
    fixed-address 192.168.2.2;
    hardware ethernet 00:25:00:fe:f4:e3;
  }

  host nargothrond {
    fixed-address 192.168.2.3;
    hardware ethernet 00:19:e3:08:00:a5;
  }

  host buschtrommel {
    fixed-address 192.168.2.4;
    hardware ethernet 00:26:4a:f3:8d:2f;
  }

  host nindalf {
    fixed-address 192.168.2.5;
    hardware ethernet c8:bc:c8:f1:77:61;
  }

#  host pelargir {
#    fixed-address 192.168.2.6;
#    # Gigabit ethernet-over-USB controller (Intranet wireless connections)
#    hardware ethernet 00:12:17:f2:34:05
#  }
}


Dynamic DNS updates

Overview

When the DHCP server assigns a new address to a client, it can send this information to a cooperating DNS server which will then update its DNS records accordingly.

This does not work for fixed IP addresses! Clients whose IP addresses should be managed like this must not contain the fixed-address option. I have tried adding ddns-updates on for such hosts, but it didn't work.


References

The information in this chapter primarily comes from the dhcpd.conf man page, section "DYNAMIC DNS UPDATES". The following article has also been valuable as a starter: http://www.debian-administration.org/article/Configuring_Dynamic_DNS__DHCP_on_Debian_Stable.


Enable dynamic DNS updates

The main configuration option that needs to be set to make the DHCP daemon perform dynamic DNS updates is this:

ddns-update-style interim;


Defining who is responsible for updating the DNS server

When the DHCP daemon hands out an IP address, DNS needs to be updated in two ways:

  • Forward resolution, or the "A" record needs to be updated
  • Reverse resolution, or the "PTR" record needs to be updated


It is possible to configure the DHCP daemon so that it allows the client to update its own "A" record. This feature is actually turned on by default, but in my network I don't want this and therefore set the following configuration option:

deny client-updates;   # tell the client it is not allowed to do updates


Client FQDN used for talking to the DNS server

The DHCP daemon will form the FQDN of a client by concatenating the client's hostname and domain name:

  • The client's hostname is determined by one of the following options. Options further up in the list have precedence.
    • ddns-hostname inside a host declaration
    • host-name inside a host declaration
    • The name used for the host declaration (this is the declaration that starts with the keyword host)
  • The domain name is determined by one of the following options. Options further up in the list have precedence.
    • ddns-domainname
    • Probably domain-name. I say "probably" because this has not been thoroughly researched. The only statement I can make is this: Even though ddns-domainname is not specified, everything seems to work. The only other source for the domain name that I can see is domain-name.


Communication with the DNS server

The DHCP daemon needs to know where the DNS server to update lives. This is achieved by a configuration file snippet like this:

# This file defines a secret that is used by DHCP to authenticate itself to the
# DNS server. It is also included by the DNS server configuration. There is no
# need for two files with different formats because both DHCP and BIND servers
# are implemented by ISC.
include "/etc/bind/dhcp-updater.key";

# The forward zone (note the trailing ".")
zone lan.herzbube.ch. {
  # Where does the primary DNS server live?
  primary 127.0.0.1;
  # Reference to the key defined in the file included further up
  key dhcp-updater;
}

# The reverse zone
zone 1.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key dhcp-updater;
}

# The forward zone (note the trailing ".")
zone wifi.herzbube.ch. {
  # Where does the primary DNS server live?
  primary 127.0.0.1;
  # Reference to the key defined in the file included further up
  key dhcp-updater;
}

# The reverse zone
zone 2.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key dhcp-updater;
}


For a detailed discussion about the authentication secret file, see the BIND page.


Noteworthy options that remain unused

The following options are noteworthy, but remain unused since the defaults are acceptable:

  • ddns-rev-domainname: Can be used to specify the domain name for the reverse zone. This is appended to the reversed IP address of the client. The default is "in-addr.arpa."
  • ddns-updates: Can be used to turn dynamic DNS updates on or off within the scope where this option appears. The default is "on".


Configuration with LDAP

Reference

The reference for the following configuration steps is

/usr/share/doc/isc-dhcp-server-ldap

This document can also be found online.


Task overview

To integrate the ISC DHCP server with LDAP, the following tasks need to be done in the listed order. Most of them are explained in more detail in one of the following chapters.

  • Install Debian package
  • Configure the LDAP server
    • Use the schema provided by the DHCP package
    • Use additional indices
    • Add new ACLs for the DHCP DN (the DN that DHCP is going to use for directory access)
  • Modify the LDAP directory
    • Add entries to the directory that represent the DHCP configuration formerly located in /etc/dhcp/dhcpd.conf
    • Add an entry to the directory that is used by the DHCP server for authentication
  • Configure DHCP to use LDAP


Install Debian package

The following Debian package needs to be installed:

isc-dhcp-server-ldap

This package seamlessly replaces the original DHCP server by installing a new version of the DHCP server binary. The original binary is preserved under a new name.

osgiliath:~# ls -l /usr/sbin/dhcpd*
-rwxr-xr-x 1 root root 755332 May 19 08:13 /usr/sbin/dhcpd
-rwxr-xr-x 1 root root 730408 May 19 08:13 /usr/sbin/dhcpd-noldap

The package also provides important files in /usr/share/doc/isc-dhcp-server-ldap which we are going to use in the next steps:

  • The LDAP schema for DHCP
  • A utility perl script that converts the regular DHCP configuration file /etc/dhcp/dhcpd.conf into an LDIF data file that can then be used to populate the LDAP directory


Configure the LDAP server

Schema

Manually copy dhcp.schema into the LDAP schema directory:

cd /etc/ldap/schema
cp /usr/share/doc/isc-dhcp-server-ldap/dhcp.schema.gz .
gunzip dhcp.schema.gz

Configure slapd to load the schema by adding the following line to /etc/ldap/slapd.conf:

include /etc/ldap/schema/dhcp.schema


Indices

Configure additional indices by adding the following lines to /etc/ldap/slapd.conf:

# Indices for DHCP (taken from /usr/share/doc/isc-dhcp-server-ldap/README.ldap.gz)
index dhcpHWAddress eq
index dhcpClassData eq  

After modifying the file, perform reindexing:

/etc/init.d/slapd stop
slapindex -n 1
/etc/init.d/slapd start
chown openldap:openldap /var/lib/ldap/herzbube.ch/*

Note: I am not sure if any of these indices are required for DHCP/LDAP integration to work. I was too lazy to test this out, I simply assume that the guy who wrote the README file knew what he was writing about.


ACLs

Note: The actual ACLs developed in theory in this chapter can be found over on the OpenLDAP page.

The DHCP server will be accessing the LDAP directory using the DN

cn=dhcp-service,ou=users,dc=herzbube,dc=ch

Our new ACLs do not have to work on the attribute level (e.g. there is no password attribute to protect), instead they simply need to give read-only access to the DHCP server to the following entries:

  • All entries under the tree ou=dhcp,dc=herzbube,dc=ch
  • All entries directly under the base DN with objectClass=dhcpServer. Note: Every such entry refers to one DHCP server; since we only have one server, there will be only one LDAP entry, but we still use a general-purpose ACL that could be used in a setup with 2 or more DHCP servers.


See the OpenLDAP page for the actual ACLs.


Modify the LDAP directory

Overview

The following entries need to be modified in the LDAP directory:

  • The DHCP server itself needs to be defined with a top-level entry directly below the base DN.
  • A subtree cn=dhcp,dc=herzbube,dc=ch must be created with corresponding entries that form the DHCP setup.
  • Host entries need to be created for machines with known MAC addresses which will get a fixed IP address
  • Last but not least, the DN cn=dhcp-service,ou=users,dc=herzbube,dc=ch used for authentication by the DHCP server must be created. ACLs developed further up will refer to this DN, and the DHCP server will be configured later on to use this DN.


Converting dhcpd.conf to LDIF

The task of creating the necessary LDAP directory entries can be vastly simplified by using a utility perl script that converts an existing DHCP configuration file into an LDIF data file. After a review and a couple of minor modifications, the LDIF file can then be simply imported into the LDAP directory.

The script in question is

/usr/share/doc/isc-dhcp-server-ldap/dhcpd-conf-to-ldap.pl.gz

After copying and gunzip'ping the script in /tmp, I used the following command line to generate my LDIF file:

/tmp/dhcpd-conf-to-ldap.pl --dhcpdn "cn=dhcp,dc=herzbube,dc=ch" --conf /etc/dhcp/dhcpd.conf --ldif /tmp/dhcpd.ldif


Add entry that represents the DHCP server

Add the following entry to the LDAP directory:

# You must specify the server's host name in LDAP that you are going to run
# DHCP on and point it to which config tree you want to use. Whenever DHCP 
# first starts up, it will do a search for this entry to find out which 
# config to use.
#
# Note: We really want the hostname only, not the FQDN.
dn: cn=pelargir,dc=herzbube,dc=ch
cn: pelargir
objectClass: top
objectClass: dhcpServer
dhcpServiceDN: cn=dhcp,dc=herzbube,dc=ch


The cn=dhcp,dc=herzbube,dc=ch subtree

Create the entry with DN cn=dhcp,dc=herzbube,dc=ch. This entry forms the root of a subtree into which we will now place further entries that form the entire DHCP configuration.

# Here is the entry that starts the DHCP config subtree
# that cn=osgiliath,dc=herzbube,dc=ch points to.
dn: cn=dhcp,dc=nherzbube,dc=ch
cn: dhcp
objectClass: top
objectClass: dhcpService
objectClass: dhcpOptions
dhcpPrimaryDN: cn=pelargir,dc=herzbube,dc=ch
dhcpStatements: ddns-update-style interim
dhcpStatements: default-lease-time 86400
dhcpStatements: max-lease-time 604800
dhcpStatements: log-facility local7
dhcpStatements: deny client-updates
dhcpStatements: include "/etc/bind/dhcp-updater.key"
#dhcpOption: time-servers time.euro.apple.com

# Define a group for hosts in the 192.168.1.0 network. This includes
# all of our known MAC addresses, and a range of 48 dynamically
# allocated addresses. The group entry also contains common options for
# all hosts in this group.
dn: cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: group-192.168.1.0
objectClass: top
objectClass: dhcpGroup
objectClass: dhcpOptions
dhcpStatements: zone lan.herzbube.ch. { primary 127.0.0.1; key dhcp-updater; }
dhcpStatements: zone 1.168.192.in-addr.arpa. { primary 127.0.0.1; key dhcp-updater; }
dhcpOption: domain-name "lan.herzbube.ch"
dhcpOption: domain-name-servers 192.168.1.11, 212.101.0.10, 212.101.4.253
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: broadcast-address 192.168.1.255
dhcpOption: routers 192.168.1.11
dhcpOption: smtp-server 192.168.1.11
dhcpOption: time-servers 192.168.1.11

# The 192.168.1.0 subnet definition is a child of the group entry.
# The subnet definition specifies that only 48 addresses may be
# dynamically allocated.
dn: cn=192.168.1.0,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: 192.168.1.0
objectClass: top
objectClass: dhcpSubnet
dhcpNetMask: 24
dhcpRange: 192.168.1.64 192.168.1.111
dhcpStatements: authoritative

# Define a group for hosts in the 192.168.2.0 network. This includes
# all of our known MAC addresses, and a range of 48 dynamically
# allocated addresses. The group entry also contains common options for
# all hosts in this group.
dn: cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: group-192.168.2.0
objectClass: top
objectClass: dhcpGroup
objectClass: dhcpOptions
dhcpStatements: zone wifi.herzbube.ch. { primary 127.0.0.1; key dhcp-updater; }
dhcpStatements: zone 2.168.192.in-addr.arpa. { primary 127.0.0.1; key dhcp-updater; }
dhcpOption: domain-name "wifi.herzbube.ch"
dhcpOption: domain-name-servers 192.168.2.6, 212.101.0.10, 212.101.4.253
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: broadcast-address 192.168.2.255
dhcpOption: routers 192.168.2.6
dhcpOption: smtp-server 192.168.2.6
dhcpOption: time-servers 192.168.2.6

# The 192.168.2.0 subnet definition is a child of the group entry.
# The subnet definition specifies that only 48 addresses may be
# dynamically allocated.
dn: cn=192.168.2.0,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: 192.168.2.0
objectClass: top
objectClass: dhcpSubnet
dhcpNetMask: 24
dhcpRange: 192.168.2.64 192.168.2.111
dhcpStatements: authoritative


Host definitions

The idea would have been to use the dhcpHostDN attribute, which is possible inside the dhcpGroup object class, to refer to host entries in the ou=hosts,dc=herzbube,dc=ch, and to augment those entries with the object class dhcpHost.

Unfortunately there is a problem with the current DHCP LDAP schema definition: The object class dhcpHost is not auxiliary! This means that other existing objects in the LDAP directory which represent a host, such as the ipHost entries below the subtree ou=hosts,dc=herzbube,dc=ch, cannot be augmented with the dhcpHost object class. So in the end, the whole idea of referring to entries in the ou=hosts subtree falls flat on its face. For the moment I ignore the possibility that the scheme would not have worked anyway because I don't know the exact semantics of dhcpHostDN, and whether the patched DHCP server would follow a reference to another subtree in the first place.

Although the DHCP LDAP schema is only a draft and not a formal standard (see this document), I am currently reluctant to modify the schema to make it fit my purposes, because I don't know what trouble I would be inviting and at the moment just want the damn thing to work. After a bit of googling, I found that somebody else would also have preferred dhcpHost to be an auxiliary object class, but one of the co-authors of the draft responds that it would be better to create a new object class dhcpHostAux which essentially duplicates the original object class but has the AUXILIARY flag turned on. I don't see the reason for this, and unfortunately the draft co-author doesn't give a reason, either.


So after all this thinking, the final defeat: Here are the host definitions that have to be placed below the cn=dhcp,dc=herzbube,dc=ch subtree:

dn: cn=technocore,cn=group-192.168.1.1,cn=dhcp,dc=herzbube,dc=ch
cn: technocore
objectClass: top
objectClass: dhcpHost
#dhcpHWAddress: ethernet ??:??:??:??:??:??
dhcpStatements: fixed-address 192.168.1.1

dn: cn=mirkwood,cn=group-192.168.1.1,cn=dhcp,dc=herzbube,dc=ch
cn: mirkwood
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:c0:26:60:01:a1
dhcpStatements: fixed-address 192.168.1.2

dn: cn=isengard,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: isengard
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:05:02:71:ec:ab
dhcpStatements: fixed-address 192.168.1.3

dn: cn=moria,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: moria
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:30:65:ef:74:8e
dhcpStatements: fixed-address 192.168.1.4

# 192.168.1.5 = imladris.lan.herzbube.ch

# 192.168.1.6 = osgiliath.lan.herzbube.ch

dn: cn=fornost,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: fornost
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:00:e8:88:ab:80
dhcpStatements: fixed-address 192.168.1.7

dn: cn=tharbad,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: tharbad
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:0d:93:b1:eb:c2
dhcpStatements: fixed-address 192.168.1.8

dn: cn=nargothrond,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: nargothrond
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:17:f2:cd:5d:09
dhcpStatements: fixed-address 192.168.1.9

dn: cn=nindalf,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: nindalf
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 10:9a:dd:5d:bb:eb
dhcpStatements: fixed-address 192.168.1.10

# 192.168.1.11 = pelargir.lan.herzbube.ch

dn: cn=laserjet1300n,cn=group-192.168.1.0,cn=dhcp,dc=herzbube,dc=ch
cn: laserjet1300n
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:30:6e:d0:e4:20
dhcpStatements: fixed-address 192.168.1.126

# 192.168.2.1 = osgiliath.wifi.herzbube.ch

dn: cn=landroval,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: landroval
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:25:00:fe:f4:e3
dhcpStatements: fixed-address 192.168.2.2

dn: cn=nargothrond,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: nargothrond
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:19:e3:08:00:a5
dhcpStatements: fixed-address 192.168.2.3

dn: cn=buschtrommel,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: buschtrommel
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:26:4a:f3:8d:2f
dhcpStatements: fixed-address 192.168.2.4

dn: cn=bundeslade,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: bundeslade
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet d8:a2:5e:07:b7:7d
dhcpStatements: fixed-address 192.168.2.5

# 192.168.2.6 = pelargir.wifi.herzbube.ch

dn: cn=nindalf,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: nindalf
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet c8:bc:c8:f1:77:61
dhcpStatements: fixed-address 192.168.2.7

dn: cn=ihoernchen,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: ihoernchen
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet c8:bc:c8:f1:77:61
dhcpStatements: fixed-address 192.168.2.8

dn: cn=wundertuete,cn=group-192.168.2.0,cn=dhcp,dc=herzbube,dc=ch
cn: wundertuete
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 04:54:53:28:aa:9f
dhcpStatements: fixed-address 192.168.2.9


Create authentication DN

The DHCP server needs to authenticate in order to access the LDAP directory. For this purpose, we need to create an authentication entry with DN cn=dhcp-service,ou=users,dc=herzbube,dc=ch. Give the entry a password and a nice description, and that's all there is to it.


Configure DHCP to use LDAP

Place the following block into /etc/dhcp/dhcpd.conf:

ldap-server "localhost";
ldap-port 389;
ldap-username "cn=dhcp-service,ou=users,dc=herzbube,dc=ch";
ldap-password "secret";
ldap-base-dn "dc=herzbube,dc=ch";
# Dynamic = Hosts are looked up every time a DHCP request comes in
# Static = Read entire configuration, including hosts, only once at startup
ldap-method dynamic;
ldap-debug-file "/var/log/dhcp-ldap-startup.log";

Because the configuration file now contains a password, change the file's permissions:

chmod 600 /etc/dhcp/dhcpd.conf


Leases

The current leases are stored in the following file (regardless of whether the DHCP server uses LDAP or not):

/var/lib/dhcp/dhcpd.leases

The leases file can be modified but the DHCP server must be restarted for the changes to have any effect.


Note: The leases file may contain many entries for the same IP address. The reason for this is that the DHCP server simply appends an entry when a new lease is handed out. When the server is restarted, the leases file is cleaned up.