Re: [ldapext] DBIS commentary

[Jordan Brown <[e-mail]>]

On 11/26/2015 3:01 AM, Bannister, Mark wrote:
>> 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

He does seem to have a pretty strict stance on the matter.  Still, the X.519 
reference that Steven supplied suggests that there may be wiggle room there.  I 
don't know whether it's enough wiggle room to be helpful here, but it seems worth 
keeping in mind.


On the case-sensitivity front:  we have a pretty fundamental disagreement.  I 
believe that UNIX names must eventually become case-insensitive, that it is only a 
matter of time until they do. UNIX is not the whole world, and the entire rest of 
the world is clear that MARK, Mark, and mark are the same person.  I've got to 
believe that even in the UNIX world those differ-only-in-case instances are 
steadily on the decline - anybody who is coexisting with Windows or has adopted 
RFC 2307 is using case-insensitive names and it seems unlikely that anybody would 
create new instances of problematic names.  Even a purely UNIX environment isn't 
purely case-insensitive - sendmail treats user names as case-insensitive for at 
least some purposes.

Transition is indeed painful.  RFC 4876 profiles and in particular the 
attributeMap mechanism can assist; you can use an attributeMap entry to direct the 
clients to use an alternative, case-sensitive, attribute for the user name if that 
is what you need.

>> 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 recommend looking pretty hard at whether a new attribute is needed, given that 
there seem to be three other existing attributes.

In general, it seems best to discourage making password hashes visible - perhaps 
even to the point of not standardizing them.

>> 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.

Sorry, my side note ended up dominating the conversation.  I agree that 
overloading information into the gecos field is undesirable and that LDAP 
attributes should be used.

My key point here is that DBIS should specify what attribute should replace it, 
what attribute clients are expected to use to populate the pw_gecos field in 
struct passwd.

>> 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.

It seems like the right answer there would be a subclass of "account" with a "MAY 
displayName", to preserve the database normalization that lets you have accounts 
that are associated with more than one person (or with no person at all) and 
people who are associated with more than one account.

(But I see that inetOrgPerson includes "uid", suggesting that it was also intended 
to represent a computer account.)

>> 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.

A subclass does.

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

Again, UNIX is not the entire world.  RFC 2307 is not the primary reference for 
"uid" - RFC 2798 (inetOrgPerson) is, adopted and renamed from RFC 1274 "userid".  
(I presume that the earlier publication in RFC 2307 is an accident of the 
development timelines of the two documents.)

Yes, it's confusing for UNIX people, but it's the standard.


>> 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.

No strong opinion.


>> 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.

Yes, it can... and for most purposes it has, in the form of groupOfNames.  If you 
have users represented in the directory, the natural way to group them is with 
groupOfNames.  If you have hosts represented in the directory, the natural way to 
group them is with groupOfNames.  The only thing that there isn't an obvious way 
to group is "user X on host Y".  Not that I've seen a lot of concrete instances of 
netgroups, but I don't think I've seen one of those yet.

I believe Active Directory makes extensive use of groups of computers; 
interoperating seems desirable.

>> 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.

Having two names that differ only in case lead to different port numbers seems 
like a spectacularly bad idea.  If there's an organization that has somehow found 
themselves in such a mess then I'm very sorry for them, but the real answer is 
that they need to extricate themselves from the mess rather than spreading it.

IANA is the reference for service names, and RFC 6335 says that they are 
case-insensitive.


>> 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.

Although the title of RFC 5531 is "RPC: ...", the opening sentence says "This 
document specifies version 2 of the message protocol used in ONC Remote Procedure 
Call (RPC).".

XML-RPC seems to have somehow dodged getting an RFC, but is referenced by RFC 3529.
JSON-RPC seems to have at least something of a footprint, but no RFC.


>
>> 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.

You have ipv4HostObject and ipv6HostObject defined as structural classes, and a 
given object can have only one structural class.

> A host with no IP address, if we need to support that, I suggest
> we change ipHostObject to be STRUCTURAL rather than ABSTRACT.

Yes.

We should also look at prior art.  Active Directory defines schemas for 
representing computers; it would seem remiss to not attempt to interoperate.

Again, that's if we need to include a "hosts" replacement at all.

(One reason to include one:  groups of hosts.)

>> 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.
> I agree, but DBIS must be backwards compatible.

When we're creating entirely new schema, backwards compatibility is not an 
absolute constraint.  Discarding evolutionary dead ends has substantial value.

>> 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?

I blindly assumed that the existing schema made sense :-)

Indeed, the underlying file-based automount schema doesn't seem to allow different 
locations to have different options.