So the bottom line, if I understand this conversation so far, allowing each
machine to synthesize OS-specific information from pure Kerberos principal
* 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
* 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
> 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.
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
Freeipa-users mailing list