#c# #asp.net-mvc #active-directory
#c# #asp.net-mvc #active-directory
Вопрос:
Я создаю ASP.NET Веб-сайт MVC, использующий C #, который позволит пользователю создать учетную запись AD через веб-страницу интерфейса. Идея заключается в том, что вы вводите соответствующие данные во внешнем интерфейсе, нажимаете отправить, а затем я создаю учетную запись AD за кулисами с помощью C #, используя введенные вами данные.
Теперь, если на сервере AD установлены определенные политики паролей (т. Е. Длина, сложность и т.д.), Можно ли в любом случае заставить интерфейс использовать эти политики напрямую, а не пытаться воссоздать их с помощью регулярных выражений и т.д.?
Причина в том, что при последующем изменении политики AD, если они не связаны, интерфейс не синхронизирован и его также необходимо изменить.
Я не очень хорошо знаком с AD, но, возможно, существует какой-нибудь объект политики паролей или аналогичный, который я могу использовать для проверки сведений о пароле (подойдет даже серверная часть).
Существует ли такая вещь, а если нет, то как люди рекомендуют обходить проблему несинхронизации?
Ответ №1:
Ответ заключается в том, что просто не внедряйте политики в свой интерфейс вообще.
AD сообщит вам, если введенные пользователем данные не соответствуют политике паролей, с помощью кодов ошибок, которые вы можете обработать и представить пользователю в удобном виде.
Вы не хотите дублировать процессы. Процесс проверки соответствия политике паролей выполняется контроллером домена и должен оставаться там.
Комментарии:
1. Я понимаю вашу точку зрения, но в моем конкретном случае перед созданием учетной записи AD произойдет еще несколько событий, которые будут скрыты. Я ожидаю плохого взаимодействия с пользователем, если после ожидания выполнения этих других действий вам только тогда скажут, что ваш пароль должен быть длиннее. Обычно эта обратная связь возникает еще до того, как вы сможете отправить форму.
2. @FullTimeSkeleton изменяет порядок процессов? В конце концов, если другие процессы полагаются на созданного пользователя или связаны с ним, вам все равно следует сделать это первым, поскольку существует множество других причин, по которым пользователь может не быть создан. Возможно, имя уже существует, возможно, dc недоступен, возможно, кто-то переместил ваше целевое подразделение, возможно, домен находится в режиме только для чтения или у него закончились sid.
3. Достаточно справедливо. На данный момент предлагается сначала создать другой объект, а затем создать учетную запись AD с данными из этого ранее созданного объекта. Технически мы могли бы изменить это и сначала создать учетную запись AD. Спасибо за предложение. Результатом этого является то, что, похоже, нет способа запросить политику паролей AD отдельно от создания учетной записи. Для меня это не идеально, но если это единственный способ, то это единственный способ.
4. @FullTimeSkeleton Единственным «способом» было бы проанализировать XML-файлы групповой политики в папке sysvol, но даже тогда вам нужно было бы знать, как / где они применяются для разработки любых переопределяющих настроек и т. Д
5. И этот способ звучит неаккуратно, поэтому не похоже, что я могу сделать это, не полагаясь на отзывы AD. Спасибо, я отмечу это как ответ.