Однажды я получил запрос от одного из наших администраторов, которому были делегированы определенные права на AD в его сфере ответственности. Он жаловался мне, что он не имеет необходимых прав на одну из учетных записей. Что ж, нет проблем: небольшое исследование и – бинго! – я выяснил, что по непонятным причинам на этой учетной записи было отключено наследование прав. Починка не отняла у меня много времени: одна галка, кнопка “Ок” – не великая потеря времени. На следующий день я получил повторный запрос по тому же поводу и по той же самой учетной записи. Наследование опять было отключено. Ладно, я не такой уж новичек, я даже знаю кое-что о таких тайнах бытия, как adminCount, adminSDHolder и SDProp. Так что я пошел и удостоверился, что проблемный пользователь не является членом ни одной из защищенных групп – так оно и было. Так что я попробовал еще пару трюков навроде переноса учетки в другое OU и обратно. Безрезультатно. И в этот самый момент я получил еще одни запрос, от другого администратора про другую учетную запись, но с тем же самым эффектом. И эта другая учетная запись тоже когда-то была членом группы Domain Admins. Что ж, теперь было очевидно, что именно SDProp перезаписывает разрешения на объектах. Проверка атрбута adminCount показала, что наконец-то я был прав: он был установлен в 1.Как только я установил его в 0 и восстановил наследование, все пришло в норму. А еще немного поковырявшись, я выяснил, что когда объект покидает защищенную группу, adminCount не возвращается в значение 0. И это сделано специально, by design. Чуть больше деталей можно найти здесь и здесь. А я в следующий раз буду чуть менее ленивым и буду больше доверять своиему внутреннему Админу – глядишь, время сэкономлю 
Комментариев нет:
Отправить комментарий