HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\CrashOnAuditFail
Пару лет назад он подарил мне несколько часов напряженного траблшутинга проблем доступа к общим папкам и, так как ни тогда, ни сейчас я не вижу объяснения этой проблемы в поиске, я решил его описать. Если вам интересно, как может получиться, что права доступа у вас и вашего коллеги есть, но получить доступ к общей папке может только один из вас, то добро пожаловать под кат.
Ситуация была очень простой и не обещала ничего любопытного — мы только начали переход на WIndows Server 2012 R2 и поставили новый сервер под File Server и Pull Print решение от стороннего интегратора. Проблемы начались после того, как, через несколько дней, этот сервер упал в BSOD. Пользователи начали жаловаться, что они не могут получить доступ к общим папкам и печатать на принтерные очереди опубликованные с этого сервера. В стек серверной команды инцидент пришёл с довольно непонятной историей — кто-то из агентов Service Desk, проверявших инцидент подтверждал, что у него тоже нет доступа к общими папкам, кто-то говорил, что доступ есть. Аналогичная ситуация наблюдалась и с принтерными очередями. У меня прекрасно работал доступ и к тому и к другому.
Здесь нужно отметить, что так как Pull Print решение было от сторонней компании, то по договорённости с заказчиком, мы поддерживали сам сервер, а при любых проблемах с ним, интегратор рекомендовал ребилд (там действительно была очень простая процедура и, вкупе с автоматизированной установкой сервера, восстановление получалось очень быстрым, а так как роль эту делили несколько серверов, то и вывести один из них на ребилд было легко). Поэтому, поразмышляв минут 10-15 о том, почему может так странно работать сервер после BSOD, я его переустановил. После ребилда все, естественно, заработало, однако вскоре сервер снова упал в BSOD и проблема проявилась снова.
Теперь уже стало понятно, что ребилдом не отделаешься и нужно понять почему так происходит. Тесты показали, что у всех в нашей команде доступ есть, а вот у пользователей нет. Гипотеза появилась сразу и, проверив ее для тех агентов Service Desk, мы убедились — к общим папкам могут получить доступ только те, кто имеет права локального админа. Поискав похожие проблемы (ограниченный доступ к общим ресурсам) в интернете я ничего не нашёл. А вот поискав с боллее общими параметрами я нашёл этот любопытный ключ реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\CrashOnAuditFail
Здесь можно почитать о нём. Этот ключ, установленный в значение «1» переводит ограничивает доступ к системе в случае переполнения Security Event Log. То есть, если у вас переполнился лог и сервер упал, то ключ получает значение «2», изменить которое администратор должен вручную, а до этого никого кроме администратора на сервер не пустит.
Теперь всё стало ясно. В наших предыдущих билдах этот ключ не использовался и имел значение «0». А в новом безопасники решили выставить его в «1». Кроме того, настройки Security Log на этих серверах, после установки приложения предполагали ручную очистку событий. Ну, а дальше, всё понятно — лог переполняется, сервер падает в BSOD, поднимается и пускает только админов. Всё как положено при использовании этого ключа. Вся сложность с поиском источника проблемы была только с тем, что мы подошли к ней с неожиданной стороны — жалобы доступ к общей папке и принтерной очереди.
Я не знал о существовании этого ключа до того, как столкнулся с этой проблемой, но почитав о нём подробнее, выяснил, что он может послужить причиной самых разных проблем. Надеюсь изложенная информация поможет кому-то сэкономить время, при попадании в такую ситуацию.
Комментарии (28)
Dare
21.03.2016 08:20+1В своё время обнаружил внимательно читая доки по внеднению PCIDSS. Чтобы соответствовать, этот параметр должен быть включён политикой
gotch
21.03.2016 09:52+2Когда на синем экране написано большими белыми буквами "STOP: C0000244 {Audit Failed}" сложно не догадаться, что произошло.
gotch
21.03.2016 10:00+5Заодно можно открыть для себя, что у Windows есть политика безопасности, один из параметров которой отвечает за описанное вами поведение
https://technet.microsoft.com/en-us/library/cc963220.aspx
Тогда и гуглить ключи реестра не придется.Aivendil
21.03.2016 10:31+2Совершенно верно.
За давностью лет, я уже не помню почему, но у меня не было тогда информации о том, с какой ошибкой выпал BSOD. О том и речь, что иногда проблемы вызванные этим ключом прямо на него указывают, а тут получилось, что жалобы были именно на проблемы с доступом к общим ресурсам.
DanXai
21.03.2016 11:44Напомнило, как однажды долго искал ключ реестра, который отвечает за сохранение атрибутов ACL файлов при копировании в сетевую папку через Проводник.
darthslider
21.03.2016 13:53«А в новом безопасники решили выставить его в «1».» То есть либо безопасники решили, что так секурнее, не понимая, что именно делает ключ реестра, либо правая рука не знает, что делает левая.
Aivendil
21.03.2016 15:38Издержки производства. Безопасники, действительно, решили что так секьюрнее, а я не соотнёс пришедший в стек инцидент со списком из пары сотен изменений безопасности.
Но, так как проблема была решена, то, я думаю, нас можно простить:)darthslider
21.03.2016 16:01-1А за что читателям вас прощать? :) Для меня как раз эта история оказалась интересна именно тем, что один отдел делает, а у второго ломается.
foxmuldercp
21.03.2016 16:22«А в новом безопасники решили выставить его в «1».
Выглядит как "раздали права админа всем направо и налево".
В нормальной структуре — хоть ты СЕО, СIO и черт на куличках — права администрирования только у авторизованных администраторов.
Не вижу особых проблем выдать группе СБ права на чтение логов аудита — либо вижу еще вариант "админов" которые не могут нормально настроить политики доступа/групповые политики.darthslider
21.03.2016 16:24А я и не говорю, что я увидел что-то хорошее. Интересное — да, хорошее — нет.
Aivendil
21.03.2016 17:45Я видимо очень косноязычен. Никаких прав админа у них нет. Я имел ввиду, что они решили выставить этот ключ в "1", в ходе подготовки нового серверного билда. Т.е. все наши 2012 R2 сервера были настроенны именно так. Просто на 2003 и 2008 раньше настройка была иная.
И я, как часть серверной команды, коненчо же получил документ с перечнем всех изменений и настроек нового билда. К сожалению, я не смог сразу же прикинуть все возможные осоложнения и, получив этот инцидент, вспомнить что в новом билде как раз менялся один ключик реестра, который мог такое поведение вызвать:)
ildarz
22.03.2016 12:09Отсюда мораль — если сервер упал в синий экран, посмотрите логи. Там чистым языком локализации написано о причине падения. Тогда и ковыряться несколько часов не пришлось бы. Для меня просто поразительно, насколько часто люди начинают чесать репу и вопрошать гугл в ситуации, когда достаточно просто заглянуть в лог.
Aivendil
22.03.2016 12:24Да я виноват, что увидев в логах инцидента, что сервер несколько дней назад падал в BSOD не полез смотреть crash dump. Но кто из нас без греха? А вот об этом ключе реестра я до этого инцидента не знал.
Кстати, я не уверен, что прочитав в логах что сервер упал изза переполнения Security Log, и убедившись, что сейчас в логе есть место, я бы решил, что проблемы с общим доступом связаны именно с тем падением. Когда ответ уже известен, всегда понятно, где можно было увидеть подсказки. А вот когда я был в процессе решения проблемы, всё было не так очевидно:)
ildarz
22.03.2016 13:06Ну с одной стороны задним умом все крепки, тут не поспоришь. :) С другой — всё-таки хороший пример того, почему надо сразу досконально выяснять обстоятельства возникновения проблемы, а не искать решения по поверхностным симптомам.
И хорошо бы заодно это стало уроком вашим безопасникам — они часто радостно хлопают в ладоши, обнаружив настройки вида "остановить сервер при переполнении лога" или "заблокировать учетку через N попыток входа", не отдавая себе отчета, что лобовое применение таких ограничений создает отличные возможности для атак, начисто парализующих инфраструктуру.Aivendil
22.03.2016 13:21Это на самом деле спорный вопрос — кому там должен быть урок. Дело в том, что лог безопасности не должен переполняться. иначе это также открывает возможности для атак — переполнил лог, а потом вершишь тёмные дела. BSOD был вызван как раз тем, что был нарушен механизм очищения лога. Там использовался софт, который события из лога забирал и чистил.
Вся проблема возникла изза того, что в связи с появлением этой новой настройки мы не произвели одного важного действия, подняв сервер и почистив логи — не пеервели ключ реестра из этого заблокированного состояния обратно в режим ожидания ошибки.
Настройка то на самом деле не бесполезная.
ildarz
22.03.2016 13:47Степень полезности/вредности настроек в первую очередь зависит от того, насколько продуманно они делаются. Вот кто-то что-то настроил и сидит такой радуется, как у него всё безопасно и соответствует параграфу Х инструкции Y. А потом злобный хакер запускает в сети скриптик, циклически логинящийся с произвольными неверными учетными данными на ваши сервера, в секунды переполняет логи и нагло ржёт, глядя на то, как несколькими нажатиями клавиш он парализовал всю работу. :)
Вот что значит "лог не должен переполняться"? Если у вас отключена ротация, он обязательно переполнится, это только вопрос времени. Значит, за ним надо следить. В итоге настройка этого параметра автоматически требует дополнительного мониторинга событий в логе безопасности и объема этого лога, с соответствующими алертами и специально выделенными людьми, которые на эти алерты обучены быстро и адекватно реагировать. Мне не доводилось работать в местах, где это было бы реально оправданно, и не хватало бы включенной ротации логов с форвардингом событий на другой сервер и их обработкой. Хотя верю, что такие места существуют.
sirota
22.03.2016 12:30Если четсно я сам до сих пор поражаюсь этому феномену. Я даже не забиваю голову кодами ошибок. Случился fail, открыл дамп, посмотрел код, открыл гугл и все. Чего в этом зазорного? У меня есть знакомый он за каждой ошибкой звонит мне и я его каждый раз отправляю в гугл. Вы знаете, но до него за эти 3 года так и не дошло что надо сначала открыть гугл, а потом если не нашел ответа, то позвонить. А я у него вроде как ярлыка для google.com… Так и тут, искал не знаю что не знаю где, а ларчик был открыт всю дорогу. Тем более искать причину BSOD не видя самого BSOD…
Aivendil
22.03.2016 12:38Я не искал причину BSOD. BSOD был предыдущим инцидентом, закрытым два дня назад. Инженер который его смотрел, как позже выяснилось проверил причину, почистил лог безопасности, проверил, что сервер нормально поднялся (ну он же админ, так что для него принтера заработали) и закрыл инцидент. Это была штатная процедура обработки таких инцидентов для наших предыдущих серверных билдов (2003 и 2008).
Я искал почему один пользователь у которого effective permissions позволяют получить доступ к общему принтеру этот доступ имеет, а другой нет. Иногда если начать изучение проблемы с неправильного вопроса, можно пойти к ответу очень окольным путём. Что и иллюстрирует данная история.sirota
22.03.2016 13:02Вот тут и кроется Ваша проблема. Ведь пускать переставало именно после BSOD. Значит что-то перед ним случилось такое что увалило систему и что сейчас не пускает. Я понимаю если бы был 1 раз BSOD. Еще можно было бы как-то. Но у Вас подряд 2 BSOD и после ребута система не пускает. Я бы сразу задумался. А еще Вашему админу надо по шапке надавать. С какого такого великого разгона он чистит логи после BSOD?
FSA
Всё-таки у Windows-админа должен быть в инструментах шаманский бубен.
Cobolorum
Должен быть не бубен, а документация!
P.S. Если нет документации, то не должно быть глупых ограничений на ее создание.