Linux dhcp with windows dns
Установка 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.
Регистрация Linux в DNS Windows 2008 R2
При необходимости иметь AD, службы DNS и DHCP проще использовать стандартные в поставке Windows Server. Практически не нуждается в настройке, разве что авторизацию DHCP в DNS включить. А автоматическая регистрация хостов работает «из коробки».
Однако Linux машины обслуживаемые тем же DHCP, что и Windows машины, автоматически не регистрируются в DNS. Да и в DHCP имя хоста пустое.
В случае с Debian, решение проблемы не сложное, скорее всего в других дистрибутивах действия будут аналогичными.
Настройка Dibian
В /etc/dhcp/dhclient.conf добавить строку:
send host-name «hostname«;
где hostname — имя Linux хоста
Или автоматически получить имя хоста:
send host-name = gethostname();
Согласно man’у имя может как содержать имя домена, так и не содержать его, с рекомендацией указывать только имя машины, без домена.
option host-name string;
This option specifies the name of the client. The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name). See RFC 1035 for character set restrictions. This option is only honored by dhclient-script(8) if the hostname for the client machine is not set.Этим мы заставим DHCP Client при запросе IP адреса передавать имя хоста. Этого более чем достаточно, чтобы в оснастке DHCP сервера появилось полное доменное имя хоста. Мне лишь не понятно, почему указание имени машины при DHCP запросах не является настройкой по-умолчанию, ну да ладно.
Примените изменения любым удобным вам образом, хоть перезагрузкой.
Настройка Windows Server
В оснастке DHCP сервера уже видно полное доменное имя хоста, который мы настраиваем.
Но в DNS новых записей не появилось, хотя DHCP настроен на обновление DNS (я надеюсь, что вы выполнили эту настройку еще когда поднимали AD, впрочем это не сложно сделать и в любое другое время).
Тут есть два пути. Либо разрешить Nonsecure Dynamic Updates для доменной зоны, либо попросить DHCP сервер обновить DNS. Второй вариант мне кажется более безопасным, а для его настройки нужно поставить аж одну галочку.
В свойствах DHCP сервера, или более локально, в свойствах Scope, на закладке DNS включите:
Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0).
На этом всё. При следующем запросе IP адреса у DHCP произойдет регистрация в Windows DNS.