Записки IT специалиста

​​Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory

Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.

Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.

В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.

Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».

Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.

При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.

Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.

Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо printer-216 надо сначала где-то найти его текущий IP-адрес.

Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».

Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.

И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.

Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.

Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.

Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».

www.group-telegram.com/ca/interface31.com/4240

2.8K viewsMay 15 at 14:02

​​Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory

Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.

Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.

В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.

Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».

Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.

При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.

Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.

Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо printer-216 надо сначала где-то найти его текущий IP-адрес.

Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».

Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.

И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.

Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.

Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.

Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».

BY Записки IT специалиста