none
доступ к КД "местного" админа win 2008 r2 RRS feed

  • Вопрос

  • Добрый день, есть такая ситуация. Домен разделённый на сайты. Порядка 40 филиалов, территориально удалены. В принципе нигде проблемы не возникает, но в одном филиале (другое юр. лицо, их сервер и лицензия, но зависимая от основной компании) местный админ очень хочет заходить на сервер и запускать консольку АД, ДХЦП именно оттуда, а не через RSAT. Сейчас ему делегированы права на его OU создание пользователей\смена пароля и т.д. Раньше у него RODC на win 2008 кд и как-то был настроен доступ его учётке к серверу. Поставили ему нормальный КД на win 2008r2 (сам домен работает в микс режиме 2003\2008). Честно пользовался гуглом как дать доступ, дошёл только до того, что в итоге он может заходить только по рдп (на старый и локально мог входить), и в любом случае не может ничего запустить, т.к. не хватает прав. Давать ему администратор домена\оператор учёта и т.д. возможности нет, т.к. тогда он может заходить и подключатся ко всем другим кд. Вот и вопрос как решить данную проблему? На старом его RODC КД такое ощущение что вначале был сделан доступ, а потом КД, т.к. сервер раньше использовался под другие задачи, хотя локальная база по идее должна была отключится.

    Уже начинаю рассматривать создание отдельного домена в лесу, но в домене работает exchange 07 и lync 2010, думаю это создаст много проблем.

    25 февраля 2013 г. 11:44

Ответы

  • RODC как раз предназначен для решения задачи, подобной Вашей - дать IT-персоналу филиала административный доступ к установленному в филиале КД, не предоставляя административный доступ к други КД и к AD в целом. Там эта задача решается просто и совершенно штатным образом (как - читайте документацию). Поэтому настоятельно рекомендую в данном случае использовать именно RODC.

    Без использования RODC возможны только паллиативные варианты, т.к. членство во встроенных группах КД (в т.ч. - и в группе Администраторы) - общее для всех КД. Возможный вариант - сделать учетку местного ИТ-шника членом группы Операторы сервера (чтобы не иметь проблем с запуском программ на КД), а возможность входа в систему на других КД - ограничить политикой: либо вынести тамошний КД из Domain Controllers в другую OU, либо определять права пользователя на вход в систему (их там два - на интерактивный вход и на вход через службу терминалов) не в Default Domain Controller policy, а в локальной политике каждого КД (да, она на КД тоже есть, доступ к ней - через gpedit.msc).  Вариант этот крайне неудобный в настройке и сопровождении, так что рекомендую все-таки RODC.

    PS Если захотите делать отдельный домен, то имейте в виду, что границей безопасности в AD является не домен, а лес, т.к. администратор любого домена в лесу с помощью небольших ухищрений (через редактирование атрибута sIDHistory) всегда способен добавить себя в группу администраторов любого другого домена.


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

    • Помечено в качестве ответа SAHEK 26 февраля 2013 г. 12:39
    25 февраля 2013 г. 16:43

Все ответы

  • а какие у него обоснования для работы на КД? "очень хочет" это не обоснования.
    25 февраля 2013 г. 12:30
    Модератор
  • RODC как раз предназначен для решения задачи, подобной Вашей - дать IT-персоналу филиала административный доступ к установленному в филиале КД, не предоставляя административный доступ к други КД и к AD в целом. Там эта задача решается просто и совершенно штатным образом (как - читайте документацию). Поэтому настоятельно рекомендую в данном случае использовать именно RODC.

    Без использования RODC возможны только паллиативные варианты, т.к. членство во встроенных группах КД (в т.ч. - и в группе Администраторы) - общее для всех КД. Возможный вариант - сделать учетку местного ИТ-шника членом группы Операторы сервера (чтобы не иметь проблем с запуском программ на КД), а возможность входа в систему на других КД - ограничить политикой: либо вынести тамошний КД из Domain Controllers в другую OU, либо определять права пользователя на вход в систему (их там два - на интерактивный вход и на вход через службу терминалов) не в Default Domain Controller policy, а в локальной политике каждого КД (да, она на КД тоже есть, доступ к ней - через gpedit.msc).  Вариант этот крайне неудобный в настройке и сопровождении, так что рекомендую все-таки RODC.

    PS Если захотите делать отдельный домен, то имейте в виду, что границей безопасности в AD является не домен, а лес, т.к. администратор любого домена в лесу с помощью небольших ухищрений (через редактирование атрибута sIDHistory) всегда способен добавить себя в группу администраторов любого другого домена.


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

    • Помечено в качестве ответа SAHEK 26 февраля 2013 г. 12:39
    25 февраля 2013 г. 16:43
  • а какие у него обоснования для работы на КД? "очень хочет" это не обоснования.
    обоснование такое, что сервер их,  и сеть их, лицензия на винду их. Они хотят админить свой дхцп (хотя там всё на века настроено), ну и за сервером смотреть, в остатке тайна покрытая мраком. К сожалению, нет регламентов работы с сетью, доменом, зон ответственности и т.д. Всё на устных договорённостях, вот устно и ругаемся.
    • Изменено SAHEK 26 февраля 2013 г. 12:59
    26 февраля 2013 г. 12:58
  • ну тогда сами себе злобные буратины. должно быть четко прописано и утверждено как минимум на уровне службы безопасности и руководства, кто должен админить домен, кд и прочие сервера и службы.
    а то что сервер их, это мало кого волнует - домен то ваш. почти все службы, включая dhcp, управляются удаленно и без роли админа сервера. а за сервером могут и снаружи посмотреть и пыль протереть.
    26 февраля 2013 г. 15:42
    Модератор
  • ну тогда сами себе злобные буратины. должно быть четко прописано и утверждено как минимум на уровне службы безопасности и руководства, кто должен админить домен, кд и прочие сервера и службы.
    а то что сервер их, это мало кого волнует - домен то ваш. почти все службы, включая dhcp, управляются удаленно и без роли админа сервера. а за сервером могут и снаружи посмотреть и пыль протереть.
    Если dhcp на кд, то доступ к ней можно получить только обладая правами доменного администратора dhcp :( насчёт регламента полностью согласен.
    1 марта 2013 г. 7:48
  • В качестве обходного решения:

    Отдельный лес, отдельный домен и настройка траста между доменами. Тогда уж точно у них все будет своим. Но это существенно усложнит администрирование, так что смотрите сами.


    Microsoft Certified Do Nothing Expert

    1 марта 2013 г. 7:55
  • Если dhcp на кд, то доступ к ней можно получить только обладая правами доменного администратора dhcp :( насчёт регламента полностью согласен.

    Неверно, задачу управления DHCP можно делегировать и на рядовом сервере, и на КД.

    http://technet.microsoft.com/en-us/library/cc786796(v=ws.10).aspx

    http://fromreallife.wordpress.com/2012/07/21/dhcp2/

    Про это часто забывают, к сожалению.

    1 марта 2013 г. 12:04
    Отвечающий