Re: [ldapext] DBIS commentary

On Thu, 2015-11-26 at 11:01 +0000, Bannister, Mark wrote:
> Hi Jordan,
> 
> This is all excellent feedback, thanks, I really appreciate the time
> you have taken to provide your
> comments.  Many of the points you raise I did spend a long time
> considering myself when I was
> writing the internet drafts, so I hope to provide you with more
> insight into my rationale and why
> I decided to do things the way I did.
> 
> I hope you don't mind but I'm copying it to the ldapext mailing list,
> so that others can also
> comment if they wish.  For others, Jordan is commenting from the
> DBIS/RFC2307
> schema comparison and not directly from the internet drafts:
> 
> http://sourceforge.net/p/dbis/wiki/DBIS%20and%20RFC2307%20schemas/
> 
> Jordan Brown wrote:
> > High-level comments:
> > - In general, our direction is towards X.500 compatibility and
> > Active Directory compatibility.  I would
> >   resist new mechanisms that duplicate those.
> > - As noted in more detail below, I consider case-insensitive
> > processing to be the correct direction and
> >   would resist moves towards case sensitivity.
> > - Some of the mechanisms here (e.g. gecos mapping) seem to
> > duplicate RFC 4876 profiles.
> 
> Thanks for the summary, I'll answer these points individually as I
> get to them below.
> 
> > 
> > Footnote 1 says that published classes may not be redefined.
> > Although not all changes seem permissible,
> > some changes (e.g. addition of MAY elements) seem like they could
> > be allowed.  Is there a reference for
> > this restriction?  Note that between X.521-1993 and X.521-2012 the
> > TelecommunicationAttributeSet had
> > an attribute deleted.
> 
> I haven't looked for a reference to this restriction, I had learned
> it from seeing previous exchanges
> on the ldapext mailing list with Kurt Zeilenga.  Here is one such
> exchange, regarding changing the
> schema declaration of 'posixGroup' in RFC2307bis:
> 
> https://www.ietf.org/mail-archive/web/ldapext/current/msg02072.html
> 
> > 
> > posixAccount / posixUserAccount
> > 
> > en:  I consider the change from a case-sensitive name in NIS to a
> > case-insensitive name in LDAP to be an
> > improvement that should not be reversed.  It is telling that (a)
> > there are no cases in the industry other
> > than UNIX user names where user names are case sensitive, (b) that
> > there are numerous examples in
> > the industry of treating the left side of an e-mail address as case
> > -insensitive, and (c) the X.520 "name"
> > attribute, the base attribute for all naming, is case-insensitive.
> 
> NIS was case sensitive.  That led some firms to put entries in
> various maps that were the same except
> for case.  I have examples here where this occurs in the passwd,
> group, netgroup and services maps.
> Changing these entries would be a) very difficult indeed to the point
> of insurmountable as they've
> been ingrained in many systems in a very large enterprise for over a
> decade and b) unnecessary had
> the RFC2307 schema been 100% backwards compatible with NIS.

NIS was just a poor job of taking the passwd and group files and
reproducing them verbatim in a networked environment, and it badly at
it.
Case sensitive names is something that may be wanted by some legacy
environments, but it is really a bad idea in modern environments and
should be discouraged.
I firmly believe you could have a way to allow case-sensitive names,
but insensitive names should be the default and recommended way, I
fully agree with Jordan on this.

Usernames are used by *users*, not just by machines, and most users
(and admins) will consider the Mark and mark to be the same thing, and
rightly so, it is. Any system that allows you to have two users with
substantially the same name is a failure and a security issue waiting
to happen, so that should not be encouraged.

>   I explain this rationale further in my
> DBIS paper:
> 
> http://ldapcon.org/2015/wp-content/uploads/2015/09/DBIS-Paper-2015.pd
> f
> 
> We had a few choices.  The one which we used for the past few years
> was to define our own custom
> schema.  We had to invent three new custom attributes and seven new
> custom object classes to
> get around this limitation.  It infuriated me that we couldn't use
> RFC2307 out-of-the-box because it
> was not 100% compatible with the NIS schema, and this was one of the
> primary driving forces
> behind me starting DBIS.
> 
> DBIS is my stake in the ground to say we MUST solve this problem.  I
> hear what you're saying,
> but your arguments for case insensitivity disregard that UNIX is
> primarily a case-sensitive
> operating system and that NIS was also case-sensitive.  Frankly, as
> RFC2307 was supposed to
> be primarily getting NIS data into LDAP, it failed tremendously by
> bending to the Windows/AD
> case insensitivity preferences.  UNIX will not change.  It will
> always be case sensitive.  Therefore
> we need an LDAP schema that will respect that.

Unix passwd files are case sensitive, that doesn't mean LDAP has to be
at all. If you have the right pam/nss modules you can definitely behave
in both case preserving or case insensitive ways easily, and the Unix
system will not care. The kernel cares only about uidNumber/gidNumber
and names are just a representation.
There are unfortunately people that code their applications in a way
that user user/group names fro access control without first resolving
them to their numeric identifier, those are already broken wrt renames,
and may be broken if you return a random case from nsswitch plugins,
but you do not have to return a random case from a nsswitch plugin you
can simply always return all lowercase and your system is perfectly
consistent then.

Proof is that we've been using case-insensitive setups for more than a
decade (both LDAP, and Samba/Windows based source of user information)
and it works in 99.9% of setups.

> I hope this doesn't mean we end up with one schema for UNIX and one
> for Windows, perhaps
> we can be creative, for example, encouraging Windows software to
> force all characters to
> lowercase before adding entries to LDAP and constructing search
> filters, although this will
> probably be prone to breakage.

Any new schema for LDAP that insist on being only case sensitive is
simply broken and cannot be a standard IMHO.

>   Or perhaps we can define some special attributes where case
> is handled differently depending on the capability of the client.

A schema that allows to define sensitivity *may* work, depending on the
details.

>   If the client claims it is
> case sensitive, these special attributes are handled case
> sensitively, and vice versa if the client
> claims it is case insensitive.  I see case sensitivity as an issue
> that will prevail forever, in the
> same way that endianness will differ between architectures; they will
> never converge and
> so we should not be accepting standards that do not provide a
> solution for both types.

Not sure about that, we have experience that unix/linux system can work
just fine with case insensitive user names, only some broken/legacy
setup cannot cope because of existing broken data, but that is not a
Unix issue, it is a specific deployment issue. It is ok to let those
deployments have an option perhaps (I think they are just broken on
security grounds, but that's just my opinion) but I think your
characterization that Unix/Liunux clients can only cope with case
sensitive names is misleading, given we have experience that they can
cope just fine assuming the nsswitch and pam module used are properly
built to deal with that.

> > 
> > authPassword:  Imported from RFC2307bis-02 and thence from RFC
> > 3112.  Partially, but only partially,
> > duplicates userPassword (from X.509 via RFC2307).  Appears to
> > completely duplicate userPwd (also
> > from X.509).  May also duplicate encryptedUserPassword, mentioned
> > in X.520 but not defined
> > anywhere that I can find.
> 
> I added authPassword simply because I wanted those using RFC2307bis
> to be able to migrate
> seamlessly to DBIS.  I made it clear in the drafts that there are
> better and more secure ways to store
> passwords and these should be used in preference - authPassword was
> provided for backwards
> compatibility only.
> 
> If you have an issue with authPassword being in RFC2307bis, now is
> the time to raise it, as it
> is on the new LDAPEXT charter and the WG are planning to finalise
> RFC2307bis in the
> next 12 months and give it its own RFC number.

I have the issue that in 2015 we cannot propose standards that assume
password hashes are distributed outside of the directory, and that
password storage should definitely be an implementation detail (it can
be standardized, but not necessarily with an identity information
standard). Clients should just use ldap binds and let the LDAP server
handle internally how authentication is handled (may not be a password
at all).

> > gecos:  Removed in DBIS with no explicit replacement.  DBIS
> > recommends using its mapping capabilities
> > to map gecos onto some other attribute, e.g. displayName.  While
> > eliminating gecos seems desirable
> > (as an unnecessarily UNIX-specific attribute), it seems desirable
> > to explicitly specify a replacement
> > rather than to rely on custom mapping.  (Note also that some
> > implementations have encoded
> > additional information, e.g. telephone number, into the gecos
> > field.  This seems like an undesirable
> > overloading of the schema.)
> 
> LDAP is so much better at representing all kinds of random
> information than NIS was, and the passwd
> flat-text file.  Just because there was a random "throw in any
> information you like" including an
> implied encouragement in Sun Microsystems' training courses to
> include telephone information
> in the gecos field, does not mean that when you move to a much more
> structured system such
> as LDAP you have to keep the general purpose nonsense.  If you want
> to encode a telephone number, 
> there is an attribute for that.  If you want a surname, or a first
> name, there are attributes for that
> too.  "Gecos" is not a unique piece of information, it is a container
> for an assortment of data, which
> will differ from one firm to the next.  The equivalent to "gecos" is
> an LDAP object.

I tend to agree with this sentiment.

> > 
> > description:  Removed from explicit mention in DBIS, but inherited
> > from Person if inetOrgPerson is
> > used as the base class.  Not clear how it fits into the UNIX/NIS
> > schema.
> 
> I removed it because I saw no purpose for it on a passwd entry, and
> as you say you can get it
> back again if you include another auxiliary class which you probably
> want to do
> anyway to have something to map gecos to.
> 
> > 
> > Structural User Account:  changes from "account" (RFC 4524) to
> > "inetOrgPerson" 
> > (RFC 2798).  While this is an obvious simplification, it does not
> > seem correct.  
> > An account may be associated with more than one person, and one
> > person may be associated with
> > more than one account.  (However, associating it with "account" 
> > leaves it unclear where to collect a gecos/display name, except
> > perhaps
> > "description".)
> 
> Quite, "account" doesn't have a field where you can sensibly put the
> descriptive
> name of the user, whereas inetOrgPerson does.  In a previous project
> where we
> were migrating NIS to AD, we used displayName to hold the contents of
> the
> gecos field, and that is what swayed my choice of inetOrgPerson here.
> 
> > 
> > posixGroup / posixGroupAccount
> > 
> > X.521 groupOfNames seems like a more appropriate basis for the
> > definition of a group.
> 
> But that doesn't allow for GID number.
> 
> > 
> > en:  See above.
> 
> Reply above.
> 
> > 
> > exactUser:  Ties into the case-sensitivity question.  If case
> > -insensitive, "memberUid" is reasonably
> > appropriate, because in the LDAP world "uid" means "login name".
> 
> "uid" meaning "login name" is a really bad choice.  I've always
> thought that, and I've pushed to get
> away from it in DBIS.  UID is a number, it should always be a number,
> why anyone thought it would
> be a good idea for that to actually be a name escapes me.  I've
> discussed the case sensitivity
> issue already, and I called this "exactUser" to follow-on from the
> idea of exact case, and to
> follow a similar line as "exactName" (en).
> 
> > 
> > manager:  although not inappropriate, X.520 "owner" seems more
> > appropriate.  (And note that
> > groupOfNames includes "owner".)
> 
> As "manager" was already in RFC2307/2307bis for host and network
> entries, I just expanded
> the support to many other entries, as it seemed a sensible thing to
> do.  Having some entries
> use "owner" and some use "manager" would be wrong, removing "manager"
> from
> host and network entries would add an unnecessary step when migrating
> from an RFC2307
> to a DBIS schema, and allowing both "owner" and "manager" seems
> excessive.

Actually owner and manager are quite different concepts, and allowing
both would not be bad idea.

> > 
> > nisNetgroup / netgroupObject
> > 
> > Although not a perfect match, groupOfNames seems like it might be a
> > better basis for
> > grouping computers.
> 
> netgroups are a specific construct, trying to squeeze them into
> something else that is
> not a perfect match would be a suboptimal decision.  LDAP can
> represent netgroup
> data better, so let's represent it better.

Netgroups are an abomination that should die. People should migrate off
of them, and we should not encode that abomination into a new standard
in 2015. This is one of the things that have me opposed to DBIS as a
standard, leave netgroups to RFC2307 and let them die there.

> > 
> > All of the changes here seem to relate to issues described above.
> > 
> > ipService / ipServiceObject
> > ipProtocol / ipProtocolObject
> > 
> > The changes here all appear to be similar to those described above,
> > with the note that case
> > sensitivity here seems especially pointless.
> 
> Not at all pointless given that we have real world examples of
> service names,
> one in uppercase, one in lowercase, which have two different port
> numbers assigned.
> If DBIS did not have an answer to that, we'd be back to using a
> custom schema,
> which defeats the object of the exercise.  NIS was case sensitive,
> DBIS aims to be
> 100% compatible with the NIS schema, as previously discussed.

NIS is dead Jim, dead! :-)

New standards should define stuff useful for the future, not backward
looking stuff that encodes and encroach mistakes done in the past.

For people that needs backwards compat with NIS what you should do is
simply define a generic NIS MAP object, and let individual sites store
what they want on these "maps" including crusty old concepts that
nobody should uses any more like the services and rpc maps.

> > oncRpc / rpcObject
> > 
> > ONC RPC is only one kind of RPC, so leaving "ONC" in its name seems
> > appropriate.
> 
> RFC5531 is titled "RPC" not "ONC RPC", and there is no other type of
> RPC defined in an
> RFC as far as I am aware.  To me it was obvious what RPC referred to.
>   I needed a new
> class anyway, and calling it oncRpcObject seemed unnecessary when
> rpcObject was
> clear enough.
> 
> > 
> > Again, the changes here all appear similar to those above.
> > 
> > ipHost / ipHostObject
> > 
> > This schema doesn't seem to allow for a host that has both IPv4 and
> > IPv6 addresses, nor for one
> > that has no addresses.
> 
> Mixing IPv4 and IPv6 should just be a case of assigning both the
> ipv4HostObject and ipv6HostObject
> classes to the same entry.  A host with no IP address, if we need to
> support that, I suggest
> we change ipHostObject to be STRUCTURAL rather than ABSTRACT.
> 
> > 
> > While I could see using an LDAP directory as the back end for a DNS
> > server, I could not see using
> > it as the client's primary source for address<->name mapping.  
> > In fact, ripping that capability out of our LDAP support is on my
> > list of things to do - it adds essentially
> > zero value and occasionally causes problems.

Amen

> I agree, but DBIS must be backwards compatible.

For you it may be, but from a Standards body it is not necessarily the
case, if your "proposal" is also "unchangeable" then there is no
discussion to be had in this group, no discussion, means also no
standard though (IMHO). As standards in IETF come from at least rough
consensus and here I do not see much consensus nor a willingness to
accept other points of view.

Simo.

> > 
> > ipNetwork/ipNetworkObject
> > 
> > As above.
> > 
> > automountMap / AutomountMapObject
> > 
> > As above.
> > 
> > automount / automountEntry
> > 
> > If we're going to change definitions, we should ensure that the new
> > definition allows for SMB
> > references in addition to NFS references. That suggests a URL form.
> 
> I actually added automountMapType to the draft but didn't update the
> comparison table.
> This was so that we could also support amd-style entries.  I suppose
> that is where we
> could also state that entries were smb-style entries too, and provide
> different
> attributes that are SMB-friendly.
> 
> > 
> > Note that splitting automountInformation into automountLocation and
> > automountOption means
> > that you can't have multiple locations with different options.
> 
> You're right, but why would you do that?
> 
> > 
> > automountMulti
> > 
> > I don't yet understand what this class is for.
> 
> I've renamed this to automountMultiMount in the draft and didn't
> update the table.
> This is for Solaris-style multi-mount entries.  I think they're being
> referred to as
> hierarchical mounts now, but see some example entries here:
> 
> http://sourceforge.net/p/dbis/wiki/Map%20Entries/
> 
> Best regards,
> Mark.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> -----------
> 
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd
> -Frank Wall Street Reform and Consumer Protection Act. If you have
> received this communication in error, please destroy all electronic
> and paper copies; do not disclose, use or act upon the information;
> and notify the sender immediately. Mistransmission is not intended to
> waive confidentiality or privilege. Morgan Stanley reserves the
> right, to the extent permitted under applicable law, to monitor
> electronic communications. This message is subject to terms available
> at the following link: http://www.morganstanley.com/disclaimers. If
> you cannot access these links, please notify us by reply message and
> we will send the contents to you. By messaging with Morgan Stanley
> you consent to the foregoing.
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext