Active Directory storage question

[JoeCDaMan]

I am trying to authenticate a user against active directory using LDAP. We are having problems that I would rather not go into. One question I do have is where does active directory store the password for a users login? and what method of encryption does it use? One thought was if the password was encrypted using md5 that we could duplicate the hashing and compare the two results.

Thanks in advance.

 

[spyordie007]

The passwords are not stored using MD5 (thank god). Besides giving an app that level of access to your domain is generally pretty bad security practice.

LDAP authentication is definitely the way to do it and it is very common.

I realize you were trying to avoid it, but what are you trying to authenticate against the domain with and for what purpose? It's much easier to give you a good answer if we have good information.

 

[JoeCDaMan]

Well I don't mean to be vague but I'm not sure how much information I want to divulge about the situation for security reasons.

Let me see if I can give you a better expanation of what specifically we are having a problem with. I am work with a 3rd party development team to try to authenticate against their active directory using LDAP on a .net web app that my company wrote. We have gotten this to work many times with other clients and there's plenty of documentation off the net so its really not that big of a deal.

The situation is that this particular active directory is organized a little bit differently than others we've seen in the past and we can only authenticate a few users that pertain to an IT usergroup. Basically instead of having one Users group, here they broke it up into multiple roles. Although we have run into similar situations in the past and have been able to overcome them. This one is really got us stumped and we have come to the conclusion that perhaps we could get around this program by hashing the users password and then comparing it to whatever ActiveDirectory has stored.

Sorry about the description.

Hope that helps a little bit more about what's going on

 

[JoeCDaMan]

Ok, I found out what hash is being used. Does anyone know where the information is being stored?

 

[spyordie007]

I've never tried to access it before but I believe it's under the "user" class stored as "user-password." I also have no idea how you would go about setting up access to it with a web app.

I dont know much about your application or their security model but it still seems like it would be easier to do this with LDAP queries.

Whatever the case may be good luck,

-Erik

 

[stash]

I'm not seeing how the user's password hash would help you here...Your app can only auth users in one group, not users in multiple groups?

I'm confused.

 

[JoeCDaMan]

I thought I would give you an update of the work around that decided to take. Unfortunately as stated before we were unable to figure out why we couldn't authenticate users w/ LDAP against their particular AD setup. Due to the excessive time and impracticality of replicating the hashed passwords of the user and comparing it to the hashed password located in the SAM file we decided to try another way for authentication. We proceeded to go into IIS and for that particular virtual directory which we want to limit access to, we turned off anonymous login and forced a user to login with integrated windows authentication which will authenticate you against the active directory domain, which is what we wanted to do in the first place. It's not as pretty as the login page we designed, but it will certainly do.

 

[stash]

Unfortunately as stated before we were unable to figure out why we couldn't authenticate users w/ LDAP against their particular AD setup

Auditing logon failures probably would help out a lot here...

Due to the excessive time and impracticality of replicating the hashed passwords of the user and comparing it to the hashed password located in the SAM file we decided to try another way for authentication.

AD domains don't use a SAM file...

We proceeded to go into IIS and for that particular virtual directory which we want to limit access to, we turned off anonymous login and forced a user to login with integrated windows authentication which will authenticate you against the active directory domain, which is what we wanted to do in the first place.

Sounds like you need to check your app's code. If integrated auth works, it would seem your auth code is faulty. Again, auditing will help you troubleshoot.

 

[spyordie007]

I agree with Stash on this.

If IIS can authenticate you but your app cannot it probably means something is up with your app.

 

[JoeCDaMan]

Well maybe you can provide some additional information about AD and where it stores it's account information. I have been trying to dig around and find some information but everyone seems to be tight lipped about it unless I'm just not looking in the right spaces.

Our app orriginally used LDAP to connect with AD. I don't really think that there is anything wrong with our code, but I believe we are trying to bind to the wrong DN. I have my suspicions that their AD is setup in a wierd fashion as well because as I said before we are only able to authenticate 3 users and they all belong to the same group. if we drag and drop another user into that group then we can authenticate the new person, but if we return them to their orriginal group then they we are denied again. If you are familiar with LDAP then you know that the actual code is pretty minimal and fairly straight forward for a simple authentication like we are trying to achieve.

 

[spyordie007]

Well maybe you can provide some additional information about AD and where it stores it's account information.

When performing an LDAP query this information is largly irrelivent.

I have my suspicions that their AD is setup in a wierd fashion as well because as I said before we are only able to authenticate 3 users and they all belong to the same group. if we drag and drop another user into that group then we can authenticate the new person, but if we return them to their orriginal group then they we are denied again.

but I believe we are trying to bind to the wrong DN.

Unless you've got your DN drilled down to an OU that only these users are in you probably have it set right. Typically I'll point the DN at the lowest reasonable level for the query to search through; if this is a small domain that might be the top level.

If you are familiar with LDAP then you know that the actual code is pretty minimal and fairly straight forward for a simple authentication like we are trying to achieve.

I dont know what language you're writing your app in but I've done LDAP binds/queries from CFM and PHP. Perhaps you could post this portion of your code (as there wouldnt really be a security concern for that) so we can review?

 

[stash]

I have my suspicions that their AD is setup in a wierd fashion as well because as I said before we are only able to authenticate 3 users and they all belong to the same group. if we drag and drop another user into that group then we can authenticate the new person, but if we return them to their orriginal group then they we are denied again.

Maybe I'm missing something, but it sounds like your app is coded to query a single specific group, like cn=groupname,ou=blah,dc=domain,dc=com.

You should just query ou=blah,dc=domain,dc=com

That's my WAG anyway, without seeing the code.

 

[Woodie]

Well, now that you've solved your problem, by correctly using the built-in authentication.... here's how we've implemented LDAP authentication to AD in several places.

Do a null LDAP query...that is, a query which will ALWAYS return a known valid response. Code your application to treat this response as a "Successful Logon", and go on your merry way. Anything else, and you fail the logon.

The trick is:
Make the LDAP query an authenticated- bind, using the credentrials submitted by the end user the credentials you pass as the LDAP credentials to do the query, not as the subject of the query.

Pros:
Easy to code
Easy to test

Cons:
Will not capture different types of authentication failures (password expired, password needs to be changed, restricted logons, etc...)

(for clarity)
Old way: LDAP query (AD-Domain Controller, UserID, Password) - To the Domain Controller, is the password for the UserID the same as Password?

New way: LDAP query (AD-Domain Controller, Group, Users) <USERID,Password> - To the Domain Controller, Logon with USERID,Password, and tell me if the Group "Users" exists.

 

[JoeCDaMan]

ok, I'll try to post up some code, it might take me a day or so though because the code is residing on a 3rd party server, so I'll try to post it tomorrow asap

Thanks for all your input though

 

[spyordie007]

Make the LDAP query an authenticated- bind, using the credentrials submitted by the end user the credentials you pass as the LDAP credentials to do the query, not as the subject of the query.

:thumbsup:

I've done this in a couple of places and it works quite well. Nice and simple (just the way I like it).