python-ldap-dev

python-ldap vs. Active directory

[Sean O'C. <oco...@so...>]

Folks-

I am trying to get a trivial python-ldap script to work talking to our
campus active directory from a Linux machine (Fedora Core 3 or Centos
4), but I am being thwarted. I have successfully used python-ldap (same
versions) to talk to an openldap server quite happily; however, the AD
servers are proving to be quite stubborn.

The client side software versions are:

openldap (openldap-2.2.13-2 RPM)
python-ldap (python-ldap-2.0.1-2 RPM)
python (python-2.3.4-13.1)

The simple script is as follows, with some silly info tossed in for the
usual reasons.

---------------------------------- snip --------------------------------

import sys
import ldap

myLdapURI="ldap://ad.ucsd.edu"
myBaseDN="dc=ad,dc=ucsd,dc=edu"
myBindDN="cn=AdAccount,ou=foo,ou=bar,dc=ad,dc=ucsd,dc=edu"
myPassWD="LetMeIn" 

# Open the LDAP connection
print "initializing .."
try:
  l = ldap.initialize(myLdapURI)
except ldap.LDAPError,e:
  print e
  sys.exit(1)

# Set protocol version to LDAPv3
l.protocol_version = ldap.VERSION3

# Bind to AD
print "binding .."
try:
  l.bind_s(myBindDN,myPasswd)
except ldap.LDAPError, e:
  print e
  sys.exit(1)
else:
  print 'Sucessfully bound to AD'

#myFilter='(objectclass=*)'
myFilter='(sAMAccountName=AKnownUserInAD)'
myRetrieveAttrs = None
myScope=ldap.SCOPE_SUBTREE

# Do a search
print "searching .."
try:
  myResults = l.search_s(myBaseDN,myScope,myFilter,myRetrieveAttrs)
except ldap.LDAPError, e:
  print e
else:
  print myResults

# Close down the connection
l.unbind()

------------------------------- snip ----------------------------------
The results are invariably:

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

It appears to do the bind properly, but seems to forget about it when it
goes to do the search. Whereas, the following returns the desired
results:

ldapsearch -x -w 'LetMeIn' -D
'cn=AdAccount,ou=foo,ou=bar,dc=ad,dc=ucsd,dc=edu' -b
'dc=ad,dc=ucsd,dc=edu' -H ldap://ad.ucsd.edu
'(sAMAccountName=AKnownUserInAD)'

Any ideas what's going on here? Am I missing something obvious? The
command line search also works using kinit (and dropping the -x flag).
The python-ldap doesn't appear to work with SASL at all.

Thanks
-- 
Sean

Re: python-ldap vs. Active directory

[Jason T. <ja...@ti...>]

Sean,

On Thu, May 19, 2005 at 03:24:13PM -0700, Sean O'Connell wrote:
> I am trying to get a trivial python-ldap script to work talking to our
> campus active directory from a Linux machine (Fedora Core 3 or Centos
> 4), but I am being thwarted. I have successfully used python-ldap
> (same versions) to talk to an openldap server quite happily; however,
> the AD servers are proving to be quite stubborn.

I had trouble when my company switched to AD (i.e., MS Exchange 2000)
from MS Exchange 5.5 too.  Hopefully, the attached script will give you
some ideas to try.  FWIW, it works for me from mutt.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Re: python-ldap vs. Active directory

[Deepak G. <de...@ar...>]

On Thu, 2005-05-19 at 15:24 -0700, Sean O'Connell wrote:
> The results are invariably:
> 
> initializing ..
> binding ..
> Sucessfully bound to AD
> searching ..
> {'info': '00000000: LdapErr: DSID-0C0905FF, comment: In order to perform
> this operation a successful bind must be completed on the connection.,
> data 0, vece', 'desc': 'Operations error'}

I was getting the exact same error. I fixed the problem by explicitly
disabling referral chasing in the OpenLDAP client libraries (for my
purposes, I didn't care about referrals). 

Before you call ldap.initialize, try:

ldap.set_option(ldap.OPT_REFERRALS, 0)

Cheers!
deepak

--
Deepak Giridharagopal

Re: python-ldap vs. Active directory

[Sean O'C. <oco...@so...>]

On Fri, 2005-05-20 at 17:09 -0500, Deepak Giridharagopal wrote:
> On Thu, 2005-05-19 at 15:24 -0700, Sean O'Connell wrote:
> > The results are invariably:
> > 
> > initializing ..
> > binding ..
> > Sucessfully bound to AD
> > searching ..
> > {'info': '00000000: LdapErr: DSID-0C0905FF, comment: In order to perform
> > this operation a successful bind must be completed on the connection.,
> > data 0, vece', 'desc': 'Operations error'}
> 
> I was getting the exact same error. I fixed the problem by explicitly
> disabling referral chasing in the OpenLDAP client libraries (for my
> purposes, I didn't care about referrals). 
> 
> Before you call ldap.initialize, try:
> 
> ldap.set_option(ldap.OPT_REFERRALS, 0)
> 
> Cheers!
> deepak
> 
> --
> Deepak Giridharagopal

Deepak-

You rock! That definitely solved the problem (of course, it now means I
have more work to do :).


-- 
Sean

Re: python-ldap vs. Active directory

[<mi...@st...>]

Deepak Giridharagopal wrote:
> On Thu, 2005-05-19 at 15:24 -0700, Sean O'Connell wrote:
> 
>>The results are invariably:
>>
>>initializing ..
>>binding ..
>>Sucessfully bound to AD
>>searching ..
>>{'info': '00000000: LdapErr: DSID-0C0905FF, comment: In order to perform
>>this operation a successful bind must be completed on the connection.,
>>data 0, vece', 'desc': 'Operations error'}
> 
> 
> I was getting the exact same error. I fixed the problem by explicitly
> disabling referral chasing in the OpenLDAP client libraries (for my
> purposes, I didn't care about referrals). 
> 
> Before you call ldap.initialize, try:
> 
> ldap.set_option(ldap.OPT_REFERRALS, 0)

This is good advice since IIRC the OpenLDAP libs chase referrals doing
an anonymous bind. Therefore it's definitely better to get the search
references (check the result type). Sort them out or chase the referrals
in your Python application.

Ciao, Michael.

Re: python-ldap vs. Active directory

[Jens V. <je...@da...>]

On May 21, 2005, at 23:26, Michael Str=F6der wrote:
>> I was getting the exact same error. I fixed the problem by explicitly
>> disabling referral chasing in the OpenLDAP client libraries (for my
>> purposes, I didn't care about referrals).
>>
>> Before you call ldap.initialize, try:
>>
>> ldap.set_option(ldap.OPT_REFERRALS, 0)
>>
>
> This is good advice since IIRC the OpenLDAP libs chase referrals doing
> an anonymous bind. Therefore it's definitely better to get the search
> references (check the result type). Sort them out or chase the =20
> referrals
> in your Python application.

For what it's worth, a long time ago I had the same problems with the =20=

LDAPUserFolder Zope product against AD. Among the resultset returned =20
by a query there would always be one record that made everything =20
barf. The (not very clean) workaround has been to special-case that =20
record and discard it. It is a AD-specific referral.

Another solution has been to connect to the "Global Catalog" port or =20
somesuch thing. This port apparently gives you a view on the data =20
contained in a forest of AD server instances as one single entity, as =20=

opposed to single AD instances handing back references to other AD =20
instances where a record may be found.

jens

Re: python-ldap vs. Active directory

[<mi...@st...>]

Jens Vagelpohl wrote:
> 
> 
> For what it's worth, a long time ago I had the same problems with the 
> LDAPUserFolder Zope product against AD. Among the resultset returned  by
> a query there would always be one record that made everything  barf. The
> (not very clean) workaround has been to special-case that  record and
> discard it. It is a AD-specific referral.

How did you sort out this special case?

IMO the appropriate way is to sort out the search references.
Having to deal with referrals / search references is *not* AD-specific!

Ciao, Michael.

Re: python-ldap vs. Active directory

[Jens V. <je...@da...>]

On May 22, 2005, at 14:11, Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
>
>> For what it's worth, a long time ago I had the same problems with the
>> LDAPUserFolder Zope product against AD. Among the resultset =20
>> returned  by
>> a query there would always be one record that made everything  =20
>> barf. The
>> (not very clean) workaround has been to special-case that  record and
>> discard it. It is a AD-specific referral.
>>
>
> How did you sort out this special case?
>
> IMO the appropriate way is to sort out the search references.
> Having to deal with referrals / search references is *not* AD-=20
> specific!

I know that references need to be dealt with, however, I have no AD =20
instance to test anything and thus the only goal was to make things =20
work somehow. I personally do not support AD, it's only on the basis =20
of "if it works for you, great. if not, sorry, can't help". Besides, =20
these "invalid" records come back as part of a normal set of search =20
results - leaving them out hasn't made anyone complain yet.

The specific case here is the return value from =20
ldap_connection.search_s, which I assume to be a sequence of two-item =20=

sequences consisting of a string (the DN) and a dictionary (the =20
attributes and their values). However, with AD you can get stuff like =20=

this as part f the results sequence:

(None, ['ldap://ForestDnsZones.PORTAL.LOCAL/=20
DC=3DForestDnsZones,DC=3DPORTAL,DC=3DLOCAL'])

I simply discard anything where the second element is not a dictionary.

jens