Made some weird progress of sorts.
If I go into cyrus-sasl's sasldb/db_gdm.c in _sasldb_getdata() and force:
realm = "mail";
then things start working again. Going to look for a place where I can force
the realm to be "mail" in the configuration, or where the code crept in to set
it to the FQDN...
> On Jun 8, 2023, at 4:31 PM, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>
> It looks pretty harmless:
>
> diff --git a/cyrus-sasl.spec b/cyrus-sasl.spec
> index 2ebbab0..53eaf21 100644
> --- a/cyrus-sasl.spec
> +++ b/cyrus-sasl.spec
> @@ -258,8 +258,8 @@ echo "$LDFLAGS"
> %endif
> --enable-sql --with-mysql=yes --with-pgsql=yes \
> --without-sqlite \
> + --enable-auth-sasldb \
> "$@"
> - # --enable-auth-sasldb -- EXPERIMENTAL
> make sasldir=%{_plugindir2}
> make -C saslauthd testsaslauthd
> make -C sampl
>
>
> So, let me try a different tack.
>
> When I stop saslauthd.service and run it from the command line, and try
> "testsaslauthd ..." manually, I see a transaction and debugging output.
>
> When I try "Get mail" with my MacOS mail client, I don't see any output, like
> "auxprop" is accessing the database directly?
>
> There's not a whole lot of documentation about "auxprop" or how to debug it...
>
> Can I use "sasldb" directly in imapd.conf? Any guidelines to troubleshooting
> it?
>
> I tried using sasldb but don't see any change in authentication failure.
>
> Time to start building .rpm's with debug logs...
>
>
>
>> On Jun 8, 2023, at 11:48 AM, Simo Sorce <s...@redhat.com> wrote:
>>
>> This is the diff between F37 and F36, maybe you'll find some clue
>> there:
>>
>> $ git log --oneline origin/f36..origin/f37
>> e0d1e57 (origin/f37) Avoid requires on systemd as well as per updated
>> guidelines
>> db25e25 Avoid systemd_requires as per updated packaging guidelines
>> a64513d (HEAD -> rawhide) Fix memory leak in digestmd5 patches
>> b96caf4 Rebuilt for
>> https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
>> 7f6beb6 (pag/sysusers, sysusers) Use systemd sysusers to create
>> saslauth user
>> de822fc Enable sasldb authentication mechanism
>> a1359a4 (pag/rawhide, pag/main) Fix changelog section with correct
>> syntax
>> eba3ea5 Update to 2.1.28
>> b229146 Move to use autorelease macro
>> d09a799 Move to use the autochangelog macro
>>
>> HTH,
>> Simo.
>>
>>
>> On Thu, 2023-06-08 at 10:39 -0600, Philip Prindeville wrote:
>>> Hi,
>>>
>>> I had been running F36 and updated to F37. After rebooting, authentication
>>> started failing (seemingly sporadically).
>>>
>>> I'm seeing:
>>>
>>> Jun 8 10:32:10 mail cyrus/imaps[16976]: starttls: TLSv1.2 with cipher
>>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits new) no authentication
>>> Jun 8 10:32:10 mail cyrus/imaps[16976]: client id
>>> sessionid=<cyrus-1686241930-16976-1-13642841045060016715>: "name" "Mac OS X
>>> Mail" "version" "16.0 (3731.600.7)" "os" "Mac OS X" "os-version" "13.4
>>> (22F66)" "vendor" "Apple Inc."
>>> Jun 8 10:32:10 mail cyrus/imaps[16976]: badlogin:
>>> macbook3-3.redfish-solutions.com [192.168.8.12] CRAM-MD5 (-notset-)
>>> [SASL(-13): user not found: user: joeb...@mail.redfish-solutions.com
>>> property: cmusaslsecretCRAM-MD5 not found in /etc/sasl2/sasldb2]
>>>
>>> But I shouldn't be seeing any domain at all (or realm, whichever) when the
>>> SASL lookups are done.
>>>
>>> This has worked in my configuration for years. Not sure why it's suddenly
>>> failing with the update.
>>>
>>> The relevant part of my /etc/imapd.conf is:
>>>
>>> sasl_pwcheck_method: auxprop
>>> sasl_mech_list: CRAM-MD5 DIGEST-MD5
>>>
>>> And if I use "testsaslauthd -u user -p password" I get a Success.
>>>
>>> This is what I'm running:
>>>
>>> cyrus-imapd-3.4.4-2.fc37.x86_64
>>> cyrus-imapd-libs-3.4.4-2.fc37.x86_64
>>> cyrus-imapd-utils-3.4.4-2.fc37.x86_64
>>> cyrus-sasl-2.1.28-8.fc37.x86_64
>>> cyrus-sasl-lib-2.1.28-8.fc37.x86_64
>>> cyrus-sasl-md5-2.1.28-8.fc37.x86_64
>>> cyrus-sasl-ntlm-2.1.28-8.fc37.x86_64
>>> cyrus-sasl-plain-2.1.28-8.fc37.x86_64
>>>
>>> SMTP Submission (port 587) with Sendmail AUTH continues to work, and that's
>>> using SASL and the same credentials, so the database isn't corrupted.
>>>
>>> My clients are MacOS and iOS, if that matters.
>>>
>>> I ran the session logging on MacOS and decoded the AUTH transaction in
>>> IMAP/S, and it's definitely sending just the username, no realm/domain...
>>> so no idea where this is creeping in.
>>>
>>> Mail is down, and there's an angry mob outside my office...
>>>
>>> Any assistance?
>>>
>>> Thanks,
>>>
>>> -Philip
>>>
>>
>> --
>> Simo Sorce
>> RHEL Crypto Team
>> Red Hat, Inc
>>
------------------------------------------
Cyrus: Devel
Permalink:
https://cyrus.topicbox.com/groups/devel/Td95652dad981f128-M49e8eabc8f7a0ffa3085924c
Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
