> > I see the first two represented on the design, but not the last. I suspect
> that this means that the plugin regards security principals and NFSv4
> identities as the same thing, which may mean it won't work for multiple
> domains?  Let me turn the question on its head: according to the OP, the NFS
> server and client is in Kerberos realm FREEIPA.EXAMPLE.ORG, and the user
> principals are from realm AD.EXAMPLE.ORG. Would your plugin work?
> I haven't tested this scenario yet, but I assume it would as long as sssd was
> able to resolve usern...@ad.example.org and there was a trust
> relationship between FREEIPA.EXAMPLE.ORG and AD.EXAMPLE.ORG. But
> again, this is something that needs more testing.

The OP said the reason for the failure was that the principal was 
"usern...@ad.example.org@FREEIPA.EXAMPLE.ORG", which Simo said was due to 
rpc.idmapd constructing the principal incorrectly. Does your plugin have the 
ability to alter how rpc.idmapd constructs principals? This may be the key.

> yes, rpc.idmapd is calling an sssd plugin to resolve identities.

As I understand it, the NFS identities sent over the wire serve much the same 
purpose as a Kerberos NT_Enterprise name. That is, NFS ids over the wire should 
all be "usern...@example.org" regardless of whether the user is defined in 
FREEIPA.EXAMPLE.ORG or AD.EXAMPLE.ORG. This makes rpc.idmapd responsible for 
two things:

1] Mapping usern...@example.org to UID/GID and vice versa;
2] Mapping usern...@example.org to the exact Kerberos security principal used 
for authentication (usern...@ad.example.org) (and vice versa).

SSSD can do #1. Can it do #2? Can it do #2 if there's no connection to the 
domain in which the user is defined?

I suspect there is some value in endowing sssd with capability #2 which reaches 
well beyond NFS. For instance, people would no longer need to type their 
username as "usern...@ad.example.org" at login prompts (web or ssh). The people 
I deal with don't know their Kerberos principal name.

OTOH, if the "plugin" went the other direction, allowing sssd to resolve ids 
using an rpc.idmapd configured to point to a local ldap server with a passable 
facsimile of the umich schema, that might add the most functionality with the 
least new code. The local mappings bind an external security principal to a 
local username/uid/gid, and give the local admins a tool to manage/resolve 
conflicts with externally managed domains. This removes the need to contact a 
foreign realm which may be protected by a firewall. Local conflict resolution 
and not contacting servers you don't control are probably the biggest reasons 
to add these mappings to freeipa once views are up.

It helps me to remember that a trust and connectivity are not the same thing. 
From within my firewall, I can kinit (@AD.EXAMPLE.ORG), walk an authentication 
path which terminates outside my firewall, and obtain a ticket for a 
"collaboration" server (@FREEIPA.EXAMPLE.ORG). This may exclude using sssd, 
since it seems predicated on configuring contactable domains. It does not 
exclude using a future umich-schema-view-enabled freeipa.

Thinking out loud, In the near term, a viable solution for manual conflict 
management may be to stand up a separate ldap server to contain just the umich 
schema elements for external users + those defined in freeipa. Poor man's 
views. :) Or just put it somewhere in the 389ds dit that freeipa will ignore... 
I may have to try this if I can work it in....


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