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


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

Reply via email to