Explanation of PrincipalContext.ValidateCredentials behaviour over LDAPS

Question

Hi,

I am using PrincipalContext.ValidateCredentials(string, string) to validate user credentials.  I am encountering behaviour that I am unable to explain and have, so far, been unable to clarify through usual searches and forum visits.  Here is the behaviour, the  credentials can be assumed to be correct on each call. The non-SSL behaviour is what I would expect.  The SSL behaviour is not as expected in my understanding of the method.

Not using SSL/TLS

• User is enabled and NOT expired - method returns TRUE
• User is disabled and NOT expired - method returns FALSE
• User is enabled and EXPIRED - method returns FALSE
• User is disabled and EXPIRED - Method returns FALSE

Using SSL/TLS

• User is enabled and NOT expired - method returns TRUE
• User is disabled and NOT expired - method returns FALSE
• User is enabled and EXPIRED - method returns TRUE
• User is disabled and EXPIRED - Method returns FALSE

To summarise - when both machines in the negotiation (app server and domain controller) have the required certs installed, they will use SSL (port 636).  In these circumstances the method returns TRUE for Expired accounts but when not using SSL (port 389) (for example the app server does not have the cert installed) the method is returning FALSE for Expired accounts.

I would expect the return value to be the same for expired accounts in both scenarios, but it's possible I'm not considering something.

Thanks

Answer 1

Hi Chris,

>>To summarise - when both machines in the negotiation (app server and domain controller) have the required certs installed, they will use SSL (port 636).  In these circumstances the method returns TRUE for Expired accounts but when not using SSL (port 389) (for example the app server does not have the cert installed) the method is returning FALSE for Expired accounts.

How about the reslut if you don't have the cert installed using SSL/TLS?

PrincipalContext.ValidateCredentials Method (String, String)

Remarks

---

The ValidateCredentials method binds to the server specified in the constructor. If the username and password parameters are null, the credentials specified in the constructor are validated. If no credential were specified in the constructor, and the username and password parameters are null, this method validates the default credentials for the current principal.

Please check above message from MSDN, per my understanding, if the username and password parameters are null, this method validates the default credentials for the current principal. No matter what kind of these users,the default credentials for the current principal will return true.

Best regards,

Kristin

---

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click HERE to participate the survey.

Answer 2

Hi Kristin, appreciate your response.

>> How about the result if you don't have the cert installed using SSL/TLS?

In this case it defaults to non SSL/TLS and I get the expected result listed in the first table above, i.e., the method returns FALSE for expired account.  I'm assuming the method fails in negotiating SSL handshake, drops to the next preferred ContextOption and goes over PORT 389 using NTLM (not 100% sure as I'm a dev not a network guy). 

>>Please check above message from MSDN, per my understanding, if the username and password parameters are null, this method validates the default credentials for the current principal. No matter what kind of these users,the default credentials for the current principal will return true.

I'm 100% sure that NULL is not being passed in the parameters, sorry if I wasn't clear, I tried to state that as an assumption for all scenarios listed above.

The crux of the issue is that when using SSL the .net method returns TRUE for expired accounts.  This would be ok (I'd just assume that it's only validating the username and pwd) if it wasn't for the fact that it returns FALSE when not using SSL and FALSE when using SSL and the account is disabled.  Basically - it's inconsistent and so hard to validate.

The network trace shows successful SSL handshake and encrypted data is sent back from AD to the application, it's just that when it gets this SSL-encrypted data back, the ValidateCredentials method returns TRUE for expired accounts.  The really confusing thing is this: ok, let's assume it's some kind of bug in the method, but if I disable the same account then the method starts returning FALSE (expected) so it doesn't look like it's having a problem with SSL, per se, just SSL and expired accounts!!

I haven't had our hosting team decrypt this traffic yet as I think it's a complex process and I don't think it's necessary until I have clarified what the "expected behaviour" is from Microsoft's perspective.  If you think this might be a bug that's fine, I can enter in Connect.  This is happening in our production environment across a large number of web servers.  We are working-around it by blocking port 636 for the specific segments/domains.  I have entered a defect against our application to perform further, specific, validations on the user accounts (such as specific check on enabled status and expiry dates) but I would like to know for sure how this method behaves so we can include it in the code in a reliable way (or not include it if required!).

Thanks again, apologies for the lengthy response.

Chris

Answer 3

Hi Chris,

Thank you for such a detailed explanation.

Now from my side, I also cannot figure it out. I suspect it's a product issue and I would recommend you submit a feedback in http://connect.microsoft.com. Thanks for your understanding.

In addition, I would suggest you also provide a simplified demo to add as attachment. If you finish submit, please remember to post your link here, I will help you vote it. Thanks.

Best regards,

Kristin

---

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click HERE to participate the survey.

Answer 4

Thanks Kristin!

Feedback submitted on Connect at url https://connect.microsoft.com/VisualStudio/feedback/details/2673750

Regards