Hi, I'm using cyrus-imapd 4.6.6 and cyrus-sasl-2.1.28 on a Fedora 37 server.
My authentication is done with sasldb (directly, no PAM). And I created my users as: echo "password" | saslpasswd2 -p -c -u mail username But I don't see a difference between creating users this way, and creating them with "-a mail" instead of "-u mail" when I dump the sasldb2. And indeed, "testsaslauthd" succeeds either way... as long as I don't pass in an explicit realm, which is confusing... because one isn't present if I just do "testsaslauthd -u username -p password" (which succeeds). I'm using: sasl_pwcheck_method: saslauthd sasl_mech_list: CRAM-MD6 DIGEST-MD5 Users don't have local accounts, so all username/password credentials come from here. The realm/appname is "mail" so I can use sasldb for other services, while keeping credentials isolated in their own [service] universe. The saslauthd.service is running as: /usr/sbin/saslauthd -m /run/saslauthd -a sasldb -r mail per "ps". Although... that means I can only authenticate for credentials in the "mail" universe, so maybe that's not good after all. So I'll drop "-r mail" from the "saslauthd" invocation, but go back to "testsaslauthd -u username -p password -r mail" and that seems to work well enough. The MS (Cyrus message store, i.e. imap server) host is called "mail.redfish-solutions.com". But when I try to authenticate, I get: philipp64: Jun 15 16:30:08 mail cyrus/imaps[50815]: badlogin: macbook3-4.redfish-solutions.com [192.168.8.12] CRAM-MD5 (-notset-) [SASL(-13): user not found: user: [email protected] property: cmusaslsecretCRAM-MD5 not found in /etc/sasl2/sasldb2] So I tried to override the "domain" that gets substituted in as the "realm" via: defaultdomain: mail in /etc/imapd.conf and restarted the service. No change, and still the same failure message. Looking through source code, it seems that "defaultdomain" doesn't do anything unless "virtdomains: true" is also set. Whaaa....t? Starting to get the feeling that "domain" and "realm" are really blurred here. Seems I have to explicitly do "hostname mail" to get authentication to work... which I don't understand. I should be able to move this service freely between hosts, without it being tied to the hostname. And indeed, I should be able to control all aspects of configuration through explicit settings, right? Nothing about the run-time environment should be bleeding through if I try to override it... yet that's what happens with the hostname. And it seems that "real" and "gethostname()" are also blurred here. It was suggested that instead of "defaultdomain" I try "servername" instead, and that seems to work. But this is getting really confusing. Is there a railroad diagram that explains all the possible values that get used by cyrus-imapd to populate the "realm" field if one isn't given? And in what order? I started to submit a patch for supporting a "defaultrealm" but on reflection, this seems to add more complexity to an already confusing and unintuitive situation. Maybe a better strategy is (1) require explicitly configuring the correct value to use, or (2) limiting the number of external values that can implicitly get filled in as the default. But wait, if I change the hostname back to "mail.redfish-solutions.com" but add the magic incantation: servername: mail Things work ... as best as I can tell. Do they? Let's peek at the dialog over the IMAP/S socket between client and server: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=CRAM-MD5 AUTH=DIGEST-MD5 SASL-IR] mail Cyrus IMAP 3.4.4-2.fc37 Fedora server ready And... hell and damnation. The host banner is presenting as "mail" and not the FQDN. So close... almost... had... it... perfect! Back to the drawing board. Sifting through the source code, I see this: https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/sasldb.c#L233-L237 if(sparams->user_realm) { user_realm = sparams->user_realm; } else { user_realm = sparams->serverFQDN; } And yes, that's in SASL, not the IMAP code of the server. That seems just plain wrong. If we're not passed all the parameters we need, take a guess at them? Not good behavior for a library. And plugins/digestmd5.c and plugins/sql.c make a similar assumption, which means that there's also duplication going on. Seeing other stuff that's questionable in the code, like: https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/digestmd5.c#L4294 params->serverFQDN ? params->serverFQDN : NULL); which is functionally equivalent to: params->serverFQDN); unless I'm missing something. Sorry if I sound grouchy. I've put a lot of time into trying to debug this and I've not figured out an adequate fix, as you can see above. I'm happy to contribute a patch or two to improve things, but first I'd have to understand all the ways that the user realm can be populated, and... how it *should* be populated because implicitly defaulting to various other things seems perilous (it was for me when I changed my hostname and authentication started failing). -Philip ------------------------------------------ Cyrus: SASL Permalink: https://cyrus.topicbox.com/groups/sasl/T3f1dd03bb4edc239-Maeee09dabf84c92b282feb6f Delivery options: https://cyrus.topicbox.com/groups/sasl/subscription
