[Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Nordgren, Bryce L -FS]

So the bottom line, if I understand this conversation so far, allowing each machine to synthesize OS-specific information from pure Kerberos principal names:

* Breaks host-based authentication for file sharing (NFS3/2).
* Breaks CIFS ACLs (no central SIDs) (Does it also break CIFS completely?)
* Means there are consequences for renaming users/groups.
* Means the machine may not be able to display a friendly user name
* Means the machine will either have non-shared home directories, or require home directories be shared via NFSv4/sshfs.
* Allows filesharing via NFSv4 or sshfs/swish (realm-wide, project-wide, or point-to-point)
* Allows filesharing via WebDAV.
* Reusable groups may not be defined.
* May break Windows entirely due to a requirement for SID<->Principal name mapping on the directory server.
* Centralizes password management
* Allows SSO operation

If one adds groups but does not attempt to manage GIDs:
* Requires a directory solution (LDAP/AD/IPA)
* Allows group usage on local filesystems and shared NFSv4 filesystems.

> Well, we try to make it so you, administrator, do not have to deal with it if not
> rarely in freeIPA. So it shouldn't be busywork for sure. Would like to know if
> anyone has a different experience and found themselves in need to tinker
> for long with UIDs in an IPA environment.

IPA supplements (or hopefully will supplement) AD in my environment. I need to worry about colliding with UIDs in a directory I don't control. IPA can't solve this problem for me. Neither can my current LDAP solution. But machines which could generate their own mappings...many headaches would go away.


> In abstract I think there isn't much to research, this kind of operation has
> been experimented for a while for real.
>...
> Eventually we may get to a point where multiple machines do not need to
> share and synchronize much user data in the traditional way. But that time
> has not arrived yet, IMHO. (Which is not to say I wouldn't want to get there,
> it would be nice to get rid of this nasty problem :-)

The renaming thing you brought up (within a non-UID/SID-sharing environment) sounds like it could be a good thesis topic. "Going forward" probably means starting to use NFSv4, which also warns against renaming because it doesn’t use UID/SIDs. It sounds like a necessary and present issue to address.

Assembling a functional realm containing only platform-independent principals (could include groups, not GIDs), by extending the NFS idmapper could be another. (Or at least ensuring that the POSIX mappings and NFS mappings are the same...) Try the same thing on Windows and see what the showstoppers are. Success may simplify integration of Windows into IPA managed domains if you didn't have to emulate an AD instance so completely. Home users everywhere may love being able to make all their machines have the same password via a KDC (or IPA?) running on their wireless router.

If you're tired of this topic, how about a thesis which makes Kerberos KDCs function more like IP routers, collaboratively and automatically maintaining the connectivity topology between Kerberos realms? Clearly, its not the same: cross-realm connectivity (I will NOT use the word "trust") is inherently unidirectional. Also, the mapping from realm->dns and specific fqdns for the KDCs will need to be communicated. The KDC could potentially communicate this topology to interested clients, but why on earth would the clients want to know? IP routers made UUCP bang paths obsolete, something should do the same for Kerberos capaths.

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.