> 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