none
Доступ в дочерний домен RRS feed

  • Вопрос

  • Коллеги, всем привет.

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

    следующем вопросе?

    Есть домен Windows: co.local. Это корень леса. Также у него есть дочерний домен branch.co.local. Администрировать оба домена приходится

    одним и тем же людям, учётные записи которых созданы в домене co.local. Все DC под Windows 2003.

    Правильно ли я понимаю, что при включении рабочих станций в домен branch.co.local в группы локальных админов будет включена только группа

    Domain Admins из branch.co.local? Как одним движением сделать админов co.local администраторами рабочих станций в branch.co.local?

    Я хотел сделать универсальную группу Branch Domain Admins в co.local, расчитывал увидеть её в branch.co.local и добавить в BRANCH\Domain

    Admins. Однако из branch.co.local я вижу только "Контакты" и "Другие объекты". А при добавлении в локальную группу BRANCH\Administrators

    отлично вижу глобальные группы корневого домена.

    Как же это всё делается? Не должно такого быть?


    MCP
    27 августа 2009 г. 8:52

Ответы


  • Создайте в дочернем домене учетные записи администраторов с идентичными верительными данными (имя входя, пароль), что и у администраторов родительского домена. Только так Вы добьетесь "прозрачного" администрирования.

    Создайте локальную доменную группу безопасности "Администраторы рабочих станций филиала", включите туда глобальную из роительского и дочернего, с помощью Restricted Groups включите ее в администраторы рабочих станций.


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)

    • Помечено в качестве ответа Alexander Smirnoff 27 августа 2009 г. 9:21
    27 августа 2009 г. 9:04
    Отвечающий

Все ответы


  • Создайте в дочернем домене учетные записи администраторов с идентичными верительными данными (имя входя, пароль), что и у администраторов родительского домена. Только так Вы добьетесь "прозрачного" администрирования.

    Создайте локальную доменную группу безопасности "Администраторы рабочих станций филиала", включите туда глобальную из роительского и дочернего, с помощью Restricted Groups включите ее в администраторы рабочих станций.


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)

    • Помечено в качестве ответа Alexander Smirnoff 27 августа 2009 г. 9:21
    27 августа 2009 г. 9:04
    Отвечающий
  • Вариант:
    1. создать Универсальную группу скажем Local Administrators в branch.co.local
    2. включить в нее пользователей (или группу пользователей) из co.local
    3. Добавить Local Administrators в группу локальных администраторов политикой (или скриптом)
    Если ответ Вам помог, нажмите на изображение зеленой галочки - «пометить как ответ». Если ответ был для Вас полезен, Вы можете пометить это сообщение как «полезное», нажав на ссылку "проголосовать за полезное сообщение" в правом верхнем углу сообщения.
    27 августа 2009 г. 9:11

  • Создайте в дочернем домене учетные записи администраторов с идентичными верительными данными (имя входя, пароль), что и у администраторов родительского домена. Только так Вы добьетесь "прозрачного" администрирования.

    Создайте локальную доменную группу безопасности "Администраторы рабочих станций филиала", включите туда глобальную из роительского и дочернего, с помощью Restricted Groups включите ее в администраторы рабочих станций.


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)

     

    Спасибо за ответ. Вариант №2 может быть полезен. Вы не знаете, является ли это best practice? Зачем же нам универсальные группы раз они не видны?
    А вариант №1 может и работающий, но явно не рекомендуемый. Если у меня будет 20 дочерних доменов, то мне 20 учётных записей создавать? А если в каком-то из доменов придёт время сменить пароль?


    MCP
    27 августа 2009 г. 9:19
  • Спасибо за ответ. Вариант №2 может быть полезен. Вы не знаете, является ли это best practice? Зачем же нам универсальные группы раз они не видны?

    Мы пользуем предложенный мной вариант. Т.е. в корневом домене группа, которая включается в универсальные группы дочерних доменов...

    http://technet.microsoft.com/en-us/library/bb726978.aspx

    Best Practice Universal groups are very useful in large enterprises where you have multiple domains. If you plan properly, you can use universal groups to simplify system administration. Members of universal groups shouldn't change frequently. Each time you change the members of a universal group, you need to replicate these changes to all the global catalogs in the domain tree or forest. To cut down on changes, assign other groups to the universal group rather than accounts. For more information, see the section entitled "When to Use Domain Local, Global, and Universal Groups."

    http://technet.microsoft.com/en-us/library/cc778219%28WS.10%29.aspx

    Use global groups or universal groups instead of domain local groups when specifying permissions on domain directory objects replicated to the global catalog. For more information, see Global catalog replication .
    For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory .

    Если ответ Вам помог, нажмите на изображение зеленой галочки - «пометить как ответ». Если ответ был для Вас полезен, Вы можете пометить это сообщение как «полезное», нажав на ссылку "проголосовать за полезное сообщение" в правом верхнем углу сообщения.
    27 августа 2009 г. 9:27
  • Вариант:
    1. создать Универсальную группу скажем Local Administrators в branch.co.local
    2. включить в нее пользователей (или группу пользователей) из co.local
    3. Добавить Local Administrators в группу локальных администраторов политикой (или скриптом)
    Совет похож на совет Дмитрия Пономарёва. Только, Артём, нужна ли мне тут универсальная группа? Наверное хватит и глобальной.
    MCP
    27 августа 2009 г. 9:29
  • Совет похож на совет Дмитрия Пономарёва. Только, Артём, нужна ли мне тут универсальная группа? Наверное хватит и глобальной.
    Вобщем то хватит, конечно локальной (не глобальной)....
    ЗЫ. Когда я писал ответ - не видел написанного Дмитрием про группы...

    Если ответ Вам помог, нажмите на изображение зеленой галочки - «пометить как ответ». Если ответ был для Вас полезен, Вы можете пометить это сообщение как «полезное», нажав на ссылку "проголосовать за полезное сообщение" в правом верхнем углу сообщения.
    27 августа 2009 г. 9:35
  • Александр, я написал сумбурно про "прозрачное администрирование", извините. Отражать идентичные верительные данные имеет смысл лишь в том случае, если Вы хотите, например, чтобы Админитсраторы одного домена имели "встроенные" привилегии администраторов в домене другом. Для администрирования рабоичх станций это необязательно, разумеется.

    Александр, совет: придерживаейтесь групповой стратегии. Вот хороший курс по дизайну AD: http://www.microsoft.com/learning/en/us/course.aspx?ID=6436A&locale=en-us#tab1.


    Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
    27 августа 2009 г. 10:10
    Отвечающий
  • Вобщем то хватит, конечно локальной (не глобальной)....
    ЗЫ. Когда я писал ответ - не видел написанного Дмитрием про группы...

    Хм, да, похоже пока только так можно сделать. В дочернем домене могу добавить кого-либо из корневого домена только в локальную группу.

    MCP
    27 августа 2009 г. 12:15
  • Создайте локальную доменную группу безопасности "Администраторы рабочих станций филиала", включите туда глобальную из роительского и дочернего, с помощью Restricted Groups включите ее в администраторы рабочих станций.


    Ну а тогда скажите, правильно ли я понимаю, что при помощи политики Restricted Groups у меня будет одинаковый состав локальных групп на рабочих станциях?
    Если так, то это может быть и минусом, т. к. состав локальных групп в настоящее время неодинаков. На некоторых рабочих станциях в "Administrators" добавлены разные учётные записи домена.
    MCP
    27 августа 2009 г. 12:41
  • Ну и может кто подскажет, как же быть с Universal Groups? В писании сказано:

    Universal groups Groups with universal scope have the largest extent. Use groups with universal scope to consolidate groups that span domains. Normally, you do this by adding global groups as members. Now when you change membership of the global groups, the changes aren't replicated to all the global catalogs. This is because the membership of the universal group didn't change.

    Отчего же универсальную группу корневого домена нельзя включить в глобальную группу дочернего домена? Так и должно быть?


    MCP
    27 августа 2009 г. 12:50
  • Ну и может кто подскажет, как же быть с Universal Groups? В писании сказано:

    Universal groups Groups with universal scope have the largest extent. Use groups with universal scope to consolidate groups that span domains. Normally, you do this by adding global groups as members. Now when you change membership of the global groups, the changes aren't replicated to all the global catalogs. This is because the membership of the universal group didn't change.

    Отчего же универсальную группу корневого домена нельзя включить в глобальную группу дочернего домена? Так и должно быть?


    MCP
    Да, так и должно бытью Об этом так и написано:

    Universal groups Groups with universal scope have the largest extent. Use groups with universal scope to consolidate groups that span domains. Normally, you do this by adding global groups as members.

    Наооборот нужно включать - глобальные в универсальные....

    Если ответ Вам помог, нажмите на изображение зеленой галочки - «пометить как ответ». Если ответ был для Вас полезен, Вы можете пометить это сообщение как «полезное», нажав на ссылку "проголосовать за полезное сообщение" в правом верхнем углу сообщения.
    27 августа 2009 г. 12:59
  • добавлять restricted надо в gpo, работающим на оба домена.  В принципе работать будет если линк на дочерний , но токо GPO будет ругатся что надо линк сделать повыше. По правильному без ругательств сможете добавлять юзеров только из того домена где есть линк на gpo.
    при создании группы "администраторы" в restricted  локальные и универсальные группы не добавляются в "члены этой группы". (добавляются но не пашут)

    6 сентября 2009 г. 7:22