Torsten Gipp wrote:

On Mon, 25 Nov 2002, Colin Sampaleanu wrote:

...

Can anybody confirm that LDAPUserFolder (1.6 beta 2) works ok with Zope 2.6.0? The docs mention it working with 2.5, but make no mention of 2.6. I am having some major issues) described below, which seem to stop me from being able to run it at all.

It is working for me (Zope 2.6.0b1 (binary release, python 2.1, linux2-x86), python 2.1.3, linux2).

...

I am running RedHat 7.3, openldap-clients-2.0.23-4, python-ldap-2.0.0pre06, and am trying to use LDAPUserFolder 1.6 beta 2. I have installed pythin-ldap for the copy of python included in my zope install, and have verified that I am able to connect to the LDAP server (MS Active Directory in this case), so there are no issues at that level as far as I can tell.

Can you do that with python as well? Does an 'import ldap' work when you use the python your Zope runs with?

However, I had to use python-ldap-2.0.0pre03-1.i386.rpm because I am using python 2.1.3.

Actually I meant that I am able to connect to it using python-ldap, using the python in my zope. So I can do a search through python-ldap, etc.

...

When I try to add an instance of the LDAPUserFolder, pressing the 'add' button results in a 'hang', with my browser never coming back. If I am browsing the zope mangement tree, and then try to hit the folder with the ldapuserfolder also 'hangs'. If I shut down everything, and hit the management url again (coming in completely unauthenticated), then I get the browser id/password popup, and entering in a name and hitting enter will also result in a hang.

I am able to go in via the zope admin/emergency use, and take a look at the ldapuserfolder, which seems to be ok, and kill it, etc.

So as far as I can tell, LDAPUserfolder is simply hanging when it goes in and tries to do a lookup. There is no exception, and nothing put in the log.

Any suggestions would be much appreciated...

If all else fails: perhaps this one helps:

http://www.geocrawler.com/archives/3/1568/2002/6/0/9027164/

Unfortunately I am not running LDAP on the same machine. I did consider the fact that perhaps this was the same issue, but the machine appears responsive otherwise. What is interesting is that after about 10 minutes it _does_ come back, saying that the user/credentials are not value. So LDAPUserFolder does not necessarilly think it has a problem, it just thinks there is an authenticaiton issue. Of course I would say if it takes 10 minutes there is a sever problem somewhere, never mind the fact that the authentication should work.. Colin

Brad Clements wrote:

On 25 Nov 2002 at 17:07, Colin Sampaleanu wrote:

...

Unfortunately I am not running LDAP on the same machine. I did consider the fact that perhaps this was the same issue, but the machine appears responsive otherwise. What is interesting is that after about 10 minutes it _does_ come back, saying that the user/credentials are not value. So LDAPUserFolder does not necessarilly think it has a problem, it just thinks there is an authenticaiton issue. Of course I would say if it takes 10 minutes there is a sever problem somewhere, never mind the fact that the authentication should work..

Sounds like there is a firewall between the two systems, configured to drop packets rather than generate an ICMP port unreachable response.

ipchains in the way?

No, they're on the same subnet, can can see each other fine. And python-ldap comes back from the query immediately, so there is no real ldap issue as far as I can tell, it is some sort of problem between LDAPUserFolder and python-ldap, more likely, or the way the LDAPUserFolder is doing its lookups...

Could this be happening because the directory server is returning a search result with a continuation reference? I have been hitting the server with a java program, and have seen that it is returning a search result with one (valid) entry, for the user, but there is also a continuation reference of "" coming back as part of that result. Now looking into this, this is supposed to happen when you do a search against Active Directory which crosses domains, and you are not hitting an Active Directory Catalog Master (basically an instance of the server which has not been set up a catalog master, having multi-domain information). I am definitely hitting a catalog master, but it is still returning the "" continuation, so something weird is going on. My hunch, in any case (and I may be completely off) is that maybe LDAPUserfolder does not know what to do with the continuation reference. Could this be it? Jens Vagelpohl wrote:

if you know how to use the python debugger you could step through the code (starting in the validate method) to determine exactly where the lag is. strategically placed logging (print statements, logging calls) would also help.

jens

On Monday, Nov 25, 2002, at 18:14 US/Eastern, Colin Sampaleanu wrote:

...

Brad Clements wrote:

...

On 25 Nov 2002 at 17:07, Colin Sampaleanu wrote:

...

Unfortunately I am not running LDAP on the same machine. I did consider the fact that perhaps this was the same issue, but the machine appears responsive otherwise. What is interesting is that after about 10 minutes it _does_ come back, saying that the user/credentials are not value. So LDAPUserFolder does not necessarilly think it has a problem, it just thinks there is an authenticaiton issue. Of course I would say if it takes 10 minutes there is a sever problem somewhere, never mind the fact that the authentication should work..

Sounds like there is a firewall between the two systems, configured to drop packets rather than generate an ICMP port unreachable response.

ipchains in the way?

No, they're on the same subnet, can can see each other fine. And python-ldap comes back from the query immediately, so there is no real ldap issue as far as I can tell, it is some sort of problem between LDAPUserFolder and python-ldap, more likely, or the way the LDAPUserFolder is doing its lookups...