Perhaps I don't understand everything involved, but ptloader now just finds the user record via user defineable filter, and only cares about the memberOf attributes, which it cycles through to find the users group membership. What I am doing now is to find the user dn via definable filter, then search for that dn in a groups container, and cycle through all returned entries, picking the cn of each as the group name. Two ldap queries unfortunately, but at least both are equality searches..I do not see how this is going to work within cyrus context. You will need to change a lot more than just ptloader/ldap code for this to work.
Thats what I thought as well. I have already written the code the does the user group membership check in ldap.c, but when I went to test it via cyradm - I created a folder, and tried to set a group:xxx ACL and at that exact point the identifier group:xxx was passed into the pts and I don't know what to do with it (do we check to see if its a valid group?? I didn't see what to do in the original ldap.c code, afskrb.c, or any other file. Perhaps I'm thick, but I just wanted to make sure there wasn't anything else I was missing before going on).I do not think such docs exist (except for the code itself). Basically, whenever a user logs in, cyrus fetches all groups the user is member of (ptloader/ldap does this in your case). This group list is later used for mailbox access (check lib/auth_pts.c).
Like I said, I don't think theres any problem with my approach (other than it being two ldap queries) but I'd sure like to know a little more about this ptloader subsystem - like what to do with group:xxx entries, and anything else other than just raw user/group lookups, and what the pts cache actually does.You'd be better of writing an ldap authorization module. Check lib/auth_unix.c for an example.
Also, another interesting thing - it seems that the original ldap.c code would return null if it didn't find any memberOf attributes in the user record and Authentication would fail!
Thanks, Tim
