Active directory dhcp dns linux

Active directory dhcp dns linux

Установка ISC DHCP сервера и настройка обновления DNS записей в Active Directory.

  • Введение.
    • Цель: установить ISC DHCP сервер и настроить его (ISC DHCP) так, что он обновлял (создавал, удалял) DNS записи на домен-контроллере.
    • Ссылки.
      • http://www.lanlinux.ru/nastrojka-serverov/ustanovka-i-nastrojka-dhcp-servera-v-ubuntu-debian.html — Установка и настройка DHCP сервера в Ubuntu (Debian).
      • https://habrahabr.ru/post/265969/ — Безопасное динамическое обновление записей на MS DNS из Linux.
      • http://unix.stackexchange.com/questions/270097/isc-dhcp-with-active-directory-secure-dynamic-dns-updates — ISC DHCP with Active Directory Secure Dynamic DNS Updates.
      • http://pathtoself.name/extras/2015/06/AD-SLES11.html — Контроллер домена Active Directory на SLES 11.
      • Виртуальный сервер, с установленным debian 8. Hostname = dhcp-srv1. На него будем устанавливать ISC DHCP. Локальный пользователь = user1 , может sudo.
      • Домен-контроллер — dc1.test-domain.localnet, на котором «крутится» MS DNS сервер. На нем будут обновляться DNS записи. Имя домена = test-domain.localnet. IP = 10.20.20.20
      • В домене (AD) создан пользователь — dns_updater . Под этой учетной записью DHCP сервер будет обновлять DNS записи.
      • Подключаемся через ssh к dhcp-srv1 .
      • Смотрим, что есть.
      • Устанавливаем пакет.
      • Если на сервере более одного сетевого интерфейса, нужно отредактировать файл — /etc/default/isc-dhcp-server .
      • Начальная настройка DHCP сервера, редактируем конфигурационный файл — /etc/dhcp/dhcpd.conf .
      • Настройка журналирования. Edit /etc/rsyslog.d/dhcpd.conf .
      • Стартуем демон.
      • Тестируем. Запускаем тестовый хост с DHCP клиентом. Смотрим журналы.
      • Устанавливаем ntp.
      • Edit /etc/ntp.conf .
      • Проверяем.
      • Установка пакета для nsupdate.
      • Установка Kerberos клиента.
      • Edit /etc/krb5.conf .
      • Создадим папку для временных файлов.
      • Создадим keytab файл. Демон (dhcpd) выполняется под рутом, следовательно работу с билетами выполняем через sudo.
      • Получаем билет kerberos и проверяем.
      • Формируем тестовый «сценарий» обновления DNS записей. Edit /var/lib/dhcp/dns-update-1.txt .
      • Запускаем тестовое обновление DNS записей.
      • Вариант с отладкой.
      • Проверяем.
      • Редактируем конфигурационный файл — /etc/dhcp/dhcpd.conf .
      • Редактируем тестовый скрипт обновления — /var/lib/dhcp/update-msdns-1.sh .
      • Тестируем. Запускаем тестовый хост с DHCP клиентом. Смотрим журналы.

      Пошаговая процедура. III этап. Реальное обновление DNS записей.

      • Редактируем конфигурационный файл — /etc/dhcp/dhcpd.conf .
      • Редактируем рабочий скрипт обновления — /var/lib/dhcp/update-msdns-2.sh .
      • Другой вариант скрипта обновления — /var/lib/dhcp/update-msdns-3.sh .
      • Тестируем. Запускаем тестовый хост с DHCP клиентом. При этом в DNS должна появиться запись с именем тестового хоста. Смотрим журналы.
      • Оба представленных скрипта обновления (update-msdns-2.sh и update-msdns-3.sh) успешно работают.
      • Иногда возникают проблемы с удалением старых DNS записей (секции «on expiry» и «on release»). Это связано с тем, что скрипт обновления (update-msdns-2.sh) не получает параметр ClientName .

      Источник

      ISC DHCP with Active Directory Secure Dynamic DNS Updates

      I’m attempting to replace Windows Server DHCP with ISC DHCP. In order to do so, I need to be able to facilitate updating DNS records from clients that do and do not support dynamic DNS record registration. Active Directory/DNS is running on Server 2012 R2 in 2012 R2 forest/domain functional levels. DNS forward and reverse lookup zones accept secure dynamic updates only. I’ve been unsuccessful at finding a guide on how to integrate just ISC DHCP into an AD DNS environment. The configuration file is below, but what I’ve noted when using ISC DHCP is that non-domain joined clients will not have an A record registered for them in forward/reverse lookup zones. For domain-joined clients, they will have an A record registered in the forward lookup zone, but not the reverse lookup zone. The forward lookup zone is using DNSSEC.

      ddns-updates on; ddns-update-style standard; default-lease-time 600; max-lease-time 7200; log-facility local7; group < option routers 10.10.20.1; option subnet-mask 255.255.255.0; option domain-search "example.local"; option domain-name-servers 10.10.20.2, 10.10.20.3; option broadcast-address 10.10.20.255; ddns-domainname "example.local"; ddns-rev-domainname "in-addr.arpa."; authoritative; allow unknown-clients; authoritative; subnet 10.10.20.0 netmask 255.255.255.0 < range 10.10.20.30 10.10.20.150; >. certain IP reservations for hosts . > 

      With the above configuration in place, DHCPD, as expected, is being refused by DNS to update/create records:

      Unable to add forward map from device.example.local to 10.10.20.56: REFUSED 

      1 Answer 1

      This can be completed through triggers for ISC DHCP. The IPv4-only script and setup information is available from ISC DHCPd: Dynamic DNS updates against secure Microsoft DNS

      There is an alternative script that supports IPv4 and IPv6, but using the same premise as the above script is available at dns-krbnsupdate.sh.

      The basic crux of the issue is that MS DNS uses Kerberos for authentication to update DNS records, while ISC DHCP, out of the box, supports TSIG [for BIND].

      The scripts above are rather lengthy, so I won’t post them here, but the basic steps are:

      Generate a keytab using ktutil . This is for an Domain User who is a member of the «DnsUpdateProxy» in Active Directory. You should be able to do this on Windows or Linux (but the keytab must be copied to the server running ISC DHCP).

      Configure the above script for your domain/DNS servers.

      Add the parameters necessary to execute the script on the ‘on commit’, ‘on release’, ‘on expiry’ triggers in your dhcpd.conf . If using the IPv4/IPv6 script, the ‘execute’ lines will need to be adjusted:

      execute("/etc/dhcp/ddnsupdate6.sh", "add", ClientIP, "-h", ClientName, "-m", ClientMac); 
      execute("/etc/dhcp/ddnsupdate6.sh", "delete", ClientIP, "-m", ClientMac); 
      execute("/etc/dhcp/ddnsupdate6.sh", "delete", ClientIP); 

      Lastly, notate if you’re using MIT Kerberos or Heimdal. With Debian Jesse, I’m using Kerberos and uncommented the KRB5MIT line.

      Once completed, you can start isc-dhcp-server and monitor the (default logging) /var/log/syslog .

      You should see log entries similar to:

      Mar 23 23:19:34 localhost dhcpd: execute_statement argv[0] = /etc/dhcp/ddnsupdate6.sh Mar 23 23:19:34 localhost dhcpd: execute_statement argv[1] = add Mar 23 23:19:34 localhost dhcpd: execute_statement argv[2] = 10.10.20.56 Mar 23 23:19:34 localhost dhcpd: execute_statement argv[3] = -h Mar 23 23:19:34 localhost dhcpd: execute_statement argv[4] = HostName Mar 23 23:19:34 localhost dhcpd: execute_statement argv[5] = -m Mar 23 23:19:34 localhost dhcpd: execute_statement argv[6] = Mar 23 23:19:34 localhost dhcpd: DHCPREQUEST for 10.10.20.56 from (HostName) via eth0 Mar 23 23:19:34 localhost dhcpd: IPv4! Mar 23 23:19:34 localhost dhcpd: DHCPACK on 10.10.20.56 to (HostName) via eth0 Mar 23 23:19:34 localhost dhcpd: DDNS: adding records for 10.10.20.56 (hostname.nauplius.local) succeeded 

      If you see lines similar to:

      DDNS: adding records for 10.10.20.51 (hostname.nauplius.local) FAILED: nsupdate status 2

      This likely means the user specified in the keytab does not have rights to the DNS record, which can happen if that user did not create the record originally (e.g. you didn’t use a proxy user to update DNS on behalf of DHCP). This should go away over time as DNS records expire, unless domain-joined Windows clients are automatically updating their own records.

      You can validate this via the DNS MMC on Windows and checking the Security tab of the A/AAAA record in question. If you see HOSTNAME$, then the Windows client registered itself in DNS, and ISC DHCP won’t be able to (I don’t personally see an issue with this). Otherwise, you should see the user specified in the keytab have Read/Write permissions over the A/AAAA record.

      Источник

      Читайте также:  Установка openssl kali linux
Оцените статью
Adblock
detector