The users in /etc/passwd have nothing to do with the users in IPA, you can configure them to have the same UID / GID as the users in IPA, and you can name them the way you want (ie, just the username without the domain suffix). This will break in interesting ways if you need to sync updates to the nodes (think - new users, password changes, group membership changes).
You will be better off adding the nodes to the IPA domain and using sssd to pull the identity information from the domain. You can configure a default domain so the users from that domain do not need a domain suffix. The latest version of sssd also allows you to login as users from any domain without a domain suffix in most cases, see: https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html
Importantly, sssd provides a raft of options to tune caching identity information, so your nodes will not actually be querying the IPA server for every lookup.

HTH,
Jatin


On Wed, Aug 2, 2017 at 7:55 AM, Chris Dagdigian via FreeIPA-users <freeipa-users@lists.fedorahosted.org> wrote:
Have a strange use case - this may be a mostly sssd.conf config question I think ...

I've got a high performance computing grid running in AWS. The front-end and user login nodes are managed IPA clients and things are working well even for the complex AD topology we have with lots of child-domains and transitive trusts to cross. I can login as "user@NAFTA.COMPANY.COM" just fine ...

What I'm trying to do is avoid having to make the HPC compute nodes into IPA clients because I expect them to auto-scale up and down in reaction to job load and I don't want to hammer my IPA server into submission, nor do I want to swamp the poor replication threads as they try to replicate all that info across the IPA server fleet.

I thought I could be clever ands scrape the IPA-provided UID and GID values and use those numbers to create local account entries on the remote compute node fleet. The login/master nodes would be "IPA integrated" while the compute nodes would have skeletal /etc/passwd and /etc/group files populated with data I stole from IPA...

However it turns out Linux really hates usernames with "@" in them and refuses to let me make accounts.  So I can't recreate "user@NAFTA.COMPANY.COM" on my remote compute fleet.  The presence of the "@" symbol in my user ID simply breaks on any host that is not an IPA client.

And it turns out even Grid Engine commands won't run with "@" in the active user name so core HPC binaries like "qrsh" and "qlogin" are busted.

So I'm in a bit of a catch-22 situation:

- I want to avoid using IPA on my elastic compute fleet if possible to avoid thrashing the IPA masters and replication
- However I can't fake local user accounts with matching UID/GID values on the fleet because Linux hates the "@" character in usernames

This may be a dumb sssd.conf question but is there a way that I can configure sssd.conf on my IPA clients to utterly and totally strip out the long domain name from the user?

I want to map:

userA@NAFTA.COMPANY.COM
userB@EAME.COMPANY.COM
userC@APAC.COMAPNY.COM

To:
  userA
  userB
  userC

.. just on my IPA enrolled HPC edge nodes  I don't care if they have to *login* using the fully qualified AD domain (that may be best anyway) but I want the local OS to just use the short username if at all possible.

If I can get the IPA_enrolled login node to use pure short names than I can fake those short names across the HPC cluster and I think things will be sorted ...

Hope this makes sense!   Any tips or hints appreciated. If I can't sort this out quickly I'm probably just going to bite the bullet and script in IPA-enroll, re-enroll and un-enroll actions into my auto-scaling stuff. I really want to avoid that if at all possible.

Regards,
Chris
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org