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:
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.


On Wed, Aug 2, 2017 at 7:55 AM, Chris Dagdigian via FreeIPA-users <> 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 "" 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 "
>" 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:
> 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 --
> To unsubscribe send an email to
FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to