[Freeipa-users] IPA+AD trust and NFS nobody issue

[Nordgren, Bryce L -FS]

> > 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 username at 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 "username at 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 "username at 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 username at example.org to UID/GID and vice versa;
2] Mapping username at example.org to the exact Kerberos security principal used for authentication (username at 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 "username at 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....

Bryce




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.