Войти

Показать полную графическую версию : [решено] Закрыть права Domain Admin-у.


Страниц : [1] 2

exo
15-04-2011, 09:19
Добрый день.
Есть контроллер домена.
Есть внештатный сотрудник.
Данный сотрудник должен административные права на сервере w2k3SP2.
Его учётная запись входит в группу Domain Admins и Administrators.
На сервере работает через терминал.

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

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

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

Спасибо.

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

zero55
15-04-2011, 11:46
грамотного человека не ограничить.
Что ему стоит создать другую учетную запись и из под нее скриптом создать или модернизировать все что требуется?

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

exo
15-04-2011, 14:13
dsa.msc или поставьте запрет на чтение и выполнение »
если стоит запрет на смену прав - тоже поменяет права? по идее нет, ведь DENY выше ALLOW.

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

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

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

zero55
15-04-2011, 14:28
у вас 1С на контроллере?
это просто отлично (черная ирония)...

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

exo
15-04-2011, 15:19
у вас 1С на контроллере?
это просто отлично (черная ирония).. »
Да, я вас понимаю.
поэтому дополнительная информация - сервер в сети один. сеть изолирована гальванически. 20 пользователей.

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

zero55
15-04-2011, 16:44
человека с правами админа почти невозможн ограничить.
Если они есть то он получит нужное...
вопрос времени и квалификации.

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

я про это писал у себя в блоге (http://blog.wadmin.ru/2011/03/group-member-monitoring/)

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

exo
15-04-2011, 20:12
а как удалить с сервера средства администрирования »
фишка в том, что я сам тоже там админю... ладно, буду ждать, когда будут сервера свободные...

Ivan Bardeen
15-04-2011, 20:18
фишка в том, что я сам тоже там админю... ладно, буду ждать, когда будут сервера свободные... »
Если дело только в оснастке ADUC - то можно распространить политику на домен (с примененым security filtering для это пользователя) Restricted snap-in http://technet.microsoft.com/en-us/library/cc786453(WS.10).aspx - тем самым запретив пользователю запускать все необходимые вам остнастки.

zero55
15-04-2011, 21:13
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-а ничего не видел, но поверьте даже при наличии прав локального администратора можно подняться до администратора домена очень просто...

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

exo
16-04-2011, 12:02
Если дело только в оснастке ADUC »
именно. пользователь может её запускать, может смотреть других пользователей. но, думаю, смотреть политики он не умеет и тем более их править.

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

zero55
16-04-2011, 12:45
я к сожалению в коде вообще не разбираюсь (кроме HTML)... »
тогда прокомментирую код.

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

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

exo
16-04-2011, 13:38
т.к. мало-мальски грамотный нарушитель получит нужное без этой оснастки »
пусть получает, мне главное что-бы он оснастку не мог использовать.
Если он получит доступ к другим административным ресурсам - накажем.

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

при учловии что пользователь входит в группу Domain admins создает нового пользователя и включает его в группу »
а зачем?

cameron
16-04-2011, 16:36
но поверьте даже при наличии прав локального администратора можно подняться до администратора домена очень просто... »
а можно пример, как так спромоутиться? :)

zero55
16-04-2011, 18:01
а зачем? »
Если вы ему ограничили доступ то он может создать другого пользователя который будет иметь доступ.

а можно пример, как так спромоутиться? »
я частично описал это в своей статье (http://blog.wadmin.ru/2011/03/basic-safety/)
но могу сказать в паре слов.
1. вещаем в секцию логина для администратора скрипт по поднятию своих полномочий.
2. смотрим на запланированные задания и если есть от админа то подменяем батники на нужные нам
3. смотрим на сервисы и либо подменяем исполняемые файлы либо .... вариантов масса.
4. с залогиненными по РДП администраторами с помощью (не буду давать название) утилит доступных в паблике можно делать все что угодно.
5. ну в конце концов можно слить хэши паролей и попытаться подобрать их. Если не отключено LM Hash то это займет отсилы 10-15 секунд (пароли ДО 15 символов подбираются почти мгновенно).
6. приложения которым нужны дополнительные права очень любят запускать под доменным админом

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

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

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

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

exo
16-04-2011, 19:08
Если вы ему ограничили доступ то он может создать другого пользователя который будет иметь доступ. »
вот мне нужно чтобы не смог он создать пользователя из ADUC, и даже просмотреть. Думаю, создать пользователя из cmd он не сможет.

zero55
16-04-2011, 19:09
ну тогда ваша задача решена...

cameron
16-04-2011, 23:20
я частично описал это в своей статье
но могу сказать в паре слов. »
спасибо, почитала.
1. вещаем в секцию логина для администратора скрипт по поднятию своих полномочий. »
мне всегда казалось что с правами пользователя это сделать, скажем так, немножко затруднительно. я не права?
2. смотрим на запланированные задания и если есть от админа то подменяем батники на нужные нам »
с правами пользователя немножко проблематично увидеть какие-либо задания, которые запускаются от system или каких либо администраторов, или есть какое-то сакральное знание?
3. смотрим на сервисы и либо подменяем исполняемые файлы либо .... вариантов масса. »
всё с теми же правами пользователя, опять же, затруднительно записать что либо туда откуда запускаются службы, не говоря уже о том, что перезаписать файл который используется, не будем же мы, право дело, перезаписывать выключенные службы.
4. с залогиненными по РДП администраторами с помощью (не буду давать название) утилит доступных в паблике можно делать все что угодно. »
вы уж будьте так любезны озвучить хотя бы парочных программ, которые могут сделать хоть что нибудь.
5. ну в конце концов можно слить хэши паролей и попытаться подобрать их. Если не отключено LM Hash то это займет отсилы 10-15 секунд (пароли ДО 15 символов подбираются почти мгновенно). »
всё с теми же правами пользователя? как интересно, даже l0pht не осиливает это. откройте тайну как.
6. приложения которым нужны дополнительные права очень любят запускать под доменным админом »
ну это уже совсем глупые.
как например те, кто делает ТС на КД и ещё и даёт там кому то права.
Вариантов куча. Надо только включить фантазию. »
всё же интересно, какие же варианты?
Если интересно то заходите ко мне на блог я в ближайшее время допишу статью по базовым правилам безопасности. »
ознакомьтесь с монументальным "протоколом" Петра Гарбара (надеюсь верно написала фамилию), aka WindowsNT и статьями Вадимса Поданса aka Camelot.
мне кажется что после этого вам станет немного интересней.

zero55
17-04-2011, 04:34
ух.... cameron, вы меня провоцируете...

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

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

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

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

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

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

как интересно, даже l0pht не осиливает это. откройте тайну как. »

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

не говоря уже о том, что перезаписать файл который используется »

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

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

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

ну это уже совсем глупые. »

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

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

cameron
17-04-2011, 09:52
ух.... cameron, вы меня провоцируете... »
мне просто скучно =)
хорошо. пусть мы их не имеем.
1. загружаемся с USB в EDR (пароль на БИОС не помеха) и меняем пароль локальному админу.
2. получая локального админа куречим систему как угодно. »

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

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

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

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

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




© OSzone.net 2001-2012