tutorial one, error locating server for domain on creds.acquire(...)

[Tom H]

Hello,

I can complete tutorial one successfully if I use the
server='dc.domain.com' parameter for creds.acquire. If I do not
specify the server manually I get the following error:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "ldap-tom.py", line 8, in <module>
creds.acquire(user, password)
File "/usr/lib/python2.5/site-packages/ad/core/creds.py", line 79,
in acquire
self._resolve_servers_for_domain(domain)
File "/usr/lib/python2.5/site-packages/ad/core/creds.py", line 163,
in _resolve_servers_for_domain
result = locator.locate_many(domain)
File "/usr/lib/python2.5/site-packages/ad/core/locate.py", line 117,
in locate_many
candidates)
File "/usr/lib/python2.5/site-packages/ad/core/locate.py", line 310,
in _select_domain_controllers
local.sort(lambda x,y: candidates.index((x.orig_hostname, x.port)
-
File "/usr/lib/python2.5/site-packages/ad/core/locate.py", line 310,
in <lambda>
local.sort(lambda x,y: candidates.index((x.orig_hostname, x.port)
-
AttributeError: 'Reply' object has no attribute 'port'

I haven't done any debugging to figure out what is causing the problem
yet. It would be nice to have the automatic server lookup working. I'm
using the version 0.8 download of python-ad. I can provide versions of
other requisite packages if that might be the issue.

[Tom H]

I'm running it in pdb now, and found the following:

x and y are of type ad.protocol.netlogon.Reply

the attribute orig_hostname is present, but doing dir(x) and dir(y) in
pdb does not show the port attribute for either.

the orig_hostname for both x and y at the time of error are valid
domain controllers.

I'm looking at the latest svn code for the Reply object, and it is
created with the following code:
for key in kwargs:
setattr(self, key, kwargs[key])
# from http://www.boskant.nl/trac/python-ad/browser/lib/ad/protocol/netlogon.py
line 39 and following

Based on this, if port is not passed in as a keyword argument to the
Reply(...) constructor, it will not be present in the resulting
object.

It appears to me that the ad.protocol.netlogon.Client code directly
parses the returned netlogon attribute from the domain controller
without checking if the port attribute is present. Our domain
controller is not including port in that reply. The dir(x) and dir(y)
for mine show:

(Pdb) dir(x)
['__class__', '__delattr__', '__dict__', '__doc__',
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',
'__weakref__', 'address', 'checked', 'client_site', 'domain',
'domain_guid', 'flags', 'forest', 'hostname', 'netbios_domain',
'netbios_hostname', 'orig_domain', 'orig_hostname', 'server_site',
'timing', 'type', 'user']

We're using Windows Server 2003 and I believe the domain functional
level is 2003 native.

Any suggestions? I'll continue specifying the server manually, but
would be nice if the server locating code would not depend on 'port'
being present in the netlogon reply since my domain controllers do not
send that.

[Tom H]

I do see a port number listed for the 'address' attribute of both x
and y.

For example:
(Pdb) pp x.address
('192.168.168.21', 389)
# x.address is a tuple

The port can be directly accessed via:
(Pdb) pp x.address[1]
389

Is this compatible with the Active Directory versions or
configurations your are working with?

On Aug 15, 2:06 pm, Tom H <tom.hoga...@gmail.com> wrote:
> I'm running it in pdb now, and found the following:
>
> x and y are of type ad.protocol.netlogon.Reply
>
> the attribute orig_hostname is present, but doing dir(x) and dir(y) in
> pdb does not show the port attribute for either.
>
> the orig_hostname for both x and y at the time of error are valid
> domain controllers.
>
> I'm looking at the latest svn code for the Reply object, and it is
> created with the following code:
> for key in kwargs:
>     setattr(self, key, kwargs[key])

> # fromhttp://www.boskant.nl/trac/python-ad/browser/lib/ad/protocol/netlogon.py

> > other requisite packages if that might be the issue.- Hide quoted text -
>
> - Show quoted text -

[Geert Jansen]

Hi Tom,

On Fri, Aug 15, 2008 at 8:13 PM, Tom H <tom.h...@gmail.com> wrote:

I do see a port number listed for the 'address' attribute of both x
and y.

For example:
(Pdb) pp x.address
('192.168.168.21', 389)
# x.address is a tuple

The port can be directly accessed via:
(Pdb) pp x.address[1]
389

Is this compatible with the Active Directory versions or
configurations your are working with?

The behaviour you have found is a bug. It is only triggered when there is more than one local domain controller in a site.

I have committed a fix in rev a6f833934802. I haven't tested it yet as it will cost me some time to install another domain controller in my development setup. Let me know if this works for you.

Regards,
Geert

[Tom Hogarty]

Thanks, I'll test it when I get back to work Monday and let you know how it goes.

 

We do have two global catalog domain controllers in our local site. One is the pdc emulator too.

-Tom

[Tom Hogarty]

The new code works well, pulled it down from the repository this morning and now I can connect without specifying a server.

 

This library will be a great tool for my project. I'm pulling data from various company sources for a unified address / telephone book (including pulling from the active directory global address list (GAL) using python-ad).

Thanks,

 

-Tom

[Sam Powers]

On Aug 17, 8:33 am, "Geert Jansen" <ge...@boskant.nl> wrote:
> The behaviour you have found is a bug. It is only triggered when there is
> more than one local domain controller in a site.
>
> I have committed a fix in rev a6f833934802. I haven't tested it yet as it
> will cost me some time to install another domain controller in my
> development setup. Let me know if this works for you.

I also have multiple domain controllers in my setup, and have run into
problems even after using the current repository. It's better, and I
was able to fix it by commenting out line 310 and 311 in locate.py.

I ran it in PDB and came up with this:

> /usr/lib/python2.5/site-packages/ad/core/locate.py(310)<lambda>()
-> local.sort(lambda x,y: cmp(candidates.index((x.q_hostname,
x.q_port)),
(Pdb) candidates
['dc2.district6.org.', 'dc1.district6.org.', 'dc3.district6.org.',
'dc2.district6.org.', 'dc3.district6.org.', 'dc1.district6.org.']
(Pdb) candidates.index((x.q_hostname, x.q_port))
*** ValueError: list.index(x): x not in list

Since it doesn't matter that much to me which DC is used, I commented
out the "local.sort" operation and appear to be happily listing
objects from the directory, per the code from tut 1.

As an aside, I really like the portable approach you're using in this
module. The other modules I researched all used ADSI/COM, and I want
to run this on Linux. I'm attempting to develop a Python script to
keep an eye on our student database and automatically add/remove
students without IT department's intervention.

-Sam

[Geert Jansen]

On Aug 31, 3:19 am, Sam Powers <sampow...@gmail.com> wrote:
>
> I also have multiple domain controllers in my setup, and have run into
> problems even after using the current repository.  It's better, and I
> was able to fix it by commenting out line 310 and 311 in locate.py.
>

> [snip]

This has now been fixed in revision 90:a55c7dc1bd77.

Regards,
Geert