Subject: Re: [ldapext] LDAP work at IETF...

From: Mark R Bannister <[email-masked]>
Date: Sun, 01 Feb 2015 22:33:08 +0000

On 28/01/2015 14:14, Simo wrote:
> On Tue, 2015-01-27 at 20:50 +0000, Mark R Bannister wrote:
>> On 27/01/2015 15:47, Michael Ströder wrote:
>>> Mark R Bannister wrote:
>>>> The following internet drafts are intended to replace RFC2307 and RFC2307bis.
>>>> [..]
>>>> draft-bannister-dbis-mapping
>>>> draft-bannister-dbis-netgroup
>>>> draft-bannister-dbis-passwd
>>>> draft-bannister-dbis-hosts
>>>> draft-bannister-dbis-devices
>>>> draft-bannister-dbis-automounter
>>>> draft-bannister-dbis-custom
>>>> [..]
>>>> I would prefer to see RFC2307bis removed from the list to be considered above,
>>>> and replaced by the DBIS drafts.
>>> This probably won't happen because there are so many RFC2307(bis) deployments
>>> out there which cannot easily be migrated.
>> DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as
>> well as using the new format.  Migration is designed to be extremely
>> easy.  In fact, it took me next to no time at all to start using
>> directory entries defined in RFC2307 format from a DBIS installation, it
>> really is just a matter of defining a few configuration maps that do the
>> class and attribute remappings, and they are mostly standard.  See
>> https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/
>>
>>> Also I have my own schema built on top of RFC2307bis (not published yet) which
>>> differs much from DBIS for very good reasons. I aim to present it at LDAPcon
>>> 2015 in Edinburgh (in case the program comittee agrees). A preview version of
>>> that is already in production for almost a year in a large data center.
>>>
>>> So my suggestion would be to brush up RFC2307bis as much as possible (taking
>>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will
>>> base my system on top of that.
>>>
>>> How does that sound to you?
>>>
>>> Ciao, Michael.
>>>
>> DBIS is not a superset nor a child schema that inherits from RFC2307bis,
>> nor is it built on top of RFC2307bis - it is a complete replacement and
>> was designed as such.  RFC2307 and RFC2307bis can be completely retired
>> and DBIS put in their place and there would be no omissions.  It's an
>> evolution that began life by taking RFC2307bis and splitting it into
>> logic units (separate internet drafts) that make for a less unwieldy
>> document and make it easier for others to extend.  Then I standardised
>> the client-side configuration, fixed some of the NIS incompatibilities
>> that had been inherited from RFC2307, added a few much needed enterprise
>> features, and that's it: a modern, modular, extensible, enterprise-ready
>> RFC2307bis under another name ("2307bis" wasn't a very friendly name,
>> after all, and I wasn't going to call my improvements "2307ter", but
>> they could have been called that, because realistically that's what they
>> are).
>>
>>> So my suggestion would be to brush up RFC2307bis as much as possible (taking
>>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will
>>> base my system on top of that.
>>>
>>> How does that sound to you?
>>>
>>> Ciao, Michael.
>>>
>> I don't see a reason to try to improve RFC2307bis, I think that would be
>> a backwards step.  The improvements needed to RFC2307bis have already
>> been made, I've done the work myself and named it "DBIS" because I
>> couldn't wait for everyone else to catch-up, and I needed it last year
>> :-)  I think if people started looking deeper into the DBIS internet
>> drafts, making suggestions for improvement etc. we'd get to a much
>> better end point than if you have people pore over RFC2307bis again.
> It hurts me to curb enthusiasm, but I think your drafts are not a step
> forward, at most a step sideways, and ignore what's out there right now.

Given that they were written to fix specific deficiencies in RFC2307bis 
that were causing
pain in a number of very large enterprises I have worked for, I don't 
see how they
could be considered a step sideways.

When you say my drafts ignore what's out there right now, what are they 
ignoring?  I
don't quite understand that point.  I'm very open to make changes that 
would make
the drafts more useful in other organisations too, but I cannot make 
improvements
when faced with generic statements that have no detail behind them.

> The software out there and now expect either RFC2307 or at most
> RFC2307bis (and then really they just test against Active Directory's
> schema and things happen to mostly work). Any other schema would just
> fail to be useful for a generic LDAP server.
>
> Simo.
>
To what software do you refer specifically?  NSS is a big subscriber, 
and I've addressed
that one.  Then there is the automounter, and sudo, and really only a 
handful of
others all of which can be fixed to use a more modern schema.

I'm not going to spend 18 months developing DBIS to be turned away 
because software
doesn't support it.  Of course software doesn't support it - yet - it's new!

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Sun, 01 Feb 2015 22:50:36 +0000

On 28/01/2015 17:51, Michael Ströder wrote:
> Mark R Bannister wrote:
>> On 27/01/2015 22:14, Michael Ströder wrote:
>>>> I think if people
>>>> started looking deeper into the DBIS internet drafts,
>>> I've looked into your drafts. But it differs very much from what I'm after. We
>>> had this discussion before: IMO netgroups must die, die, die...
>> This contradicts your earlier assertion that clients are hard-coded.  In the
>> same vein, clients are hard-coded to use netgroups, ergo netgroups cannot
>> "die, die, die".
> No contradiction, since IMO one can easily avoid using netgroups completely.

And use what instead?  When one needs to group together users and hosts 
in logical units,
what other pervasive choices are there?

> With my approach the ACLs on the LDAP server sort out what clients can
> actually see. Therefore you get the flexible access control without the client
> having to enforce e.g. login access control locally based on netgroups.

Ah, I see, so you're talking specifically of access control.  Yes, if 
all netgroups are there to do
is access control, then you can offload that as ACLs on the LDAP 
server.  But what about the
netgroups that are there to define application roles?

>
>> Rather than attempting to kill off something that is used extensively, and has
>> actually proved to be very useful in large UNIX/Linux estates (if a bit
>> clunky), I've embraced them, rationalised them, defined them in a neater and
>> queryable format, and complemented them with netservices.
> I'd avoid them and convert access control rules based on netgroups into
> another schema and let the LDAP server's ACL work through the data.

Agreed, great for access control.  But I don't see how that will work 
for the other netgroup
use-cases.

>> Apart from netgroups, which you are not a fan of, how else does DBIS differ
>> from what you're after?
> My main objective is that not the client system evaluates all the stuff. The
> client system should not see data not usable on the system. The client system
> acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system
> still enforces file access permissions etc. locally.
>

I agree with you on that point.  Perhaps I could take a similar approach 
with DBIS.  I'm interested,
today the NSS library on Linux hosts does not have the identity of the 
requester.  It is quite normal
for there to be a service account used in the LDAP bind, or perhaps even 
an anonymous bind.
The LDAP server can then only usefully filter with ACLs data that is 
restricted to specific hosts,
but not to specific users.  So you are only solving half the problem, right?

Best regards,
Mark.

---

From: "[email-masked] (POP3)" <[email-masked]>
Date: Mon, 02 Feb 2015 11:20:22 +0100

(Changed the subject.)

Mark R Bannister wrote:
> Agreed, great for access control.  But I don't see how that will work for the
> other netgroup use-cases.

Which particular netgroup use-cases do you see?
One example is sufficient.

> with DBIS.  I'm interested, today the NSS library on Linux hosts does not
> have the identity of the requester.  It is quite normal for there to be a
> service account used in the LDAP bind, or perhaps even an anonymous bind.

IMO it's ok to use an individual machine identity to request NSS data from the
LDAP server. But if the machine gets rooted the attacker should not see the
rest of the NSS data for other server/service groups. So my threat model is
that the machine is already out of control.

> restricted to specific hosts, but not to specific users.  So you are only
> solving half the problem, right?

Filtering more based on identity of end user on a machine would IMO violate
POSIX semantics.
What do others think?

Ciao, Michael.

---

From: "[email-masked] (POP3)" <[email-masked]>
Date: Mon, 02 Feb 2015 11:29:12 +0100

Mark R Bannister wrote:
> that were causing pain in a number of very large enterprises I have worked
> for, I don't see how they could be considered a step sideways.

Maybe I did not look closely enough. Could you please point me to some text
describing the specific deficiencies you solved in more detail?

> ignoring?
> To what software do you refer specifically?

I think like me Simo also meant the client side.

> NSS is a big subscriber, and I've addressed that one.  Then there is the
> automounter, and sudo, and really only a handful of others all of which can
> be fixed to use a more modern schema.
> 
> I'm not going to spend 18 months developing DBIS to be turned away because
> software

But the question is whether there's a solution which is compatible to existing
client-side software. I know you're working on PAM/NSS clients but the
question is whether you can install that on legacy Unices or strange applicances.

My approach is to lower the configuration level the client has to support by
filtering what's delivered to the client at the LDAP server.

Ciao, Michael.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 04 Feb 2015 21:41:01 +0000

> One example is sufficient.

Generically, application roles.  A specific example: sudo, where sudo 
rules are enabled for users based on netgroup membership.  The LDAP 
server does not know the user requesting sudo access, only the client 
system knows that, so server-side ACLs are not going to help.

I do need to give a second example, because the first is specific to 
users.  Here is one specific to hosts: NFS, where an NFS server might 
grant read-only access to every host on the network except for those 
that are members of a specific netgroup, which get read-write access.  
The NFS server needs to know when a client request comes in whether this 
host is a member of the netgroup that grants read-write access or not, 
and this cannot be implemented by server-side ACLs, because only the NFS 
server knows the identity of the client requesting access to the fileshare.

> that the machine is already out of control.

In the deployments I see, typically every user can login to every host, 
and any application could run anywhere, therefore any compromised 
machine will of course yield all NSS data.  However, the NSS data isn't 
particularly sensitive anyway, and quite often the LDAP directories are 
open for anyone with a network device to query over port 389 anyway, so 
I haven't worked in an organisation yet where applying server-side ACLs 
to NSS maps would actually be of any practical use.

What was the use-case you saw for it?

> Filtering more based on identity of end user on a machine would IMO violate
I wasn't suggesting that different users get different filtered views of 
the NSS maps.  They're open for all to see.  They should, however, 
continue to be used to determine application rights and roles on a 
client, as they do today, which server-side ACLs cannot replace.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 04 Feb 2015 21:55:42 +0000

> describing the specific deficiencies you solved in more detail?

Have at look at the abstract on page 2 of 
http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt.  One of the 
first biggest requirements was reintroducing case sensitivity in a way 
that would be fully compatible with NIS, see the description of the en 
(4.2) and rn (4.3) attributes in particular.  Also, another requirement 
was to fix the schema so that duplicate alias names could be easily 
detected and prevented (1.2).

> I think like me Simo also meant the client side.

Ok, well I'm working on fixing that already.

> question is whether you can install that on legacy Unices or strange applicances.

Legacy unices ... depends how old we're talking.  I currently have 
something that works on RHEL4.8 and newer, and the large organisations I 
have spent most of my time with over the past 5 years are at a point 
where RHEL4.8 is their oldest legacy now.

Strange appliances - not unless I can get the vendor to add support for 
DBIS.  However, even the appliances I've worked with support local class 
& attribute remapping rules, so could be tuned to fit DBIS, or vice 
versa with the DBIS configuration maps 
(http://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/).

> filtering what's delivered to the client at the LDAP server.

By filtering, you mean just removing entries from maps?  But you still 
have an old schema to support that wasn't fully NIS compatible to begin 
with ...

Mark.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 05 Feb 2015 00:06:48 +0100

Mark R Bannister wrote:
> [email-masked] wrote:
>> Mark R Bannister wrote:
> Generically, application roles.  A specific example: sudo, where sudo rules
> are enabled for users based on netgroup membership.  The LDAP server does not
> know the user requesting sudo access, only the client system knows that, so
> server-side ACLs are not going to help.

The server only sees 'sudoRole' entries assigned as visible for its particular
server/host/service group(s). Which particular command a user can execute is
indeed subject to fine-grained control by sudo on the client (based on
attribute 'sudoUser' which with my approach is restricted to only referencing
user groups).

Similar file system permissions/ACLs are evaluated locally, but based on the
limited subset of visible user groups.

> I do need to give a second example, because the first is specific to users. 
> Here is one specific to hosts: NFS, where an NFS server might grant read-only
> access to every host on the network except for those that are members of a
> specific netgroup, which get read-write access.  The NFS server needs to know
> when a client request comes in whether this host is a member of the netgroup
> that grants read-write access or not, and this cannot be implemented by
> server-side ACLs, because only the NFS server knows the identity of the client
> requesting access to the fileshare.

In my model such a NFS client host would be also simply an authenticated
(system) user and member of user groups. The NFS server only sees user groups
assigned as visible for its particular server/host/service group. And
furthermore it only sees the members of those user groups (NFS clients in this
example).

Yes, of course: No IP-based authentication!

> In the deployments I see, typically every user can login to every host, and
> any application could run anywhere, therefore any compromised machine will of
> course yield all NSS data.

Yes. But not with my approach.

> However, the NSS data isn't particularly sensitive anyway,

I disagree.

> and quite often the LDAP directories are open for anyone with a network 
> device to query over port 389 anyway,

Yes in general, but not with my approach. ;-}

> so I haven't worked in an organisation yet where applying server-side ACLs

Well, this system is in production use.  :-)

> What was the use-case you saw for it?

Role separation with separate credentials (especially passwords for sudo
access), and paranoid protection of information I consider sensitive because
it could be used to plan next steps (e.g. social engineering).

And furthermore you can keep the client configuration and map evaluation very
simple because the visibility of users and user groups is constrained by
access control based on server/host/service group membership of the NSS client.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 05 Feb 2015 00:18:55 +0100

Mark R Bannister wrote:
> http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt.  One of the first
> biggest requirements was reintroducing case sensitivity in a way that would be
> fully compatible with NIS, see the description of the en (4.2) and rn (4.3)
> attributes in particular.

Yes, case-sensitive matching is an issue and I already saw that text in your
drafts. I've simply added additional local constraints to the config limiting
e.g. attribute 'uid' to lower-case values. So it was not that important to me.

> Also, another requirement was to fix the schema so
> that duplicate alias names could be easily detected and prevented (1.2).

Are you talking about this text?

https://tools.ietf.org/html/draft-bannister-dbis-mapping-00#section-1.2

Frankly I don't get it (besides the SHALL for LDAP client configuration).

> Legacy unices ... depends how old we're talking.  I currently have something
> that works on RHEL4.8 and newer, and the large organisations I have spent most
> of my time with over the past 5 years are at a point where RHEL4.8 is their
> oldest legacy now.

That's pretty old right now.

> Strange appliances - not unless I can get the vendor to add support for DBIS.

And that is exactly the point.

> However, even the appliances I've worked with support local class & attribute
> remapping rules, 

Unfortunately there are counter examples where you cannot configure local
class & attribute remapping rules.

> By filtering, you mean just removing entries from maps?

Yes, making users, user groups and sudoers entries invisible if the client is
not authorized to see them.

> But you still have an old schema to support

What the client sees is fully compatible to RFC2307(bis) and sudo-ldap schema.

> that wasn't fully NIS compatible to begin with ...

I don't care about full NIS feature set. I've replaced it with something
different. ;-)

Ciao, Michael.

---

From: Clément OUDOT <[email-masked]>
Date: Thu, 5 Feb 2015 09:51:18 +0100

2015-01-25 23:06 GMT+01:00 Michael Ströder <[email-masked]>:
> Clément OUDOT wrote:
>> 2015-01-25 22:03 GMT+01:00 Michael Ströder <[email-masked]>:
>>> Gavin Henry wrote:
>>>>> I would also like to hear about volunteers to work on those documents, either contributing text or reviewing them carefully.
>>>>
>>>> I would like to help where I can.
>>>
>>> Glad to here that. Do you have any particular interest.
>>>
>>> Everybody can start reviewing existing stuff.  Which could also mean that you
>>> simply ask questions if something is not clear enough.
>>>
>>> For inetOrgPerson 2.0 it would help if we collect a wish list and then compile
>>> a realistic requirement list from that.
>>
>> I am also volunteer to help, especially on the password policy draft.
>
> Would you be willing to act as an editor?
>
> If yes, then simply start a new e-mail thread.
>
> A good start would be to agree on a goal.
>
> IMHO we should try to mainly document current state of implementations of
> draft-behera-ldap-password-policy, but also have a closer look on Appendix A
> of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00
>
> Digging the list archives could also help here.

Hi,

thanks for the inputs, I will do my best to work on this. I'll try to
start on new thread on the subject.

Clément OUDOT.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 5 Feb 2015 10:48:24 +0100

Hi Clement,

There was a general consensus that the current password policy draft needs to be split in multiple documents to separate the configuration of it, the internal state representation and the management side of it (controls and possible extended operations).

Ludo
-- 
Ludovic Poitou
http://ludopoitou.com

On 5 Feb 2015 at 09:51:26, Clément OUDOT ([email-masked]) wrote:

Hi,

Clément OUDOT.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 11 Feb 2015 11:56:44 +0000

> attribute 'sudoUser' which with my approach is restricted to only referencing

So you've come up with a point solution for 'sudo' that would replace 
the need for sudo to use
netgroups, because you don't like netgroups.  Great for sudo, perhaps, 
but netgroups are of
generic use to multiple applications, whereas 'sudoRole' and 'sudoUser' 
are specific to sudo
only.  I don't think it's a great idea to replace a solution of generic 
applicability with one that
addresses the need of one specific use-case only.

> furthermore it only sees the members of those user groups (NFS clients in this

I'm not the world's biggest fan of "service accounts", as users should 
be users in my mind, not
systems, but they're prevalent everywhere and I'm not going to solve 
that one.  However,
replacing another example of where netgroups fit nicely with one that 
requires every NFS client
to have its own authenticated user account is not practical in an 
enterprise environment with
80,000 user accounts already and 60,000 hosts.

NFSv4 has already solved the NFS authentication problem, and that 
requires nothing more
than the user who attempts to access the files having a valid Kerberos 
ticket.

> Yes. But not with my approach.

Why not?  If everyone can login everywhere, your approach solves 
nothing?  It just adds an extra
layer of complexity and an extra hurdle to those attempting to 
troubleshoot issues.

>> However, the NSS data isn't particularly sensitive anyway,

If everyone can login everywhere, what NSS data is sensitive?

> Yes in general, but not with my approach. ;-}

Yes but I'm trying to see how your approach can be made applicable for 
all, I don't see how it
could be put out for general use, and therefore I don't see how it can 
be compared with DBIS
or RFC2307, both of which are designed for wide adoption.

> Well, this system is in production use.  :-)

So is a lot of software, good and bad.

> it could be used to plan next steps (e.g. social engineering).

So what if I login one of your hosts and type 'getent passwd'.  What 
will I see?  Enough data
to do some social engineering?

> access control based on server/host/service group membership of the NSS client.

At the cost of added complexity, a false sense of security unless you 
are very careful how
you design who can login to which hosts, and at best you've just shifted 
the target point
for hackers to the LDAP servers instead.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 11 Feb 2015 12:11:12 +0000

> e.g. attribute 'uid' to lower-case values. So it was not that important to me.

"Not that important to me" suggests, once again, that you are coming up 
with a point solution,
and not a solution that could be widely adopted.  I have designed a 
replacement for an RFC
that can be very widely adopted.  Your approach to the 'uid' attribute 
precludes any other
use of this attribute within the same directory server by other 
applications and is not
standards-compliant.

> Frankly I don't get it (besides the SHALL for LDAP client configuration).

As in http://sourceforge.net/p/dbis/wiki/Aliases.

> That's pretty old right now.

Indeed it is, and DBIS will run on them.  So I am supporting legacy unices.

> And that is exactly the point.

That is no different with any new technology.  As uptake spreads, and 
customer demands increase, vendors
add support for the new stuff.  As DBIS works with the old 
RFC2307/RFC2307bis schema as well, customers
can begin to use DBIS right away on the unices that they have control 
over, while the appliances can
continue to use the same data the old way.  Then the pressure increases 
on those vendors and over time
they move to the new way too.  Change has to start somewhere.

> class & attribute remapping rules.

Fine, then in those cases you use the RFC2307 schema and the new DBIS 
clients you install can be
configured to use it with no trouble: 
http://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307

> not authorized to see them.

You could do that with DBIS too, if you wanted.  You could either use 
netgroup constraints 
<http://sourceforge.net/p/dbis/wiki/Netgroup%20Constraints/> (client-side),
and if you really want server-side restrictions in place, split the maps 
up into separate places in the DIT
and use ACLs to restrict which hosts can see them.  Don't forget that 
DBIS can join entries from many
different places in a DIT into a single coherent map, and it uses 
netgroups to determine which hosts
should get which pieces of the map.

Best regards,
Mark.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 11 Feb 2015 13:35:20 +0100

Mark R Bannister wrote:
> So you've come up with a point solution for 'sudo' that would replace the
> need for sudo to use netgroups,

No, it's generally applicable.

> enterprise environment with 80,000 user accounts already and 60,000 hosts.

It is indeed practical. BTW: This is basically what's already done when adding
servers and workstations in MS AD with Kerberos used as authc mech.

> NFSv4 has already solved the NFS authentication problem, and that requires 
> nothing more than the user who attempts to access the files having a valid
> Kerberos ticket.

AFAICS it also requires the servers to have a Kerberos keytab with their
service principal's key(s).  Others with more in-depth Kerberos knowledge
might elaborate on that.  So this model fits my approach quite nicely. :-)

> Why not?  If everyone can login everywhere, your approach solves nothing? 
> [..]

Your assumption that "everyone can login everywhere" is wrong.

> So what if I login one of your hosts and type 'getent passwd'.  What will I
> see?  Enough data to do some social engineering?

If you are root on a system you will see this partial directory data to do
social engineering:

1. getent group: the user groups assigned as visible for this server group

2. getent passwd: all member users of the visible user groups (see 1.).

3. sudo -l: You can discover who can use which sudoers rules visible for this
server group

Admins with access to very sensitive systems are adviced to have separate
accounts (role separation).

> At the cost of added complexity,

But the complexity is implemented *centrally* at the LDAP server's side.
Furthermore the server-side visibility rules are even then enforced when a NSS
client got hacked and re-configured by an attacker.

Which both is a huge gain over having to tweak *all* PAM/NSS clients to do the
right thing.

Note that only LDAP entries are added/modified.  The ACLs working their way
through the references are *static* configuration.

> a false sense of security unless you are very careful how you design who
> can login to which hosts, and at best you've just shifted the target point 

Yes, similar like DBIS this is a frame-work.  The responsible system admins
have to be sufficiently eager to make use of the authorization mechanisms
provided.  The admins have to carefully craft an access control policy by
defining server groups and their relationship to user groups and sudo rules, etc.

Admins who just want an easy one-size-fits-it-all security policy are
definitely not the target audience of any serious access control scheme (and
IMHO should be kicked out of business in the long run).

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 11 Feb 2015 13:52:56 +0100

Mark R Bannister wrote:
> with a point solution, and not a solution that could be widely adopted.

Not right. I simply have other priorities leading to another compromise.

> I have designed a replacement for an RFC that can be very widely adopted.

As already pointed out:
Your approach is not backward compatible to PAM/NSS clients making hard-coded
use of RFC 2307 schema.  I have some doubts that it will be widely used.

> Your approach to the 'uid' attribute precludes any other use of this
> attribute within the same directory server by other applications and is
> not standards-compliant.

Could you please elaborate why defining local constraints is "not
standards-compliant".  I'm really eager to learn more about standards. ;-)

Since you tend to solve things at the client side you could easily configure
PAM/NSS clients to use an extensible LDAP filter using case-sensitive matching
rule for searching users and groups by their name.

> As in http://sourceforge.net/p/dbis/wiki/Aliases.

I know what LDAP alias entries are but I avoid using them.  I suspect that you
try to cure a problem caused by using a specific search base in your PAM/NSS
client configuration.  The approach is simply wrong.

Instead I'd say fix your data and keep client config simple. ;-)

> customer demands increase, vendors add support for the new stuff.  As DBIS
> works with the old RFC2307/RFC2307bis schema as well, customers can begin
> to use DBIS right away on the unices that they have control over, while the
> appliances can continue to use the same data the old way.  Then the
> pressure increases on those vendors and over time they move to the new way
> too.  Change has to start somewhere.

Good luck.

> You could do that with DBIS too, if you wanted.  You could either use netgroup
> constraints <http://sourceforge.net/p/dbis/wiki/Netgroup%20Constraints/>
> (client-side),
> and if you really want server-side restrictions in place, split the maps up
> into separate places in the DIT
> and use ACLs to restrict which hosts can see them.

Your schema is not suitable to let *static* LDAP server ACLs work their way
through the data.

Ciao, Michael.