> 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 

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to