Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Ok so I have been struggling with this plugin that binds to LDAP, and this is what I have figured out so far:

there are a two strings I can modify and send to the plugins .Search() method, one of them is the baseDN and the other is the filter.

So far the baseDN value that works properly looks like this: "DC=something,DC=something" and the value for filter looks like this: "objectClass=*".

This is all well and good and returns me back a tree of various items that look like this:

>DC=something,DC=something
-DC=admin
-CN=Builtin
-CN=Computers...

etc, and more things I don't understand, I am not sure exactly what I am seeing here but I am trying to look up a user and get his attributes.

What would I change the baseDN to or the filter to do this?

I tried this for the baseDN: "uid=username@domain.com" and it gave me an error, I also tried it like this "uid=username@domain.com,DC=something,DC=something" and it also gave me an error.

I think I am really confused though because I am able to browse through these tree of things but none of it looks like actual values they more look like definitions if you know what I mean, is there another layer of searching that must be done to get back user attributes?

share|improve this question

3 Answers 3

up vote 4 down vote accepted

That looks like AD. In LDAP-for-AD, the actual location of a user in the domain matters. For instance, take 'bobs' who lives in a specific Organizational Unit. His LDAP 'home' is:

CN=bobs,OU=Employees,DC=domain,DC=com

If you want to find 'bobs' in Employees:

Base:   OU=Employees,DC=domain,dc=com
Filter: (cn="bobs")

or if you want to find the User named 'bobs'

Filter: (&(objectClass=User)(cn="Bobs"))

Or if you just want to find "bobs" wherever the heck he is in AD:

Base:   DC=domain,DC=com
Filter: (&(objectClass=User)(cn="Bobs"))

One thing that makes LDAP filters hard to understand is that they use a prefix notation. You can see it in action in the complex filter above, where the ampersand precedes both of its operators. This can make for some very complex looking statements.


As for AD specifically, there are a couple of attributes you can use to search for users. "CN" may be either the account name or the 'Display Name' on the user. 'samAccountName' is the first 16 characters (I think) of the username, if your usernames never get that long it's a good choice for filtering.

share|improve this answer
    
woa nice, spot on, thanks –  ioSamurai Oct 30 '10 at 18:00

The filter should be (uid=username). There is no need to change the base DN from DC=something,DC=something, but, if you want, it should be the same as the user's DN (including OUs), but without the uid=username, bit.

share|improve this answer
    
OK great, this is what I have also been discovering, however my client says that I will be parsing user data in a TSQL like format, they said: "...to pull back the attributes, you would use a form of the SELECT FROM WHERE FILTER commands we discussed using the LDAP object as the basis for the search." Do you have any idea what he is talking about by chance? –  ioSamurai Oct 30 '10 at 17:27
    
None of those are valid in LDAP - I have no idea, I'm sorry. –  fahadsadah Oct 30 '10 at 17:40

Try reading LDAP for Rocket Scientists as an introduction to LDAP.

share|improve this answer
    
thanks for the resource I'll add it to my arsenal, here, have an upvote –  ioSamurai Oct 30 '10 at 17:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.