Email address as username.

[kyrian666]

I don't even know for sure this is the right place to do it, but I've looked through the various docs and I cannot seem to find any useful pointers.

I grow tired of having to reconfigure a certain software vendor's products that seem to think by default usernames should no longer exist, and they are making it increasingly hard to do so. So I am wondering if pam_mysql could be made to cope with user@domain format of usernames. A quick and dirty test shows that a straight swap in the username column doesn't work, and I guess that is because it's stripped off by saslauthd which is also in my auth chain where it matters.

So I'm raising this as an issue to see if we can do it here, and failing that, as a point of reference for other poor unfortunates in future who are trying to answer the same type of question.

Having said that I noticed theres a saslauthd option thusly, which I thought may help:

-r | Combine the realm with the login (with an ’@’ sign in between). e.g. login: "foo" realm: "bar" will get passed as login: "foo@bar". Note that the realm will still be passed, which may lead to unexpected behavior.

But while the logs (for both pam-mysql and mysql itself with query logging enabled) suggest it does pass through user@password format of username it won't authenticate even then. However putting pam_mysql into verbose mode does suggest that it is querying mysql for the user@domain format of username, and in a way that works when run manually at the mysql CLI, so I guess something in the return path isn't working. Or that pam does support realms/domains, and it's just not clear how and where it is configured and written into module code.

However, even if the email address format works, that would break the username-only format of login unless extra code were added to allow for a column with email address as well as the username column that already exists, because you wouldn't want to have just one or the other to avoid users having to reconfigure because you still end up with the same problem. So I guess either way a little bit of extra code will be needed in pam-MySQL.

[kyrian666]

Interesting... Assume the same test rig as described above, by the way. Then... Debian packages a 'pamtester' package. If I search and replace (in my user database table, obviously) a username for email address and use 'pamtester' it authenticates fine with the email address as username at first, then after the search and replace authenticates fine with the email address as well, so the problem with authenticating as an email address with the code as-is must be elsewhere in the chain. But there is still the issue of having an email column as well as a username column to account for here so I'll probably write a patch for that and submit it.

[kyrian666]

A slight expansion on the caveats around "saslauthd -r":

         Note that the realm will still be passed, which may
         lead to unexpected behavior for authentication mechanisms that
         make use of the realm, however for mechanisms which don't, such
         as getpwent, this is the only way to authenticate domain-specific
         users sharing the same userid.

[kyrian666]

Heavily redacted, for obvious reasons. But... This would tend to suggest it's not saslauthd either:

login@server:~# testsaslauthd -u user@domain -p `cat /tmp/pass`  -r "domain" -s service
0: OK "Success."
login@server:~# testsaslauthd -u user@domain -p `cat /tmp/pass`  -r "" -s service
0: OK "Success."

Rather that it's in the server in front of both.

[kyrian666]

There is a user-map pam module that might accomplish this sort of thing a bit easier, but it does not appear to have been picked up by debian, I don't know about other major distros: https://mariadb.com/kb/en/configuring-pam-authentication-and-user-mapping-with-unix-authentication/#installing-the-pam_user_map-pam-module

[NigelCunningham]

Thanks for your messages. Did you have any success in the end?

[kyrian666]

The above is about as far as I took it by the looks of things. I was in the middle of a server build (one that would have benefited a bit from this capability) and had a bad day with a certain vendor's software products and felt like looking into it, but the rest of the server build took precedence. I'll try and return to it at some point, but can't make any promises. Probably the next time a certain vendor's products lead me down this path though!

It should be a trivial process to test, I just didn't want to do it on a production server with something compiled from source rather than a distro package. Maybe it's a job for a weekend though on a development machine first.

[NigelCunningham]

Ok; thanks!

[kyrian666]

Reasons uncertain, only the version of pam_user_map.c up to the mariadb 10.1 compiles. Later versions require a config_auth_pam.h file which is in the .gitignore for the mariadb source code, but looks like it was intended to be included at some point. Maybe they couldn't get it to work with their new build system, who knows?

I got it to build basically by the book from the web page above once I found only up to 10.1 builds. docker run -t -i debian:buster bash apt-get update && apt-get install wget build-essential libpam0g-dev cd /tmp/ wget https://raw.githubusercontent.com/MariaDB/server/10.1/plugin/auth_pam/mapper/pam_user_map.c gcc pam_user_map.c -shared -lpam -fPIC -o pam_user_map.so

I think the ansible run I was waiting on while doing this has got 'stuck' so I'd best return to it now.

[kyrian666]

Oh, this seems to at least compile a more recent version:

root@6cf26832f024:/tmp# apt-get install libmariadb-dev root@6cf26832f024:/tmp# wget https://raw.githubusercontent.com/MariaDB/server/10.6/plugin/auth_pam/mapper/pam_user_map.c ---> Edit the above to use plugin_auth_common.h instead of config_auth_pam.h root@6cf26832f024:/tmp# gcc -I/usr/include/mariadb/mysql/ pam_user_map.c -shared -lpam -fPIC -o pam_user_map.so

But when I make it live with any of these 3 formats of map, I can't authenticate anything at all, it would appear:

"user@domain": otheruser

user@domain: otheruser

3. Completely blank map file.

So I don't think the pam_user_map module is a thing that can help here or with any other such scenario either.

It does seem to authenticate if you have this type of thing in the map file:

user: otheruser

But thereafter my mail server cannot associate the user with its mailbox so that's no good, for me at least.

[NigelCunningham]

Thanks for the info. I'll give it a try this evening, when I'm finished work.

[kyrian666]

I did some more random research around this matter, and it seems that another tiresome consequence of the lack of it is that autoconfiguration for Thunderbird/Outlook can't work properly unless your username exactly matches your email address local part in all cases, because the only other dynamic option seems to be to use the full email address as a username.

[kyrian666]

So, random further look at stuff, and this suggests that it is possible with pam-mysql at that, and it's dated 25 February 2015 (the significance being it's several years before Nigel ported this project to github). Postfix though, and I don't use that.

https://us.informatiweb-pro.net/system-admin/linux/debian-install-and-secure-a-complete-mail-server--4.html

The only immediately notable thing I can see there is that it only uses auth & account PAM checks, where my own config that I tested stuff on previously probably used session and other PAM modules as well by default, so maybe cutting things back to just pam-mysql will unlock this capability.

That's one for another day though as it's bed time here.