System.DirectoryServices.AccountManagement и сообщения об ошибках от LDAP vs LDAPS

Question

У меня есть код C# с использованием System.DirectoryServices.AccountManagement, который позволяет пользователю изменять пароль учетной записи пользователя Active Directory. В настоящее время он использует LDAP (: 389), и я хотел переключить его на LDAPS (: 636) для целей безопасности. Однако, когда я переключаюсь на LDAPS, сообщения об ошибках, возвращаемые мне, меняются и становятся менее полезными.

Вот проблема в двух словах:

Если я связываю с помощью LDAP (: 389) Я использую следующие ConextOptions

ContextOptions.Negotiate | ContextOptions.ServerBind | ContextOptions.Signing 

Если я связываю с использованием LDAPS (636) Я использую следующие ContextOptions

ContextOptions.Negotiate | ContextOptions.ServerBind | ContextOptions.SecureSocketLayer 

Либо версия работает для изменения паролей, если пользователь подает правильный текущий пароль и действующий новый пароль. Тем не менее, в случае, например, что пользователь вводит неверный текущий пароль, сообщение об ошибке я получаю обратно различны и менее полезны в случае LDAPS:

LDAP (: 389):

указанный сетевой пароль неверен. (Исключение из HRESULT: 0x80070056)

LDAPS (: 636):

произошло нарушение ограничения. (Исключение из HRESULT: 0x8007202F)

Ключ к различию, как представляется, ContextOptions.Signing - если я не указано, что для LDAP (: 389) связи я получаю те же сообщения об ошибках с LDAPS (636) , Однако, если я укажу ContextOptions.Signing для LDAPS, DC отказывается отвечать.

• Есть ли способ, которым я могу использовать ContextOptions.Signing при использовании LDAPS?
• Есть ли другой способ получить более значимые сообщения об ошибках без использования ContextOptions.Signing?
• ContextOptions.Sealing говорит, что он шифрует данные с помощью Kerberos - могу ли я использовать эту опцию: 389, чтобы получить тот же уровень безопасности, что и при использовании LDAPS?Документация скудны на деталях

Answer 1

На основании этой статьи, кажется, что это просто лучшее, что вы получите с LDAPS: https://blogs.msdn.microsoft.com/dsadsi/2012/06/06/changepassword-and-password-complexity-violation-error-codes/

Чтобы обойти эту проблему, вы могли бы сделать некоторые проверки, прежде чем на самом деле выполняет изменение пароля , такие как:

• Аутентифицировать счет с текущим паролем данным, чтобы увидеть, если это правильно
• Посмотрите политику паролей для проверки:
  • Новая сложность пароля
  • Минимальный возраст существующий пароль (проверьте пароль последнего изменения атрибутов)

Это боль, но если вы делаете все эти проверки заранее, вы можете дать вашим пользователям гораздо более описательные сообщения об ошибках.

Хотя вы не сможете проверить, что новый пароль еще не использовался.