Active directory with linux dhcp

Active directory with linux dhcp

Установка 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-машину в среду домена Windows AD (Active Directory)

    В этой статье будет описан процесс добавления Linux-машины (Ubuntu 20.04) в домен Windows AD.

    Шаг 1. Установка пакетов и подготовка

    После этого установите требуемые пакеты.

    sudo apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

    Далее мы настроим все инструменты. Вам требуется знать:

    Шаг 2. Настройка DNS

    Откройте конфигурационный файл netplan:
    

    Если вы видите там «dhcp4: true», то есть ваш DHCP-сервер настроен корректно, переходите к следующему шагу. Если вы настраиваете параметры сетевого подключения вручную, ознакомьтесь с примером настройки:

    network:ethernets:enp0s3:addresses:- 192.168.0.15/24gateway4: 192.168.0.10nameservers:addresses: [192.168.0.1, 192.168.0.2]search:- office.localoptional: trueversion: 2

    • addresses — это IP, назначаемый сетевой карте;
    • gateway4 — IP роутера;
    • nameservers — DNS-сервера;
    • search — целевой домен.

    Шаг 3. Обнаружение домена, присоединение к нему и проверка результата.

    В первую очередь требуется обнаружить домен:

    Вы увидите что-то подобное. Это означает, что настройки сети верны и машина получила ответ от домена. Если нет, вам необходимо проверить настройки сети, домен и работоспособность DNS.

    Затем присоединитесь к домену AD. Замените admin1 на имя администратора и укажите пароль.

    Проверьте, возможен ли прием информации о пользователе AD. Замените user1 на имя пользователя вашего домена.

    id user1@office.localuid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

    Шаг 4. Последние настройки и авторизация.

    Необходимо произвести настройку, чтобы в будущем каждый раз не добавлять имя домена к имени пользователя.

    Измените значение use_fully_qualified_names на False. Перезагрузите и проверьте:

    sudo systemctl restart sssdid useruid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

    Теперь нужно настроить создание домашних каталогов для пользователей AD при входе в систему.

    sudo nano /etc/pam.d/common-session#add this line in the end of filesession optional pam_mkhomedir.so skel=/etc/skel umask=077

    Войдите в систему как пользователь AD.

    Это означает, что вы успешно вошли в систему как пользователь AD.

    Также вы можете разрешить авторизацию для некоторых пользователей и групп AD или же ограничить других. В приведенном ниже примере настроен запрет для всех пользователей, кроме user0, user1 и группы Main Admins.

    sudo realm deny –allsudo realm permit user0@office.local user1@office.localsudo realm permit -g ‘Main Admins’

    Настройка пользователей AD для получения root-прав такая же, как и для локальных, но выполняется в другом файле.

    Добавьте к нему нужные строки. Например:

    Источник

    Читайте также:  Linux citrix receiver install