python-ldap - Operations Error

[theiviaxx]

Hello all, I am trying to integrate TurboGears with our Active
Directory here at the office. TurboGears aside, i cannot get this to
work. The simplest thing i can do to test this is:

import ldap
l = ldap.initialize("ldap://server.net")
l.simple_bind(DN, "secret") 1
l.result(1) (97, [])
l.search("dc=server,dc=net", ldap.SCOPE_SUBTREE, "(sAMAccountName=user)")

OPERATIONS_ERROR: {'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'}

The simple bind works fine and returns a result, when i get the
result, it returns 97 meaning successful. So there was a successful
bind on the connection, right? I'm really not sure where the problems
lies. Is it with the way im connecting or is it something to do with
our AD server?

Thanks

 

[Jason Scheirer]

Hello all, I am trying to integrate TurboGears with our Active
Directory here at the office.  TurboGears aside, i cannot get this to
work.  The simplest thing i can do to test this is:

import ldap
l = ldap.initialize("ldap://server.net")
l.simple_bind(DN, "secret") 1
l.result(1) (97, [])
l.search("dc=server,dc=net", ldap.SCOPE_SUBTREE, "(sAMAccountName=user)")

OPERATIONS_ERROR: {'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'}

The simple bind works fine and returns a result, when i get the
result, it returns 97 meaning successful.  So there was a successful
bind on the connection, right?  I'm really not sure where the problems
lies.  Is it with the way im connecting or is it something to do with
our AD server?

Thanks

Seems more promising: http://tgolden.sc.sabren.com/python/active_directory.html

Also, same problem: http://groups.google.com/group/turbogears/browse_thread/thread/10fcd1f9e920d0a8

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

Google is pretty awesome when you paste in literal error strings.

 

[theiviaxx]

Thanks for that last link, i'll try that tomorrow As for the
tgolden modules, i will use that in a pinch, but it means our server
has to be a windows box. just trying to keep this as open as
possible

Thanks again

 

[Michael Ströder]

Seems more promising: http://tgolden.sc.sabren.com/python/active_directory.html

This is based on ADSI?
Then the caveat is that it only runs on Windows.

Ciao, Michael.

 

[Tim Golden]

This is based on ADSI?
Then the caveat is that it only runs on Windows.

Yes, it's Windows-only. (I've no idea if it would
run under something like WINE).

TJG

 

[Michael Ströder]

> 1

^^^
You probably want to use the synchronous method simple_bind_s() since
you want to impersonate on this LDAP connection immediately before doing
anything else on that connection.

(97, [])

Could you please use argument trace_level=2 when calling
ldap.initialize() and examine the debug log? It records all method calls
of your particular LDAPObject instance.

l = ldap.initialize("ldap://server.net",trace_level=2)

Level 2 outputs a debug log with results received. Protect this log
since it also contains passwords!

OPERATIONS_ERROR: {'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'}

Still something went wrong with your bind. Since I don't know your DN I
can't say anything. The DN should be a local user in this domain and not
a user from another trusted domain. If you have a complicated AD setup
with various domains and delegated trust connecting to the GC (global
catalog) on port 3268 might be easier.

The simple bind works fine and returns a result, when i get the
result, it returns 97 meaning successful.

It would raise an exception if an LDAP error was received.

So there was a successful
bind on the connection, right?

Don't know. Since I don't know your DN and AD domain configuation.

I've added a new example script ms_ad_bind.py to python-ldap's Demo/
directory illustrating all the possible bind methods:

http://python-ldap.cvs.sourceforge....ap/Demo/ms_ad_bind.py?content-type=text/plain

For getting the SASL stuff to correctly work your DNS has to be properly
set up for AD (A RRs and matching PTR RRs for the DCs).

Ciao, Michael.

 

[theiviaxx]

Thanks for the help guys, it works! I used the
ldap.set_option(ldap.OPT_REFERRALS, 0) from http://peeved.org/blog/2007/11/20/
immedialtey after import, then did the initialize trace_level=2 and
did the simple_bind_s. I was able to search and get the results.
That trace_level thing is nice, i'm sure i will be debugging this more
as i move forward

Not sure if this is an AD thing or just something i needed to do with
our particular server/config.

Thanks again!

 

[t.a.adjuster]

Not sure if this is an AD thing or just something i needed to do with
our particular server/config.

Glad to hear my posting helped somebody.

In our case, our domain controller was passing us referrals to the
Configuration, ForestDNSZones, and DomainDNSZones partitions of the
directory when we were doing SCOPE_SUBTREE scoped searches from the
root DN of an AD domain. When python-ldap tried to chase those
referrals it did so with an anonymous bind, hence the error.

Once we turned off the OPT_REFERRALS option, our only other
consideration was to be sure that, when iterating over our search
results, we just scrubbed out the referrals that were returned (based
on the referrals being lists and the real search results being
dictionaries). This is a bit quick and dirty, perhaps, but it's what
did the trick for us.

Evan

 

[Michael Ströder]

Thanks for the help guys, it works! I used the
ldap.set_option(ldap.OPT_REFERRALS, 0) from http://peeved.org/blog/2007/11/20/

Hmm, maybe I should generally switch off referral chasing in python-ldap
forcing applications to enable it if needed overriding libldap's
default. I did this already for LDAPObject.protocol_version where
libldap's default is LDAPv2 and python-ldap sets it to LDAPv3 in
LDAPObject.__init__(). Although this was an incompatible change no-one
complained.

immedialtey after import, then did the initialize trace_level=2 and
did the simple_bind_s. I was able to search and get the results.
That trace_level thing is nice, i'm sure i will be debugging this more
as i move forward

Not sure if this is an AD thing or just something i needed to do with
our particular server/config.

Basically the concept of LDAPv3 referrals is broken since there's no
concept for specifying how to bind to the referral's target without
a-priori local configuration. See also an old posting to
related to this:

http://groups.google.com/group/microsoft.public.windows.server.active_directory/msg/d061e0398cc366a5

Ciao, Michael.