Вопрос о блокировке учётной записи
С одной стороны, временная блокировка (минут на 15) учётной записи при 100+ попытках подбора пароля - правильное решение. Особенно для пользователей, у которых таки может оказаться "нехороший" пароль.
С другой стороны, в условиях спамящего запросами паразита можно оказаться в условиях, когда даже администратору не зайти на компьютер.
Варианты решения проблемы:
1) Поднять поддомен в том же дереве (например, adm.domain.ru) в виртуальной машине и завести резервную учётную запись администратора там. Настроить доверительные отношения, дать этому "чужеродному" администратору права на администрирование основного домена. DC выключить (при этом авторизация прокатит? если нет - смысла нет). Не забыть про tompstone.
2) Создать отдельный OU для доверенных учётных записей (учётных записей, у которых хорошие пароли точно) и enforce'нуть групповую политику с отсутствием ограничений на число попыток обращения.
3) Попытаться сделать узел (Site) для админской машины с особыми групповыми политиками. Тут я в сомнениях, так как узлы (и назначенные на них групповые политики) вроде бы, работают только на компьютеры, т.е. групповая политика с разрешениями ничего толком не даст - зайти на свою машину я смогу, а вот дальше - нет, так как область действия групповой политики - узел.
Склоняюсь к эксперименту с 1, но по сути - к варианту 2.
Уточнение идеи: контроллер "резервного" домена в виртуальной машине, с настроенными фильтрами таким образом, чтобы взаимодействовать только с контроллерами основного домена. Таким образом у нас будет возможность авторизоваться с учётной записью резервного домена на любой машине в домене (т.к. GC будет содержать данные, достаточные для идентификации/авторизации). Однако, энумерация (как по-русски, кстати?) записей через LDAP будет сильно затруднена - это не доменная учётная запись, это посторонний домен, контроллер которого с заражённой машиной (и/или машиной злоумышленника) просто не будет разговаривать.
Решено. Точно.
С другой стороны, в условиях спамящего запросами паразита можно оказаться в условиях, когда даже администратору не зайти на компьютер.
Варианты решения проблемы:
1) Поднять поддомен в том же дереве (например, adm.domain.ru) в виртуальной машине и завести резервную учётную запись администратора там. Настроить доверительные отношения, дать этому "чужеродному" администратору права на администрирование основного домена. DC выключить (при этом авторизация прокатит? если нет - смысла нет). Не забыть про tompstone.
2) Создать отдельный OU для доверенных учётных записей (учётных записей, у которых хорошие пароли точно) и enforce'нуть групповую политику с отсутствием ограничений на число попыток обращения.
3) Попытаться сделать узел (Site) для админской машины с особыми групповыми политиками. Тут я в сомнениях, так как узлы (и назначенные на них групповые политики) вроде бы, работают только на компьютеры, т.е. групповая политика с разрешениями ничего толком не даст - зайти на свою машину я смогу, а вот дальше - нет, так как область действия групповой политики - узел.
Склоняюсь к эксперименту с 1, но по сути - к варианту 2.
Уточнение идеи: контроллер "резервного" домена в виртуальной машине, с настроенными фильтрами таким образом, чтобы взаимодействовать только с контроллерами основного домена. Таким образом у нас будет возможность авторизоваться с учётной записью резервного домена на любой машине в домене (т.к. GC будет содержать данные, достаточные для идентификации/авторизации). Однако, энумерация (как по-русски, кстати?) записей через LDAP будет сильно затруднена - это не доменная учётная запись, это посторонний домен, контроллер которого с заражённой машиной (и/или машиной злоумышленника) просто не будет разговаривать.
Решено. Точно.