I am having issue in the user authentication with his credentials(LogonUserName , password).
My Issue :
AD will accept the last two password in the user authentication . But If I try the authentication using the previous password in the client live machine , it won't accept(accept only current password).
First, on what do you base the statement "AD will accept the last two password in the user authentication using the unboundId sdk"? Most directory servers only recognize one password for a user, and I'm not aware of any feature in Active Directory that would cause it to behave differently (although I am certainly not an Active Directory expert, and this is definitely not the correct forum for advice specific to Active Directory). Nor should the LDAP API that you use to interact with the server make any difference because ultimately all LDAPv3-compliant APIs should end up generating the same request.
It also doesn't really help for you to provide sample code if you don't provide any indication of what happens when you try to run it, or any context for the parameters you're providing. Is "password@1234" the current password for the user, or is it the previous password that you nonetheless expect to work for some reason? And since you suggest that it doesn't work, then I assume you're getting an exception, but without providing any information about that exception then it's really not possible to make any determination about the reason for the failure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am resetting my password as password@123 . Now I check the authentication with my credential as password@123 . Now my authentication will get success.
Again I am resetting my password as password@12345 . Now I check the authentication with my credential as password@12345 . Now also my authentication will get success.
But this time , I check the authentication with my credential as password@123 (But my current password is password@12345) . Now also my authentication will get success. I don't know why ?
Also If I give any wrong password , I will get exception except these password@123 and password@12345 .
I am using the above code for user Authentication.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know a lot about Active Directory, but I know that at least at one time, Windows used a really stupid mechanism for hashing passwords that only looked at the first seven or eight characters of your password. It's possible that Active Directory has continued this horrible tradition and since the passwords you are using start with the same characters then that's what's going on. To test that, you could see if you can authenticate with a password of "password@123thishasneverbeenmypassword". If that works, then Windows is stupid and broken and insecure.
But at any rate, this isn't in any way related to your use of the UnboundID LDAP SDK. I would expect any other API to exhibit exactly the same behavior. This is a problem in Active Directory and you should work with Microsoft to figure out how to address the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having issue in the user authentication with his credentials(LogonUserName , password).
My Issue :
Here is my code ,
Hope I will get a good solution.
Last edit: anand 2014-07-03
I'm not really clear on your question.
First, on what do you base the statement "AD will accept the last two password in the user authentication using the unboundId sdk"? Most directory servers only recognize one password for a user, and I'm not aware of any feature in Active Directory that would cause it to behave differently (although I am certainly not an Active Directory expert, and this is definitely not the correct forum for advice specific to Active Directory). Nor should the LDAP API that you use to interact with the server make any difference because ultimately all LDAPv3-compliant APIs should end up generating the same request.
It also doesn't really help for you to provide sample code if you don't provide any indication of what happens when you try to run it, or any context for the parameters you're providing. Is "password@1234" the current password for the user, or is it the previous password that you nonetheless expect to work for some reason? And since you suggest that it doesn't work, then I assume you're getting an exception, but without providing any information about that exception then it's really not possible to make any determination about the reason for the failure.
I will explain you clearly.
I am resetting my password as password@123 . Now I check the authentication with my credential as password@123 . Now my authentication will get success.
Again I am resetting my password as password@12345 . Now I check the authentication with my credential as password@12345 . Now also my authentication will get success.
But this time , I check the authentication with my credential as password@123 (But my current password is password@12345) . Now also my authentication will get success. I don't know why ?
Also If I give any wrong password , I will get exception except these password@123 and password@12345 .
I am using the above code for user Authentication.
I don't know a lot about Active Directory, but I know that at least at one time, Windows used a really stupid mechanism for hashing passwords that only looked at the first seven or eight characters of your password. It's possible that Active Directory has continued this horrible tradition and since the passwords you are using start with the same characters then that's what's going on. To test that, you could see if you can authenticate with a password of "password@123thishasneverbeenmypassword". If that works, then Windows is stupid and broken and insecure.
But at any rate, this isn't in any way related to your use of the UnboundID LDAP SDK. I would expect any other API to exhibit exactly the same behavior. This is a problem in Active Directory and you should work with Microsoft to figure out how to address the problem.