Subject: [ldapext] DBIS - new IETF drafts

From: Mark R Bannister <[email-masked]>
Date: Sun, 05 Jan 2014 20:21:41 +0000

In August this year, I submitted some new IETF drafts with the intent 
that they would replace NIS and RFC2307.  It introduces Directory Based 
Information Services (DBIS).

Michael Ströder suggested I post a link to this mailing list.  The 
following article (and further articles on my blog) discuss some of the 
aspects of DBIS, and link to all of the relevant internet drafts:
http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html

I am currently working on a reference implementation here:
     http://sourceforge.net/projects/dbis/

This may be coming out of the blue for many of you, and I appreciate you 
may need some time to read and digest my drafts, and then ask me lots of 
questions.

But my first question to you is, where is the best place for discussion 
related to these drafts?  Is this the mailing list to use?

Best regards,
Mark Bannister.

e: [email-masked]

---

From: Howard Chu <[email-masked]>
Date: Mon, 06 Jan 2014 09:40:13 -0800

> related to these drafts?  Is this the mailing list to use?

Yes, this is the correct list.

I must say I'm alarmed at seeing a new proposal that is primarily based on 
NIS-compatible attribute values. This is exactly the same fundamental problem 
in the original RFC2307 which made it less than useful for non-Solaris-based 
OSs like AIX and HPUX. This is the same flaw that I attempted to correct in my 
updated draft http://tools.ietf.org/html/draft-howard-rfc2307bis-02

If you're going to all the trouble of storing data into a universally 
accessible distributed database, you must store it in a canonical format, not 
a particular OS-specific format as NIS/RFC2307 did.

A lot of the data elements and behaviors that the DBIS spec defines appear to 
be client-implementation-specific details. It seems to me their definition is 
inappropriate in (outside the scope of) a universally accessible distributed 
data context.

The discussion of caching here 
http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example 
- this is purely a client-side implementation issue. Also you give nscd as an 
example, and nscd has been thoroughly discredited and is well known to be 
unsuitable for real use. Critical deployments can use a local LDAP server with 
a replica of the central data, to avoid error-prone caching implementations. 
This is a commonly recommended approach when using OpenLDAP nssov, for example.

I agree that this area of spec needs to be polished up, but not by 
disregarding all of the work that was done and experience that has been gained 
since the original RFC2307 was published.

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

-- 
   -- 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: Mark R Bannister <[email-masked]>
Date: Mon, 06 Jan 2014 20:59:57 +0000

On 06/01/2014 17:40, Howard Chu wrote:
>> <snip>

First, Howard let me apologise up-front for not approaching you about 
this sooner.  I appreciate, as the editor of RFC2307bis-02 that it must 
come as quite a shock to you to see a new set of Internet Drafts 
released that could be seen as a direct challenge to your work, and I 
quite understand your defensive posture.  However, I launched this 
initiative as a direct result of working with large corporations (mainly 
banks) who were using RFC2307 extensively across big Linux and Solaris 
installations (between 10,000 to 40,000 hosts) and facing numerous 
pain-points which needed to be addressed.  It was purely technically 
motivated, and I did not mean to cause any offence.  I am completely 
open to ideas and suggestions to further improve DBIS, and I think if 
you dig deep into these drafts and ask me detailed questions you'll 
realise that a lot of time and thought has gone into every decision I 
have made thus far, including preserving whatever makes sense to 
preserve from the RFC2307 heritage.

>
> I must say I'm alarmed at seeing a new proposal that is primarily 
> based on NIS-compatible attribute values. This is exactly the same 
> fundamental problem in the original RFC2307 which made it less than 
> useful for non-Solaris-based OSs like AIX and HPUX. This is the same 
> flaw that I attempted to correct in my updated draft 
> http://tools.ietf.org/html/draft-howard-rfc2307bis-02

Please would you give me some specific examples of what you believe is 
less than useful for AIX and HP-UX, and how you corrected these in 
RFC2307bis-02.  Forgive me but I am coming from a Linux and Solaris 
perspective.

> accessible distributed database, you must store it in a canonical 
> format, not a particular OS-specific format as NIS/RFC2307 did.

Please give me some specific examples of attributes which I am storing 
in an OS-specific format.  I am struggling to think of any, so some 
examples will help me understand your point better.

>
> A lot of the data elements and behaviors that the DBIS spec defines 
> appear to be client-implementation-specific details. It seems to me 
> their definition is inappropriate in (outside the scope of) a 
> universally accessible distributed data context.

Again, examples would help you make your point, and help me to 
understand it.

> http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such 
> example - this is purely a client-side implementation issue. Also you 
> give nscd as an example, and nscd has been thoroughly discredited and 
> is well known to be unsuitable for real use. Critical deployments can 
> use a local LDAP server with a replica of the central data, to avoid 
> error-prone caching implementations. This is a commonly recommended 
> approach when using OpenLDAP nssov, for example.

That's why it's in a section titled "Implementation Notes", i.e. notes 
to help those implementing DBIS.  It's not core to the draft, it's just 
some helpful notes to make the point that the domain-level TTL must 
override any local settings.  I don't see that as such a big deal.  Am I 
missing something?

> disregarding all of the work that was done and experience that has 
> been gained since the original RFC2307 was published.

Yes, this is why I suspect I may be causing offence, for which I 
apologise.  If you believe I am disregarding all of the work that was 
done on RFC2307 and RFC2307bis, this is not true.  When writing DBIS I 
spent much of my time reading RFC2307 and RFC2307bis, ensuring that I 
had thought about everything, and that I could sensibly preserve 
whatever I could from those documents, because I did not wish to 
reinvent the wheel.  However, some of the fundamental incompatibilities 
with NIS, and some of the flexibility and modularity required in a 
successor, mandated (at least in my mind) splitting it out into a number 
of separate drafts and providing a framework to makes it easy for others 
in the future to define additional maps as and when required.

I did actually begin by thinking, shall I just expand on RFC2307bis?  
But I'm sorry to say this, I found the document too unwieldy and 
inflexible to add much value to it.

I hope you do not feel resentful and perhaps would consider offering 
some more constructive guidance on the development of DBIS.

Best regards,
Mark Bannister.

---

From: Howard Chu <[email-masked]>
Date: Mon, 06 Jan 2014 13:19:31 -0800

> preserve from the RFC2307 heritage.

Nothing defensive here at all. I have nothing personally invested in one spec 
or another. As I stated before, it's a mistake to embed Solaris-specific 
semantics into a supposedly universal spec. My response is purely technical, 
since technical details are my only concern.

> RFC2307bis-02.  Forgive me but I am coming from a Linux and Solaris

This is all pretty old ground. 
http://www.openldap.org/lists/openldap-software/200310/msg00138.html

---

From: Mark R Bannister <[email-masked]>
Date: Mon, 06 Jan 2014 21:29:20 +0000

On 06/01/2014 18:41, Simo wrote:
> I have to say I have to agree with Howard here, although I wouldn't 
> consider rfc2307bis *the* solution, at least it tried to fix some of 
> the most glaring issues ion rfc2307, there is lots that can be 
> improved of course, but the direction is good. 

As I wrote in my response to Howard just now, I considered both RFC2307 
and the improvements made in RFC2307bis when I wrote the DBIS drafts.  I 
have not disregarded lessons learned from the past, I am simply 
attempting to move it onto the next logical step.  Look harder, I think 
you'll see a lot of technical content you recognise (although admittedly 
I couldn't keep much of the descriptive text because it didn't fit the 
new model).

> If there is a flawed model that should *not* be followed going forward that is NIS.
> And especially netgroups, please spare us from the disease of NIS
> netgroups, they should be buried, there are much better ways to group
> diverse objects.

Please provide a technical description of "disease" please, because it's 
hard to do anything constructive with a statement like that. Like it or 
not, there are very big installations out there using NIS or RFC2307 and 
netgroups.  If netgroups have been built into the way a corporation 
works, they'll possibly never be extracted.  Embrace and extend (without 
the extinguish) if you'd like to bring those corporations with you and 
make improvements for everyone.  Ignore them, and you get IPv6 all over 
again.  I have taken netgroups and tried to take the "disease" out of 
them, while providing a clear migration path, but was it the same 
disease you were suffering?  I don't know.  Perhaps.  More detail please.

> Same concerns here.

As before, I'm not sure I understand what you mean.  Please provide 
specific examples.

> I do not think this section is particularly bad though.
> It just mentions nscd (bad as it is) as an example but all it really
> does is to prescribe the use of a domain level ttl for all entries. That
> may be useful, but I am not sure it sufficient, at the very least you
> would have to define also how the client handles negative caching and
> have a different timeout there. In the SSSD project we also have
> additional knobs, it is a more complex than you think at first area, and
> using nscd as a blue print is a bad idea.

Yes I have also had similar thoughts about negative caching.  On the one 
hand, not mentioning it at all implies there is one TTL for everything 
(positive and negative) but leaves room for a local implementation to 
vary that.  On the other hand, if there is no standard place to store a 
negative TTL then we get fragmentation and I'd like to avoid that.  This 
was the whole point about putting a framework out there, because at the 
moment too many of these configuration attributes today are 
implementation specific and scattered around the place.  DBIS aims to 
provide a single place that describes how the whole domain is 
configured, right down to the nuts and bolts.  About all a local 
configuration file would need to know is how to contact the LDAP server 
and a base DN for the domain.  Everything else it needs to know is in a 
standard place in the DIT.

> Ack.
> For the security point of view I find it extremely amusing that the
> drafts assumes distribution of the hashes to clients (and mandates the
> use of CRYPT to top it all!). I think that is a very wrongheaded
> approach and should not be pursued at all.

CRYPT is a throwback to RFC2307bis and provides a place to start. That's 
why these are drafts, because they are a work in progress.  I need to 
support old clients as well as new clients, possibly old clients that 
cannot be upgraded.  Backwards compatibility is important.  If DBIS 
doesn't support CRYPT, how do I support the old clients?  Suggestions 
welcomed.  Now I was considering implementing pseudo NIS servers that 
act as a gateway for NIS clients that can't be upgraded, but the PAM 
modules on the old clients are going to expect passwords in CRYPT format 
I assume?  I had yet to prove this in a lab environment, but until now I 
assumed that CRYPT would have to be the lowest common denominator, I'd 
have to support it.  Better authentication schemes can be added as and 
when I found the time to further explore the options.

>
> Mark,
> you are obviously building new clients as nothing existing supports your
> schema so you have to implement new stuff. With this premise keeping
> distributing hashes to any machines on a network instead of relying on a
> LDAP bind operation and keeping hashes private is simply not acceptable
> in 2014 IMO and should not be ratified in IETF as a standard.
>
> Simo.
>
>

I agree the authentication piece always made me uncomfortable, but then 
I'm no expert on the subject.  Find me an expert, lock us in a room with 
a whiteboard, and I'm sure we'll come out with something that ticks all 
the right boxes, my previous paragraph notwithstanding.

Best regards,
Mark Bannister.

---

From: Mark R Bannister <[email-masked]>
Date: Mon, 06 Jan 2014 21:35:16 +0000

> http://www.openldap.org/lists/openldap-software/200310/msg00138.html

Ok, so rather than being "alarmed" you could have just said, "please 
would you consider seconds instead of days for some of the shadow 
attributes".  This is a small request, and very easy to put into DBIS, 
and by no means a "fundamental problem".  Let's put comments into their 
right perspective.

Do you have any more alarming problems that can be turned into simple 
requests?

Thanks :-)

p.s. I'm being playful, no rudeness intended.

---

From: Howard Chu <[email-masked]>
Date: Mon, 06 Jan 2014 13:49:40 -0800

> Do you have any more alarming problems that can be turned into simple

The alarming part is that such obvious flaws in data modeling are still 
occurring today, over a decade after they were first addressed. I raised these 
issues back in 2001 as I recall. Some references in 2002 
http://www.openldap.org/lists/openldap-software/200201/msg00628.html

---

From: Howard Chu <[email-masked]>
Date: Mon, 06 Jan 2014 13:57:26 -0800

> Do you have any more alarming problems that can be turned into simple

Just read thru http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and 
again there's a lot of redundant work here, this time in regards to 
http://tools.ietf.org/html/draft-behera-ldap-password-policy-10

The obvious issue is collisions in some attribute descriptors with the ppolicy 
spec, which is already widely deployed.

More problematic is the data model itself, again. Storing the actual policy 
settings in the user entries will be unmanageable for any moderately large 
sized user population. This is one reason why draft-behera uses dedicated 
policy objects. It is the client side DUA's job to adapt the universal data 
store to the local host's security implementation. And we already have 
pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so I don't 
see much value in defining yet another new broken data model that has no 
existing client support.

As much as you claim to have read and absorbed the prior work in this area, it 
really appears that you have ignored most of it.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 08 Jan 2014 20:01:45 +0100

Mark R Bannister wrote:
>> I have to say I have to agree with Howard here, although I wouldn't consider
>> rfc2307bis *the* solution, at least it tried to fix some of the most glaring
>> issues ion rfc2307, there is lots that can be improved of course, but the
>> direction is good. 

Was Simo's message personal or did I miss a posting by him to the ietf-ldapext
list?

> Please provide a technical description of "disease" please, because it's hard
> to do anything constructive with a statement like that.

@Simo: I know that FreeIPA/sssd has a custom schema. Is there a formal
description of the schema so we can look at what cure you're implementing for
the netgroups "disease"?

Personally I also avoid netgroups (or I don't have a real use-case for them
for now).

Ciao, Michael.

---

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

On 06/01/2014 21:49, Howard Chu wrote:
> The alarming part is that such obvious flaws in data modeling are 
> still occurring today, over a decade after they were first addressed. 
> I raised these issues back in 2001 as I recall. Some references in 
> 2002 http://www.openldap.org/lists/openldap-software/200201/msg00628.html

Well, I still wouldn't call that "alarming" unless you are of the 
singular belief that every message you have personally written has been 
read by everyone in the world.  So, getting down to the exact detail 
here, and ignoring the fluff, am I right that the only complaint you are 
making in this particular message is that whereas on Solaris some of the 
shadow attributes are represented in days, in HP-UX and AIX they are 
represented in seconds?  As already stated, this is easy to fix.  So if 
that is all, I'll log the request, and make the appropriate change in 
the draft in due course.  If you spot any other details you think can be 
done better, I would really like to know.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 08 Jan 2014 20:24:28 +0000

On 06/01/2014 21:57, Howard Chu wrote:
> Just read thru 
> http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again 
> there's a lot of redundant work here, this time in regards to 

Originally I had shadow attributes mingled in with the user and group 
document, as it is in RFC2307, however I decided quite late on in fact 
that it would be better as a separate bolt-on option.  So it went into 
its own draft.  I thought I'd already made it clear in the drafts that 
password policies are best handled a separate way, however, DBIS would 
be incomplete if it did not support the old NIS way of doing it as 
well.  I don't personally like the idea of having per-user shadow 
attributes, however some might see it as a feature and there may be some 
edge cases where this is exactly what is required.  So, what's the harm 
in supporting it?  As long as I make it clear that it is not 
recommended, which is the intention of the following paragraph in 
section 1.1.1:

    It is RECOMMENDED that password policies are managed using native
    features in the LDAP Directory Server if available, or using
    Pluggable Authentication Modules [PAM] to provide consistency of
    security and centralised administration.  Whether or not the shadow
    attributes are used by the policy will vary between implementations.

Perhaps we can work this paragraph better.  I must admit I haven't seen 
draft-behera-ldap-password-policy-10 so I shall add that to my reading list.

>
> The obvious issue is collisions in some attribute descriptors with the 
> ppolicy spec, which is already widely deployed.

draft-behera-ldap-password-policy-10 is already widely deployed, you 
say?  Then it must go higher up in my reading list.

>
> More problematic is the data model itself, again. Storing the actual 
> policy settings in the user entries will be unmanageable for any 
> moderately large sized user population. This is one reason why 
> draft-behera uses dedicated policy objects. It is the client side 
> DUA's job to adapt the universal data store to the local host's 
> security implementation. And we already have 
> pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so 
> I don't see much value in defining yet another new broken data model 
> that has no existing client support.

Indeed, I agree, as stated earlier on I would whole-heartedly recommend 
against having user-specific policy settings.  However, providing the 
facility as an option for those who want to make minimal changes to 
their NIS environment is harmless.

>
> As much as you claim to have read and absorbed the prior work in this 
> area, it really appears that you have ignored most of it.

Appearances can be deceptive.  If you ask me for a reason why I did 
something in a particular way, you'll realise I have actually put a lot 
of thought into the entire design.  I haven't ignored RFC2307 nor 
RFC2307bis, nor indeed any of the RFCs I make reference to in my 
drafts.  I was unaware of draft-behera-ldap-password-policy-10 so thank 
you for pointing this out.  I suspect it will not make a big difference 
short of perhaps becoming the recommended approach.  I'll review it and 
let you know what I think afterwards.

Best regards,
Mark.

---

From: Mark R Bannister <[email-masked]>
Date: Wed, 08 Jan 2014 20:36:02 +0000

On 06/01/2014 23:17, Simo wrote:
> On Mon, 2014-01-06 at 21:29 +0000, Mark R Bannister wrote:
> One thing I forgot to say is that I haven't seen a good rationale
> document to be honest, what did you identify as problems, what did you
> see in the field, what solutions did you discard (you mentioned
> something about RFC2307bis not being good enough in reply to Howard) and
> why. What is the guiding principle behind the choices you made ?
> Apologies if you have mentioned all this, my quick read of the initial
> pages and introductory paragraphs didn't seem to give this information.

You're right I've not written a good rationale document yet and it's 
something I've been meaning to do.  The abstract in 
draft-bannister-dbis-mapping-02 goes some of the way, it doesn't go all 
of the way.  Thinking about this chronologically:

   * At one of my clients, NIS was being migrated into Active Directory 
using the RFC2307bis schema.  This client had circa 6,000 Linux hosts 
and 1,500 Solaris.  They had to use a commercial product to achieve 
this, even though their Linux and Solaris estate had full Open Source 
support for putting all of their NIS maps, including the automounter, 
into LDAP and even though they could have used Open Source tools to get 
the Kerberos authentication working.  I even assessed how it could be 
done with Open Source tooling and wrote about it in my blog which you 
are welcome to read at your leisure: 
http://technicalprose.blogspot.co.uk/2011/10/linux-integration-with-active-directory.html. 
However, they chose a commercial product because the job was so 
difficult, the Linux tooling so fragmented, and RFC2307bis alone was not 
going to help them with a big merger of two NIS domains with clashing 
UIDs and GIDs.  It was at this time that I first decided that RFC2307bis 
did not go far enough to help with the complexities of large 
corporations, even given the similarities in architecture the way in 
which NSS is configured on Solaris and Linux is considerably (and 
unnecessarily) different due to lack of standardisation at the client 
layer.  Unless Open Source tools were to be patched, it would not be 
possible to manage the merger of two NIS domains with clashing UIDs/GIDs 
without renumbering large numbers of user and group accounts.  I 
realised at this time the importance of having a standardised 
abstraction/rewriting layer above the data that would essentially allow 
the data to be fragmented across the DIT, using a different mix of 
attributes to define the fields required by NSS databases, and removing 
the need to perform complex and error-prone data merge and cleansing 
operations in favour of simply linking and transforming.

    * Another of my clients, with approx. 35,000 Linux hosts and 1,000 
Solaris, struggled in particular with case sensitivity.  In fact they 
had to come up with their own schema on top of RFC2307bis in order to 
make things case sensitive again (like they were in NIS).  It seemed 
ludicrous to me that RFC2307bis had made stuff case insensitive, and 
there didn't appear to be a good reason for doing so.  So to fix this 
problem, I couldn't just redefine the same attributes again, because 
that would make migration from RFC2307bis to DBIS really rather tricky 
and probably impossible for large deployments.  So wherever an attribute 
in RFC2307bis is defined as case insensitive, but needed to be case 
sensitive, a new attribute would be required.

    * Looking first at RFC2307bis and deciding how best to tackle these 
problems, I also realised that defining all of the NSS databases in a 
single document was not a good approach.  If I were to support an 
abstraction layer above the data itself, allowing the flexibility I 
wanted to glue maps together from different parts of the DIT, first I 
would need a standard framework.  This would also solve another thing I 
didn't like about current implementations, that NSS client 
configurations can get long, especially when you want to start remapping 
attribute names, are not always defined in a single configuration file, 
and differ from one OS to another.  If I started with a standard 
framework, where all of the information pertaining to the location and 
transformation of the data were in the DIT, it would also make it easier 
for administrators to make structural changes to this data over time 
without ever having to touch the client.  Where would I define this 
framework?  In configuration map objects, defined in 
draft-bannister-dbis-mapping-02.  It seemed to make natural sense to 
define the framework in its own document, and for it to be extensible so 
that even after the standard NSS databases had been described in this 
framework, vendors could come along in the future and plug-in their own 
databases (for example, Solaris has extra databases such as user_attr, 
auth_attr, prof_attr and exec_attr that I wouldn't want to define within 
DBIS at this time but nothing stops Oracle adding them).  It was taking 
shape itself: one document to describe the framework, then one document 
for each of the standard NSS databases.

    * Netgroups, urgh.  A third field that always seems redundant, and 
I've worked at clients where they have thousands of nested netgroups and 
it's a horrible mess.  So I had to do something about those.  Cleaning 
up their definition so there is no redundant data was step one, 
introducing netservices to help reduce the sheer number of them was step 
two.  I hope the net result will be to make them a lot more appealing 
and a lot easier to use.

> This said,
>
> What is the point of a new schema if you feel bound to serve unchanged
> legacy clients for example, aren't you pretty much shackled to RFC2307
> that way ?

So a new schema is required anyway, if problems such as case 
insensitivity and to be avoided.  There are other things I've fixed 
throughout the schema as well which I won't list here, but should be 
clear in my drafts.

Legacy NIS clients can't use RFC2307, only if they have already been 
configured with nss_ldap.  So, legacy NIS clients can either be migrated 
to use nss_dbis, or alternatively we can point them at a pseudo NIS 
server that back-ends to DBIS.

Clients already migrated to nss_ldap need to move over to nss_dbis 
first.  This can be done quickly and in stages, because DBIS 
configuration maps can be defined that point to the existing data in 
LDAP.  It should be as painless as setting up a few configuration maps, 
then deploying nss_dbis to the clients.  New NSS data, such as new user 
accounts and group accounts, can start to be populated in a different 
area in the DIT using the new schema, and referenced by a different set 
of configuration maps, which are received by clients filtered by 
netgroup.  Don't forget that a single client can use data from multiple 
places in the DIT using a mix of different schemas in order to piece 
together a single map.  Then, optional if you want the benefits of the 
new schema, we may choose to do a mass migration of data from RFC2307 
schema to DBIS schema and get rid of RFC2307 completely.  Except 
switching from nss_ldap to nss_dbis, all this done off-client and 
seamlessly.  The clients are none the wiser that the data is being moved 
around and transformed beneath them. So, no, not shackled in any way to 
RFC2307.

> OTOH, if you think you can change stuff then why stick to the NIS
> paradigm, which doesn't really map well at all to modern directories ?

If by this you are referring solely to shadow entries (password 
policies), then I think I've answered this question in my response to 
Howard.  Do you have examples of anything besides shadow entries that 
don't map well to modern directories?  I could do with some specifics to 
give you a meaningful response.

> Well the definition of netgroups simply makes little sense as it is in
> NIS and RFC2307. The fact you have triplets but then only 2 parameters
> at a time can be effectively used at once makes little sense and keeping
> that representation simply maintains a bad data representation model and
> keeps legitimizing it instead of fading it off.

So this is why I've changed that.  I've slightly redefined the meaning 
of the "domain" component in the triplet, and I'm defining netgroup 
members using two multi-valued attributes: netgroupHost and 
netgroupUser, rather than by a triplet.  The domain component can 
optionally be used with either of those two attributes, and has a more 
useful meaning when applied.  Take a closer look at 
draft-bannister-dbis-netgroup-01 again.

> It looks like you are trying to build a glorified NIS, trying to follow
> closely the way information is stored in files, but why ?
> I do understand quite well the need for compatibility on the client, esp
> with nsswitch interfaces, but that doesn't mean the best representation
> in the directory is a straight copy, which is unfortunately what the
> NIS/RFC2307 schema extenders did.
>
> What I mean, and suspect Howard may mean too, is that what should be
> done is to provide the objects and attributes that matter to identity
> management today, and only as a second layer explain how a client can
> map those attributes to the legacy NIS concepts for clients that need to
> serve that representation internally through its legacy interfaces.
>
> This is what I ave tried to do in the FreeIPA project for example,
> although within the limits of what we could do many years ago when we
> started, and only later we provided a compatibility tree that provides a
> view of the data to make legacy clients happy, performing whatever
> transformations are necessary to make them work, but not binding the
> directory model to the legacy objects and attributes.

So the problem here is that I wanted a solution we can use right now, 
today, and with minimal pain.  You'll see from some of my description 
above that it's actually very easy to swap a client from nss_ldap to 
nss_dbis to gain lots of benefits.  Changing the data model considerably 
makes it a lot more difficult to migrate from one solution to another, 
and large corporations obviously want to minimise the amount of big 
change going on, as large changes are prone to error.  Migrating to DBIS 
involves a small number of steps which are all easily reversed.  Up-take 
depends on ease of migration, if you want a solution to be used you have 
to consider backwards compatibility, otherwise like I said before, you 
end up with IPv6 (which despite being invented in the 1990s I have 
personally yet to see any of my clients making any use of it).  I'm not 
someone who likes to design something "academically perfect" if no one 
besides academics are going to use it.

>> cannot be upgraded.
> Old clients that can't be updated can't make any use of new schema nor
> follow it anyway, so I fail to see the point to cater for those clients
> in this schema. I am not saying you shouldn't make allowances to
> *optionally* support exposing those hashes for compatibility purposes,
> but it should be clear it is an option and there should be language in
> the security considerations about how to properly limit exposure of such
> hashes through ACI or other configuration etc...

I agree.  I really dislike having to support CRYPT.  If I could get rid 
of it completely I would.  But I would only get rid of it completely if 
I could still guarantee a smooth migration from one system to another.  
I don't see how that is possible.  You're going to force 10,000+ users 
to change their passwords?  Ok, users might not be such an issue because 
they are probably being forced to change their passwords every 90 days 
anyway.  But service accounts, that's very difficult.  I have to support 
CRYPT because I don't want a migration to DBIS forcing passwords to be 
changed.  However, I entirely agree that we should give people as much 
help as possible to migrate to a more secure password scheme, and should 
strongly recommend it.  If it's really easy to do, then it'll be a 
no-brainer.

>
>> Backwards compatibility is important.
> The only way to be backward compatible at the LDAP level is to maintain
> all the problems of RFC2307, which I would rather see left behind.

Indeed.  But as you'll see from my earlier points, you can use the 
RFC2307 schema with a DBIS client, and that can be a very useful 
stepping stone in moving on to a better schema.

>
>> If DBIS  doesn't support CRYPT, how do I support the old clients?
> Through a new PAM module ? After all if you can't even put a new pam
> module on those client syou most probably can't put a new nsswitch
> client either so the new schema will not be used at all.

I think I've covered CRYPT already.

>> Suggestions welcomed.
> The way I solved it in most cases is by using pam_krb5 (or equivalents),
> ie move auth completely way from LDAP for those clients.

Service accounts.  Don't want to force password changes.  Discussed this 
already above.

>> Now I was considering implementing pseudo NIS servers that
>> act as a gateway for NIS clients that can't be upgraded,
> We've done this too in FreeIPA (see slapi-nis directory module), because
> you have no choice after all, if you need to serve legacy clients you
> are better off providing a gateway, so you do not have to touch those
> clients at all, except when it is finally time to decommission them and
> then you can flip a single switch and throw away all the compatibility
> garbage you were forced to provide. Meanwhile the main DIT is free(er)
> to evolve.

Fine if migration occurs once and once only.  Large corporations buy 
companies.  Mergers & acquisitions mean that your data will be polluted 
again.  Rather than making each and every merger painful, with DBIS you 
have the flexibility to plug-in new data, even though it doesn't comply 
with the standards you prefer, and get using it straight away.  Then you 
can perform migrations under the covers in your own time without senior 
management breathing down your neck asking you when they can finally 
kill the legacy network links or legacy infrastructure because it's 
costing them lots of money to maintain it.

>>   but the PAM
>> I assume?
> Well, the point of the "Pluggable Authentication Module" system,
> usually, is that you can plug new modules. I do understand there may be
> resistance doing that on some old systems, but you need to draw a line
> at some point.

Why draw a line?  We don't need to draw a line.  Old NIS clients can use 
DBIS if you point them at a NIS gateway server.  No changes required at 
all on the NIS client.  Old infrastructure can continue to rot for a few 
more years.  Sometimes we have no choice.  Senior management says "jump" 
and we have to jump.  "These 100 hosts are critical to the running of 
this bank and must NOT be touched under any circumstances".  Oh and also 
"decommission those old NIS servers".  DBIS with a NIS gateway allows us 
to do both.  Prior to DBIS, we could not meet both of these requirements.

>
>>   I had yet to prove this in a lab environment, but until now I
> Exposing hashes should be a last resort for compatibility reasons only
> and should be disabled by default with appropriate ACIs.

I don't suggest DBIS makes any mention of ACIs.  That's up to local 
rules & procedures, not something that could possibly be standardised.

> My point of view is that using LDAP binds SHOULD be mandated for
> authentication for any new client following any new schema, and exposing
> hashes MUST be disabled by default, and explicitly enabled by admins
> that needs backwards compatibility. We need to move up the security bar,
> and you do that only with appropriate defaults, and new IETF work should
> reflect that IMHO.
>
> Simo.
>
>
>

I don't think LDAP binds can be mandated, we can only strongly recommend 
it.  Given the migration path I have already described, I find it highly 
unlikely that people will be able to move to LDAP binds and move off 
CRYPT immediately, I would rather encourage them to get onto DBIS first 
and then gently steer them down a more secure route afterwards.  To be 
honest, people can make up their own minds about security, we don't have 
to make their minds up for them.  We offer them the tools and the 
options, the interoperability, and they decide how secure they want to 
be.  Both of the clients I mentioned earlier, with 7,000 hosts and 
36,000 hosts respectively, used Kerberos authentication with RFC2307bis 
anyway.  So they had already elected a stronger password scheme.

Best regards,
Mark.

---

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

Mark R Bannister wrote:
> I don't personally like the idea
> of having per-user shadow attributes, however some might see it as a feature
> and there may be some edge cases where this is exactly what is required.

AFAICS today nobody is seriously using LDAP with shadow attributes anymore.

> draft-behera-ldap-password-policy-10 is already widely deployed, you say? 
> Then it must go higher up in my reading list.

Yes, it's the only standard considered widely deployed. You have to know it.

> against having user-specific policy settings.  However, providing the facility
> as an option for those who want to make minimal changes to their NIS
> environment is harmless.

If I replace NIS with LDAP I already have two options:
1. Simply use RFC 2307(bis) for a naive transition
2. Do a migration to really meaningful LDAP schema

IMHO with 2. I can drop all NIS specific things anyway. You have to decide
whether DBIS is just an improvement for 1. or a real innvotation for 2.

Ciao, Michael.

---

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

>> and should be disabled by default with appropriate ACIs.

The problem with exposing a central {CRYPT} hash is that a central and single
password will be compromised even though newer systems might be capable of
using stronger authc mechs. Especially if you want to support old systems you
likely won't be able to use a stronger {CRYPT} hashing scheme.

=> I'd avoid that mess completely and I won't support any schema encouraging
this. At least your drafts should contain big ALARM notes in the security
considerations section.

> I don't suggest DBIS makes any mention of ACIs.  That's up to local rules &
> procedures, not something that could possibly be standardised.

>> and you do that only with appropriate defaults, and new IETF work should

+1 to Simo's comment.

> I don't think LDAP binds can be mandated, we can only strongly recommend it. 
> Given the migration path I have already described, I find it highly unlikely
> that people will be able to move to LDAP binds and move off CRYPT immediately,

If your customers have old legacy systems which they won't change at all then
simply let them run them in a isolated environment with all the old cruft
around they need for those systems. Sooner or later they have to migrate
anyway because systems are running out-of-service (e.g. will not receive
security updates anymore).

IMO any new standard should focus on getting the near future right.

Ciao, Michael.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 09 Jan 2014 17:02:34 +0100

> Michael Ströder <mailto:[email-masked]>
> January 9, 2014 at 15:50
> Mark R Bannister wrote:

Actually, I'm not sure version 10 is the version that is widely 
implemented. Version 9 is the one that was implemented in Sun DS, 
OpenDS, OpenDJ, Oracle servers...

Ludo
> Mark R Bannister <mailto:[email-masked]>
> January 8, 2014 at 21:24
> attributes, however some might see it as a feature and there may be 
> some edge cases where this is exactly what is required.  So, what's 
> the harm in supporting it?  As long as I make it clear that it is not 
> Perhaps we can work this paragraph better.  I must admit I haven't 
> seen draft-behera-ldap-password-policy-10 so I shall add that to my 
> reading list.
>
>>
>> The obvious issue is collisions in some attribute descriptors with 
>> the ppolicy spec, which is already widely deployed.
>
>> pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, 
>> so I don't see much value in defining yet another new broken data 
>> model that has no existing client support.
>
> Indeed, I agree, as stated earlier on I would whole-heartedly 
> recommend against having user-specific policy settings.  However, 
> providing the facility as an option for those who want to make minimal 
> changes to their NIS environment is harmless.
>
>>
> something in a particular way, you'll realise I have actually put a 
> lot of thought into the entire design.  I haven't ignored RFC2307 nor 
> drafts.  I was unaware of draft-behera-ldap-password-policy-10 so 
> thank you for pointing this out.  I suspect it will not make a big 
> difference short of perhaps becoming the recommended approach.  I'll 
> review it and let you know what I think afterwards.
>
> Best regards,
> Mark.
>
>
> Howard Chu <mailto:[email-masked]>
> January 6, 2014 at 22:57
>
>
> Just read thru 
> Mark R Bannister <mailto:[email-masked]>
> January 6, 2014 at 22:35
>
>
> and by no means a "fundamental problem".  Let's put comments into 
> their right perspective.
>
> Howard Chu <mailto:[email-masked]>
> January 6, 2014 at 22:19
> Mark R Bannister wrote:
>>
> Nothing defensive here at all. I have nothing personally invested in 
> one spec or another. As I stated before, it's a mistake to embed 
> Solaris-specific semantics into a supposedly universal spec. My 
> response is purely technical, since technical details are my only 
> concern.
>

---

From: Clément OUDOT <[email-masked]>
Date: Thu, 9 Jan 2014 17:26:31 +0100

2014/1/9 Ludovic Poitou <[email-masked]>

>
>
>   Michael Ströder <[email-masked]>
>  January 9, 2014 at 15:50
>
> Mark R Bannister wrote:
>
> implemented. Version 9 is the one that was implemented in Sun DS, OpenDS,
> OpenDJ, Oracle servers...
>

And OpenLDAP. Seems RedHat (389) use it too, as it was implemented in the
SUN DS code base used for this server.

I think nobody implements version 10 yet.

Clément.

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 9 Jan 2014 17:43:21 +0000

> >> and should be disabled by default with appropriate ACIs.

Absolutely. You need the LDAP server to support the old-style hashes
to allow for migrating data in, but exposing *any* form of hash
outside your trusted LDAP servers is asking for trouble.

Every LDAP-aware client system that I have worked with can use the
bind operation as a means to validate passwords, so the only
possible excuse for exporting hashes is temporary support of
migrating systems. If you only allow the export of hashes that are
actually needed by the old non-LDAP systems then at least you are
not making matters worse than they were before the migration.

> >> and you do that only with appropriate defaults, and new IETF work should

Another +1.

I find that showing people the crack-attempt rate tables on
Hashcat's front page usually ups the priority for getting rid of old
hashes... To see the data for Crypt-style hashes you need to go back
in the archive a bit:

	http://web.archive.org/web/20130703144216/http://hashcat.net/oclhashcat-plus/

Comparing those figures (July 2013, based on software from January
2013) with todays is interesting too. The latest hardware they have
tested boosts the crack-rate by another order of magnitude so
traditional Unix-style crypt(3) hashes are probably testable at 600M
attempts/sec, with plain MD5 now at 81000M and NTLM at 140000M...
That means that *every possible* 8-character ASCII password can be
tested against a file of NTLM hashes in 12 hours, or against Unix crypt
in 117 days on a single PC. Real passwords are at least 1000 times
weaker in practice.

In terms of LDAP best practice what this means is:

	Store password data using a modern salted hash that was
	designed specifically for this purpose. Preferably choose
	one that allows the number of iterations to be increased in
	the future. [ I currently favour bcrypt ($2a$), falling back to
	sha512crypt ($6$) or md5crypt ($1$) if that is not available ]

	Use ACIs to prevent access to password storage fields.

	Use all good system-management practices to protect the LDAP
	database, the filesystem, the physical disks, and the backup
	tapes from being copied or stolen.

	Advise users to set much longer passwords than before.
	e.g. a 5-word Diceware password is about 1000 times better
	than the best possible 8-character ASCII password - and a
	lot easier to remember and to type!

	Passwords hashed with weak schemes may be imported as part
	of a migration process provided they are changed within some
	short period of time to be set by a sensible risk analysis.

> security updates anymore).

I would be a bit more flexible than that. There are often advantages
to loose coupling of the old system to the new one: reduced support
effort, maybe even increased security as passwords actually do get
changed, etc. There are risks though, and these need to be
considered on a case-by-case basis. An obvious example here would be
a system that stores an old Unix-crypt hash alongside a bcrypt one
with both derived from the same data. The old hash is easily
attacked and will expose the first 8 chars of the full password with
very little effort, making it much easier to attack the full
password in the bcrypt hash.

> IMO any new standard should focus on getting the near future right.

Yes, but that does have to include migrating stuff that is currently
stuck in the technological past!

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 19:08:12 +0100

Simo wrote:
> The full schema definitions can be found here:
> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif

Looked at the schema:

I'm a bit confused by some object classes directly referencing MAY memberOf.
'memberOf' is normally an operational attribute also in 389 DS isn't it?

Also I don't understand the rationale for object class nestedGroup SUP
groupOfNames with memberOf.

Regarding host groups: Can hosts be member in more than host group and if yes,
why? I've also considered that in my own schema but did not find a good reason
to do so.

Ciao, Michael.

---

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

Simo wrote:
> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>> Simo wrote:
> It is a generated by the memberof plugin, it's semantics are different
> from other solutions (like AD), all descendants are resolved at modify
> time.

Really different semantics?

AFAIK memberOf should be a simple back-link from the member's entry to the
group entry. When the attribute value is actually created (on modify or on
read) is not relevant for memberOf semantics. Or did I get you wrong?

> Not sure where's the confusion.

I'm confused by seeing an operational attribute like 'memberOf' being defined
in user schema.

Ciao, Michael.

---

From: Howard Chu <[email-masked]>
Date: Thu, 09 Jan 2014 18:33:56 -0800

Mark R Bannister wrote:
> read by everyone in the world.

Don't be stupid. My expectation is that anyone who intends to write new LDAP 
specifications for the IETF has already read all of the existing LDAP 
specifications and any discussions surrounding relevant works-in-progress, 
along with the already published defects in such unfinished items. Clearly you 
have not done your due diligence.

It takes very little time to troll the ldapext mailing list archive and find 
previous attempts to fix RFC2307. E.g. 
http://www.ietf.org/mail-archive/web/ldapext/current/msg01808.html

It takes not much time at all to google "rfc2307 nis ldap" and find commentary 
from the original author(s) noting the spec's problems and better alternatives.
http://www.openldap.org/lists/openldap-software/200201/msg00628.html
http://www.openldap.org/lists/openldap-software/200109/msg00278.html

It takes not much time at all to see that most of the problems you're trying 
to address have already been attacked, e.g. the schema mapping in your spec 
overlaps RFC4687.

If you haven't fully absorbed the existing specs and standardization efforts 
then there's no way to take anything you've done as anything other than 
reinventing the wheel. That's not how progress gets made, that's how time gets 
wasted.

---

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

> AFAICS today nobody is seriously using LDAP with shadow attributes anymore.

Please provide me some empirical evidence that this assertion is true.

> Yes, it's the only standard considered widely deployed. You have to know it.

Thanks.  Do we have any idea how widely adopted it is?

> whether DBIS is just an improvement for 1. or a real innvotation for 2.

It's 2.  Show me something I've done that's not "really meaningful" and 
we'll look at improving it.

Best regards,
Mark.

---

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

> this. At least your drafts should contain big ALARM notes in the security

As long as we have a solution to make migration to DBIS straightforward 
and without forcing everybody to change their passwords and without 
forcing legacy NIS clients to require upgrading, then I'm with you.

>>> and you do that only with appropriate defaults, and new IETF work should

Can all LDAP servers on the market today use a CRYPT-style password to 
serve a bind request?  If so, it's easy to mandate this.  If not, it 
won't be mandatory.

> IMO any new standard should focus on getting the near future right.

This is where we differ a lot.  You would throw away the past to build 
the future (ironically something that Howard seems to be accusing me 
of).  I, on the other hand, am all about building bridges between the 
past and the future so that we don't cut anybody out.  Everyone should 
be able to make use of DBIS, right now, without pain.  Flick a switch, 
you're on DBIS, then slowly make improvements once you're on a better 
framework.  That's the philosophy, and I'll happily battle hard and feel 
lots of pain now convincing everybody that you can't ignore the past, if 
it means users of DBIS in the future don't have to feel any pain.

Best regards,
Mark.

---

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

> not making matters worse than they were before the migration.

Ok, so I posed this question just now, but can all LDAP servers you can 
think of authentication bind operations using CRYPT-style passwords?  If 
it can be done server-side there'll be no problem here and we need never 
expose the hashes to clients.

> stuck in the technological past!

Thanks Andrew, I think this point can't be emphasised enough.  We must 
always be aware of how customers are going to be expected to get from A 
to B.  That journey needs to be as simple as possible. If that means 
supporting extra legacy stuff to smooth the transition, than so be it.

Best regards,
Mark.

---

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

> Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords?  If it can be done server-side there'll be no problem here and we need never expose the hashes to clients.

Active Directory cannot.

-- Luke

---

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

On 10/01/2014 02:33, Howard Chu wrote:
> Don't be stupid.
<snip>

Howard,

If you have some more technical input I'd really like to hear it. 
Otherwise you have already made your point, which regards only 5 
attribute definitions in 1 of my 8 submitted drafts, and which I have 
already committed to fixing.

Best regards,
Mark.

---

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

>> Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords?  If it can be done server-side there'll be no problem h…

Right.

But it's not a real operational issue because if you already have an AD domain
with a big user base they already have passwords set for Windows anyway.

Ciao, Michael.

---

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

>> Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords?  If it can be done server-side there'll be no problem h…

Thanks Luke.  Everywhere I have seen UNIX accounts deployed on AD, 
Kerberos password authentication has been used, so in those places it 
would not be an issue.  However, I cannot possibly know how many people 
out there rely on CRYPT hashes in AD attributes, and I'm not about to 
cut off the possibly of them migrating to DBIS.  CRYPT will therefore 
have to remain as an option, although I'm perfectly happy to put 
stronger wording around it.  So far I have written:

    While a DUA MAY implement any authentication password scheme
    supported by the DSA, it MUST support the CRYPT scheme for backwards
    compatibility, which is an implementation of the traditional UNIX
    crypt algorithm.  However, it is RECOMMENDED that a more secure
    scheme is used.

and ...

    Passwd and group database entries contain encrypted passwords and
    SHOULD be transmitted securely when transferred between DSA and DUA
    to prevent eavesdropping.  A DUA SHOULD NOT allow a user to see any
    encrypted passwords except they MAY see the password on their own
    posixUserAccount entry in encrypted form.

Open to suggestions on how to reword this.

Best regards,
Mark.

---

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

> Please provide me some empirical evidence that this assertion is true.

Not numbers but my impression from lurking on various directory-related
mailing lists.

> Thanks.  Do we have any idea how widely adopted it is?

Currently everybody who wants to use LDAP password policy has to use it. It's
the only standard I know of for which is at least some client support implemented.

> It's 2.  Show me something I've done that's not "really meaningful" and we'll
> look at improving it.

Well, if you claim that you will implement a NIS/DBIS gateway you don't have
to define user-specific policy settings. You can map anything you want in your
gateway provided there's a reference from the user entry to the policy entry.
I'd go for a DN reference so you can make use of deref control.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 10 Jan 2014 17:37:31 +0000

> > Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords?  If it can be done server-side there'll be no problem…

True, but there are many things that Active Directory cannot do.
It is not a general-purpose LDAP server: it is a proprietary
database that happens to support an LDAP access method.

As for CRYPT (at least the traditional 13-character DES version) in
other servers:

	OpenLDAP				yes
	IBM Tivoli Directory Server		yes
	389					yes
	OpenDJ					yes
	Sun/Oracle DSEE				yes
	Oracle OID				yes
	Isode M-Vault				yes
	ApacheDS				yes
	Lotus Domino				very unlikely

The only server that I have not been able to find a clear
statement of CRYPT support for is Lotus Domino - and like AD, that
is really not intended as a general-purpose LDAP server.

Of course these days we are not just talking about 13-character
CRYPT in migration jobs. Any decent Unix-like system released in the
past decade or two is likely to use a stronger hash algorithm in
/etc/shadow. Support for those is much more restricted, and normally
depends on the underlying OS to supply the hashing code. Some of the
enterprise distros have only gained support for my preferred hash
algorithms in the past couple of years, so running LDAP servers on
older enterprise OSs can be rather limiting.

Andrew

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 10 Jan 2014 17:44:11 +0000

>    crypt algorithm.  However, it is RECOMMENDED that a more secure

Is it really necessary for client code to get involved with this at all?

>    posixUserAccount entry in encrypted form.

Don't rely on the DUA (client code) to protect data from the user.
That's just saying "here is a bit of paper with a secret on the
other side; please don't turn it over". The person currently looking
at the screen may not be the person who logged in...

Andrew

---

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

> is really not intended as a general-purpose LDAP server.

Domino/LDAP uses its own password attribute for LDAP simple bind with the
so-called "Domino HTTP password".

Ciao, Michael.

---

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

Simo wrote:
> On Thu, 2014-01-09 at 21:45 +0100, Michael Ströder wrote:
>> Simo wrote:
> It is not a backlink in FreeIPA.
> 
> If you have:
> groupA:
>    member: GroupB
> 
> groupB:
>    member: userC
> 
> then userC's memberof is:
> 
> userC:
>   memberOf: groupA
>   memberOf: groupB
> 
> This makes initgroups a lot more efficient as it is a single dereference
> search to get all groups a user directly or indirectly belongs to.

(Sigh!) You took the attribute type NAME and OID from MS AD:

( 1.2.840.113556.1.2.102
  NAME 'memberOf'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  NO-USER-MODIFICATION )

But you've changed the semantics. In AD 'memberOf' does not(!) include nested
group membership.

That's really bad practice and makes client developers live really miserable!

Ciao, Michael.