From murch at fastmail.com Tue Sep 18 10:10:56 2018 From: murch at fastmail.com (Ken Murchison) Date: Tue, 18 Sep 2018 10:10:56 -0400 Subject: SASL 2.1.27 rc8 In-Reply-To: References: Message-ID: 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. On 5/10/18 8:28 PM, Ken Murchison wrote: > > All, > > I have built a eighth (and hopefully last) release candidate of SASL > 2.1.27 which can be downloaded from here: > > * HTTP: > > https://www.cyrusimap.org/releases/cyrus-sasl-2.1.27-rc8.tar.gz > https://www.cyrusimap.org/releases/cyrus-sasl-2.1.27-rc8.tar.gz.sig > > * FTP: > > ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.27-rc8.tar.gz > ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.27-rc8.tar.gz.sig > > > The primary reason for this candidate is to revert the GSSAPI flag > changes.? I'd like to roll out the final release early next week, so > please test this RC as soon as possible. > > > The (mostly) complete list of changes from 2.1.26 are these: > > * Added support for OpenSSL 1.1 > * Added support for lmdb (from Howard Chu) > * Lots of build fixes (from Ignacio Casal Quinteiro and others) > * Treat SCRAM and DIGEST-MD5 as more secure than PLAIN when > selecting client mech > * DIGEST-MD5 plugin: > o Fixed memory leaks > o Fixed a segfault when looking for non-existent reauth cache > o Prevent client from going from step 3 back to step 2 > o Allow cmusaslsecretDIGEST-MD5 property to be disabled > * GSSAPI plugin: > o Added support for retrieving negotiated SSF > o Properly compute maxbufsize AFTER security layers have been set > * SCRAM plugin: > o Added support for SCRAM-SHA-256 > o Allow SCRAM-* to be used by HTTP > * LOGIN plugin: > o Don?t prompt client for password until requested by server > * NTLM plugin: > o Fixed crash due to uninitialized HMAC context > * saslauthd: > o cache.c: > + Don?t use cached credentials if timeout has expired > + Fixed debug logging output > o ipc_doors.c: > + Fixed potential DoS attack (from Oracle) > o ipc_unix.c: > + Prevent premature closing of socket > o auth_rimap.c: > + Added support LOGOUT command > + Added support for unsolicited CAPABILITY responses in > LOGIN reply > + Properly detect end of responses (don?t needlessly wait) > + Properly handle backslash in passwords > o auth_httpform: > + Fix off-by-one error in string termination > + Added support for 204 success response > o auth_krb5.c: > + Added krb5_conv_krb4_instance option > + Added more verbose error logging > > > > At this point any major changes (e.g. API, wire protocol) will be > pushed out to 2.1.28 or 2.2.0. > > -- > Kenneth Murchison > Cyrus Development Team > FastMail Pty Ltd -- Ken Murchison Cyrus Development Team FastMail US LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From quanah at symas.com Tue Sep 18 11:05:48 2018 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 18 Sep 2018 08:05:48 -0700 Subject: SASL 2.1.27 rc8 In-Reply-To: References: Message-ID: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> --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: From jan.parcel at oracle.com Tue Sep 18 12:10:54 2018 From: jan.parcel at oracle.com (Jan Parcel) Date: Tue, 18 Sep 2018 09:10:54 -0700 Subject: Docs and 2.1.27 and threads In-Reply-To: References: Message-ID: <5BA1238E.7050701@oracle.com> I have not had time to look at all the docs to see what changed, but we have had a problem here with a multi-threaded program calling sasl_client_init multiple times in parallel and getting crashes and hangs. I've found various comments inside code and on the web about which routines are vs. are not thread-safe, including that the sasl_set_* routines are not, but I have not seen anything that says "make sure you don't have parallel calls to sasl_client_init" Can there be some kind of note somewhere about thread safety? Sometime, if I have time, I will be trying to make sasl_client_init thread-safe if possible, probably using static pthread locks (in a library, static locks are the ONLY way to guarantee no parallel mutex lock creation, which is a big no-no) but I got stuck on a non-sasl customer issue which might take me a long time. From abokovoy at redhat.com Tue Sep 18 14:32:33 2018 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Sep 2018 21:32:33 +0300 Subject: Docs and 2.1.27 and threads In-Reply-To: <5BA1238E.7050701@oracle.com> References: <5BA1238E.7050701@oracle.com> Message-ID: <20180918183233.GX23348@redhat.com> On ti, 18 syys 2018, Jan Parcel wrote: >I have not had time to look at all the docs to see what changed, but >we have had a problem here with a multi-threaded program calling >sasl_client_init multiple times in parallel and getting crashes and >hangs. > >I've found various comments inside code and on the web about which >routines are vs. are not thread-safe, including that the sasl_set_* >routines are not, but I have not seen anything >that says "make sure you don't have parallel calls to sasl_client_init" > >Can there be some kind of note somewhere about thread safety? > >Sometime, if I have time, I will be trying to make sasl_client_init >thread-safe if possible, probably using static pthread locks (in a >library, static locks are the ONLY way to guarantee >no parallel mutex lock creation, which is a big no-no) but I got stuck >on a non-sasl customer issue which might take me a long time. It used to be not possible to run SASL server and SASL client in the same application at the same time with GSSAPI plugin as it was using the same static lock for both. I changed that to use per-context locks. As long as you are not sharing the same SASL context among multiple threads with GSSAPI, there shouldn't be a problem. GSSAPI itself is blocking but Cyrus-SASL will not block threads working on different SASL contexts. This cannot be extended to other plugins. digestmd5 uses a single reauth cache entry lock shared among all contexts. krb4 deals with non-threaded kerberos4 library and thus has a single static lock. It is mostly dead as krb4 is quite rare to see in real life. Other plugins don't use locking at all. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland From jan.parcel at oracle.com Tue Sep 18 15:05:27 2018 From: jan.parcel at oracle.com (jan parcel) Date: Tue, 18 Sep 2018 12:05:27 -0700 Subject: Docs and 2.1.27 and threads In-Reply-To: <20180918183233.GX23348@redhat.com> References: <5BA1238E.7050701@oracle.com> <20180918183233.GX23348@redhat.com> Message-ID: Then it might be a good idea to ONLY lock sasl_client_init, and maybe only until the variable is set that it is already initialized. What I was seeing was multiple threads calling sasl_client_init at the same time, thus running multiple copies of the early plugin loading that loads all plugins.? Since we provide multiple plugins (it is for the customer to configure which ones to use), it made a mess.? For now, the solution was to tell the caller "don't do that." On 9/18/2018 11:32 AM, Alexander Bokovoy wrote: > On ti, 18 syys 2018, Jan Parcel wrote: >> I have not had time to look at all the docs to see what changed, but >> we have had a problem here with a multi-threaded program calling >> sasl_client_init multiple times in parallel and getting crashes and >> hangs. >> >> I've found various comments inside code and on the web about which >> routines are vs. are not thread-safe, including that the sasl_set_* >> routines are not, but I have not seen anything >> that says "make sure you don't have parallel calls to sasl_client_init" >> >> Can there be some kind of note somewhere about thread safety? >> >> Sometime, if I have time, I will be trying to make sasl_client_init >> thread-safe if possible,? probably using static pthread locks (in a >> library, static locks are the ONLY way to guarantee >> no parallel mutex lock creation, which is a big no-no) but I got >> stuck on a non-sasl customer issue which might take me a long time. > It used to be not possible to run SASL server and SASL client in the > same application at the same time with GSSAPI plugin as it was using the > same static lock for both. I changed that to use per-context locks. As > long as you are not sharing the same SASL context among multiple threads > with GSSAPI, there shouldn't be a problem. GSSAPI itself is blocking but > Cyrus-SASL will not block threads working on different SASL contexts. > > This cannot be extended to other plugins. digestmd5 uses a single > reauth cache entry lock shared among all contexts. krb4 deals with > non-threaded kerberos4 library and thus has a single static lock. It is > mostly dead as krb4 is quite rare to see in real life. Other plugins > don't use locking at all. > -- Jan Parcel, Software Developer Oracle Systems Server & Cloud Engineering From murch at fastmail.com Thu Sep 20 11:57:36 2018 From: murch at fastmail.com (Ken Murchison) Date: Thu, 20 Sep 2018 11:57:36 -0400 Subject: SASL 2.1.27 rc8 In-Reply-To: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> References: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> Message-ID: <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: rc8.diff Type: text/x-patch Size: 3778 bytes Desc: not available URL: From quanah at symas.com Thu Sep 20 13:02:16 2018 From: quanah at symas.com (Quanah Gibson-Mount) Date: Thu, 20 Sep 2018 10:02:16 -0700 Subject: SASL 2.1.27 rc8 In-Reply-To: <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> References: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> Message-ID: --On Thursday, September 20, 2018 12:57 PM -0400 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. Thanks Ken! I followed up on 529. The issue you raised definitely needs to be addressed, I proposed a fix in my comments. The main issue being fixed in my pull request is the fact that plugindir was hard coded regardless of what option was passed to configure. The issue you raised is that the default value for plugindir in configure conflicts with what the hard coded value was in the makefile. My suggested patch in the comment aligns the two. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From julien at trigofacile.com Thu Sep 20 16:03:11 2018 From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=) Date: Thu, 20 Sep 2018 22:03:11 +0200 Subject: SASL 2.1.27 rc8 In-Reply-To: <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> References: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> Message-ID: Hi Ken, > 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. Many thanks for taking time to finalize the release this week. Greatly appreciated. FWIW, building with GCC 8.1 gives the following warnings (one -Wtautological-compare and all the others are -Wcast-function-type). saslutil.c: In function ?sasl_utf8verify?: saslutil.c:305:29: warning: bitwise comparison always evaluates to true [-Wtautological-compare] if ((str[++i] & 0xC0) != 0xF0) return SASL_BADPROT; /* needed a 10 octet */ ^~ common.c:114:22: warning: cast between incompatible function types from ?int (*)(void *, const char **)? to ?int (*)(void)? [-Wcast-function-type] SASL_CB_GETPATH, (sasl_callback_ft)&_sasl_getpath, NULL ^ common.c:117:26: warning: cast between incompatible function types from ?int (*)(void *, char **)? to ?int (*)(void)? [-Wcast-function-type] SASL_CB_GETCONFPATH, (sasl_callback_ft)&_sasl_getconfpath, NULL ^ common.c: In function ?sasl_set_path?: common.c:230:39: warning: cast between incompatible function types from ?int (*)(void *, const char **)? to ?int (*)(void)? [-Wcast-function-type] default_getpath_cb.proc = (sasl_callback_ft)&_sasl_getpath_simple; ^ common.c:244:43: warning: cast between incompatible function types from ?int (*)(void *, const char **)? to ?int (*)(void)? [-Wcast-function-type] default_getconfpath_cb.proc = (sasl_callback_ft)&_sasl_getconfpath_simple; ^ common.c: In function ?_sasl_global_getopt?: common.c:1416:9: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? [-Wcast-function-type] if (((sasl_getopt_t *)(callback->proc))(callback->context, ^ common.c: In function ?_sasl_conn_getopt?: common.c:1457:9: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? [-Wcast-function-type] && (((sasl_getopt_t *)(callback->proc))(callback->context, ^ common.c: In function ?_sasl_getcallback?: common.c:1731:13: warning: cast between incompatible function types from ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? to ?int (*)(void)? [-Wcast-function-type] *pproc = (sasl_callback_ft)&_sasl_conn_getopt; ^ common.c:1734:13: warning: cast between incompatible function types from ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? to ?int (*)(void)? [-Wcast-function-type] *pproc = (sasl_callback_ft)&_sasl_global_getopt; ^ common.c:1779:14: warning: cast between incompatible function types from ?int (*)(void *, int, const char *)? to ?int (*)(void)? [-Wcast-function-type] *pproc = (sasl_callback_ft)&_sasl_syslog; ^ common.c:1792:14: warning: cast between incompatible function types from ?int (*)(void *, int, const char **, size_t *)? {aka ?int (*)(void *, int, const char **, long unsigned int *)?} to ?int (*)(void)? [-Wcast-function-type] *pproc = (sasl_callback_ft)&_sasl_getsimple; ^ common.c:1796:14: warning: cast between incompatible function types from ?int (*)(void *, char *, int)? to ?int (*)(void)? [-Wcast-function-type] *pproc = (sasl_callback_ft)&_sasl_verifyfile; ^ common.c:1800:14: warning: cast between incompatible function types from ?int (*)(sasl_conn_t *, void *, const char *, unsigned int, const char *, unsigned int, const char *, unsigned int, struct propctx *)? {aka ?int (*)(struct sasl_conn *, void *, const char *, unsigned int, const char *, unsigned int, const char *, unsigned int, struct propctx *)?} to ?int (*)(void)? [-Wcast-function-typ] *pproc = (sasl_callback_ft)&_sasl_proxy_policy; ^ common.c: In function ?_sasl_find_verifyfile_callback?: common.c:2156:5: warning: cast between incompatible function types from ?int (*)(void *, char *, int)? to ?int (*)(void)? [-Wcast-function-type] (sasl_callback_ft)&_sasl_verifyfile, ^ server.c:619:15: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, char **)? [-Wcast-function-type] result = ((sasl_getconfpath_t *)(getconfpath_cb->proc))(getconfpath_cb->context, ^ server.c:657:19: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char *, sasl_verify_type_t)? {aka ?int (*)(void *, const char *, enum )?} [-Wcast-function-type] result = ((sasl_verifyfile_t *)(verifyfile_cb->proc))(verifyfile_cb->context, ^ server.c: In function ?sasl_server_init?: server.c:909:9: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char *, sasl_verify_type_t)? {aka ?int (*)(void *, const char *, enum )?} [-Wcast-function-type] ret = ((sasl_verifyfile_t *)(vf->proc))(vf->context, ^ dlopen.c: In function ?_sasl_get_plugin?: dlopen.c:364:10: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char *, sasl_verify_type_t)? {aka ?int (*)(void *, const char *, enum )?} [-Wcast-function-type] r = ((sasl_verifyfile_t *)(verifyfile_cb->proc)) ^ dlopen.c: In function ?_sasl_load_plugins?: dlopen.c:464:15: warning: cast between incompatible function types from ?int (* const)(void)? to ?int (*)(void *, const char **)? [-Wcast-function-type] result = ((sasl_getpath_t *)(getpath_cb->proc))(getpath_cb->context, ^ dbconverter-2.c:379:23: warning: cast between incompatible function types from int (*)(void *, const char *, const char *, const char **, unsigned int *)? to int (*)(void)? [-Wcast-function-type] { SASL_CB_GETOPT, (int (*)(void))&good_getopt, NULL }, ^ dbconverter-2.c: In function ?main?: dbconverter-2.c:428:19: warning: cast between incompatible function types from void (*)(const char *, const char *, const char *, const char *, unsigned int)? to ?void * (*)(const char *, const char *, const char *, const char *, unsigned int)? [-Wcast-function-type] listusers(db, (listcb_t *) &listusers_cb); ^ saslpasswd.c:256:23: warning: cast between incompatible function types from ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? to ?int (*)(void)? [-Wcast-function-type] { SASL_CB_GETOPT, (sasl_callback_ft)&good_getopt, NULL }, ^ sasldblistusers.c:91:23: warning: cast between incompatible function types from ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? to ?int (*)(void)? [-Wcast-function-type] { SASL_CB_GETOPT, (sasl_callback_ft)&good_getopt, NULL }, ^ pluginviewer.c: In function ?main?: pluginviewer.c:559:22: warning: cast between incompatible function types from ?int (*)(void *, int, const char *)? to ?int (*)(void)? [-Wcast-function-type] callback->proc = (sasl_callback_ft)&sasl_my_log; ^ pluginviewer.c:566:26: warning: cast between incompatible function types from ?int (*)(void *, const char **)? to ?int (*)(void)? [-Wcast-function-type] callback->proc = (sasl_callback_ft)&getpath; ^ pluginviewer.c:575:22: warning: cast between incompatible function types from ?int (*)(void *, const char *, const char *, const char **, unsigned int *)? to ?int (*)(void)? [-Wcast-function-type] callback->proc = (sasl_callback_ft)&plugview_sasl_getopt; ^ -- Julien ?LIE ??Destiny decides who you meet in life but it's only your heart that can decide who gets to stay in your life.?? From murch at fastmail.com Mon Sep 24 05:25:59 2018 From: murch at fastmail.com (Ken Murchison) Date: Mon, 24 Sep 2018 05:25:59 -0400 Subject: SASL 2.1.27 rc8 In-Reply-To: <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> References: <73D508D78D1CBDBE76F5A285@[192.168.1.39]> <24ddcd24-49b1-cf70-ab19-816f48c288ef@fastmail.com> Message-ID: <5c9500d8-c707-f68c-b366-29254f35726a@fastmail.com> 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 raines at nmr.mgh.harvard.edu Thu Sep 27 16:04:02 2018 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Thu, 27 Sep 2018 16:04:02 -0400 (EDT) Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 Message-ID: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> I have a saslauthd server running on a CentOS6 system that I want to upgrade to CentOS7. On the CentOS6 system I have /etc/saslauthd.conf set as (domain changed): ldap_servers: ldaps://ldap.foobar.org ldap_use_sasl: yes ldap_mech: DIGEST-MD5 and saslauthd is run as /usr/sbin/saslauthd -m /run/saslauthd -a ldap -O /etc/saslauthd.conf The LDAP server is the LDAP portal of the corporate AD server. This works fine as 'testsaslauthd -s ldap ...' succeeds. This same config worked when it was on a CentOS5 system. When I set up this identical config on a test CentOS7 system the testsaslauthd always fails. Debug output is Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 parse_server_challenge() Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 make_client_response() Aug 24 11:05:42 hound saslauthd[118834]: Authentication failed for per2: Bind to ldap server failed (invalid user/password or insufficient access) (-7) Aug 24 11:05:42 hound saslauthd[118834]: do_auth : auth failure: [user=per2] [service=ldap] [realm=] [mech=ldap] [reason=Unknown] I have tried ldap_auth_method with 'bind' and 'fastbind' and ldap_use_sasl set to no, but every combo fails. It does work to use a /etc/saslauthd.conf with explicit credentials such as ldap_servers: ldaps://ldap.foobar.org ldap_search_base: dc=foobar,dc=org ldap_filter: (sAMAccountName=%u) ldap_bind_dn: cn=myuid,cn=users,dc=foobar,dc=org ldap_password: ********* but I don't like putting my password in a config file and also having to remember to change it everytime the password changes in AD Does anyone have any ideas why the initial setup does not work in CentOS7? --------------------------------------------------------------- Paul Raines http://help.nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA From dwhite at olp.net Fri Sep 28 14:36:33 2018 From: dwhite at olp.net (Dan White) Date: Fri, 28 Sep 2018 13:36:33 -0500 Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> Message-ID: <20180928183633.GA3318@dan.olp.net> On 09/27/18?16:04?-0400, Paul Raines wrote: >I have a saslauthd server running on a CentOS6 system that I want >to upgrade to CentOS7. On the CentOS6 system I have /etc/saslauthd.conf >set as (domain changed): > >ldap_servers: ldaps://ldap.foobar.org >ldap_use_sasl: yes >ldap_mech: DIGEST-MD5 > >and saslauthd is run as > >/usr/sbin/saslauthd -m /run/saslauthd -a ldap -O /etc/saslauthd.conf > >The LDAP server is the LDAP portal of the corporate AD server. > >This works fine as 'testsaslauthd -s ldap ...' succeeds. This >same config worked when it was on a CentOS5 system. > >When I set up this identical config on a test CentOS7 system the >testsaslauthd always fails. Debug output is > >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 parse_server_challenge() >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() >Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 make_client_response() >Aug 24 11:05:42 hound saslauthd[118834]: Authentication failed for >per2: Bind to ldap server failed (invalid user/password or >insufficient access) (-7) >Aug 24 11:05:42 hound saslauthd[118834]: do_auth : auth >failure: [user=per2] [service=ldap] [realm=] [mech=ldap] >[reason=Unknown] > >I have tried ldap_auth_method with 'bind' and 'fastbind' and >ldap_use_sasl set to no, but every combo fails. > >It does work to use a /etc/saslauthd.conf with explicit credentials such >as > >ldap_servers: ldaps://ldap.foobar.org >ldap_search_base: dc=foobar,dc=org >ldap_filter: (sAMAccountName=%u) >ldap_bind_dn: cn=myuid,cn=users,dc=foobar,dc=org >ldap_password: ********* > >but I don't like putting my password in a config file and also having >to remember to change it everytime the password changes in AD > >Does anyone have any ideas why the initial setup does not work >in CentOS7? Check your DNS settings. Trouble shoot this by using the ldap client utilities directly: ldapwhoami -d -1 -H ldaps://ldap.foobar.org -Y DIGEST-MD5 -U per2 -W From raines at nmr.mgh.harvard.edu Fri Sep 28 15:19:33 2018 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Fri, 28 Sep 2018 15:19:33 -0400 (EDT) Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: <20180928183633.GA3318@dan.olp.net> References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> <20180928183633.GA3318@dan.olp.net> Message-ID: Thanks! That has got me to a solution On my C5/C6 boxes running ldapwhoami -d -1 -H ldaps://ldap.foobar.org -Y DIGEST-MD5 -U per2 -W worked giving: SASL/DIGEST-MD5 authentication started SASL username: per2 SASL SSF: 0 u:FOOBAR\per2 But on my C7 machines I would get SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090303: LdapErr: DSID-0C090520, comment: The digest-uri does not match any LDAP SPN's registered for this server., data 0, v1db1 Looking at the debug output on the C5/C6 boxes I saw in the dump section something that said digest-uri="ldap/dc8.foobar.org" while in the same section on a C7 box I saw digest-uri="ldap/ldap.foobar.org" A "host ldap.partners.org" gives back 4 IP address which match the dc8, dc3, dc12, and dc10 actual host names. If I run ldapwhoami -d -1 -H ldaps://dc8.foobar.org -Y DIGEST-MD5 -U per2 -W on the C7 box it works fine. If I change /etc/saslauthd.conf to use dc8.foobar.org it works fine for testsaslauthd too. The only issue doing this is I lose high availability. But I can actually list the explicity in the "ldap_servers:" line so I can get around that. Any idea why on C7 the DIGEST-MD5 thing going on does not set digest-uri like it does on C6? I guess that is really a question for the openldap devs. Thanks again On Fri, 28 Sep 2018 2:36pm, Dan White wrote: > External Email - Use Caution > On 09/27/18?16:04?-0400, Paul Raines wrote: >> I have a saslauthd server running on a CentOS6 system that I want >> to upgrade to CentOS7. On the CentOS6 system I have /etc/saslauthd.conf >> set as (domain changed): >> >> ldap_servers: ldaps://ldap.foobar.org >> ldap_use_sasl: yes >> ldap_mech: DIGEST-MD5 >> >> and saslauthd is run as >> >> /usr/sbin/saslauthd -m /run/saslauthd -a ldap -O /etc/saslauthd.conf >> >> The LDAP server is the LDAP portal of the corporate AD server. >> >> This works fine as 'testsaslauthd -s ldap ...' succeeds. This >> same config worked when it was on a CentOS5 system. >> >> When I set up this identical config on a test CentOS7 system the >> testsaslauthd always fails. Debug output is >> >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 >> parse_server_challenge() >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 client step 2 >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 ask_user_info() >> Aug 24 11:05:42 hound saslauthd[118834]: DIGEST-MD5 make_client_response() >> Aug 24 11:05:42 hound saslauthd[118834]: Authentication failed for per2: >> Bind to ldap server failed (invalid user/password or insufficient access) >> (-7) >> Aug 24 11:05:42 hound saslauthd[118834]: do_auth : auth failure: >> [user=per2] [service=ldap] [realm=] [mech=ldap] [reason=Unknown] >> >> I have tried ldap_auth_method with 'bind' and 'fastbind' and >> ldap_use_sasl set to no, but every combo fails. >> >> It does work to use a /etc/saslauthd.conf with explicit credentials such >> as >> >> ldap_servers: ldaps://ldap.foobar.org >> ldap_search_base: dc=foobar,dc=org >> ldap_filter: (sAMAccountName=%u) >> ldap_bind_dn: cn=myuid,cn=users,dc=foobar,dc=org >> ldap_password: ********* >> >> but I don't like putting my password in a config file and also having to >> remember to change it everytime the password changes in AD >> >> Does anyone have any ideas why the initial setup does not work >> in CentOS7? > > Check your DNS settings. > > Trouble shoot this by using the ldap client utilities directly: > > ldapwhoami -d -1 -H ldaps://ldap.foobar.org -Y DIGEST-MD5 -U per2 -W > > > > From quanah at symas.com Fri Sep 28 15:44:51 2018 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 28 Sep 2018 12:44:51 -0700 Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> <20180928183633.GA3318@dan.olp.net> Message-ID: <3C7E00077B3ED0F4D73DA1DF@[192.168.1.39]> --On Friday, September 28, 2018 4:19 PM -0400 Paul Raines wrote: > Any idea why on C7 the DIGEST-MD5 thing going on does not set > digest-uri like it does on C6? I guess that is really a question > for the openldap devs. Seems more like a DNS resolution issue than an OpenLDAP issue. RHEL6 uses OpenLDAP 2.4.40, RHEL7 uses OpenLDAP 2.4.44. There haven't been any changes related to this functionality between the two. It's possible RedHat has made their own custom modifications in this arena so you might want to look for any differences there. However, it seems more that on your CentOS 5/6 boxes that when DNS is queried for "ldap.foobar.org" it gets back "dc8.foobar.org" whereas on your CentOS7 box, it gets back "ldap.foobar.org". --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From raines at nmr.mgh.harvard.edu Fri Sep 28 15:58:09 2018 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Fri, 28 Sep 2018 15:58:09 -0400 (EDT) Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: <3C7E00077B3ED0F4D73DA1DF@[192.168.1.39]> References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> <20180928183633.GA3318@dan.olp.net> <3C7E00077B3ED0F4D73DA1DF@[192.168.1.39]> Message-ID: On Fri, 28 Sep 2018 3:44pm, Quanah Gibson-Mount wrote: > External Email - Use Caution > --On Friday, September 28, 2018 4:19 PM -0400 Paul Raines > wrote: > >> Any idea why on C7 the DIGEST-MD5 thing going on does not set >> digest-uri like it does on C6? I guess that is really a question >> for the openldap devs. > > Seems more like a DNS resolution issue than an OpenLDAP issue. RHEL6 uses > OpenLDAP 2.4.40, RHEL7 uses OpenLDAP 2.4.44. There haven't been any changes > related to this functionality between the two. It's possible RedHat has made > their own custom modifications in this arena so you might want to look for > any differences there. > > However, it seems more that on your CentOS 5/6 boxes that when DNS is queried > for "ldap.foobar.org" it gets back "dc8.foobar.org" whereas on your CentOS7 > box, it gets back "ldap.foobar.org". > Running 'host ldap.foobar.org' on the C6 and C7 machine both return the exact same four lines/IPs. Reverse DNS of the 4 IPs using the host command is also the same on both C6 and C7 machines. It really looks like OpenLDAP is just not doing the reverse DNS on C7 when building the MD5 digest From quanah at symas.com Fri Sep 28 16:12:26 2018 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 28 Sep 2018 13:12:26 -0700 Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> <20180928183633.GA3318@dan.olp.net> <3C7E00077B3ED0F4D73DA1DF@[192.168.1.39]> Message-ID: --On Friday, September 28, 2018 4:58 PM -0400 Paul Raines wrote: > Running 'host ldap.foobar.org' on the C6 and C7 machine both return the > exact same four lines/IPs. Reverse DNS of the 4 IPs using the host > command is also the same on both C6 and C7 machines. It really looks > like OpenLDAP is > just not doing the reverse DNS on C7 when building the MD5 digest Hi Paul, Again, as I stated, there have been no changes to OpenLDAP in this area. Additionally, OpenLDAP leverages cyrus-sasl for SASL mechanism negotiations. The culprit most likely would be a change in the version of cyrus-sasl being used between C5/C6 and C7. c7 has: 2.1.26-23.el7 c6 has: 2.1.23-15.el6_6.2 Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From raines at nmr.mgh.harvard.edu Fri Sep 28 16:24:25 2018 From: raines at nmr.mgh.harvard.edu (Paul Raines) Date: Fri, 28 Sep 2018 16:24:25 -0400 (EDT) Subject: same SASL config that works on CentOS5 & 6 fails on CentOS7 In-Reply-To: References: <120275_1538079067_w8RKB5mn001419_alpine.LRH.2.21.1809271551440.26779@entry.nmr.mgh.harvard.edu> <20180928183633.GA3318@dan.olp.net> <3C7E00077B3ED0F4D73DA1DF@[192.168.1.39]> Message-ID: On Fri, 28 Sep 2018 4:12pm, Quanah Gibson-Mount wrote: > External Email - Use Caution > --On Friday, September 28, 2018 4:58 PM -0400 Paul Raines > wrote: > >> Running 'host ldap.foobar.org' on the C6 and C7 machine both return the >> exact same four lines/IPs. Reverse DNS of the 4 IPs using the host >> command is also the same on both C6 and C7 machines. It really looks >> like OpenLDAP is >> just not doing the reverse DNS on C7 when building the MD5 digest > > Hi Paul, > > Again, as I stated, there have been no changes to OpenLDAP in this area. > Additionally, OpenLDAP leverages cyrus-sasl for SASL mechanism negotiations. > The culprit most likely would be a change in the version of cyrus-sasl being > used between C5/C6 and C7. > > c7 has: 2.1.26-23.el7 > c6 has: 2.1.23-15.el6_6.2 > Okay, that makes sense. Though the change may go even deeper such as newer openssl or other crypto library maybe. Thanks