Active Directory Password Validation (that won't lock out account)

[cerebalbore]

Hi,

I'm trying to learn VB.NET, using Visual Studio 2005, and I need to build an application for users to log in to that works with the Active Directory (so that my database doesn't need to store passwords, and users can use their XP passwords). I've searched the forums and found some code here and there, which has been very useful, but none of the threads seem to answer my question.

The problem I have is that I don't want a users XP account to be locked out if they enter their password incorrectly once (or more), just to not let them use this application, and none of the code I've found is explicit to this fact. I don't want to know what the password stored/encrypted in the AD is.

So, here's the code I used (thanks must go to CSutton, I've only changed bits to make it like other code I have, and variable oPath is the domain pulled from an earlier query, which works ok):

Dim Success As Boolean = False

Dim Entry As New System.DirectoryServices.DirectoryEntry(oPath)
Entry.Username = Username
Entry.Password = Password


Dim Searcher As New System.DirectoryServices.DirectorySearcher(Entry)
Searcher.SearchScope = SearchScope.Subtree
Try
Dim Results As System.DirectoryServices.SearchResult
Results = Searcher.FindOne
Success = Not (Results Is Nothing)
Catch ex As Exception
Success = False
End Try

Return Success

My question is "If a user enters their password incorrectly does this mean that the user could eventually be locked out of their XP account?"
(I don't want to do any more testing as our IT dept has already had to unlock my account several times this morning because I wanted to know what would happen with an incorrect password!)

Anyone have the answer to this?

Thank you

Kat


I'm such a noob

 

[Sorwen]

Generally if the network is setup right the active directory should be tied directly to the windows login and not through your program. Then you just check the currently login user to the machine. You don't have to check their password directly.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[cerebalbore]

In our environment, we have more users than PCs on the shop floor, so more often than not, the user who is logged into the PC may not be the person using the application, so I can't rely on that information.

I only really need to know if the code I posted above will lock a users account if they attempt to login with an incorrect password, and how many attempt this will give (I'm guessing three as that's the standard when attempting to log into XP here).

And if it will, what can I do to prevent it?



I'm such a noob

 

[PRPhx]

And it may also be the company or IT department's policy that X number of invalid login attempts locks the user account. It's a security issue.

 

[cerebalbore]

Yes, three attempts with an incorrect password locks the user out of their XP account here, but I'm not interested in the security of the XP account, only whether the passwords are the same. For simplicity we want the password for this application to match the one for the XP account. This means we don't have to store and manage passwords in our own database, and users don't have to remember yet another password).

Maybe I need to ask a different question.

Is there a way to check that the password entered on my login form matches that in the AD, without any impact on their XP account if the password entered on the login form is different to the one in the AD??


I'm such a noob

 

[Sorwen]

No, there isn't. The whole point is to keep the password secure. If you could then a person could just do brute force attack on the password to figure out what it is. That is why systems usually go with a limited number of tries. If you could bypass that security regulation what would be the point of having it in the first place?

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[cerebalbore]

Ok, I already have an application that does just the thing I'm describing here. It's intriguing me to find out what it does - it's a shame we bought it from a vendor, but could it be that the vendors sold us un-secured piece software?? Might try and break my admin account to see if it does anything sensible.

Thanks anyway Sorwen. Might end up just going with what I have. Though I don't see it as being the most elegant solution to the issue, I can't be held responsible if people don't know their own passwords. You can only do so much to make applications idiot proof (short of taking their keyboards away).

The helpdesk are going to love this one - ha ha.



I'm such a noob

 

[Sorwen]

Hmmm....New one on me. I have no clue how it could work and test the password. Highly unsecure. Think of it like this if it was from an unscrupulous company the program if it wanted could hit with incorrect passwords until the correct one is sent then transmit that correct password. What is even worse about that is if there is a company exchange server the Active Directory would generally contain all of that users email identity information so it could send out an email as that user possibly bypassing other security measures.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[cerebalbore]

So this morning I try to log in to my application with my admin account, twice, putting in an incorrect password each time. Now oddly, the account I'm logged into the PC with is completely different to the account I'm testing the application with, but the code locked my normal account anyway. Wierd.

I don't think I'm going to solve this anytime soon.


I'm such a noob