Subject: Re: [ldapext] DBIS - new IETF drafts

From: Arthur de Jong <[email-masked]>
Date: Tue, 07 Jan 2014 23:25:22 +0100

Hi,

I'm the maintainer of nss-pam-ldapd, a PAM and NSS module that extracts
information from LDAP to map to Unix users, groups, and other maps
defined in RFC2307.

I quickyly went through draft-bannister-dbis-mapping-02.txt and
draft-bannister-dbis-passwd-01.txt and would like to add a few comments
(not very well organised, sorry).

For me, it is very interesting that the work is being done to to correct
some of the mistakes in RFC2307. I particularly like the idea of making
the attributes case sensitive and ensuring that values can appear only
once. Leaving out the case sensitivity filters from implementations
should make them a lot simpler. Mixing case sensitive and non-cases
sensitive interpretations of the same values can have security
implications.

The use of the term overlay may be confusing to users because that is
also used as one of the types of loadable modules of the OpenLDAP LDAP
server (slapd). I don't have a better alternative, sorry (the mechanism
is interesting though).

I personally wouldn't worry too much about the format of password
hashes. In an centralised network it would seem wiser to use a
centralised mechanism to authenticate users which already have plenty of
solutions available (LDAP bind authentication, Kerberos, etc.). Exposing
password hashes throughout the network is somewhat analogous to putting
password hashes in /etc/passwd instead of /etc/shadow.

I agree with Howard Chu that there must be a better format to store
timestamps and durations (mostly for shadow information) in. Something
that is interoperable with other systems.

I personally like the use of flat names to describe group membership. It
makes the semantics much simpler than dealing with things like the
member or uniqueMember attribute (at least from a client implementation
perspective).

The use of distinguished names may seem more logical from an LDAP
structure point of view, but you will have to dereference any DN to a
user name for building up a group entry resulting in potentially a lot
of search operations to get complete data.

I was recently pointer to draft-masarati-ldap-deref-00 which I've just
implemented in nss-pam-ldapd. This would reduce the number of required
lookups but this draft isn't widely implemented (I think nss-pam-ldapd
is the second Open Source client application to use it).

On the other hand, the use of exactPrimary will also require another
lookup because POSIX getpwent() expects to return a numerical group id.

I haven't ready it fully yet but the combination of exactGroup in
posixUserAccount and exactUser in posixGroupAccount will leaver room for
different interpretations for which users belong to which group,
depending on which way you look. Adding nested groups to the mix will
make it more difficult to maintain consistency. I would say that it is
better to have one way of specifying group membership and not two.

Nested groups are also an interesting concept and I can see the value
from a data management perspective but it will again result in multiple
LDAP search operations, especially for queries to determine the groups
that contain a specific user (initgroups() implementations). If a user
is found to be a member of 10 groups in the first pass, for each of the
10 groups it needs to be determined whether these groups are again
member of some other groups.

Some of these performance issues can be addresses with caches but since
caches are one of the only two difficult things in computer science
doing without them is better. Let's keep things simple.

Also, you may be interested in looking at the nss-pam-ldapd code. It
seems to have a somewhat similar design as the ideas described in the
DBIS Reference Implementation. There is even a work-in-progress Python
implementation that you could replace with a DBIS implementation.

Anyway, that's it for now. Perhaps I'll take a further look in a few
days.

-- 
-- arthur - [email-masked] - http://arthurdejong.org/ --

---

From: Michael Ströder <[email-masked]>
Date: Wed, 08 Jan 2014 19:57:24 +0100

> of search operations to get complete data.

Using DNs allows to implement server-side access control. I'm not a friend of
letting client-side demons enforce the access control because if a machine got
hacked the attacker can find out more about the infrastructure.

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 08 Jan 2014 21:14:58 +0000

> sensitive interpretations of the same values can have security

Hi Arthur,

Yes as you'll see from my recent reply to Simo, the case sensitivity 
issue was one of the problems I faced at a large installation, and it 
had been solved in that case by inventing a custom schema.  It seemed 
quite strange to me that RFC2307 should have differed like this from NIS 
in the first place.  Case sensitivity was one of the first problems I 
wanted DBIS to rectify.

> server (slapd). I don't have a better alternative, sorry (the mechanism

Indeed, I'm sure various technologies use the term.

> password hashes in /etc/passwd instead of /etc/shadow.

Also as I mentioned in my previous reply, people are free to choose a 
more secure password scheme, and Kerberos seems to be the one I've come 
across more often than not in recent years.  However, had I completely 
omitted the userPassword and authPassword attributes then I would not be 
providing an easy migration path for those people already making use of 
them.

> that is interoperable with other systems.

DBIS actually represents timestamps using the Generalized Time syntax, 
which I think is a better choice than an integer as in RFC2307bis.  
Durations remain as integers, currently number of days (to align with 
NIS on Solaris and Linux), but unless someone has a good reason not to I 
think these should become number of seconds as Howard suggested and can 
be translated accordingly by the Solaris and Linux DUAs.

> member or uniqueMember attribute (at least from a client implementation

Yes this was another aspect I wanted to simplify.  RFC2307bis does not 
make it easy to express group membership.

> of search operations to get complete data.

Given the way that configuration maps work in DBIS, it was no longer 
possible for me to represent them as DNs anyway, as someone could 
specify a DN that may or may not fall under the control of one or other 
configuration maps, and the DUA would not know what transformation rules 
to apply, if any.  You could even have specified a DN from another 
domain!  It made no sense to use DNs when expressing group membership, 
simple group names are quite sufficient.

> lookup because POSIX getpwent() expects to return a numerical group id.

Local caching should reduce the number of lookups.

> better to have one way of specifying group membership and not two.

There won't be different interpretations, just two different ways to 
express group membership.  This keeps options open for people who, for 
security reasons, may want group membership to be defined solely in the 
user account object (which is easier for a human to read), or solely 
with the group account object (for delegated administration).  They can 
then apply ACIs to ensure that their preferred route was the only one 
available.  We might add a flag somewhere to say which one it is, that 
would help performance by not performing redundant search operations if 
local security policy has mandated one approach and not the other.

> member of some other groups.

Nested groups are very important especially in large enterprises, and 
really do assist with data management.  Yes we'll get more search 
operations, but I don't think this will be a problem.  I should be able 
to prove this will work in my reference implementation.

> doing without them is better. Let's keep things simple.

Caching is very important, and something that has great focus within the 
reference implementation I am currently developing.  I hope to have 
something working in the next few months, after which you'll be able to 
download it and have a play.  I'm writing a multi-threaded caching 
daemon called dbis_cachemgr in Python that takes queries over a socket 
and is responsible for managing and caching the results of the 
appropriate LDAP search operations, and then I'll develop a simple 
nss_dbis library in C that translates NSS calls to an appropriate 
command that is sent to dbis_cachemgr.

> Anyway, that's it for now. Perhaps I'll take a further look in a few

Thanks I had a look at your code already.  I may be able to re-use some 
of it, possibly the NSS layer, however quite a lot of it becomes 
redundant or would have to be rewritten for DBIS.  I think the 
architecture I have designed in dbis_cachemgr will scale better on busy 
enterprise servers and will handle LDAP server outages more gracefully, 
as I have worker threads that can operate on many connections 
simultaneously while sharing a pool of LDAP connections.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 08 Jan 2014 21:25:29 +0000

> hacked the attacker can find out more about the infrastructure.

Hi Michael,

Please will you give me a more solid example of what you are referring 
to re access control?  What is it exactly you think you'd like to do 
with regards to group membership and server-side access control?

Thanks,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 09 Jan 2014 16:35:56 +0100

Mark R Bannister wrote:
> Please will you give me a more solid example of what you are referring to re
> access control?  What is it exactly you think you'd like to do with regards to
> group membership and server-side access control?

If the client system *individually* binds to the LDAP server you can implement
server-side access control in the LDAP server. During the last weeks I defined
a schema and OpenLDAP ACLs for such a deployment. Nothing to publish yet since
this is done for a customer.

Similar to what Simo described for IPA I use server groups (IPA host groups)
with rights assigned to user groups.

In opposite to all other implementations all clients MUST individually bind to
the LDAP server and server-side ACLs limit access to posixAccount, posixGroup,
server group and sudoRole entries.

I have to clarify if I'm allowed to disclose further details about this which
will take a while.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 09 Jan 2014 16:48:37 +0100

Mark R Bannister wrote:
> Yes as you'll see from my recent reply to Simo, the case sensitivity issue was
> one of the problems I faced at a large installation,

This could be easily solved with RFC2307bis. Or not?

In my deployments I simply define additional (OpenLDAP) constraints for those
attributes (e.g. to enforce lower-case 'uid' values).

IMHO only re-defining the matching rules does not fully solve the case problem
anyway. Restricting to lower-case attribute values helps better.

> It seemed quite strange to me that
> RFC2307 should have differed like this from NIS in the first place.

We all agree that RFC 2307 - even though widely deployed - has serious issues.

> Yes this was another aspect I wanted to simplify.  RFC2307bis does not make it
> easy to express group membership.

What does "express group membership" mean exactly?

> Nested groups are very important especially in large enterprises, and really
> do assist with data management.

I am always getting told this but I have strong doubts about nested groups.

>  Yes we'll get more search operations, but I
> don't think this will be a problem.  I should be able to prove this will work
> in my reference implementation.

Resolving nested group membership is a big performance cost. I can see this
with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
sends many search requests even though nested groups are not used in this
deployment.

Also nested groups are a pain if you want to report all effective user rights
to auditors (which is something banks have to do at least once per year). In
this context even maintaining the group membership does not look that simple
anymore.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 9 Jan 2014 18:08:51 +0000

> I am always getting told this but I have strong doubts about nested groups.

Groups are usually there to define permissions - the Authorisation
part of the AAA triple. Allowing nested groups helps to decouple
individual users from individual permissions. For example:

	The Helpdesk group contains a, b, c, d
	The SysManagers group contains e, f
	The PasswordRestKiosk group contains j, k, l, m
	The AccountProvisioning group contains p

I can now write permission rules like:

	Members of Helpdesk, PasswordRestKiosk, AccountProvisioning may set user passwords
	Members of SysManagers may set system-account passwords
	Members of Helpdesk, AccountProvisioning may change user contact data

where each of the rules is expressed as a group whose members are
other groups. It is easy to explain such rules, and easy to maintain
them as they are visibale as data in the LDAP tree.
I think this is a lot better than maintaining flat groups like:

	UserPasswordSetGroup contains a, b, c, d, j, k, l, m, p
	SysPasswordResetGroup contains e, f
	UserContactModifyGroup contains a, b, c, d, p

> sends many search requests even though nested groups are not used in this

That is because there is no standard schema for nested groups, so
there is no server-side support to make them efficient. [In fact
many LDAP server implementations do define their own nesting
schemes, but I don't think any of them are shared with other
unrelated implementations.]

You and I started trying to sort this out after the first LDAP
conference, but the effort got bogged down. Maybe we should dust off
the drafts and see if anything can be salvaged.

> this context even maintaining the group membership does not look that simple

I don't see that it adds much to the work. If the server supports
nested groups then it is a single query; otherwise it is a series of
derefs. (I am assuming a simple two-level nesting here as I can see
many uses for that without making the rules too complex.)

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Michael Ströder <[email-masked]>
Date: Thu, 09 Jan 2014 21:36:08 +0100

Simo wrote:
> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
> I'd go beyond this, supporting case-sensitive user names is actively
> harmful for various reasons.
> 
> - Assuming users (and admins) should be able to distinguish based on
> case is wrong, we naturally consider the strings 'Admin' and 'admin' to
> be the same thing.
> 
> - Some systems are case-preserving (meaning they'll show you back the
> same case you entered, but are really case-insensitive and if you have
> to interoperate with them you cannot assume Admin and amdin to be
> different users, it could lead to serious security issues.
> 
> - If we are in the legacy game, there are still systems that will simply
> accept only all caps names, like ADMIN. In these cases what do you map
> that to ? Admin ? admin? a third user called ADMIN ?
> 
> And there are many other examples where really being case sensitive
> causes a lot more problem than it resolves.
> Due to these problems what we did in FreeIPA is to always create users
> in lower case and explicitly state we are case-preserving and
> insensitive. It is the only reasonable compromise IMHO.

So basically you're doing the same thing like I described above.

> Great value at least in IPA, we use them a lot to associate things like
> permissions to roles to groups and ultimately to users (All through
> nesting each of these as groupsofnames). It does really make some
> problems much easier to handle at the end of the process.

Which problems are easier? Personally I'd definitely consider abusing
groupOfNames for permissions bad schema design.

> Performance issues with nested groups can easily be solved via caching
> and the deref control though.

But the deref control gives you only one level. Speaking of nested groups in
general people mean more than just two-level group memberships.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 09 Jan 2014 21:40:09 +0100

> 	Members of Helpdesk, AccountProvisioning may change user contact data

What you describe is rather assigning permissions to user groups. IMHO that's
not what people mean when they are talking about nested groups in general.

> unrelated implementations.]

Ok, let the server internally search all the group membership (like AD does
e.g. with tokenGroups attribute) would make things more effecient.

> the drafts and see if anything can be salvaged.

Server-side resolving of nested groups were far beyond our former scope. But
we could try.

> many uses for that without making the rules too complex.)

Aha, you're limiting to two levels... ;-)

Ciao, Michael.

---

From: Charlie <[email-masked]>
Date: Thu, 9 Jan 2014 19:32:28 -0500

What I have learned from about a decade of quietly following LDAP
across multiple forums and lists is the following:

1) Whenever people say "nobody is using this/that" they are invariably wrong.

2) POSIX group semantics are the bane of open-source LDAP.  The
functional paradigm that a member is an attribute of a group is
fundamentally broken; group membership is an attribute of the member.
The security concerns frequently raised concerning this are all either
trivially solvable or pragmatically completely bogus.

3) Howard knows what he's talking about.  But Kurt also knows what
he's talking about, and Kurt wrote "multi-master considered harmful"
(draft-zeilenga-ldup-harmful-00).  Sometimes real world pragmatism
obviates perfectly valid academic arguments.

--Charlie

---

From: Luke Howard <[email-masked]>
Date: Fri, 10 Jan 2014 11:42:25 +1100

I was reluctant to join this conversation as I haven't had a chance to look at the drafts, but: to anyone wanting to improve on RFC2307 (or indeed, anything), I would say go for it.

To get traction IMO, it needs to (a) be published in a finished state (unlike 2307bis), and (b) have a reference implementation that supports every platform. Enterprises that are still welded to NIS and need all the corner cases (netgroups, case sensitivity, etc) are also likely to still be using AIX, HP-UX, Solaris 8, etc. (Of course there is always inertia owing to the installed base, but were one to have that attitude about everything, there would be no progress. In the end the market will decide.)

-- Luke

---

From: "Neal-Joslin, Robert (3PAR Engineering)" <[email-masked]>
Date: Fri, 10 Jan 2014 01:29:24 +0000

My apologies for commenting on this without having read the draft, and also being out of this technology for several years.

It seems the root of the complaint is that the RFC2307 schema isn't good enough.  But what I've learned is that there is no schema that is good enough.  Which is why we wrote RFC4876, which allows the DUA to convert the RFC2307 schema (or any schema) to the locally deployed schema.  For example, posixGroup can be mapped to a dynamic group.

Regards,

Bob Neal-Joslin

> -----Original Message-----
> From: Ldapext [mailto:[email-masked]] On Behalf Of Charlie
> Sent: Thursday, January 09, 2014 4:32 PM
> To: Mark R Bannister; ldapext
> Subject: Re: [ldapext] DBIS - new IETF drafts
>

---

From: Michael Ströder <[email-masked]>
Date: Fri, 10 Jan 2014 11:40:11 +0100

Simo wrote:
> On Thu, 2014-01-09 at 21:36 +0100, Michael Ströder wrote:
>> Simo wrote:
> It's an 80/20 thing, the most common case is 2 levels deep, so the worst
> case is not usually a big issue.

But if you don't enforce the 2-level-nested-groups limit the client has to
search for nested groups and deref control does not help.

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Fri, 10 Jan 2014 14:02:40 +0000

> This could be easily solved with RFC2307bis. Or not?

Not.  It uses the 'cn' attribute for a start, which is case insensitive.

> attributes (e.g. to enforce lower-case 'uid' values).

Hard to do with 'cn'.  We had to invent a new custom attribute to 
replace 'cn' with.

> What does "express group membership" mean exactly?

"Express", meaning, to put into words.

> I am always getting told this but I have strong doubts about nested groups.

If you're always getting told this, then there must be lots of people 
who like nested groups.  If people like it, then it's in demand.

> sends many search requests even though nested groups are not used in this

Caching will improve the situation.  Yes there is a performance cost.  
So what?  Don't innovate if it takes CPU cycles?

> this context even maintaining the group membership does not look that simple

Not if you come up with the good tools to help you search and visualise 
the nested structures.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Fri, 10 Jan 2014 14:13:15 +0000

> harmful for various reasons.

UNIX is traditionally case sensitive.  I am currently working at a large 
installation where there is an important distinction between lower-case 
and upper-case user names.  This debate isn't just about user names 
anyway.  There are loads of NIS fields that were case sensitive, and 
UNIX isn't going to change.  They will always be case sensitive.  So 
trying to represent them in case insensitive fields is just, well, wrong.

> case is wrong, we naturally consider the strings 'Admin' and 'admin' to

If you're used to Microsoft Windows, yes.  DBIS is not aimed at Microsoft.

> insensitive. It is the only reasonable compromise IMHO.

NIS, RFC2307, RFC2307bis and DBIS are for UNIX.  UNIX is case 
sensitive.  It makes no sense to store data in a case insensitive 
fashion if the client expects it to be case sensitive.  Data loss or 
corruption will occur this way.

Best regards,
Mark.

---

From: Luke Howard <[email-masked]>
Date: Sat, 11 Jan 2014 01:16:51 +1100

> UNIX is traditionally case sensitive.  I am currently working at a large installation where there is an important distinction between lower-case and upper-case user names.  This debate isn't just about user names anyway.  There are loads of NIS fields that were case sensitive, and UNIX isn't going to change.  They will always be case sensitive.  So trying to represent them in case insensitive fields is just, well, wrong.

Unfortunately once again this exists for historical reasons (mostly to do with Netscape's original internal deployment, if my memory serves me correctly). Obviously you can fix it with client-side schema mapping, but it's also good to have a schema to map to, agreed.

-- Luke

---

From: Mark R Bannister <[email-masked]>
Date: Fri, 10 Jan 2014 14:17:34 +0000

> 1) Whenever people say "nobody is using this/that" they are invariably wrong.

Thanks Charlie, good point.  It's like when you watch the TV news and a 
journalist says "the public think this" or "the public think that".  
Once something is in the public domain, I don't think anyone can claim 
to know who is using what, how everyone is using it, nor on what 
antiquated features anyone may or may not rely, except perhaps the NSA, 
but let's not go there ;-)

> trivially solvable or pragmatically completely bogus.

DBIS allows you to represent it from both angles.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Fri, 10 Jan 2014 14:21:40 +0000

> I was reluctant to join this conversation as I haven't had a chance to look at the drafts, but: to anyone wanting to improve on RFC2307 (or indeed, anything), I would say go for it.

Thanks Luke, I went for it already.

> To get traction IMO, it needs to (a) be published in a finished state (unlike 2307bis)

That bit might be hard, even once the reference implementation is 
complete and it's proven how does one get something out of draft into a 
published state?

> , and (b) have a reference implementation that supports every platform.

Working on it.  As much as possible with be Python, so apart from 
NSS/PAM semantics, it will be quite portable.

> Enterprises that are still welded to NIS and need all the corner cases (netgroups, case sensitivity, etc) are also likely to still be using AIX, HP-UX, Solaris 8, etc. (Of course there is always inertia owing to the installed base, but were one to have that attitude about everything, there would be no progress. In the end the market will decide.)

Indeed, and all of the big clients I've worked for still have a sizeable 
Solaris 8 footprint, and those clients are very reluctant if not 
refusing to upgrade that estate.  I haven't seen as much AIX or HP-UX.  
I would rather DBIS supports all of the legacy platforms as well, so 
that everyone can make a clean break from NIS and RFC2307 rather than 
having to support both environments.  This is why I have focused very 
hard on compatibility between the models.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Fri, 10 Jan 2014 14:25:31 +0000

> It seems the root of the complaint is that the RFC2307 schema isn't good enough.  But what I've learned is that there is no schema that is good enough.  Which is why we wrote RFC4876, which allows…

Hi Bob,

Thanks, but one of the most powerful features of DBIS gives us the 
ability to pull together the entries for any given map from multiple 
locations in the DIT, using a mix of different schemas.  This makes it 
so much easier to merge NIS domains together without having to manually 
export/transform/import anything.

Best regards,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 10 Jan 2014 16:05:39 +0100

Mark R Bannister wrote:
> Hard to do with 'cn'.  We had to invent a new custom attribute to replace 'cn'
> with.

Not hard with OpenLDAP to restrict a 'cn' constraint to entries of a certain
object class. Other directory servers have similar constraint capabilities too.

Ciao, Michael.

---

From: Howard Chu <[email-masked]>
Date: Sun, 12 Jan 2014 18:59:48 -0800

> trivially solvable or pragmatically completely bogus.

Sorry but that makes no sense. It's the same as saying 'element e is a member 
of set S' is true but 'set S contains element e' is false. If one is true then 
both must be true.

Of course there are two different ways to view it. From a sysadmin's point of 
view, what is important is knowing which users are the member of a group. From 
an individual user's point of view, knowing which groups they belong to is 
more important. In real life, users will login many times more frequently than 
sysadmins will manipulate group memberships, so you may decide that optimizing 
for the user check is more important. But while sysadmin manipulation may be 
infrequent, the consequences of making a mistake are high, so data models up 
till now have been designed to make the sysadmin view more straightforward. 
Complexity for the user's perspective is simple to automate and never have to 
worry about ever again.

I think it would be a mistake to lose sight of this distinction.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Charlie <[email-masked]>
Date: Mon, 13 Jan 2014 12:21:06 -0500

Howard replied:
>Sorry but that makes no sense. It's the same as saying 'element e is a member of set S' >is true but 'set S contains element e' is false. If one is true then both must be true.

Perhaps I'm not conveying the concept well.  I'm talking about how
something is expressed and the results certain semantics actually have
on real life, on real human endeavors.  I'm not talking about the
academic equivalency of two forms of symbolic expression.

But it's true that it's no more difficult to add a "memberOf"
attribute to an object than it is to add a "Member" attribute to
another object.  The spurious efficiency of querying LDAP for a member
list (at least one member of which will be queried *again* nearly one
hundred percent of the time) instead of querying against a membership
filter is a mental bugaboo that has retarded progress in LDAP-capable
directory software.

POSIX group lists are an ill-considered hack that somebody (I think
Ritchie) haphazardly pasted onto Unix when they were still trying to
interact with GECOS systems.  They infect the filesystem paradigm and
the user management paradigm and make *nix lamer than it needs to be.
They discourage group nesting and just-in-time resolution and other
desirable practices that exist in the real world that directories are
trying to usefully represent.  Their flat list design ignores human
psychological and empirical organizational realities.

Dynamic groups and/or stored group queries are better, although I've
never seen an optimal implementation of either.  The groups that
people REALLY need to represent in their directories are things like
"the set of people on site competent to reconstitute the threadline"
and "the set of employees accessing the reactor robotics right now"
and "the set of objects in route to Dusseldorf".  Enterprise
directories that try to accurately model reality as it exists will be
far more pragmatically useful than those that simply regurgitate
inherently error-prone and outdated static lists.

POSIX groups suck.  They are the second worst thing in *nix.  OK,
maybe the 3rd.  A directory should never model /etc/groups... yes, it
should be able to generate group lists for POSIX compatibility, but
internally a directory should attempt a more powerful cognitive model
than a grocery list.

If people want to discuss this more, please split the topic off from
Mr. Bannister's thread or contact me privately, since he's already
replied to my post.

--Charlie