none
Посоветуйте, как правильно назвать домен AD? RRS feed

  • Вопрос

  • В связи с увеличением размера организации возникла необходимость поднять AD. Сейчас у нас имеется примерно следующие ресурсы: внутри сети несколько www сайтов на IISe под доменным именем допустим site.ru (01.site.ru, 02.site.ru и т.д.), есть так же еще один домен почты у провайдера, назовем его mail.ru. Кроме того, есть еще просто свободный домен free.ru.

    Посоветуйте, как правильно назвать домен AD (первый домен в лесу) чтобы в дальнейшем не получить большого количество проблем с внутренними ресурсами, в планах так же есть перенести почтовый сервер внутрь сети возможно на Exchange. Сейчас склоняюсь к варианту названия AD как office.mail.ru, в таком случае как мне кажется в дальнейшем не будет особых проблем с переносом почтового сервера внутрь AD. Либо назвать домен AD не используемым сейчас free.ru т.е. будет office.free.ru? И вообще насколько правильно делать домен AD, доменов 3го уровня на основе реального домена интернета?

    8 февраля 2016 г. 14:03

Ответы

  • Не думал, что данный вопрос вызовет такие баталии и имеет несколько подходов и кардинальных мнений, и так попробую резюмировать, то что понял из постов выше. Есть три варианта:

    1) Называем домен AD - mail.ru (имя домен контроллера к примеру dc.mail.ru.). В ВНЕШНЕМ DNS домена mail.ru провайдера прописываем A, MX и PTR записи для нашего почтового сервера.

    2)  Называем домен AD - free.ru (имя домен контроллера к примеру dc.free.ru.). При переносе почты настраиваем Exchange на работу с другим доменом (не делал такого, потому не знаю, сколько проблем тут может быть). В ВНЕШНЕМ DNS домена mail.ru провайдера прописываем A, MX и PTR записи для нашего почтового сервера.

    3) Называем домен AD - site.ru (имя домен контроллера к примеру dc.site.ru.). В настройках делегирования домена у хостера в качестве одного из dns серверов прописываем NS запись нашего контроллера. В таком случае получается, что необходимо настраивать проброс  портов для службы DNS на фаерволе. Плюс надо еще есть искать один DNS сервер.

    4.1, 4.2, 4.3) Есть варианты когда мы называем наш домен AD как домен 3его уровня, т.е. например office.site.ru (имя домен контроллера к примеру office.dc.site.ru.). И тут в зависимости от имени домена идем по 1,2 или 3 варианту, но это роли не играет, поэтому варианта всего три.

    Как мне кажется 3й вариант не очень правильный и безопасный, а так же увеличивает нагрузку на dns. На мой взгляд самый предпочтительный 2 вариант (т.к. данное имя не используется для чего либо, а если и будет использоваться то в дальнейшем при необходимости, это можно будет настроить), при условии что в дальнейшем не возникнет проблем с почтой, а именно с тем, что Exchange находится в одном домене AD, а обслуживает другой, а так же с сертификатами если в них будет необходимость.


    • Изменено Life_13 9 февраля 2016 г. 9:56
    • Помечено в качестве ответа Life_13 15 февраля 2016 г. 9:45
    9 февраля 2016 г. 9:48

Все ответы

  • Назвать free.ru (первый домен в лесу). Если потом категорически захочется, чтобы внутреннее имя домена, реально содержащего рабочие учётные записи и проч., отличалось от внешнего, создавать в лесу поддомен office.free.ru.

    Использовать office.mail.ru как внутреннее имя, хотеть перенести к себе почту, и что б она туда приходила не лучший вариант - прописывание делегирования DNS на поддомен производится в зоне DNS родительского домена - то есть, нужно обращаться к хозяевам mail.ru, чтобы они обеспечили делегирование на office.mail.ru, или сопровождали ваш домен на своих DNS. Вы точно этого хотите?

    Совпадение внутреннего имени домена с внешним именем _своего_ домена - хороший вариант, при котором не требуется выяснений, почему одно и то же называется отсюда так, а оттуда эдак (а там вообще рыбу заворачивали). Только требуется включать мозг для грамотного сопровождения внутренней и внешней одноимённых зон DNS, содержимое которых очевидно должно быть разным. Почему-то это для очень многих оказывается сложнее, чем с разными именами :).


    S.A.


    • Изменено Alexander RusinovModerator 8 февраля 2016 г. 22:54 удалена не цензурная лексика
    8 февраля 2016 г. 14:43
  • Идти нужно от обратного: Как не нужно называть домены Active Directory

    Читал не только эту заметку, собственно потому и родился данный вопрос, и именно поэтому я как вариант предлагаю домен 3го уровня.
    8 февраля 2016 г. 15:04
  • Назвать free.ru (первый домен в лесу). Если потом категорически захочется, чтобы внутреннее имя домена, реально содержащего рабочие учётные записи и проч., отличалось от внешнего, создавать в лесу поддомен office.free.ru.

    Использовать office.mail.ru как внутреннее имя, хотеть перенести к себе почту, и что б она туда приходила не лучший вариант - прописывание делегирования DNS на поддомен производится в зоне DNS родительского домена - то есть, нужно обращаться к хозяевам mail.ru, чтобы они обеспечили делегирование на office.mail.ru, или сопровождали ваш домен на своих DNS. Вы точно этого хотите?


    S.A.

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

    Мне кажется самый правильный вариант будет назвать домен AD - mail.ru. В таком случае у нас не будет особых проблем с сайтами, т.к. они на другом домене, и для переноса почтового сервера достаточным будет во внешнем DNS прописать MX и PTR записи для почтового сервера.

    8 февраля 2016 г. 15:11
  • домен 3го уровня.

    Company.domain.ru или Company.company.ru

    тогда netbios имя домена будет совпадать с названием вашей организации.
    Если пользователи будут использовать логины вида company\username - то будут понимать в какой домен они логинятся. А в друг у вас филиал откроется, а вход всё равно по имени Office...


    8 февраля 2016 г. 15:12
    Модератор
  • Мне кажется самый правильный вариант будет назвать домен AD - mail.ru. В таком случае у нас не будет особых проблем с сайтами, т.к. они на другом домене, и для переноса почтового сервера достаточным будет во внешнем DNS прописать MX и PTR записи для почтового сервера.

    Человек же написал, что это "почтовый домен у провайдера". Если это _свой_ домен, тогда да. Если имя домена принадлежит провайдеру, тогда нет от слов "никак" и "никогда".

    И не могу удержаться от комментария к "статье по ссылке", а конкретно п.2 (совпадающие имена).

    С ростом организации, неизбежно появляется всё большее количество внутренних ресурсов, доступ к которым необходим одновременно и изнутри (из локалки), и снаружи (из интернет). И естественно, когда доступ изнутри происходит по локальным адресам, доступ снаружи по внешним.

    При использовании совпадающих имён внутреннего и внешнего доменов вопрос решается естественным образом - откуда имя срезольвили, по тому IP и обращаемся, при использовании одного и того же имени. Да, надо заботиться о корректном содержимом двух зон, а не одной. Аргумент - "... а это неизбежно приведет к путанице и дополнительной рутине" - приводит в восторг.

    А вот когда у нас имена доменов внешнее/внутреннее различаются, для организации доступа к таким ресурсам, будем делать что? Можно, конечно, объяснять пользователям, что вот на работе, чтобы попасть сюда, нужно это имя, а как с работы ушел, уже вовсе вот это для всё туда же, и с планшета/смартфона, если тут по файфай, это так называется, а при подключении через оператора уже вовсе и не так, а эдак. И вполне может найтись топ, который задаст вопрос - "... ты придурок? Сделать, чтобы одно и то же называлось всегда одинаково, мозгов не хватает?" - и будет прав, по большому счёту. Несимпатично, да? А выбор путей решения, приводит всё к тому же split dns, хоть обрешайся. И при уже выбранных разных именах, "путаница и дополнительная рутина" будет возводиться в степень ... в зависимости от уровня сообразиловки :).

    Как же разгребать результаты деятельности желающих изначально избавить себя от "путаница и дополнительная рутина", ы-ы-ы...

    И кстати, если кто не помнит (многие, похоже). Домен .local (убийственный вариант, т.е. повбывав бы :)) подбрасывался при поднятии домена в Small Business Server. Оно таки тоже подарок от Майкрософта, да.


    S.A.


    • Изменено Alexander RusinovModerator 8 февраля 2016 г. 22:56 удалена не цензурная лексика
    8 февраля 2016 г. 16:14
  • Добавлю еще не совсем техническое замечание, если вы планируете, чтобы ваш домен AD прослужил вам долго. Используйте в имени вашего домена наименование торговой марки, отвлеченное название, но только не наименование юридического лица. А то при любой смене юр. лица, продаже бизнеса и т.п. первое, что захочет сделать владелец, это переименовать домен. От слияния/поглощения так не защититься, а от переименования - можно. 
    8 февраля 2016 г. 16:26
    Модератор
  • Не могу удержаться от комментария к комментарию г-на Safronov A. Лично я как раз являюсь сторонником того подхода, чтобы имя домена Active Directory было составной частью единого пространства имён Интернета - то есть, доменом третьего уровня, надлежащим образом делегированным из принадлежащего предприятию домена второго уровня (либо специально выделенным для этого доменом второго уровня).

    Главное удобство такого подхода - имена объектов домена AD доступны без дополнительных усилий, в принципе, отовсюду. Это облегчает работу в филиалах (особенно - мелких), даёт пространство для дополнительных обходных решений проблем, уменьшает трудности взаимодействия с партнёрами и т.д.

    Если же требуется, чтобы какие-то доступные извне объекты внутренней сети (к примеру, веб-сайты) были доступны изнутри сети по другим адресам IP, то это решается совсем не сложно и без поддержания полноценной split DNS: созданием на внутренних DNS-серверах зон с именами таких объектов и записями, совпадающими с именами зон и указывающими на нужный адрес. И это решение никоим образом не зависит от того, как именно называется домен AD.  Но лично я всегда придерживался стратегии, что такие объекты должны иметь маршрутизируемые в Интернете адреса и находиться в "демилитаризованной зоне" - чтобы не иметь такой путаницы в принципе. Кстати, эта стратегия имеет ещё и дополнительный плюс - более высокую защищённость от атак.


    Слава России!

    8 февраля 2016 г. 16:47
  • Человек же написал, что это "почтовый домен у провайдера". Если это _свой_ домен, тогда да. Если имя домена принадлежит провайдеру, тогда нет от слов "никак" и "никогда".


    S.A.

    Это я и писал )) Просто возможно не правильно выразился, да все домены принадлежат нам, соответственно прописывать мы в них можем любые записи.

    Т.е. как я понял из всего выше прочитанного в нашем случае будет оптимальным вариантом наименование домена AD - mail.ru (т.е. имя домен контроллера к примеру dc.mail.ru.).

    8 февраля 2016 г. 18:47
  • Это я и писал )) Просто возможно не правильно выразился, да все домены принадлежат нам, соответственно прописывать мы в них можем любые записи.

    Т.е. как я понял из всего выше прочитанного в нашем случае будет оптимальным вариантом наименование домена AD - mail.ru (т.е. имя домен контроллера к примеру dc.mail.ru.).

    В этом случае потребуется, чтобы зона DNS домена AD была целиком доступна из Интернета и делегирована для ваших серверов DNS с реальными IP (а их потребуется, минимум, два, впрочем, для второго можно воспользоваться чьей-нибудь платной услугой Secondary DNS). Если вас это не смущает, и если вы твёрдо уверены, что веб-сайта mail.ru не будет - тогда можно.

    PS Обслуживаемые MS Exchange почтовые домены практически никак не связаны с доменом AD и могут быть любыми (потребуется лишь незначительная начальная настройка Exchange). Так что от совпадения имени почтового домена  с именем домена AD практического выигрыша нет.


    Слава России!





    • Изменено M.V.V. _ 8 февраля 2016 г. 19:23
    8 февраля 2016 г. 19:19
  • Если же требуется, чтобы какие-то доступные извне объекты внутренней сети (к примеру, веб-сайты) были доступны изнутри сети по другим адресам IP, то это решается совсем не сложно и без поддержания полноценной split DNS: созданием на внутренних DNS-серверах зон с именами таких объектов и записями, совпадающими с именами зон и указывающими на нужный адрес.

    Угум. Вот у меня для одного из доменов более 30 уникальных записей во внешней зоне, из них 5 на чисто внешние ресурсы, остальные публикации. Во внутренней зоне, большинство дублируемых записей с авторегистрацией, а несколько (статических) осознанно на на внешние IP, уже для осознанного выбора: по этому имени получаем доступ через интернет, по тому по локалке (выбор для филиалов при не очень быстром vpn/intranet). Оцените усилия на то же самое "созданием на внутренних DNS-серверах зон с именами таких объектов и записями, совпадающими с именами зон и указывающими на нужный адрес". Как оно, с точки зрения "путаница и дополнительная рутина"? Для "админа", неспособного разобраться с содержимым одноимённых зон, это просто дорога в Ад :).

    И это решение никоим образом не зависит от того, как именно называется домен AD. 

    Конечно не зависит. Один из моих доменов был зарегестрирован в прошлом веке, нашим доменам NT4 тогда DNS был глубоко пофиг, но внутреннее имя домена DNS для смешанной среды было выбрано совпадающим с внешним (точнее, наоборот, но без разницы). Зато при миграции на W2K вопрос выбора имени леса вообще не стоял :). Правда, отказались от BIND'a с вьюшками и реально разделили DNS, но это уже вопрос квалификации "тогда". Оно "не зависит", но когда "внутри совпадает", это помощь, а не помеха. Главное, не забывать, что внешняя зона штука сугубо отдельная, а непосредственного доступа к содержимому зоны внутренней не должно быть никогда...


    S.A.

    8 февраля 2016 г. 19:25
  • Это я и писал )) Просто возможно не правильно выразился, да все домены принадлежат нам, соответственно прописывать мы в них можем любые записи.

    Т.е. как я понял из всего выше прочитанного в нашем случае будет оптимальным вариантом наименование домена AD - mail.ru (т.е. имя домен контроллера к примеру dc.mail.ru.).

    Извиняюсь за невнимательность.

    Imho, да.


    S.A.

    8 февраля 2016 г. 19:28
  • 30 уникальных записей - это уже серьёзное основание подумать над выносом соответствующих ресурсов в DMZ с реальными IP Или допиливание публикации так, чтобы обращение к этому адресу изнутри тоже работало. То есть - требуется больше планирования. Но если это не подходит, то более простая, чем создание по зоне для каждой записи альтернатива тоже есть: в основной зоне записи прописываются как псевдонимы (CNAME) со ссылками на некую другую зону, которая уже делается раздельной: для внешних пользователей она делегирована на внешние серверы, а для внутренних - размещена на всех КД (ну, или через view в BIND).


    Слава России!

    8 февраля 2016 г. 19:50
  • В этом случае потребуется, чтобы зона DNS домена AD была целиком доступна из Интернета и делегирована для ваших серверов DNS с реальными IP

    Э-э... Ни в коем разе. Не надо зону домена AD доступной из интернета :). Да, Вам понадобятся два внешних DNS, НО - никак не связанные с внутренними. При наличии желания и свободных IP (для 2-х DNS требуются IP из разных подсетей) можно поднимать свои, при сегодняшних смешных ценах на DNS-хостинг, ни разу не проблема "не свои". Почти любой регистратор предлагает услугу праймари-днс вкупе с регистрацией домена...

    Там Вы прописываете имена для тех (только) ресурсов своего домена, которые имеют внешние IP. При наличии ресурсов, которые имеют только внешние IP, их имена нужно будет вручную продублировать на внутренних DNS.

    Как пример, внутренняя почта (Exchange): выполняете публикацию (NAT/Reverse proxy) на внешних IP - соответствующие записи с внутреннего DNS дублируете на внешнем DNS, уже с соответствующими внешними IP.

    Имеется веб-сайт на внешнем хостинге - делаете запись для него на внешнем DNS, и дублируете на внутренних DNS с тем же внешним IP.

    При понимании и минимальной аккуратности :), имеете унифицированный управляемый доступ "отовсюду" по оптимальным/желаемым путям/маршрутам.

    И имена в сертификатах для внутри/снаружи одинаковые ;)


    S.A.

    8 февраля 2016 г. 19:52
  • ... Или допиливание публикации так, чтобы обращение к этому адресу изнутри тоже работало. То есть - требуется больше планирования. Но если это не подходит, то более простая, чем создание по зоне для каждой записи альтернатива тоже есть: в основной зоне записи прописываются как псевдонимы (CNAME) со ссылками на некую другую зону, которая уже делается раздельной: для внешних пользователей она делегирована на внешние серверы, а для внутренних - размещена на всех КД (ну, или через view в BIND).

    А ЗАЧЕМ? И доступ к публикациям по внешним IP изнутри работает, если надо, но ЗАЧЕМ? Для Камчатки, для Крыма, пришли они к нам по VPN (intranet), а я их ба-бах - на внешние IP TMG, потом обратно... промолчу :).

    Я вот никак не могу понять одной простой вещи. Или - как другие не могут понять простую вещь :).

    Есть два пространства имён DNS. Разные. С разным содержимым. По разному управляются. Могут быть пересекающимися, и пересечение тоже управляется. А теперь делаем небольшое усилие, и ... просто называем эти два пространства имён одинаково. Что изменилось? В чём "кошмар-кошмар ужас-ужас"?

    Одноимённые методы разных объектов наследников одного класса, выполняющие весьма различающиеся действия - это проблема?

    Одинаковые имена переменных, в процедурно-ориентированных языках, в зависимости от области видимости, означающие разные переменные - это проблема? Обращение к конкретному экземпляру переменной с явным указанием модуля, которому она принадлежит, с пересечением области видимости, проблема? (ну, бывает, в зависимости от ;)).

    Так почему проблема одинаковые имена разных пространств DNS? Область видимости - определяется структурой сети (откуда запрос резольвинга). Отсутствие механизмов пересечения области видимости - да, решаем вручную дублированием. Но почему проблема? Ну, кроме квалификации...


    S.A.

    8 февраля 2016 г. 20:26
  • Назвать free.ru (первый домен в лесу). Если потом категорически захочется, чтобы внутреннее имя домена, реально содержащего рабочие учётные записи и проч., отличалось от внешнего, создавать в лесу поддомен office.free.ru.

    Использовать office.mail.ru как внутреннее имя, хотеть перенести к себе почту, и что б она туда приходила не лучший вариант - прописывание делегирования DNS на поддомен производится в зоне DNS родительского домена - то есть, нужно обращаться к хозяевам mail.ru, чтобы они обеспечили делегирование на office.mail.ru, или сопровождали ваш домен на своих DNS. Вы точно этого хотите?

    Совпадение внутреннего имени домена с внешним именем _своего_ домена - хороший вариант, при котором не требуется выяснений, почему одно и то же называется отсюда так, а оттуда эдак (а там вообще рыбу заворачивали). Только требуется включать мозг для грамотного сопровождения внутренней и внешней одноимённых зон DNS, содержимое которых очевидно должно быть разным. Почему-то это для очень многих оказывается сложнее, чем трахаться с разными именами :).


    S.A.

    Добрый день, Safronov A. _.

    Отредактируйте ваши посты удалите не цензурные выражения либо они будут удалены.

    И впредь, следите за выражениями



    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://www.ru-tech.net/

    8 февраля 2016 г. 22:06
    Модератор
  • Зачем?

    К примеру, типичная проблема страдальцев с доменами AD - это именно неверная настройка DNS: в списке серверов DNS для члена домена оказываются те, которые про домен ничего не знают, именно из-за того, что пространство имён разделено. А если домен AD нормальным образом делегирован, так что поиск через корневые серверы DNS в интернете его находит, то этой проблемы не возникает в принципе.


    Слава России!

    8 февраля 2016 г. 22:08
  • К примеру, типичная проблема страдальцев с доменами AD - это именно неверная настройка DNS: в списке серверов DNS для члена домена оказываются те, которые про домен ничего не знают, именно из-за того, что пространство имён разделено.

    Неправда. Эта действительно типичная проблема возникает по единственной причине - отсутствие понимания работы DNS. На этом форуме можно найти несчислимое количество обсуждений, где проблемы, в конечном итоге, созданы представлениями "указываем этот DNS - для резольвинга доменных имён, а другой - для резольвинга других". Оно никаким боком не связано с любыми вариантами именования любых доменов. Можно называть домены как угодно, но при наличии таких представлений о DNS, проблемы в сопровождаемой системе гарантированы, рано, или поздно.

    А если домен AD нормальным образом делегирован, так что поиск через корневые серверы DNS в интернете его находит, то этой проблемы не возникает в принципе.

    Домен AD - именно AD - не должен быть делегирован (в публичной системе DNS), ни правильно, ни не правильно, вообще никак. В принципе. За исключением случаев, когда сознательно создаётся публичный AD, именно для внешнего доступа. Построение внутренней корпоративной среды к этим исключениям не относится. Не должно быть внешнего доступа к внутреннему домену AD, никакого. Иначе будут уже другие проблемы. В принципе :).

    Правильно делегирован должен быть внешний домен, используемый для внешнего доступа.

    Это вне всякой зависимости от именования доменов. Разные это пространства имён, внутри и снаружи.

    Использование одинакового названия (DNS-имени домена), для этих разных пространств имён, всего лишь частный случай. Приём, позволяющий гибко переложить раздумья "изнутри/снаружи" с пользователей, на администратора, сопровождающего систему. Если администратор тупее пользователей, наверное, делать этого не стоит. Но иметь ввиду, что в этом случае, пользователи могут оказаться способными ситуацию понять, и захотеть изменить.


    S.A.

    9 февраля 2016 г. 6:11
  • Не думал, что данный вопрос вызовет такие баталии и имеет несколько подходов и кардинальных мнений, и так попробую резюмировать, то что понял из постов выше. Есть три варианта:

    1) Называем домен AD - mail.ru (имя домен контроллера к примеру dc.mail.ru.). В ВНЕШНЕМ DNS домена mail.ru провайдера прописываем A, MX и PTR записи для нашего почтового сервера.

    2)  Называем домен AD - free.ru (имя домен контроллера к примеру dc.free.ru.). При переносе почты настраиваем Exchange на работу с другим доменом (не делал такого, потому не знаю, сколько проблем тут может быть). В ВНЕШНЕМ DNS домена mail.ru провайдера прописываем A, MX и PTR записи для нашего почтового сервера.

    3) Называем домен AD - site.ru (имя домен контроллера к примеру dc.site.ru.). В настройках делегирования домена у хостера в качестве одного из dns серверов прописываем NS запись нашего контроллера. В таком случае получается, что необходимо настраивать проброс  портов для службы DNS на фаерволе. Плюс надо еще есть искать один DNS сервер.

    4.1, 4.2, 4.3) Есть варианты когда мы называем наш домен AD как домен 3его уровня, т.е. например office.site.ru (имя домен контроллера к примеру office.dc.site.ru.). И тут в зависимости от имени домена идем по 1,2 или 3 варианту, но это роли не играет, поэтому варианта всего три.

    Как мне кажется 3й вариант не очень правильный и безопасный, а так же увеличивает нагрузку на dns. На мой взгляд самый предпочтительный 2 вариант (т.к. данное имя не используется для чего либо, а если и будет использоваться то в дальнейшем при необходимости, это можно будет настроить), при условии что в дальнейшем не возникнет проблем с почтой, а именно с тем, что Exchange находится в одном домене AD, а обслуживает другой, а так же с сертификатами если в них будет необходимость.


    • Изменено Life_13 9 февраля 2016 г. 9:56
    • Помечено в качестве ответа Life_13 15 февраля 2016 г. 9:45
    9 февраля 2016 г. 9:48
  • 2)  
    При переносе почты настраиваем Exchange на работу с другим доменом (не делал такого, потому не знаю, сколько проблем тут может быть).

    почтовый домен (new-domain.com) как минимум прописывается в настройках почтового сервера. Например для Exchange 2013

    9 февраля 2016 г. 9:59
    Модератор
  •  При переносе почты настраиваем Exchange на работу с другим доменом (не делал такого, потому не знаю, сколько проблем тут может быть).

    Никаких проблем. Поддерживаемые почтовые домены никак не связаны в доменом AD.
    9 февраля 2016 г. 10:00
    Модератор