<div dir="ltr">I just thought I would answer my own email in case anyone else has the same setup. I found out there is obviously some type of bug in the -23 versions of the SASL packages so they just won't work. Once reverting to the -20 or -21 versions, everything works great. My suspicion about the faulty SASL was correct, but since there was only a problem with the daemons themselves and not mupdatetest and imtest, it was difficult to see this. I suppose I should report this to the SASL list, but I'm really not sure what to say since the logging information is rather incomplete.<div><br></div><div>Steve<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 1, 2018 at 5:16 PM, Stephen Ingram <span dir="ltr"><<a href="mailto:sbingram@gmail.com" target="_blank">sbingram@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I recently upgraded a CentOS 7 Cyrus 2.4.17 system with Murder and Kerberos and ran into lots of issues with the new packages. What's really puzzling though is although I used to be able to use a SASL minimum layer of 256 (I'm using TLS with GSSAPI for auth), I now must use 1 for the front-ends and backends communicating to the mupdate server. I've run into SASL package issues before (2.1.23 to 2.1.26 was a mess) and had to actually revert to an older version so I'm thinking that might be the problem. However, when I use mupdatetest and imtest, everything works perfectly. It's only when I fire up the daemons themselves that I see:<div><br></div><div><div>Jun  1 23:53:21 imap mupdate[19865]: couldn't authenticate to backend server: mechanism too weak for this user</div><div>Jun  1 23:53:21 imap mupdate[19865]: mupdate_connect failed: no auth status</div><div>Jun  1 23:53:21 imap mupdate[19865]: couldn't connect to mupdate server</div><div>Jun  1 23:53:21 imap mupdate[19865]: retrying connection to mupdate server in 27 seconds</div></div><div><br></div><div>If I grab a ticket and mupdatetest -m GSSAPI -t '' <a href="http://mupdate.test.net" target="_blank">mupdate.test.net</a> with a 256 min layer, I get in perfectly. So perhaps it's a change/new config issue in cyrus-imap this time around?</div><div><br></div><div>I'm using cyrus-imapd-2.4.17-13 and cyrus-sasl-2.1.26-23 versions of the various package sets.</div><div><br></div><div>Steve</div></div>
</blockquote></div><br></div></div></div>