Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
[Maxus]
Зарегистрирован: 22.01.2010 Сообщения: 7 Откуда: Харьков
|
Добавлено: Вс Янв 24 2010 15:32 Заголовок сообщения: Использование сторонних DNS для AD |
|
|
Здравствуйте.
Имеется корпоративная сеть с 11 филиалов и головным офисом. В сети суммарно более 200 клиентских рабочих станций, более 150 включены в домен. Сеть соединена IPSec туннелями, на каждом офисе стоит D-Link DFL-210, на головном офисе стоит D-Link DFL-800. Контролеры домена находятся на головном офисе. О них я писал в теме http://forum.citforum.ru/viewtopic.php?t=105652 Когда фирма не имела такого размаха, который есть сейчас, мы базировались в одном (ныне головном) офисе, домен наш был локальным, имел вид наше_имя.local Теперь филиалы появились, но для корректной работы каждой клиентской машине нужно прописывать в настройках те DNS сервера, которые находятся в головном офисе. В итоге, если пропадает связь с головным офисом, то удаленные не могут работать в интернете из-за отсутствия ДНС-ов, а также, если какой-нибудь а также стали иметь место загрузки маршрутизатора на головном офисе из-за большого количества ДНС-запросов с одного из филиалов. (часто делаемого торрентами).
Было принято решение, полностью пересадить филиалы на DNS сервера местных провайдеров.
Первое что было сделано, это регистрация домена, и перевод контролера домена и всех клиентов с локального наше_имя.local на глобальный our_domain.net
Вторым делом, мы попросили провайдера головного офиса поднять на двух его серверах поддержку SLAVE для нашего домена, и у регистратора домена мы внесли NS записи соответствующие серверам провайдера.
Домен полностью ведется на наших двух контроллерах домена с адресами 172.16.0.1 и 172.16.0.2 а провайдерские 2 сервера обращаются к нашему внешнему адресу, на котором стоит DLINK DFL-800 и делает проброс на 53-й порт как TCP так и UDP. Транзакция зоны на провайдерские Slave С-сервера проходит успешно. Также успешно резолвится любой вторичный домен вида test.our_domain.net с любой точки мира.
Теперь после описания структуры – о самой проблеме.
На удаленных филиалах, компьютеры не хотят корректно работать в домене если на них стоят провайдерские DNS.
То есть, насколько я понимаю, работа с контроллером домена имеет следующую схему: клиент узнает у своего DNS-сервера к какому ему айпишнику обращаться и обращается дальше к этому айпишнику любым удобным маршрутом через сеть. Да, если ставлю ДНСы которые собственно и являются контролером домена – все чудесно работает (так что в туннелях и фаерволах все в порядке.)
В чем проблема ? Я что-то не так настроил (в принципе почти все по умолчанию) или Acive Directory работает только при условии, что на клиентах в настройках DNS прописаны только контролеры домена ?
Спасибо. |
|
Вернуться к началу |
|
|
VeL
Зарегистрирован: 18.01.2006 Сообщения: 521 Откуда: Харьков
|
Добавлено: Пн Янв 25 2010 12:55 Заголовок сообщения: |
|
|
Все дело в том что для работы AD на контроллере домена используется реализация DNS от майкрософт, AD при своей работе в днс зонах хранит много самой разной информации для своей работы (можно сказать использует ДНС как бы в качестве хранилища информации), поэтому стандартной настройки никсового ДНС-а недостаточно для работы AD.
Как советовал когдато and3008 посмотрите книжку "Active Directory подход профессионала". Там рассматриваются варианты использования сторонних ДНС.
Навскидку от себя добавлю, Вам скорее всего нужно на провайдерских серверах настроить проброс (форвардинг) ДНС запросов на зону our_domain.net (т.е. чтобы провайдерский ДНС сам не резолвил запросы при обращению к ДНС от AD а просто все подобные запросы передавал на контроллер домена, а остальные запросы которые касаются работы в интернете резолвил сам). Эт я так примерно по памяти рассказываю. Это в выше приведенной книжке рассказывается.
От себя добавлю, для того чтобы использовать сторонние ДНС нужно досконально знать AD (с точки знения какие зоны и для чего она использует и какие записи она туда пишет, поскольку для AD ДНС - это фундаментальная служба).
Плюс к этому Майкрософт после очередного апдейта может поменять протоколы или что-то кардинально намутить в зонах ДНС. В результате при использовании в АД сторонних ДНС фирма сядет в лужу и все старания по настройке стороннего ДНС пойдут на смарку. Поэтому на мой взгляд использование сторонних ДНС это не очень хорошая идея в контексте Майкрософта.
Поищите по этому форуму здесь подобная тема уже подымалась и эти вопросы рассматривались _________________ Best regards |
|
Вернуться к началу |
|
|
and3008
Зарегистрирован: 12.10.2001 Сообщения: 14893 Откуда: Н.Новгород
|
Добавлено: Пн Янв 25 2010 23:17 Заголовок сообщения: |
|
|
Причина в отсутствии сервисных записей, относящихся к контроллерам домена. Так называемых SRV-записях.
Как только их добавите, получите счастье. Ну и книжечку почитайте. Ее можно в свободном доступе нагуглить. Уже попадалась отсканированная. |
|
Вернуться к началу |
|
|
[Maxus]
Зарегистрирован: 22.01.2010 Сообщения: 7 Откуда: Харьков
|
Добавлено: Вт Янв 26 2010 17:53 Заголовок сообщения: |
|
|
Книжечку скачал спасибо большое.
Вот так зона трансферится на линукс-днс. Поубирал лишние записи А
Айпишник 172.16.0.8 я о нем писал в предыдущей теме, спасибо за ответ, помогло. Однако на момент трансфера зоны я не обратил на него внимание. Уже убрал, посмотрю результат.
Записи SRV вроде как есть, нормально должно работать ?
$ORIGIN .
$TTL 3600 ; 1 hour
our_domain.net IN SOA ns1.our_domain.net. hostmaster. (
420 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
864000 ; expire (1 week 3 days)
3600 ; minimum (1 hour)
)
NS ns1.our_domain.net.
$TTL 600 ; 10 minutes
A 172.16.0.1
$ORIGIN our_domain.net.
$TTL 1200 ; 20 minutes
ns1 A 172.16.0.1
$TTL 3600 ; 1 hour
1c8 A 172.16.0.8
_msdcs NS ns1
$ORIGIN _tcp.default-first-site-name._sites.our_domain.net.
$TTL 600 ; 10 minutes
_gc SRV 0 100 3268 ns1.our_domain.net.
_kerberos SRV 0 100 88 ns1.our_domain.net.
_ldap SRV 0 100 389 ns1.our_domain.net.
$ORIGIN _tcp.our_domain.net.
_gc SRV 0 100 3268 ns1.our_domain.net.
_kerberos SRV 0 100 88 ns1.our_domain.net.
_kpasswd SRV 0 100 464 ns1.our_domain.net.
_ldap SRV 0 100 389 ns1.our_domain.net.
$ORIGIN _udp.our_domain.net.
_kerberos SRV 0 100 88 ns1.our_domain.net.
_kpasswd SRV 0 100 464 ns1.our_domain.net.
$ORIGIN our_domain.net.
$TTL 600 ; 10 minutes
domaindnszones A 172.16.0.1
A 172.16.0.8
$ORIGIN domaindnszones.our_domain.net.
_ldap._tcp.default-first-site-name._sites SRV 0 100 389 ns1.our_domain.net.
_ldap._tcp SRV 0 100 389 ns1.our_domain.net.
$ORIGIN our_domain.net.
$TTL 3600 ; 1 hour
dp A 172.16.0.4
$TTL 600 ; 10 minutes
forestdnszones A 172.16.0.1
A 172.16.0.8
$ORIGIN forestdnszones.our_domain.net.
_ldap._tcp.default-first-site-name._sites SRV 0 100 389 ns1.our_domain.net.
_ldap._tcp SRV 0 100 389 ns1.our_domain.net.
$TTL 3600 ; 1 hour
icq_server A 172.16.0.1 |
|
Вернуться к началу |
|
|
and3008
Зарегистрирован: 12.10.2001 Сообщения: 14893 Откуда: Н.Новгород
|
Добавлено: Сб Янв 30 2010 02:12 Заголовок сообщения: |
|
|
А вы сами попробуйте. Если честно, мне лениво разбираться в этом.
Идею дал, дальше сами. |
|
Вернуться к началу |
|
|
|