System.DirectoryServices.AccountManagement and error messages from LDAP vs LDAPS

I have some C# code using System.DirectoryServices.AccountManagement that is used to allow a user to change their Active Directory user account password. It is currently using LDAP (:389) and I wanted to switch it to LDAPS (:636) for security purposes. However, when I switch to LDAPS the error messages returned to me change and become less useful.

Here is the problem in a nutshell:

If I connect using LDAP (:389) I use the following ConextOptions

ContextOptions.Negotiate | ContextOptions.ServerBind | ContextOptions.Signing

If I connect using LDAPS (:636) I use the following ContextOptions

ContextOptions.Negotiate | ContextOptions.ServerBind | ContextOptions.SecureSocketLayer

Either version works to change passwords if the user supplies the correct current password and a valid new password. However, in the case for example that the user enters an incorrect current password, the error message I receive back are different and less useful in the case of LDAPS:

LDAP(:389) :

The specified network password is not correct. (Exception from HRESULT: 0x80070056)

LDAPS(:636) :

A constraint violation occurred. (Exception from HRESULT: 0x8007202F)

The key to the difference appears to be ContextOptions.Signing - if I do not specify that for the LDAP(:389) connection I get the same error messages as with LDAPS(:636). However, if I specify ContextOptions.Signing for the LDAPS the DC refuses to respond.

• Is there a way I can use ContextOptions.Signing when using LDAPS?
• Is there any other way to get the more meaningful error messages without using ContextOptions.Signing?
• ContextOptions.Sealing says it encrypts the data using Kerberos - can I use this option on :389 to get the same level of security as using LDAPS? The documentation is sparse on details

Based on this article, it seems that's just the best you will get with LDAPS: https://blogs.msdn.microsoft.com/dsadsi/2012/06/06/changepassword-and-password-complexity-violation-error-codes/

To work around this, you could do some verifications before actually performing the password change, such as:

• Authenticate the account with the current password given to see if it's correct
• Look up the password policies to verify:
  • New password complexity
  • Minimum age of existing password (check the password last changed attribute)

It's a pain, but if you do all those checks beforehand, you can give your users much more descriptive error messages.

Although you won't be able to verify that the new password has not been used before.