ok, my fault, i overlooked that in your configuration settings description. first of all, since you are using cookie auth, make sure to delete all and any cookies with the name "__ac" from that particulat server. sometimes the wrong cookies hang around and you'll never be able to log in. better yet, test this without cookies first. set the user folder to use basic auth. from your description it looks like the LDAPUserFolder is further down in the tree, with at least one other user folder above. it is possible in extreme cases that you will run into problems if both user folders have a user with the same login defined. by the way, what LDAPUserFolder version are you using? the latest revision, 1.5 beta3, has a lot of improvements specifically for running it with role information stored in the ZODB like you are trying to do. that includes a "convenience" user listing on the Users tab for all those user records that have a role associated with them which is only visible if you store roles in the ZODB. if you can find users by searching via the Users tab and if they do have roles associated with them (as would be apparent on the user detail view for specific records) then this should work. are you sure your passwords are set correctly? use the "change password" form on the record detail view from the Users tab to reset the password if you are unsure. jens On Monday, August 12, 2002, at 07:39 , Joel Burton wrote:

On Mon, Aug 12, 2002 at 07:28:56PM -0400, Jens Vagelpohl wrote:

...

the objectClass "organizationalRole" is not supported as a suitable group "holder". store your group memberships in objects that are supported, such as groupOfUniqueNames, groupOfNames, or group.

...

...

dn: dc=joelburton, dc=com objectClass: dcObject objectClass: organization o: Example Company dc: joelburton

dn: cn=Manager,dc=joelburton,dc=com objectClass: organizationalRole cn: Manager

dn: cn=bob,dc=joelburton,dc=com sn: bob givenName: bob cn: bob objectClass: top objectClass: person objectClass: inetorgperson userPassword:: e1NIQX1TQmdhelNLejdhNjhpa1I0YUtmZmZPWXBrZ289

Jens (& others) --

Thanks for the help. If I understand right, though, the "Manager" here is just the dn of the user who has full privileges to the LDAP server -- it shouldn't be related to the Zope roles (which I'm not storing in the LDAP server). If I were keeping the Zope roles in the LDAP server, I would use groupOfUmiqueNames to connect that group to the users.

My plan was to get authentication to work w/o the additional complications of groups in LDAP, and then try to add the LDAP groups in. Is this not a workable strategy?

Do you have any tips on how to get this authenticated with the groups being stored in the ZODB?

Thanks!

- J. --

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant

from looking at the code inside _lookupuser, the following seems to happen: - the user record is indeed found - in the next step, when the full record is retrieved ***while binding as that very same user that is being looked up*** the lookup fails. the user record lookup is done in two steps. first, the given login name is looked up to see if a matching record exists at all. this lookup will, if the record exists, return the full DN for the record. it is done while bound as the manager user. in the second step the authentication credentials are switched to the full DN just found and the password that was provided by the user. this is to make sure that access restrictions put in place by the LDAP admins are not overridden and the user can only see what they are supposed to see. then, under these new credentials, all attributes are looked up inside the record identified by the full user DN. the results of this second search are used to assemble the user object zope needs. i have a suspicion that your LDAP server access control is wrong. try to replace the line in your slapd.conf that says... access to * by anonymous write with... access to * by * write i have a feeling with your existing rule only anonymous users end up having any access rights. in your first email you say that you are not very knowledgeable about LDAP. IMHO that is a real problem when you are trying to work with a product that assumes at least some knowledge about LDAP, such as the LDAPUserFolder. i have said it before and i will say it again: working with directory servers is harder than many people think. you must gain adequate knowledge of LDAP and the LDAP tree structure to work this product successfully. jens On Tuesday, August 13, 2002, at 09:00 , Joel Burton wrote:

On Mon, Aug 12, 2002 at 07:53:41PM -0400, Jens Vagelpohl wrote:

...

ok, my fault, i overlooked that in your configuration settings description.

first of all, since you are using cookie auth, make sure to delete all and any cookies with the name "__ac" from that particulat server. sometimes the wrong cookies hang around and you'll never be able to log in. better yet, test this without cookies first. set the user folder to use basic auth.

Done that, too. I switched it to cookies only so I could see that cookie form to verify that it was LDAPUserFolder that was trying to authenticate me, and not just the root user folder. Switching it back to HTTP_Basic still doesn't authenticate.

...

from your description it looks like the LDAPUserFolder is further down in the tree, with at least one other user folder above. it is possible in extreme cases that you will run into problems if both user folders have a user with the same login defined.

Nope -- my acl_users in the root contains only joel, my LDAP folder contains only bob.

...

1.5 beta3, has a lot of improvements specifically for running it with role information stored in the ZODB like you are trying to do. that includes a "convenience" user listing on the Users tab for all those user records that have a role associated with them which is only visible if you store roles in the ZODB.

Am running 1.5b3. The "Users with locally stored roles" shows

"cn=bob,dc=joelburton,dc=com Manager"

...

if you can find users by searching via the Users tab and if they do have roles associated with them (as would be apparent on the user detail view for specific records) then this should work. are you sure your passwords are set correctly? use the "change password" form on the record detail view from the Users tab to reset the password if you are unsure.

bob shows up when I search the user list. He has the Manager privilege. I've changed his password (again, to "bob") but still no luck.

Not sure if this is helpful, but:

* under "Caches", there was no Cached users

* The log (set to "Debugging") is full of "joel not found (getUser)" and a few "bob not found (getUser)" and "No data is _lookupuser for uid bob" -- joel is the manager account that owns the ldap folder.

-- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant

Working with directory servers *is* harder than people think; mostly, I think, because there isn't a lot of decent walkthroughs for how to use LDAP in a small/medium-scale setting. Let's hope that changes.

i am of the opinion that a lot of people who want to use LDAP in a small/medium-scale setting might not have considered all options. the decision for or against LDAP should be based on real need or whether LDAP is already in place and available. many people (no offense, joel) seem to base that decision on notions like how cool it would be or what they might be able to do later on instead of what they really need now. jens