На некоторых серверах Windows я хотел бы установить разную сложность пароля в зависимости, например, от длины пароля. Можно ли создать условия, чтобы я мог иметь высокий уровень сложности с длиной пароля = 8 и низкий уровень сложности или его отсутствие с длиной пароля = 16 или более.
спасибо за советы.
Можно написать свой собственный код для критериев пароля. DLL можно зарегистрировать на рядовых компьютерах или контроллерах домена.
Это не сработает, если включена «Дополнительная защита LSA», поскольку для этого требуется, чтобы библиотеки DLL LSA были подписаны Microsoft.
Как уже указывалось, можно использовать настраиваемый фильтр паролей с использованием passfilt.dll. Фактически, я использую один такой фильтр (или одну из его вилок), доступный на GitHub. Это называется OpenPasswordFilter. Я решил использовать этот фильтр, потому что документация для системных администраторов о том, как создать собственный фильтр паролей и управлять им, скудна. Хотя я обычно видел, что это используется для настройки черного списка паролей, можно выполнить проверку того, о чем вы спрашиваете. Возникает вопрос, насколько сложно это сделать с помощью настраиваемого фильтра паролей?
Однако эти изменения необходимо внедрить на каждый контроллер домена и каждый новый контроллер домена. Учитывая сегодняшний уровень автоматизации и управления конфигурацией, это, вероятно, не очень сложно, но это еще что-то, что нужно контролировать и поддерживать.
В общем, это прекрасное решение, но с ограниченной документацией. У вашего преемника также могут быть трудности с поддержкой, обновлением и расширением этого решения - фактор, который следует учитывать при принятии решения о его внедрении.
Я считаю, что наиболее простым решением вашего вопроса является использование детальных политик паролей. Это может быть реализовано очень быстро с минимальным тестированием; эти настройки автоматически копируются между всеми контроллерами домена. Обратная сторона; однако это то, что для этого требуется участие / выборы конечного пользователя.
Мое решение было бы следующим:
Некоторые примечания к вышеизложенному или другие соображения:
Вы можете добиться того же с одной группой. Я предпочитаю использовать два параметра видимости, но, убедившись, что политика паролей домена по умолчанию настроена с минимальной длиной 8 и включенной сложностью, вы ограничиваете количество изменений в группе, которые необходимо внести. - вам нужно добавлять пользователей в группу, только если они делают выборы - вам не нужно гарантировать, что пользователи являются членами только одной группы, или - вам не нужно настраивать разные значения предшествования для каждого FGPP
Хотя я работаю в NIST и Microsoft (по большей части), когда дело доходит до ротации паролей, мой работодатель по-прежнему требует ротации паролей. Я решил «вознаграждать» пользователей, которые принимают более длинные минимальные пароли, путем ротации паролей только один раз в год. Те, у кого более короткие требования к паролю, «наказываются» ежеквартальной сменой пароля. На мой взгляд, это слишком часто, чтобы быть полезным, но я надеюсь, что это раздражение дает пользователям достаточный стимул переходить на более длинные минимальные пароли.
Хотя это не отмечено выше, если вы действительно используете FGPP таким образом, я бы определенно настроил другой приоритет для каждого из параметров настройки пароля, чтобы гарантировать отсутствие неожиданного поведения при изменении паролей. Это решило бы проблему, с которой можно было бы столкнуться, если бы они были членами обеих групп, и прецедент на обоих ГСВ был равным.
Независимо от того, какой метод вы выберете, я хотел бы указать, что вы должны обязательно исключить учетную запись «krbtgt» из любых подобных проверок сложности пароля. У меня есть отдельный FGPP для этой учетной записи и аналогичных учетных записей, используемых контроллерами домена только для чтения, чтобы гарантировать, что изменение их паролей не затронет. В моем krbtgt FGPP нет требований к длине, возрасту или сложности.