Re: PTS & LDAP Take 3
Sava, Thanks, I had a quick look at what you had there. Looks good. Perhaps I won't have to reinvent the wheel. Thanks again, Tim Sava Chankov wrote: Tim Pushor wrote: No, ldap.c doesn't work for me at all. If there are no memberOf attributes, it dies and user authentication fails (!). I guess I could setup a test user and step through it, but I did see what was happening at least in my adaptation of ldap.c. Canonicalization (of a group) was returning null because of the colon. So what use is it? There are enough unknowns that I would like to get cleared up if at all possible. I was hoping someone from CMU would be able to help advise. Thanks, Tim Hi Tim, I have gone through all that you explain here, even stepped through the program with gdb. I have fixed some bugs (like canonicalization failure with colon and null replies on error that used to hang ptloader) and added some additional functionality. If you are interested, you can download them from ftp://ftp.blueboard.biz/pub/cyrus-imap-ptloader-patches/ -- Sava Chankov, research & development blueboard.biz
Re: PTS & LDAP Take 3
On Fri, 23 Jan 2004, Sava Chankov wrote:
> Tim Pushor wrote:
> > No, ldap.c doesn't work for me at all. If there are no memberOf
> > attributes, it dies and user authentication fails (!). I guess I could
> > setup a test user and step through it, but I did see what was happening
> > at least in my adaptation of ldap.c. Canonicalization (of a group) was
> > returning null because of the colon. So what use is it? There are enough
> > unknowns that I would like to get cleared up if at all possible. I was
> > hoping someone from CMU would be able to help advise.
> >
> > Thanks,
> > Tim
>
> Hi Tim, I have gone through all that you explain here, even stepped
> through the program with gdb. I have fixed some bugs (like
> canonicalization failure with colon and null replies on error that used
> to hang ptloader) and added some additional functionality. If you are
> interested, you can download them from
> ftp://ftp.blueboard.biz/pub/cyrus-imap-ptloader-patches/
>
If someone is interested, I attached a patch which removes dependency on
openldap internal libs/includes (lutil).
--
IgorIndex: configure.in
===
RCS file: /cvs/src/cyrus/configure.in,v
retrieving revision 1.277
diff -u -r1.277 configure.in
--- configure.in6 Jan 2004 22:08:07 - 1.277
+++ configure.in18 Jan 2004 03:52:44 -
@@ -540,7 +540,7 @@
LDAP_LIBS=""
AC_CHECK_LIB(ldap, ldap_initialize, [
- LDAP_LIBS="-lldap -llber -llutil" ],,-llber)
+ LDAP_LIBS="-lldap -llber" ],,-llber)
else
AC_ERROR(unknown with-pts value)
fi
Index: ptclient/ldap.c
===
RCS file: /cvs/src/cyrus/ptclient/ldap.c,v
retrieving revision 1.2
diff -u -r1.2 ldap.c
--- ptclient/ldap.c 22 Oct 2003 18:03:22 - 1.2
+++ ptclient/ldap.c 18 Jan 2004 03:53:08 -
@@ -60,10 +60,7 @@
#include
#include
-
-/* xxx autoconf checks for these? */
-#include
-#include
+#include
/* libimap */
#include "global.h"
@@ -129,6 +126,51 @@
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
+typedef struct ldapglue {
+ const char *authc;
+ const char *authz;
+ const char *realm;
+ const char *password;
+} ldapglue;
+
+static int ldap_interact(
+ LDAP *ld,
+ unsigned flags __attribute__((unused)),
+ void *def,
+ void *inter)
+{
+ sasl_interact_t *in = inter;
+ const char *p;
+ ldapglue *glue = def;
+
+ for (;in->id != SASL_CB_LIST_END;in++) {
+ p = NULL;
+ switch(in->id) {
+ case SASL_CB_AUTHNAME:
+ if (glue->authc)
+ p = glue->authc;
+ break;
+ case SASL_CB_USER:
+ if (glue->authz)
+ p = glue->authz;
+ break;
+ case SASL_CB_GETREALM:
+ if (glue->realm)
+ p = glue->realm;
+ break;
+ case SASL_CB_PASS:
+ if (glue->password)
+ p = glue->password;
+ break;
+ }
+
+ in->result = p ? p : "";
+ in->len = strlen(in->result);
+ }
+
+ return LDAP_SUCCESS;
+}
+
/*
* Convert 'identifier' into canonical form.
* Returns a pointer to a static buffer containing the canonical form
@@ -190,34 +232,25 @@
/* Initilization */
if(config_getswitch(IMAPOPT_LDAP_SASL))
{
- struct berval passwd = { 0, NULL };
const char *sasl_password =
config_getstring(IMAPOPT_LDAP_SASL_PASSWORD);
const char *sasl_mech = config_getstring(IMAPOPT_LDAP_SASL_MECH);
const char *sasl_realm = config_getstring(IMAPOPT_LDAP_SASL_REALM);
const char *sasl_authc_id = config_getstring(IMAPOPT_LDAP_SASL_AUTHC);
const char *sasl_authz_id = config_getstring(IMAPOPT_LDAP_SASL_AUTHZ);
- unsigned sasl_flags = LDAP_SASL_AUTOMATIC;
+ldapglue glue;
- void *defaults;
- passwd.bv_val = sasl_password;
- if(passwd.bv_val) passwd.bv_len = strlen(passwd.bv_val);
-
- /* xxx security properties */
- syslog(LOG_DEBUG, "making LDAP defaults");
- defaults = lutil_sasl_defaults( ld,
- (char *)sasl_mech,
- (char *)sasl_realm,
- (char *)sasl_authc_id,
- passwd.bv_val,
- (char *)sasl_authz_id );
+glue.authc = sasl_authc_
Re: PTS & LDAP Take 3
Tim Pushor wrote: No, ldap.c doesn't work for me at all. If there are no memberOf attributes, it dies and user authentication fails (!). I guess I could setup a test user and step through it, but I did see what was happening at least in my adaptation of ldap.c. Canonicalization (of a group) was returning null because of the colon. So what use is it? There are enough unknowns that I would like to get cleared up if at all possible. I was hoping someone from CMU would be able to help advise. Thanks, Tim Hi Tim, I have gone through all that you explain here, even stepped through the program with gdb. I have fixed some bugs (like canonicalization failure with colon and null replies on error that used to hang ptloader) and added some additional functionality. If you are interested, you can download them from ftp://ftp.blueboard.biz/pub/cyrus-imap-ptloader-patches/ -- Sava Chankov, research & development blueboard.biz
Re: PTS & LDAP Take 3
On Mon, 19 Jan 2004, Rob Siemborski wrote: > On Sat, 17 Jan 2004, Igor Brezac wrote: > > > You'd be better of writing an ldap authorization module. Check > > lib/auth_unix.c for an example. > > It is unclear that this is the case, as the advantage of using the > ptloader format is that you can use a single ldap connection for all of > the cyrus processes, and you get the implicit caching benefits (yes, you > could write an auth_ldap that cached things correctly too). This is certainly the case if you have an option of pre-fetching all the groups. My initial understanding was that this was not the case. -- Igor
Re: PTS & LDAP Take 3
On Sat, 17 Jan 2004, Igor Brezac wrote: > You'd be better of writing an ldap authorization module. Check > lib/auth_unix.c for an example. It is unclear that this is the case, as the advantage of using the ptloader format is that you can use a single ldap connection for all of the cyrus processes, and you get the implicit caching benefits (yes, you could write an auth_ldap that cached things correctly too). I do agree that using group schemes doesn't fit the cyrus model that well. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: PTS & LDAP Take 3
Igor Brezac wrote: You could use ldap_whoami() instead of the first query. Where does that come from? You do not need to do anything with this. The identifier is passed to pts for canonicalization, the group is not validated. I don't see this in ldap.c. The identifier group:xxx gets passed into pts as the identifier and rejected by the canonicalizer because of the colon. So the canonicalized identifer is null throughout the rest of the code. I don't see a test for group: anywhere ( or in afskrb.c either ). So assuming that we just want to make sure that the group name is valid, and that the canonicalizer should be fixed to recognize group:xxx syntax, what then am I suppose to do with it? Returning NULL seems to Do Bad Things, and I don't see an entry for canonicalized group in the auth_state struct.. Have you tried to step through the program with gdb or other debugger? No, ldap.c doesn't work for me at all. If there are no memberOf attributes, it dies and user authentication fails (!). I guess I could setup a test user and step through it, but I did see what was happening at least in my adaptation of ldap.c. Canonicalization (of a group) was returning null because of the colon. So what use is it? There are enough unknowns that I would like to get cleared up if at all possible. I was hoping someone from CMU would be able to help advise. Thanks, Tim
Re: PTS & LDAP Take 3
On Sun, 18 Jan 2004, Tim Pushor wrote: > > > Igor Brezac wrote: > > >I see. I did not realize you were going to retrieve groups with another > >search filter. This should work. > > > > > > > Yeah, I'm sure it will. I wish I could do it in one query though.. How You could use ldap_whoami() instead of the first query. > often does the ptloader get called on? Will the pts cache here help at > all? What exactly does the pts cache do? ( I realize that it probably > caches authorizaton info, but is it always consulted first, before > asking the ptloader to look up the information again?) > > >>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). > >> > >> > > > >You do not need to do anything with this. The identifier is passed to pts > >for canonicalization, the group is not validated. > > > > > > > I don't see this in ldap.c. The identifier group:xxx gets passed into > pts as the identifier and rejected by the canonicalizer because of the > colon. So the canonicalized identifer is null throughout the rest of the > code. I don't see a test for group: anywhere ( or in afskrb.c either ). > So assuming that we just want to make sure that the group name is valid, > and that the canonicalizer should be fixed to recognize group:xxx > syntax, what then am I suppose to do with it? Returning NULL seems to Do > Bad Things, and I don't see an entry for canonicalized group in the > auth_state struct.. > Have you tried to step through the program with gdb or other debugger? -- Igor
Re: PTS & LDAP Take 3
Igor Brezac wrote: I see. I did not realize you were going to retrieve groups with another search filter. This should work. Yeah, I'm sure it will. I wish I could do it in one query though.. How often does the ptloader get called on? Will the pts cache here help at all? What exactly does the pts cache do? ( I realize that it probably caches authorizaton info, but is it always consulted first, before asking the ptloader to look up the information again?) 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). You do not need to do anything with this. The identifier is passed to pts for canonicalization, the group is not validated. I don't see this in ldap.c. The identifier group:xxx gets passed into pts as the identifier and rejected by the canonicalizer because of the colon. So the canonicalized identifer is null throughout the rest of the code. I don't see a test for group: anywhere ( or in afskrb.c either ). So assuming that we just want to make sure that the group name is valid, and that the canonicalizer should be fixed to recognize group:xxx syntax, what then am I suppose to do with it? Returning NULL seems to Do Bad Things, and I don't see an entry for canonicalized group in the auth_state struct.. Thanks, Tim
Re: PTS & LDAP Take 3
On Sat, 17 Jan 2004, Tim Pushor wrote: > Igor Brezac wrote: > > >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. > > > > > > > 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 see. I did not realize you were going to retrieve groups with another search filter. This should work. > > >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). > > > > > > > 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). You do not need to do anything with this. The identifier is passed to pts for canonicalization, the group is not validated. -- Igor
Re: PTS & LDAP Take 3
Igor Brezac wrote: 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. 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 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). 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). You'd be better of writing an ldap authorization module. Check lib/auth_unix.c for an example. 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. 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
Re: PTS & LDAP Take 3
On Sat, 17 Jan 2004, Tim Pushor wrote: > > >>I have determined that the way its currently setup (the ldap ptloader) > >>won't do what I want, so I am in the process of rewriting it for my needs. > >> > >> > > > >Interesting. Why is that? (Not using it myself right now, but would > >like to at some point.) > > > > > > > Because it relies on a user having multiple memberof attributes to > describe their group membership. This is OK if thats how you do group > membersip, but I already protect various bits of the directory using > OpenLDAP's group scheme - a seperate group object that contains multiple > member attributes, each being the DN of the 'subscriber'. I don't want > to support multiple group schemes if I can at all avoid it. 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. > I hope I didn't come off sounding like a jerk. I really don't mind doing > the work. It'd be twice as nice if others were interested, but if not > thats ok too ;-) I'd just like to see the API docs, or at least some > notes, if they exist. This is one of the major things that I really > wanted to see in Cyrus (external authorization). I'm excited! 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). You'd be better of writing an ldap authorization module. Check lib/auth_unix.c for an example. -- Igor
Re: PTS & LDAP Take 3
I have determined that the way its currently setup (the ldap ptloader) won't do what I want, so I am in the process of rewriting it for my needs. Interesting. Why is that? (Not using it myself right now, but would like to at some point.) Because it relies on a user having multiple memberof attributes to describe their group membership. This is OK if thats how you do group membersip, but I already protect various bits of the directory using OpenLDAP's group scheme - a seperate group object that contains multiple member attributes, each being the DN of the 'subscriber'. I don't want to support multiple group schemes if I can at all avoid it. I hope I didn't come off sounding like a jerk. I really don't mind doing the work. It'd be twice as nice if others were interested, but if not thats ok too ;-) I'd just like to see the API docs, or at least some notes, if they exist. This is one of the major things that I really wanted to see in Cyrus (external authorization). I'm excited! Tim
Re: PTS & LDAP Take 3
On Sat, 17 Jan 2004, Tim Pushor wrote: > I am assuming by the lack of response that no-one really cares (at least > at this point) about LDAP group based authorization. Oh, I wouldn't go that far. I just think folks haven't gotten too deep into it yet. If you search the archive you'll see it was discussed just a short while ago. > I have determined that the way its currently setup (the ldap ptloader) > won't do what I want, so I am in the process of rewriting it for my needs. Interesting. Why is that? (Not using it myself right now, but would like to at some point.) -- Amos
