Étiquette : dhcp

DHCP Failover Auto Config Sync sous Windows Server 2012

YoannLeave a comment

Dans Windows Server 2012, le service DHCP peut être configuré pour fournir une haute disponibilité. Les baux d’adresses IP d’une étendue sont ainsi synchronisés entre deux serveurs DHCP en relation de basculement. Cependant, lorsque l’administrateur effectue des modifications dans la configuration d’une étendue, celle-ci n’est pas répliquée sur l’autre serveur DHCP.

L’outil DHCP Failover Auto Config Sync écrit en Windows PowerShell, permet de réaliser cette réplication automatiquement.

La documentation que je vous propose, présente cette problématique et met en œuvre l’outil DHCP Failover Auto Config Sync (DFACS) à travers un atelier pratique.

Télécharger la documentation sur DHCP Failover Auto Config Sync [1.33 Mo]

Problème de serveur DNS avec Windows 7 et dhcp (dans un cas bien particulier)

Cyril1 Comment

Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :


...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers  192.168.0.1;
option  routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host  monposte.be-root.com {
option domain-name-servers  192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}

Symptômes :

Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1  (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).

Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.

Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres  192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.

Résolution :
On peut contourner de problème de plusieurs façons :

  • Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
  • Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
  • Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
    Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
    Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.

Mise en place serveur DHCP couplé à un annuaire LDAP sous Centos 6

CyrilLeave a comment

Dans cet article, nous allons voir comment faire en sorte qu’un serveur dhcp utilise une configuration stockée dans un annuaire ldap plutôt que dans des fichiers de configuration statiques.

Le serveur utilisé tourne sous Centos 6. Un minimum de connaissance d’openldap et dhcpds est requis puisque nous ne détaillerons pas les commandes utilisées.

Tout d’abord, nous allons procéder à l’installation des paquets openldap et dhcpd :

yum install dhcp openldap-servers

Le paquet dhcp fourni par la distribution contient nativement tout le nécessaire pour coupler le serveur à un annuaire LDAP.
Dans le fichier /etc/openldap/slapd.conf, rajoutons ces lignes :

include         /etc/openldap/schema/dhcp.schema
...
index           dhcpHWAddress eq
index           dhcpClassData eq

Dans notre exemple, le fichier slapd.conf est configuré pour gérer l’arbre dc=be-root,dc=com.
Dans le fichier /etc/dhcpd/dhcpd.conf, supprimons tout le contenu existant et remplaçons le par :

ldap-server "localhost";
ldap-port 389;
ldap-username "uid=dhcpdaemon,dc=be-root,dc=com";
ldap-password "blahblah";
ldap-base-dn "dc=be-root,dc=com";
ldap-method dynamic;

Voici le fichier LDIF utilisé pour créer la racine de l’annuaire LDIF ainsi que le compte uid=dhcpdaemon
utilisé par le serveur dhcp pour interroger la base :

dn: dc=be-root,dc=com
objectclass: top
objectclass: organization
objectclass: dcObject
structuralObjectclass: organization
dc: be-root
o: Annuaire 

dn: uid=dhcpdaemon,dc=be-root,dc=com
objectclass: top
objectclass: inetOrgPerson
objectclass: Person
cn: Utilisateur pour daemon DHCP
givenName: dhcpdaemon
sn: dhcpdaemon
uid: dhcpdaemon
userPassword: {CRYPT}K3nDIt87oiYnA

Bien évidemment, ajustez les ACLs dans le fichier slapd.conf afin que l’utilisateur dhcpdaemon ait des droits suffisants.

Nous allons ensuite déclarer dans notre fichier LDIF une entrée permettant de déclarer un serveur dhcp ainsi que la configuration globale correspondante :

dn: cn=hostname_serveur_dhcp, dc=be-root, dc=com
objectClass: top
objectClass: dhcpServer
cn: hostname_serveur_dhcp.be-root.com
dhcpServiceDN: cn=configdhcp, dc=be-root, dc=com

dn: cn=configdhcp, dc=be-root, dc=com
cn: Configuration du serveur DHCP
objectClass: top
objectClass: dhcpService
objectClass: dhcpOptions
dhcpStatements: ddns-update-style none
dhcpStatements: default-lease-time 3600
dhcpStatements: max-lease-time 7200
dhcpOption: domain-name-servers 10.0.2.2
dhcpPrimaryDN: cn=hostname_serveur_dhcp, dc=be-root, dc=com

Nous allons ensuite déclarer le subnet 10.0.2.0 comportant un pool allant de 10.0.2.10 à 10.0.2.20 dans le fichier LDIF :

dn: cn=10.0.2.0, cn=configdhcp, dc=be-root, dc=com
cn: 10.0.2.0
objectClass: top
objectClass: dhcpSubnet
objectClass: dhcpOptions
dhcpOption: routers 10.0.2.2
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: broadcast-address 10.0.2.255
dhcpNetMask: 24
dhcpRange: 10.0.2.10 10.0.2.20

Nous pouvons également ajouter de l’adressage statique :

dn: cn=monpc, cn=configdhcp, dc=be-root, dc=com
objectClass: top
objectClass: dhcpHost
cn: monpc
dhcpHWAddress: ethernet 08:00:27:9B:3A:4D
dhcpStatements: fixed-address 10.0.2.100

Bien évidemment, le fichier ldif doit être cohérent par rapport au fichier slapd.conf.
Il nous reste maintenant à utiliser la commande slapadd pour injecter notre fichier LDIF dans openldap et ensuite démarrer les services :

service slapd start
service dhcpd start

Vérifiez les logs pour vous assurer du bon fonctionnement des services.
De plus, le serveur dhcpd-4.1.1 empaqueté avec la distribution Centos 6 fourni un script perl présent sous /usr/share/docs/dhcp-4.1.1/dhcpd-conf-to-ldap permettant de convertir un fichier dhcpd.conf existant au format ldif. La syntaxe est la suivante : perl /usr/share/docs/dhcp-4.1.1/dhcpd-conf-to-ldap < /etc/dhcpd/dhcpd.conf > output.ldif