python-ldap: searching without specifying an OU?

[hotani]

I am attempting to pull info from an LDAP server (Active Directory),
but cannot specify an OU. In other words, I need to search users in
all OU's, not a specific one.

Here is what works:

con = ldap.initialize("ldap://server.local")
con.simple_bind_s('user@domain', pass)
result = con.search_ext_s(
'OU=some office, DC=server, DC=local',
ldap.SCOPE_SUBTREE,
"sAMAccountName=username", ['mail']
)[0][1]

for i in result:
print "%s = %s" (i, result)

But i really need it to not require an OU. When I remove that part, it
breaks. Or it just won't find the user. Is there a proper syntax for
this that I'm missing? Maybe a different search function?

 

[Michael Ströder]

I am attempting to pull info from an LDAP server (Active Directory),
but cannot specify an OU. In other words, I need to search users in
all OU's, not a specific one.

If the user you're binding with has the right in AD to search the whole
subtree you can start searching at the domain-level.

con = ldap.initialize("ldap://server.local")
con.simple_bind_s('user@domain', pass)

^^^^^^^^^^^^
Just for the records: A simple bind with userPrincipalName only works on
AD. It's not a LDAPv3 compliant bind request then (which requires a full
DN).

result = con.search_ext_s(
'OU=some office, DC=server, DC=local',
ldap.SCOPE_SUBTREE,
"sAMAccountName=username", ['mail']
)[0][1]

for i in result:
print "%s = %s" (i, result)

But i really need it to not require an OU.

It should work. I'm doing this quite often.

When I remove that part, it breaks.

What does "it breaks" mean? Any exception raised by python-ldap?

Maybe a different search function?

Nope.

Ciao, Michael.

 

[hotani]

Thanks for the response. The user I'm connecting as should have full
access but I'll double check tomorrow.


This is the LDAP error that is returned when I leave out the OU:

{'info': '00000000: LdapErr: DSID-0C090627, comment: In order to
perform this operation a successful bind must be completed on the
connection., data 0, vece', 'desc': 'Operations error'}

 

[Michael Ströder]

Thanks for the response. The user I'm connecting as should have full
access but I'll double check tomorrow.

This is the LDAP error that is returned when I leave out the OU:

{'info': '00000000: LdapErr: DSID-0C090627, comment: In order to
perform this operation a successful bind must be completed on the
connection., data 0, vece', 'desc': 'Operations error'}

This clearly indicates that the bind was not successful and you're
trying anonymous search access here which is not allowed in default
configuration of AD. I'm not sure whether you can allow anonymous access
at ou-level.

You could try to use trace_level=2 to check whether bind is really
successful and which bind-DN and credentials are actually used.

Ciao, Michael.

 

[hotani]

It seems the only way I can bind is by using this format:
simple_bind_s('(e-mail address removed)','password')

If I try using a DN, it fails every time. This will not work:
simple_bind_s('cn=user,dc=server,dc=local', 'password')

Errors out with "invalid credentials": ldap.INVALID_CREDENTIALS:
{'info': '80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 525, vece', 'desc': 'Invalid
credentials'}


If I put the *wrong* credentials in the first format, it will fail -
which seems to indicate the bind is working. With that
'successful' (?) bind, it is returning the bind error from my earlier
post only when I leave out the OU when searching.

 

[hotani]

This fixed it!
http://peeved.org/blog/2007/11/20/

By adding this line after 'import ldap', I was able to search from the
root level:
ldap.set_option(ldap.OPT_REFERRALS, 0)

 

[Michael Ströder]

It seems the only way I can bind is by using this format:
simple_bind_s('(e-mail address removed)','password')

Believe me: This is not true.

If I try using a DN, it fails every time. This will not work:
simple_bind_s('cn=user,dc=server,dc=local', 'password')

Check the DN you're using. Maybe you should search this particular user
entry with filter ([email protected])

Ciao, Michael.

 

[Michael Ströder]

This fixed it!
http://peeved.org/blog/2007/11/20/

By adding this line after 'import ldap', I was able to search from the
root level:
ldap.set_option(ldap.OPT_REFERRALS, 0)

Uumh, yes. I'm always switching off OpenLDAP client lib's internal
referral chasing.

But be prepared to also handle (at least ignore) the search
continuations (LDAP URL) in the search results you will probably
receive. These are not regular search entries.

Ciao, Michael.

 

[Michael Ströder]

http://peeved.org/blog/2007/11/20/

BTW: This blog entry claims that LDAP_SERVER_DOMAIN_SCOPE_OID control
cannot be used with python-ldap. But support for such simple LDAPv3
extended controls was added to python-ldap way back in 2005.

Actually it's easy (relevant code excerpt):

----------------------------------------------------------------
import ldap
from ldap.controls import BooleanControl
LDAP_SERVER_DOMAIN_SCOPE_OID='1.2.840.113556.1.4.1339'
[..]
l = ldap.initialize(ldap_uri,trace_level=trace_level)
# Switch off chasing referrals within OpenLDAP's libldap
l.set_option(ldap.OPT_REFERRALS, 0)
# Simple bind with user's DN and password
l.simple_bind_s(dn,password)
res = l.search_ext_s(
'DC=dom,DC=example,DC=com',
ldap.SCOPE_ONELEVEL,
'(objectClass=subentry)',
['*'],
serverctrls = [
BooleanControl(
LDAP_SERVER_DOMAIN_SCOPE_OID,
criticality=0,controlValue=1
)
]
)
----------------------------------------------------------------

Strange enough it has no effect. And setting criticality=1 raises an
error indicating that this control is not supported although this
control is explicitly mentioned in attribute 'supportedControl' of the
server's rootDSE:

ldap.UNAVAILABLE_CRITICAL_EXTENSION: {'info': '00000057: LdapErr:
DSID-0C09068F, comment: Error processing control, data 0, vece', 'desc':
'Critical extension is unavailable'}

Might depend on the domain functional level AD is running with...

Ciao, Michael.