Need help with mapping usernames

Hello,

We could use some advice on mapping usernames.

We have an OOD site that is being accessed by users in multiple domains. We have authentication set up with ADFS. ADFS passes the email address, and we want to map that email address to the .local FQDN. This is how our filesystem is set up and how we are distinguishing different users from different domains.

So for instance – john.doe@university.edu needs to map to john.doe@univ.local. Then, jane.doe@college.edu needs to map to jane.doe@college.local. So on and so forth.

Please forgive the novice attempts, and maybe there’s a much easier way of doing this, but we’ve added the necessary domains to ad_enabled_domains in sssd.conf.

Also, we’ve created a user_map_cmd script that runs on startup, and it does the following: echo $1 | tr ‘[:upper:]’ ‘[:lower:]’ | sed ‘s/%40/@/’

Originally when we attempted to log in, the username got mapped in URL encoded format (%40 vs @) so we added the sed piece to change it to @.

After doing this, it seems we are pretty close, and we want to do exactly what this error message is telling us as far as mapping, but we can’t proceed past here:

Error -- Username ‘first.last@university.edu' is being mapped to ‘first.last@univ.local' in SSSD and they don't match.
Users with domain names cannot be mapped correctly. If 'first.last@univ.local' still has the domain in it you'll need to set SSSD's full_name_format to '%1$s'.
See https://github.com/OSC/ondemand/issues/1759 for more details.
Run 'nginx_stage --help' to see a full list of available command line options.

Adjusting the full_name_format in SSSD hasn’t seemed to help – yet- but we are far from experts and aren’t exactly sure what needs to go here.

Does anyone have a similar setup, and how are you getting it to work?

Many thanks!

Just to be sure, you’re full_name_format is set to %1$s? I also assume that it’s in the [sssd] section. I am not entirely sure if you should have it in a different section or not. I’m also far from an SSSD expert.

I recall fixing that bug and adding that error message. You could edit the file that’s throwing the error (so that it doesn’t throw the error), but I seem to recall you having issues with sockets as well (if you look at the github ticket listed there - they also have issues booting a PUN but not being able to access the socket. IIRC you had a similar issue).

Here’s a little ruby one liner to test what values we’re seeing. As you can see my username johrstrom resolves directly to johrstrom. It would seem that you need to get first.last to remove the domain name.

[~()]  ruby -e "require 'etc'; puts Etc.getpwnam('johrstrom')"
#<struct Etc::Passwd name="johrstrom", passwd="*", uid=30961, gid=5515, gecos="Jeff Ohrstrom", dir="/users/PZS0714/johrstrom", shell="/bin/bash">

Also - the actual users on the system are first.last without any domain at all? What shows up for them in the name field if you issue the ruby one liner here?

Hi Jeff,

We don’t have the full_name_format set to %1$s, we got rid of that because it strips the domain name off of the end. In order for this to work with our setup, we’ll need OOD to map the user with the domain name included. So, it looks like by the error message above things are set up the way we need them to be - username first.last@university.edu maps to first.last@university.local - but OOD doesn’t let us proceed and tells us the usernames don’t match. Is there a way around that?

So for instance, this is what your one liner returns:

ruby -e "require 'etc'; puts Etc.getpwnam('first.last@domain.local')"
#<struct Etc::Passwd name="first.last@domain.local", passwd="*", uid=1997533168, gid=1997400513, gecos="First Last", dir="/home/domain.local/first.last", shell="/bin/bash">

OK - it sounds like your user_map_cmd needs to map university.eduuniversity.local. That is, it needs to map the domains as well as the username.

I wonder if something like this could work, though I’m sure you could combine the sed commands into 1 expression.

echo $1 | tr '[:upper:]' '[:lower:]' | sed 's/%40/@/' | sed 's/.edu/.local/'

Ok, thanks! We’re working on something in user_map_cmd. Mainly, we were just wondering if we could get past this without editing user_map_cmd since it seems like the university.edu was being mapped to university.local correctly in the error message (but OOD didn’t like it). But if this is the only way, we have a script written up that we can use with user_map_cmd that we tested out a bit yesterday and I think we can get something working.

Did you see the ticket that error message related to? I did recall this correctly - you have this discourse topic for a similar error. I suspect that’s what’s causing these Address already in use errors - somehow the user can boot the PUN, but can’t actually access the socket as that user. And I suspect the reason is that they have different domains. I mean the user that started the PUN has one domain and somehow the user that’s trying to access the socket has a different domain and somehow SSSD/Linux is seeing those as distinct users.

Which is to say - OOD doesn’t like the different domains because I believe the different domains cause the Address already in use issue. So hopefully it fixes that for you as well! :crossed_fingers:

Jeff, maybe a side note - how does SSSD play in once a user authenticates? This is a brand new OOD instance and we’re trying to configure SSSD in a way that handles the multiple domains. If we SSH to the server, we have SSSD configured in a manner that it places us directly where we need to go, regardless of the domain, no problem. But it seems that OOD ignores anything and everything we put in SSSD and the only way to manipulate how users are mapped or handled is via the optional user logon script (user_map_match or user_map_cmd). Is that expected behavior?

OOD only really deals with strings. So if I authenticate with the user aoakley (the string that’s the result of any kind of user mapping), then we’ll tell Nginx to boot itself as that user.

Nginx then likley makes some system calls like fork and setuid, among lots of others likely, which I assume hits the SSSD stack, especially to figure out other group membership and where HOME is and so on.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.