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