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

[Simo Sorce]

On Sat, 2014-03-08 at 01:19 +0000, Nordgren, Bryce L -FS wrote:
> I'm not suggesting that POSIX machines stop using UIDs internally. The
> local persistent map to a machine dependent representation will be
> necessary. It will also be necessary on Windows machines. And on
> mobile platforms. And within web applications. The shared items
> (principal names) would be common to all OSes and platforms though.

True, however posix information carry also other data, notably home
directory, gecos and shell. If you never share home directories you can
synthesize a home dire locally. And you could claim that everyone uses
bash and has to change the shell on each machine independently.
Gecos could also be ignored, although it is used in most desktops to
show a 'nice' name when your login is something like kxy3456yt ...

So yes you can probably forfeit all the user related information,
however it is rarely ok to forfeit groups, so you still need to
synchronize those around at least in homogeneous islands of activity.

> People trying to create heterogeneous environments are already
> carefully restricting protocols and applications to those which don't
> require sharing a UID map. File sharing via: Samba/CIFS, NFSv4,
> WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple
> machines has never involved knowing your UID, and ssh key pairs makes
> it more or less effortless to execute commands on another machine
> whether or not your username is the same, much less your UID. Kerberos
> SSO is more or less the same, but ensures that a common set of
> identities are recognized.

True, but the ability to successfully login does not exhaust the reason
why you have a common directory, there is other data that is
synchronized and shared.

> Ideally, if realm admins delegate authorization to the individual
> machines, the machines (regardless of OS) should be capable of
> functioning with only Kerberos authentication and without any
> centralized directory services.

Only if you think grouping mechanism are not necessary, I do not think
that's the case in any current deployment.

>  Minimal directory services could add group definitions via LDAP.

I guess you need to define what 'minimal' would mean here :)

>  A full AD/IPA solution would be needed to centralize authorization
> and/or enforce policy. Yet I still am not seeing the requirement for
> new deployments of cross-platform environments to manage internal user
> representations for a single os.

I am not sure I understand what you mean by 'single os' here, they
manage IDs as a single domain. Now, Posix is unfortunately limited by
the fact that it has a single user space and a single group space
because it was standardized when networks where rare and there were no
concepts of groups of machines with homogeneous identity stores. It
would be nice to fix this problem, but it is not simple to do it right,
and it would require kernel support to do it right.

> > However there are also issues with operations like 'renames', what
> > happen when you change a user name or a group name ? You do not
> > want to lose access to files when that happen, so you still need a
> > unique identifier that is not the everyday name (or forbid renames).
> 
> Presumably, you also would not want your Windows users to lose access
> to files after a rename, and Windows doesn't use UIDs.

Windows uses SIDs, they are perfectly equivalent to UIDs in this
discussion, although they have better properties when it comes to
networked machines.

In fact, over CIFS, SIDs are used to set ACLs, and in general you cannot
properly operate a Windows-centric domain if you do not have SID<->Name
translation services provided by the Domain Controller.

>  You also would not want to lose access to web apps, which do not use
> UIDs.

Web apps often duplicate the whole user database and have their own
groups, yet in enterprises they are also commonly integrated with a
directory for authentication and groups. They can ignore UIDs, just
like any other application, indeed.

>  You also don't want stale usernames to be sitting in access control
> lists (filesystem based or web app based).

Indeed which is why all filesystems tend to use UIDs (or SIDs for NTFS)
to perform access control. Unfortunately web applications almost always
do use usernames for access control, which is why renames are harder
there.

>  Retaining UIDs does nothing to make renaming more acceptable, because
> principal names are a realm-wide platform independent property, and
> UIDs are not.

This is debatable, but I do grant renames always need to be treated
carefully, however homogeneous UIDs/SIDs allow renames to happen.
Without UIDs stored in filesystems renames would simply not be possible,
w/o administrators running on every single machine and operating local
changes.

> > This is not an exhaustive list of course, and every problem can be
> probably
> > worked around one way or another, however at the moment it is till
> "easier"
> > to synchronize IDs than not ...
> 
> As I see it, for a cross-platform environment, every problem must be
> worked around regardless of whether you have to synchronize UIDs.
> Managing UIDs is just more work at the end, and it might be busywork.
> Determining whether it's busywork or not may make a good thesis
> topic. :)

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.

> It makes a good thesis topic because the central question is paradigm
> shifting: Draw a line between realm-wide properties and local machine
> representations of those properties, and ask "Can each machine be made
> responsible for performing their own localizations for internal
> bookkeeping purposes?" This would seem to be of particular interest to
> the type of crowd which would download and use a FreeIPA/sssd
> solution, but it may not be something they have the time to pursue.

In abstract I think there isn't much to research, this kind of operation
has been experimented for a while for real.
Local mappings have been done for as long as Samba/Winbindd have
existed, as in the old days there was no "central" LDAP servers, and NT4
Domains were not extensible, so you had to create local ids for users.
However the fact each machine had a different view of the UIDs caused
issues when said machine needed to share files. Granted, "some" of this
would be easier today, but not hugely so.
This is why idmapping in the samba project has been a long and thorny
issue with multiple backends being invented and the most successful ones
being the ones that can predictably map Windows SIDs so that all Linux
machines get the same UIDs for the same users after mapping.

Going forward it is possible that local network file systems will become
less and less relevant, and groups will become more and more localized
into applications instead of being enterprise-wide, with enterprises
asserting properties of users instead of their groupings and deferring
to applications to deal with what to do with these attributes.

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York