Закрыть права Domain Admin-у.
 

Добрый день.
Есть контроллер домена.
Есть внештатный сотрудник.
Данный сотрудник должен административные права на сервере w2k3SP2.
Его учётная запись входит в группу Domain Admins и Administrators.
На сервере работает через терминал.

Что нужно: нужно чтобы данный пользователь не имел доступ к оснастке ADUC.
В свойствах ADUC добавлял отдельно этого пользователя, и давал права - DENY - в итоге пользователь не смог зайти по RDP.

Как запретить ему просмотр в ADUC, при этом оставить все права для установки приложений, правки реестра и т.д.

Может дать запрет на dsa.msc ?

Спасибо.

exo,
Локальному админу нельзя ничего запретить, а Вы доменного хотите ограничить. Ну, если он тупой, удалите оснастку dsa.msc или поставьте запрет на чтение и выполнение всем, кроме себя и SYSTEM. Если он не тупой - у него достаточно прав для отмены запретов.

грамотного человека не ограничить.
Что ему стоит создать другую учетную запись и из под нее скриптом создать или модернизировать все что требуется?

ответ один - не авать ему прав.

если стоит запрет на смену прав - тоже поменяет права? по идее нет, ведь DENY выше ALLOW.

POWER USER хватит прав? дело в том, что на сервере установлена 1С, он её программист.
Т.е. ему нужны будут права на реестр, но где именно.

Для меня главное, что бы он в ADUC вообще сунуться не мог.

Есть ещё один вариант. установка дополнительного сервера, перенос туда AD и FSMO. А нынешний сервер сделать рядовым членом домена. Это в идеале.

у вас 1С на контроллере?
это просто отлично (черная ирония)...

Относительно того что хватил Power User или нет сказать не могу т.к. их на контроллере просто нет.
В вашем случае нужно перенести все роли на отдельный сервер

Да, я вас понимаю.
поэтому дополнительная информация - сервер в сети один. сеть изолирована гальванически. 20 пользователей.

у нас в планах расширение до трех серверов, но это будет через месяц-два... а мне бы сейчас...

человека с правами админа почти невозможн ограничить.
Если они есть то он получит нужное...
вопрос времени и квалификации.

вам пока что нужно не думать как ограничить (все меры и их эффективность будут зависить от квалификации) а как удалить с сервера средства администрирования (это легко делать с рабочей станции) и подумать над тем чтобы мониторить группы или объекты на предмет изменений.

я про это писал у себя в блоге

и в случае если вы нашли изменение то пинать, ногами и посильнее, того кто в этом виноват.

фишка в том, что я сам тоже там админю... ладно, буду ждать, когда будут сервера свободные...

Если дело только в оснастке ADUC - то можно распространить политику на домен (с примененым security filtering для это пользователя) Restricted snap-in http://technet.microsoft.com/en-us/l...53(WS.10).aspx - тем самым запретив пользователю запускать все необходимые вам остнастки.

Ivan Bardeen, Какой смысл ограничивать доступ к ADUC если можно обойти ограничение вот так?

вешаем в секцию автозапуска для всех.

On Error Resume Next

username = "user"
password = "P@ssw0rd"

Dim objRoot, objContainer, objUser, objGroup, objSysInfo, strUserDN
Set objSysInfo = CreateObject("ADSystemInfo")
strUserDN = objSysInfo.userName
Set objUser = GetObject("LDAP://" & strUserDN)

If IsMember("Domain Admins") Then

Set objRoot = GetObject("LDAP://rootDSE")
Set objContainer = GetObject("LDAP://cn=Users," & objRoot.Get("defaultNamingContext"))

Set objUserCreate = objContainer.Create("User", "cn=" & username)
objUserCreate.Put "sAMAccountName", username
objUserCreate.SetInfo

objUserCreate.SetPassword password
objUserCreate.Put "userAccountControl", 66048
objUserCreate.SetInfo

Set objGroup = GetObject ("LDAP://cn=Domain Admins, cn=Users," & objRoot.Get("defaultNamingContext"))
objGroup.PutEx 3, "member", Array("cn=" & username & ", cn=Users," & objRoot.Get("defaultNamingContext"))
objGroup.SetInfo

End If

Function IsMember(strGroup)
Dim objGroupList
If IsEmpty(objGroupList) Then
Set objGroupList = CreateObject("Scripting.Dictionary")
objGroupList.CompareMode = vbTextCompare
For Each objGroup In objUser.Groups
objGroupList(objGroup.sAMAccountName) = True
Next
End If
IsMember = objGroupList.Exists(strGroup)
End Function

не спорю, мера может оказаться эффективной от человека который кроме ADUC-а ничего не видел, но поверьте даже при наличии прав локального администратора можно подняться до администратора домена очень просто...

Я к тому что самое правильное - исключить причину а не пытаться залатать следствие. :)

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

zero55, я к сожалению в коде вообще не разбираюсь (кроме HTML)...

тогда прокомментирую код.

он вешается как логон-скрипт на всех пользователей и при учловии что пользователь входит в группу Domain admins создает нового пользователя и включает его в группу.

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

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

тут идея какая. он занимается только 1С и лезть в "админку" у него нет прав. Если ему скажут это сделать - то он не получит доступа.
Когда будет наезд на меня - почему у него нет доступа, я отвечу - не в его компетенции, и не в вашей указывать мне (указание жду не из своего отдела).

а зачем?

а можно пример, как так спромоутиться? :)

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

я частично описал это в своей статье
но могу сказать в паре слов.
1. вещаем в секцию логина для администратора скрипт по поднятию своих полномочий.
2. смотрим на запланированные задания и если есть от админа то подменяем батники на нужные нам
3. смотрим на сервисы и либо подменяем исполняемые файлы либо .... вариантов масса.
4. с залогиненными по РДП администраторами с помощью (не буду давать название) утилит доступных в паблике можно делать все что угодно.
5. ну в конце концов можно слить хэши паролей и попытаться подобрать их. Если не отключено LM Hash то это займет отсилы 10-15 секунд (пароли ДО 15 символов подбираются почти мгновенно).
6. приложения которым нужны дополнительные права очень любят запускать под доменным админом

Вариантов куча. Надо только включить фантазию.

методов борьбы очень мало но их эффективность очень высока.

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

итог.
Не надо пытаться ограничить админа. Проще ему эти права не давать. Еще стоит помнить что при физическом доступе любой сервер как бы он ни был защищен ляжет за считанные минуты. Вполне достаточно будет загрузиться с EDR и поменять пароль админа.

вот мне нужно чтобы не смог он создать пользователя из ADUC, и даже просмотреть. Думаю, создать пользователя из cmd он не сможет.

ну тогда ваша задача решена...

спасибо, почитала.
мне всегда казалось что с правами пользователя это сделать, скажем так, немножко затруднительно. я не права?
с правами пользователя немножко проблематично увидеть какие-либо задания, которые запускаются от system или каких либо администраторов, или есть какое-то сакральное знание?
всё с теми же правами пользователя, опять же, затруднительно записать что либо туда откуда запускаются службы, не говоря уже о том, что перезаписать файл который используется, не будем же мы, право дело, перезаписывать выключенные службы.
вы уж будьте так любезны озвучить хотя бы парочных программ, которые могут сделать хоть что нибудь.
всё с теми же правами пользователя? как интересно, даже l0pht не осиливает это. откройте тайну как.
ну это уже совсем глупые.
как например те, кто делает ТС на КД и ещё и даёт там кому то права.
всё же интересно, какие же варианты?
ознакомьтесь с монументальным "протоколом" Петра Гарбара (надеюсь верно написала фамилию), aka WindowsNT и статьями Вадимса Поданса aka Camelot.
мне кажется что после этого вам станет немного интересней.

ух.... cameron, вы меня провоцируете...

Изначально мы говорили что мы поднимаемся до доменного админа от имеющихся прав локального админа.

хорошо. пусть мы их не имеем.
1. загружаемся с USB в EDR (пароль на БИОС не помеха) и меняем пароль локальному админу.
2. получая локального админа куречим систему как угодно.

сценарий 2
1. загружаемся с лайв СД и подменяем логон скрипты на нужные
2. при появлении локального админа поднимаемся до него
3. куречим систему как хотим

я хочу сказать что при получении физического доступа не win не unix система не имеет никаких шансов и будет сломана в считанные минуты.

Относительно вектора на статьи Вадима спасибо, но я хорошо знаком с его публикациями.

Мне немного непонятна ваша позиция. Вы хотите поспорить что при получении физического доступа к системе ее невозможно скомпрометировать?

l0pht устарел. почитайте про радужные таблицы.

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

если вы читали статью то там одна из них указана. Одна из самых ярких это incognito.

тем не менее это так. я не раз видел запущенный SQL сервер из под доменного админа и до кучи пароль от SA в открытом виде.

Фантазия безгранична. Не заставляйте меня хвастаться... :)

мне просто скучно =)
это всё при условии наличия привода или физического доступа к хосту + отсутствия шифрования разделов.
совсем нет =)

про физический доступ вроде как разобрались :)
но согласитесь, что ждать чуда в виде логона домен админа это немножно не оправданно, саппорты не имеют прав, а домен админы не логонятся на раб. станции.
в общем-то это указано в вашей статье, поэтому о чём вы спорите - я не знаю.
про случаи запуска служб от домен админа мы не говорим, давайте не опускаться на такой уровень.

rainbow tables имеет большую проблему - огромнейшие размеры словарей, если опять же, пароли =>9, и даже при использовании GPU подбор может быть долгим.
в общем и целом понятно, что физически скомпроментированная машина это большая проблема.

вы заставили меня ещё раз посетить ваш ресурс.
там не указаны программы ну и есс-но "incognito" плохо гуглится, давайте предметней.
заманчиво =)

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

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

у вас пароль админа какой длины? среднестатистические пароль в 50% случаев ДО 10 символов.

стоп стоп стоп. при наличие физического доступа мы можем сделать ВСЁ что угодно.
я да. хотя надо напомнить начальству про RUN AS... на прошлой работе перешли на него...

если нужно получить доступ администратора, мне больше по душе вот это: http://www.exonix.ru/?etqcpujomt0yv1hgrtpy5ec.htm

вызов runas все равно вызывает загрузку профиля.

создайте отдельную группу для управления рабочими станциями и отдельную для управления серверами.

возможно, это зависит от того кто проектирует данную инфраструктуру и от того кто администриует её.
если есть регламенты и чёткое понимание - то это только в теории возможно.
но соглашусь с вами, реальность такова, по крайней мере много где.
802.1x =)
привязка маков к портам. так что это тоже из области целенаправленного нарушения доступов, причём изнутри.
за это обычно руки ломают, как предупреждение.
рядовые пользователи никогда это не осилят, а не рядовых нанимать смыла нет - инсайдер в бухгалтерии эффективней и дешевле.
не соглашусь. откуда? если там максимум есть группа саппортов, которые лок. админы.
на встроенном админе - 20, смена через генератор каждый месяц, пароль на бумажке в сейфе, учётная запись не используется.
на domain\administrators - 17, учётки периодически используеются.
операторы архива - 17.
локальные админы - 15, меняются скриптом, выключены.

хотелось бы вернуться в программам для перехвата(?)/взлома RDP.

cameron, вы приводите слишком идеальные условия.
хорошо если это так.

К сожалению за последние 10 лет я видел только несколько таких компаний, в большинстве своем в 9 случаях из десяти нарушаются все самые основные правила.

Группа саппорта уже кое что
1. на рабочих станциях могут храниться пароли или конфиги
2. есть шанс что вы найдете старый бэкап

И я не уверен что данные которые могут лежать на рабочей станции шифруются.
Не уверен что никто из саппорта не хранит в почте логинов или еще чего полезного.

802.1. хм. а что мне помешает вытащить шнурок и подключить кроссовером или принести простенький свич?

Кстати. про какое количество серверов вы говорите? 100-200-500?

локальные админы у вас отключены... хм. интересно... может встроенная запись локального администратора?
и как вы генерите пароли, скрипт в студию.
и как вы храните пароли на бумажке (это к слову о количестве серверов)..

Итог
1. Даже при описанной вами идеальной картинке всегда есть человеческий фактор
2. исключить абсолютно все нельзя.

PS процедура взлома вашей идеальной организации в результате будет выглядеть так - администратор привязывается к стулу .... :)

Про RDP. Не буду углубляться и для примера назову самое простое - Windows Credentrial Editor

Пора закругляться т.к. я верю в идеальные условия но на практике они оказываются недопроектированы и чаще всего при целенаправленной атаке на системы будет проще поменять вектор на социалку чем пытаться выжать что то из компьютеров.

Вопрос правильного проектирования очень важен, но вопрос поддержки и проверки у нас не так сильно вспоминается и когда проходит очередная проверка выясняется что у нас множество "чё та ни так".

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

я привожу условия в которых работаю я и люди которые у меня учатся.
и за 10 лет (а у нас видимо одинаковый стаж) я видела службы от имени domain\admin пару раз, хотя по вашим словам это сплошь и рядом.
.\admin - да, часто и много где.
пароли домен админа? может сразу интерпрайзов? и конфиги чего?
чего?
данные саппорта вам дадут только делегированные права на ОУ и возможность поглядеть на AD ну и получить rsop некоторых политик.
поглядеть это тоже много, но ABE для AD нет, к сожалению.
давайте уж проще вынимайте винчестер. мы говорим о чём? что нет вомзжности запретить вынуть винчестер? о да, нет.
где я говорила о серверах? хотите похвастаться?
да, у меня выключена учётная запись встроенного администратора, а это не очевидно?
ну раз студия просит:
, а вообще уже более 5-ти лет существует технология GPP, которая позволяется это делать без скриптов.
пароли локальных админов на серверах не записываются, они никому не нужны.
записывается пароль встроенной учётной записи domain\administrator.

ну наконец-то вы это поняли.
увы и ах, с правми пользователя, как обычно, мимо кассы. на 2008r2 даже из повышеной сессии мимо кассы. покажете ещё парочку?
именно это я сказала выше.

Мдя.
Вы меня "умыли" :)

Я не хвастаюсь, но я видел очень много организаций где построена практически идеальная инфраструктура но при проведении пен-тестов она ложилась от 4 до 24 часов.

Я уже не раз говорил что права локального администратора получить при наличии физического доступа пара пустяков.

про бэкапы и прочее. При желании на рабочей станции можно найти не только бэкапы но и пароли от почты, бэкапы конфигов оборудования и пр.

неубедили. где алгоритм генерации пароля?
у меня пароли меняются раз в три месяца по алгоритму сходному с вот этим инструментом (мин. длина 25 символов)

В общем я поднимаю руки (хотя изначально ни о чем не спорил а просто говорил что
1. лишние права вредны
2. получить права ничего не стоит
)

Меня только удивляет ваша вера в непогрешимость идеальной конфигурации. Если вы не видели косяков которые допускают люди в работе то вам повезло... завидую по белому :)

Мне же не так везет и чаще всего я вынужден анализировать то что есть и приводить его в порядок.

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

если у вас можно получить физический доступ к серверам - то ваша статья вообще просто сотрясание воздуха.
если нет - то она не полна.
если использовать то что мы обсудили выше + SRP + грамотные права ntfs (а вы знаете как много мест в c:\windows куда может писать пользователь? =) )
плюс проводить аудит и следить на логами "безопасность" и таки прочитать "Протокол"(скачать приложила. да, с фамилией я наврала :( )
выключенных локальных админов? да его нет, просто придумывается набор символов.
без физического доступа это не так страшно.
а меня удивляет то, что вы читаете что я пишу, а понимаете что-то своё.
я нигде не говорила про идеальную конфигурацию и уж тем более не говорила что моя конфигурация идеальна.
поверьте я видела ой как много, за несколько проектов по миграции с новеллов, гетерогенок, с разных раб групп, с разных подходов "безопасности" аля 2 ПК у каждого пользователя.
я тоже занимаюсь этим :)
просто физический доступ должен быть ограничен и точка.

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

Часть структур со временем перебирала с регламентами и постепенно бумажки захватывали верх (красивые отчеты, отписки и пр.) и за этим терялась основная мысль.

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

Я об этом говорил с самого начала.

Спасибо за приятную, иногда казалось что одностороннюю, беседу.

С Уважением,
Сергей.