- PVSM.RU - https://www.pvsm.ru -
В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье [1] Шона Айви [2] на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.
Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM администраторами, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!
Рассмотрим следующий сценарий:
Пока всё хорошо. Это довольно типовой сценарий работы DHCP сервера и всё происходит именно так, как мы ожидаем. Давайте теперь добавим сюда DNS сервер.
(Если, вдруг, вы не знаете, что такое “очистка зоны”, “интервал блокирования/обновления”, то рекомендую вам почитать блог моего коллеги [3]. Он шикарен! Примечание: раз вы читаете перевод оригинальной статьи, то, возможно, вам проще будет ознакомиться с русскоязычным материалом [4])
Вот теперь всё уже не так хорошо. Такое случается гораздо чаще, чем вы можете подумать. Теперь у Клиентов А и Б DNS записи ссылаются на одинаковый IP адрес.
Рисунок 1
Итак, у нас в DNS есть два разных имени, ссылающихся на одинаковый IP адрес. И, скорее всего, всё именно так и останется еще минимум 6 дней, пока не истекут описанные выше интервалы. Какие проблемы это может вызвать? Давайте посмотрим.
Я уже упомянул, что симптомом этой ситуации была проблема с установкой SCCM клиента, но, на самом деле, мы можем использовать для демонстрации более простой пример — доступ к общей папке. Принцип один и тот же.
Давайте представим, что мне нужно получить доступ к общей папке на Клиенте А. Для примера, возьмём одну из административных папок общего доступа.
Рисунок 2
А вот это уже интересно. Во первых, клиент А даже не включен… но мы получаем ответ от его имени. И это ошибка аутентификации! Некоторые из вас уже догадались, что это происходит, когда вы посылаете сеансовый ключ Kerberos предназначенный для одного компьютера другому, но давайте по порядку.
Мы видим, что наш компьютер (Infra-App1) посылает в DNS запрос на имя client-a.corp.contoso.com. В ответ он получает IP адрес 10.0.0.100.
Рисунок 3
Насколько знает DNS, так оно и есть. Клиент А действительно имеет адрес 10.0.0.100, но точно такой же адрес имеет Клиент Б.
Отлично, теперь мы получаем сеансовый ключ Kerberos. Вот только DNS запрос был на имя Клиента А, так что ответ от службы Kerberos также будет на имя клиента А.
Рисунок 4
Рисунок 5
Мы видим запрос на Рисунке 4 и ответ контроллера домена на Рисунке 5.
Теперь, получив ключ, мы можем попытаться подключиться, к тому, что мы считаем Клиентом А.
Рисунок 6
Здесь мы видим сеансовый ключ Kerberos.
И, наконец, мы видим сообщение об ошибке от Клиента А. Почему? Потому, что клиент А это не Клиент А, а Клиент Б.
Рисунок 7
Всё это только подтверждает то, что вы, вероятно, и так знали. Для того чтобы Kerberos отработал нормально, вы должны обратиться с правильным сеансовым ключом к правильному адресату (Если вы хотите узнать больше о Kerberos, почитайте блог Роба Грина "Kerberos для занятых админов [5]" Примечание: аналогичного материала на русском я не нашёл, но с общими сведениями можно ознакомиться вот здесь [6]).
Конечно, всё отлично сработает, если вместо FQDN имени мы обратимся по IP адресу. Почему? Потому, что в этому случае вместо Kerberos будет использована аутентификация NTLM. Используя IP адрес, мы не делаем никаких предположений о том, к какому клиенту мы подключаемся. Мы просто подключаемся по определённому IP адресу. Некоторые из вас могут подумать, что и для FQDN должно сработать. В конце концов, получив ошибку при использовании Kerberos, мы должны переключиться на NTLM, верно? Не совсем. Я не буду углубляться в детали, но мы переключимся на NTLM, только если мы не смогли договориться об использовании Kerberos. Вы можете прочитать об этом подробнее здесь [7]. В любом случае, Kerberos не возвращал нам ошибки, он штатно ответил нам сеансовым ключом.
Теперь, когда мы выяснили, что проблема вызвана устаревшими записями в DNS давайте обсудим, как мы можем предотвратить такую ситуацию. Есть несколько разных способов как это сделать. Давайте обсудим каждый из них.
Примечание: я рекомендую уменьшить интервал очистки для каждого из этих способов до 1-3 дней. Интервал в 7 дней, используемый по умолчанию, позволяет проблемным записям оставаться в DNS чересчур долго.
Преимущества:
Недостатки:
Преимущества:
Недостатки:
Преимущества:
Недостатки:
Попробуйте поэкспериментировать с интервалами обновления и блокирования и длительностью аренды DHCP. Вы можете обнаружить, что изменение интервалов по умолчанию благотворно сказывается на работе ваших сетевых служб. Короткий срок аренды DHCP часто используются для беспроводных сетей. В то же время, не забывайте о дополнительной нагрузке, которую вы возлагаете на сервер, особенно если вы настраиваете частую (раз в несколько часов) очистку для очень большой DNS зоны.
Почти всё! Теперь мы понимаем, почему происходит такая ситуация, когда возникает проблема и как её предотвратить. Но как нам легко и быстро найти такие записи, если беда уже случилась? Вы можете легко найти такие парные записи в DNS используя несложный PowerShell скрипт (это, конечно же, не единственный способ).
#Import the Active Directory Module
import-module activedirectory
#Define an empty array to store computers with duplicate IP address registrations in DNS
$duplicate_comp = @()
#Get all computers in the current Active Directory domain along with the IPv4 address
#The IPv4 address is not a property on the computer account so a DNS lookup is performed
#The list of computers is sorted based on IPv4 address and assigned to the variable $comp
$comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address
#For each computer object returned, assign just a sorted list of all
#of the IPv4 addresses for each computer to $sorted_ipv4
$sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object
#For each computer object returned, assign just a sorted, unique list
#of all of the IPv4 addresses for each computer to $unique_ipv4
$unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique
#compare $unique_ipv4 to $sorted_ipv4 and assign just the additional
#IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4
$duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject}
#For each instance in $duplicate_ipv4 and for each instance
#in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign
#the computer object to array $duplicate_comp
foreach ($duplicate_inst in $duplicate_ipv4)
{
foreach ($comp_inst in $comp)
{
if (!($duplicate_inst.compareto($comp_inst.ipv4address)))
{
$duplicate_comp = $duplicate_comp + $comp_inst
}
}
}
#Pipe all of the duplicate computers to a formatted table
$duplicate_comp | ft name,ipv4address -a
Ниже приведён образец вывода этого скрипта:
Рисунок 8
Скрипт очень простой. Рассматривайте его только как пример. Он вернёт дублированные IP адреса зарегистрированные для компьютерных учётных записей в Active Directory. Помните, что он запросит все компьютерные объекты из Active Directory домена и проверит в DNS IP адрес каждого из них. Если у вас много компьютеров, то используйте ключ -searchbase вместе с командой get-adcomputer, чтобы ограничить количество опрашиваемых каждый раз объектов. Если ваш компьютер не включен в Active Directory домен, то вы не сможете найти его командой get-adcomputer. Мой скрипт специально заточен на то, чтобы получить дублированные записи DNS для сценария, который я описал выше.
Есть очень много статей о настройке интеграции DHCP и DNS. Цель этой — обобщить сведения о том, как эти две службы работает вместе, чтобы вам было проще это понять. Подведём итог:
Надеюсь, что статья была вам полезна! Правильная настройка интеграции DNS и DHCP избавит вас от такого рода проблем в вашей сети!
Автор: ICL Services
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/dns-2/118006
Ссылки в тексте:
[1] статье: https://blogs.technet.microsoft.com/askpfe/2011/06/03/how-dns-scavenging-and-the-dhcp-lease-duration-relate/
[2] Шона Айви: https://social.technet.microsoft.com/profile/Sean+Ivey+%5BMSFT%5D
[3] блог моего коллеги: https://blogs.technet.microsoft.com/networking/2008/03/19/dont-be-afraid-of-dns-scavenging-just-be-patient/
[4] материалом: https://technet.microsoft.com/ru-ru/library/cc771677.aspx
[5] Kerberos для занятых админов: https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
[6] вот здесь: https://technet.microsoft.com/ru-ru/library/hh831553.aspx
[7] здесь: http://technet.microsoft.com/en-us/library/cc780455(WS.10).aspx
[8] здесь: https://support.microsoft.com/en-us/kb/816592
[9] здесь: https://technet.microsoft.com/ru-ru/library/cc771732.aspx
[10] Источник: https://habrahabr.ru/post/281410/
Нажмите здесь для печати.