> Thing is, nfsidmap always adds and then substracts '@' plus domain,
> assuming that the part prior to '@' is what going to be mapped by the
> domain-specific idmap mapper.
That's the crux of the problem right there. Sssd is not a domain-specific
idmap mapper. Sssd is a domain-aware, multidomain idmap mapper. Hence the
first "@".
> What you get here by not adding the '@' to
> the name which contains '@' already is that wrong domain will be classified
> and then wrong name is passed to the system to ask for.
The corollary of not adding the '@' is not subtracting it either.
If sssd is the system service that deals with multidomain issues, then let it.
The NFS idmapper doesn't need to add or subtract the "@" and should pass it on
to sssd, if it's interacting with sssd. One flag to the mapper
("domain-aware-system=true"), the internal linux only problems are solved
internally, and the over the wire traffic is not broken in ways that break
other clients (e.g., your patched system emits traffic which looks _exactly_
like the "traditional"-read-"conforming" NFS case to unpatched systems and
other ground-up implementations). Breaking the protocol in a self-consistent
way which excludes other platforms is a very Microsoft-like approach and makes
me feel all dirty. Sometimes (not now) it's necessary as a band-aid/workaround,
but this time the band-aid doesn't have to break things. :)
I'd say the real solution, long term, is to point both sssd and the nfs
idmapper at something like a umich_ldap server managed by freeipa. This has
additional benefits like centralizing the idmapping in a way that's exportable
to foreign organizations so they can be clients to my servers, being able to
resolve uidNumber collisions when I'm not in control of the AD I'm trying to
use, supporting bare Kerberos trusts, allowing multiple GSSAuthNames (e.g., my
AD account, Kerberos credentials from my home network KDC, my SAML account) to
be recognized as the same user, etc. Room for growth.
This electronic message contains information generated by the USDA solely for
the intended recipients. Any unauthorized interception of this message or the
use or disclosure of the information it contains may violate the law and
subject the violator to civil or criminal penalties. If you believe you have
received this message in error, please notify the sender and delete the email
immediately.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
