none
Междоменно-трастовая каша или dsget vs gpresult RRS feed

 > 

  • Вопрос

  • Question
    Нужно войти
    0
    Нужно войти
    Всем доброго времени суток

    Как бы разобраться, почему список групп доменном контроллере не соответствует реально имеющимся правам на конкретном сервере?
    Список групп по команде dsget не соответсвует списку по команде gpresult. Ну и приложение соответственно ругается на неверные права.

    Подробное описание. В темно-синем лесу (с) есть два домена, в них заведены две группы для проекта. В группах пользователи. В проекте есть акаунты и из первого и из второго домена. Обе проектные группы объединены через одну универсальную группу, безопасность в приложении и на файловых ресурсах настроена для универсальной группы. Сервера под приложения и терминальные сервера стоят в одном из доменов. Все работает годами.
    Затем нам выдают новые сервера, которые положено держать в совершенно отдельном объединительном лесу доменов. Настроены трасты. Первый и Второй домены прекрасно видны на новых серверах, старые акаунты действуют как для логина на терминал-сервере так и для доступа к приложению.
    Однако не совсем.
    Пользователи из Первого домена (которых большинство) действительно не имеют никаких проблем. Универсальная группа из первого леса видна во втором и все прозрачно работает.
    Пользователи из Второго домена не могут использовать приложение на сервере в новом лесу, потому что они, оказывается, не входят в ту правильную универсальную группу.
    Командой dsget я запрашиваю данные по универсальной группе, с различных серверов из различных доменов и лесов. Данные идентичны, пользователи сконфигурированы правильно.
    Для пользователей из Первого домена, по отчету приложения и по списку групп от gpresult, информация об универсальной группе корректно передается из леса в лес.
    Для пользователей из Второго домена информация об универсальной группе не передается.

    Где читать, что мониторить?
    9 июня 2011 г. 16:47
    |

Все ответы

  • Question
    Нужно войти
    0
    Нужно войти
    Не совсем понятно описание проблемы. Но возможно, вам поможет тот факт, для более понятного описания задачи, что универсальные группы имеют область действия только в пределах своего леса, и могут содержать членов только своего леса. То есть их нельзя использовать для разделения доступа в разных лесах.
    9 июня 2011 г. 17:32
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти

    С удовольствием опишу подробнее, что именно неясно?

     

    Универсальная группа из леса юзеров и доменная группа из Первого домена (где я) видны у меня через gpresult на сервере в лесу для компов. И я могу этим группам раздавать права. Это как?

    10 июня 2011 г. 8:35
    |
  • Question
    Нужно войти
    0
    Нужно войти

    С удовольствием опишу подробнее, что именно неясно?

     

    Универсальная группа из леса юзеров и доменная группа из Первого домена (где я) видны у меня через gpresult на сервере в лесу для компов. И я могу этим группам раздавать права. Это как?


    Опишите ситуацию лучше назвав домены своими именами. (ну например domain1.ru ). Хотелось бы разобраться, какой домен к какому лесу принадлежит и какова вообще структура AD
    10 июня 2011 г. 8:48
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти

    Структура AD зело сложная и обжалованию не подлежит.

    Домены

    contoso.msft
    d2.cont.ms

    Видимая мне структура

    dsget group "CN=U_PROJECT_GROUP,OU=TAGroups,DC=contoso,DC=msft" -members -expand

    "CN=PROJECT_GROUP,OU=TAGroups,DC=contoso,DC=msft"
    "CN=PROJECT_GROUP,OU=TAGroups,DC=d2,DC=cont,DC=ms"
    ...
    "CN=username,OU=TAUsers,DC=contoso,DC=msft"
    ...
    "CN=vorname.lastname,OU=TAUsers,DC=d2,DC=cont,DC=ms"
    ..

    Сервера

    qsb1.d2.contoso.msft Исправлено на qsb1.d2.cont.ms
    qsb2.t1.si.msft

    Доступ выдан группе U_PROJECT_GROUP на всех серверах.

    Пользователь username на любом сервере является членом U_PROJECT_GROUP и имеет доступ.

    Пользователь vorname.lastname на qsb1.d2.contoso.msft является членом U_PROJECT_GROUP и имеет доступ.

    Пользователь vorname.lastname на qsb2.t1.si.msft не попадает в U_PROJECT_GROUP

    Командой dsget user -memberof -expand на любом сервере получаем правильные группы для всех пользователей, а именно U_PROJECT_GROUP и PROJECT_GROUP соответствующего домена.

    Командой gpresult на qsb2.t1.si.msft для vorname.lastname получаем в числе прочих только PROJECT_GROUP а универсальную - нет.

     


    • Изменено dvv70 15 июня 2011 г. 15:32 очепятка в имени домена
    15 июня 2011 г. 11:24
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Вы перечислили домены:

    contoso.msft
    d2.cont.ms

    Эти домены принадлежат одному лесу? Больше доменов нет?

    qsb2.t1.si.msft - t1.si.msft - это что за домен?

    qsb1.d2.contoso.msft - d2.contoso.msft - а это что за домен?

    15 июня 2011 г. 12:13
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти

    Перечислены два мне релевантнные домены. Имеется много иных прочих.

    Думаю что они таки в одном лесу.

    qsb1 и qsb2 это мои терминальные сервера, на которых все и происходит. Соответственно t1.si.msft - тот самый домен для машин. d2.cont.ms - домен для юзеров и некоторых серверов. Выше значит опечатка. Читать так:

    qsb1.d2.cont.ms
    qsb2.t1.si.msft

    Между лесами contoso и si есть односторонние трасты: в si я вижу объекты из contoso но не наоборот.

     



    15 июня 2011 г. 15:31
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Думаю что они таки в одном лесу.

    Покажите вывод команды netdom query fsmo

    c qsb1.d2.cont.ms и qsb2.t1.si.msft

    15 июня 2011 г. 16:19
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти
    Вообще, при создании таких отношений между лесами, я бы во втором лесу создал глобальную группу, в нее добавил пользователей, а потом уже эту группу внес в нужную универсальную группу первого леса.Такое проделывал не раз и все исправно функционировало.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow MSTechnetForum on Twitter

    Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    16 июня 2011 г. 8:07
    |
    Модератор
  • Question
    Нужно войти
    0
    Нужно войти
    >netdom query fsmo
    Schema owner                s5aba.si.msft
    Domain role owner           s5aba.si.msft
    PDC role                    S4AA1.T1.si.msft
    RID pool manager            S4AA1.T1.si.msft
    Infrastructure owner        S4AA1.T1.si.msft

    The command completed successfully.

    >netdom query fsmo
    Schema owner                D3AMI.ads.ms
    Domain role owner           D3AMI.ads.ms
    PDC role                    g4AQR.d2.cont.ms
    RID pool manager            g4ame.d2.cont.ms
    Infrastructure owner        g4ame.d2.cont.ms

    The command completed successfully.
    17 июня 2011 г. 14:52
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Вообще, при создании таких отношений между лесами, я бы во втором лесу создал глобальную группу,
    Тут все не столь просто. Ресурсы раздаются не на уровне файловых шар а на уровне внутренней секуры приложения. А там запомнены старые SID и GID . Посему крутить все под новые домены не хочется. К тому же у большинства все работает прозрачно за счет трастов.
    17 июня 2011 г. 14:55
    |
  • Question
    Нужно войти
    0
    Нужно войти
    >netdom query fsmo
    Schema owner                s5aba.si.msft
    Domain role owner           s5aba.si.msft
    PDC role                    S4AA1.T1.si.msft
    RID pool manager            S4AA1.T1.si.msft
    Infrastructure owner        S4AA1.T1.si.msft

    The command completed successfully.

    >netdom query fsmo
    Schema owner                D3AMI.ads.ms
    Domain role owner           D3AMI.ads.ms
    PDC role                    g4AQR.d2.cont.ms
    RID pool manager            g4ame.d2.cont.ms
    Infrastructure owner        g4ame.d2.cont.ms

    The command completed successfully.


    Между вашими  доменами нельзя использовать универсальные группы, так как домены находятся в разных лесах - последуйте совету Юрия

     

    17 июня 2011 г. 15:00
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти
    Давайте поточнее, о которых из доменах идет речь. Их там много разных.
    17 июня 2011 г. 18:46
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Давайте поточнее, о которых из доменах идет речь. Их там много разных.
    Ваши - "релевантные вам"
    17 июня 2011 г. 18:48
    |
    Отвечающий
  • Question
    Нужно войти
    0
    Нужно войти

    contoso.msft
    d2.cont.ms

    в одном лесу или нет?

    t1.si.msft - этот точно в ином лесу.

    17 июня 2011 г. 18:58
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Между вашими  доменами нельзя использовать универсальные группы, так как домены находятся в разных лесах - последуйте совету Юрия

    A почему я в t1.si.msft вижу U_PROJECT_GROUP и могу ее использовать по имени и GID?

    И gpresult для username@contoso.msft дает ее в списке групп?

    21 июня 2011 г. 14:08
    |