From murch at fastmail.com Fri Oct 5 11:49:54 2018 From: murch at fastmail.com (Ken Murchison) Date: Fri, 5 Oct 2018 11:49:54 -0400 Subject: SASL 2.1.27 rc8 In-Reply-To: <5c9500d8-c707-f68c-b366-29254f35726a@fastmail.com> References: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> <5c9500d8-c707-f68c-b366-29254f35726a@fastmail.com> Message-ID: <83d62d39-3848-d0ce-5e9f-3cf5029bdf2e@fastmail.com> OK.? Back home and looking to finally get this release done. I've committed a couple of build fixes this morning which I would like tested by someone other than me.? I also need someone to review the Visual Studio PR since I don't have a Windows build environment. On 09/24/2018 05:25 AM, Ken Murchison wrote: > I was busier than expected over the weekend and didn't work on SASL, > but I will try to finalize it this week during breaks at my conference. > > > On 9/20/18 11:57 AM, Ken Murchison wrote: >> I merged all of these plus a few others except for 529 (added a >> comment).? Take a look at the commit logs.? Attached is the diff from >> rc8. >> >> I was able to find a desktop running a slightly older OS which still >> allows me to build a distro (building docsrc/ fails on newer >> Fedora).? I will probably wait a day or two for people to review the >> current changes and request others.? I will be able to SSH to my >> build machine from my hotel this weekend and will construct a final >> release and get it to my colleagues for posting my Monday. >> >> >> On 9/18/18 11:05 AM, Quanah Gibson-Mount wrote: >>> --On Tuesday, September 18, 2018 11:10 AM -0400 Ken Murchison >>> wrote: >>> >>>> >>>> I want to get 2.1.27 released this week, but I'm not sure where we >>>> stand >>>> with the GSSAPI stuff, and since I'm no longer at CMU, I don't have a >>>> Kerberos infrastructure to test with. >>>> >>>> So, I need someone to summarize the existing problem(s) and >>>> solution(s), >>>> preferably with a pull request or patch. >>> >>> Hi Ken, >>> >>> On GSSAPI: There is no mechanism in Heimdal to allow for pulling the >>> SSF level for a Kerberos mechanism (only exists in MIT). I've opened >>> an issue on the Heimdal side for this, but I wouldn't hold the >>> release on this.? I don't have an MIT environment, so someone else >>> would need to confirm the SSF bits (no more hard coded "56" with >>> GSSAPI, for example) are working correctly. >>> >>> Otherwise, there are several pull requests fixing issues with >>> building the last RC: >>> >>> >>> >>> >>> >>> >>> --Quanah >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Product Architect >>> Symas Corporation >>> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >>> >>> -- Ken Murchison Cyrus Development Team FastMail US LLC From aio.sasl at aio.nu Tue Oct 16 05:00:45 2018 From: aio.sasl at aio.nu (AiO) Date: Tue, 16 Oct 2018 11:00:45 +0200 (CEST) Subject: Kerberos/GSSAPI credentials delegation/ticket fowarding Message-ID: Hello all, I'm trying to figure out how to make Cyrus SASL handle Kerberos ticket delegation. I have read the mailing lists and the information is a bit thin on this topic. I saw that Morten and Rob had discussions about it back int 2003. And also S4U2 was discussed at some point between Howard and Alexey back in 2010. I am looking to be able to pass user identity to services behind a front-service - Much like Apache is able to do with mod_auth_kerb or mod_auth_gssapi. To maintain the user identity for accessing for example databases and such in a larger ecosystem of services. Or OpenSSH is able to do delegation. In both Apache and OpenSSHD there are additional configuration parameters to GSSAPI... Can the Cyrus SASL library be used in the same manner? (Given that the KDC and service policies are configured correctly, either unconstrained delegation or S4U2 delegation) Play with the idea that I want to write an IMAP server that stores its data in a PostgreSQL database, and I want to restrict users access to various parts of the database using the built-in ACL's to secure the stored data. In this example; authentication on to IMAP using GSSAPI and a previously received ticket and then delegation of credentials achieve full single-sign-on authentication and authorization to the data. In my case I have a Qpid Proton AMQP serice. I have managed to get GSSAPI single-sign-on working to it using Cyrus SASL (libsasl) that is linked with Qpid Proton. This is all good and totally AWESOME! However. How on earth do I convince the libsasl-process instance to impersonate the user when accessing other kerberized services. Yes as users. Not service-service. Is there something additional that can be added to the /etc/sasl2/.conf file that might convince the GSSAPI-parts of SASL to do this automagically? I'm a bit lost, currently. I hope to find someone here that know how to do this wizardry. :) Thanks in advance! Kind regards, AiO From lan at zato.ru Wed Oct 31 03:58:38 2018 From: lan at zato.ru (Alexander N. Lunev) Date: Wed, 31 Oct 2018 10:58:38 +0300 Subject: ldapdb_canonuser_plug_init invalid parameter supplied Message-ID: <613c0137-21a2-347f-0d37-25abfc8957f1@zato.ru> Hello everyone! I'm stuck in the problem that cyrus-sasl library doesn't recognize ldapdb auxprop plugin. I have these packages installed on FreeBSD-10.3R: # pkg info | grep sasl cyrus-sasl-2.1.26_13 cyrus-sasl-ldapdb-2.1.26_5 cyrus-sasl-saslauthd-2.1.26_3 openldap-sasl-client-2.4.46 openldap-sasl-server-2.4.46_5 But pluginviewer only lists sasldb plugin, and not ldapdb: # pluginviewer -a Installed and properly configured auxprop mechanisms are: sasldb List of auxprop plugins follows Plugin "sasldb" , API version: 8 supports store: yes And in logs i see this: Oct 31 10:24:17 startsnto pluginviewer: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied Oct 31 10:24:17 startsnto pluginviewer: auxpropfunc error invalid parameter supplied Oct 31 10:24:17 startsnto pluginviewer: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied In fact every sasl-linked program that run on system make such error message in logs (I have also nss_ldap configured, so every call to system functions about uid/gid is also produce this error): ldapwhoami: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied chown: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied saslauthd[15698]: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied But what's more intriguing is that ldapdb plugin is actually working! cyrus-imapd successfully authorizing users with this config file: sasl_pwcheck_method: auxprop sasl_auxprop_plugin: ldapdb sasl_mech_list: cram-md5 digest-md5 plain login sasl_ldapdb_uri: ldap://localhost/ sasl_ldapdb_id: cyradm sasl_ldapdb_pw: somepassword sasl_ldapdb_filter: (uid=%u) sasl_ldapdb_canon_attr: mail /usr/local/lib/sasl2# ls Sendmail.conf libanonymous.so.3.0.0 libcrammd5.so.3.0.0 libdigestmd5.so.3.0.0 liblogin.a libntlm.a libotp.a libplain.a libsasldb.a libscram.a libanonymous.a libcrammd5.a libdigestmd5.a libldapdb.a liblogin.la libntlm.la libotp.la libplain.la libsasldb.la libscram.la libanonymous.la libcrammd5.la libdigestmd5.la libldapdb.so liblogin.so libntlm.so libotp.so libplain.so libsasldb.so libscram.so libanonymous.so libcrammd5.so libdigestmd5.so libldapdb.so.3 liblogin.so.3 libntlm.so.3 libotp.so.3 libplain.so.3 libsasldb.so.3 libscram.so.3 libanonymous.so.3 libcrammd5.so.3 libdigestmd5.so.3 libldapdb.so.3.0.0 liblogin.so.3.0.0 libntlm.so.3.0.0 libotp.so.3.0.0 libplain.so.3.0.0 libsasldb.so.3.0.0 libscram.so.3.0.0 -- Best regards Alexander Lunev From dwhite at olp.net Wed Oct 31 09:38:49 2018 From: dwhite at olp.net (Dan White) Date: Wed, 31 Oct 2018 08:38:49 -0500 Subject: ldapdb_canonuser_plug_init invalid parameter supplied In-Reply-To: <613c0137-21a2-347f-0d37-25abfc8957f1@zato.ru> References: <613c0137-21a2-347f-0d37-25abfc8957f1@zato.ru> Message-ID: <20181031133849.GB10053@dan.olp.net> On 10/31/18?10:58?+0300, Alexander N. Lunev via Cyrus-sasl wrote: >I'm stuck in the problem that cyrus-sasl library doesn't recognize >ldapdb auxprop plugin. > >I have these packages installed on FreeBSD-10.3R: > ># pkg info | grep sasl >cyrus-sasl-2.1.26_13 >cyrus-sasl-ldapdb-2.1.26_5 >cyrus-sasl-saslauthd-2.1.26_3 >openldap-sasl-client-2.4.46 >openldap-sasl-server-2.4.46_5 > >But pluginviewer only lists sasldb plugin, and not ldapdb: > ># pluginviewer -a >Installed and properly configured auxprop mechanisms are: >sasldb >List of auxprop plugins follows >Plugin "sasldb" , API version: 8 > supports store: yes >But what's more intriguing is that ldapdb plugin is actually working! >cyrus-imapd successfully authorizing users with this config file: > >sasl_pwcheck_method: auxprop >sasl_auxprop_plugin: ldapdb >sasl_mech_list: cram-md5 digest-md5 plain login >sasl_ldapdb_uri: ldap://localhost/ >sasl_ldapdb_id: cyradm >sasl_ldapdb_pw: somepassword >sasl_ldapdb_filter: (uid=%u) >sasl_ldapdb_canon_attr: mail To see the plugin with pluginviewer, you'll need to create a config for it under service name 'pluginviewer', with something specificed for the ldapdb_uri parameter. E.g.: ~$ cat /usr/lib/sasl2/pluginviewer.conf | grep ldapdb_uri ldapdb_uri: ldapi:/// /usr/lib/sasl2 is the default but may have been overridden by FreeBSD (with the --with-configdir configure option).