Re: DBIS - new IETF drafts

Hi,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAABCAAGBQJSzH7SAAoJECqLdGgQ4K/BVywQAJIwmjKYCe9kap4b/BN2x5SK
NepmmEKKWx6faPqBJSBD9cFs02Zlk3S8cvDrBlF3j9tNFz3whWcinzs3xetGbLiK
T3OUrDMILTgiH4BqQZwsmpOXzU5YK2Brwknnsn2HkHEv/TOpFgI4e2Hw2k8dqRq3
5tf0HDQj9ZxpAjCNbf20RUeyZuZ3I81jFK59yqhwB1PphOf2ciEToYAHPESVr7fo
ou0aY00VyoSfAubAS4FNI2Ua+hKebaDWkFuolQgMdE0YEoRo5btIPhDRB5ZUJdFW
Wh1jbv9zH1NKm2mGc8RyHAyZXVjWV3dF8Bmhg7SbjKicCXkFjZ6PghQ5Mbk5/tWA
o1yHJbWg7NBAd5eJtChIBy+1rvX7n9lOzfCA+PBGm4pHxh/96yreNQnZ65YXKB4D
oe6AXt+CZGCrRnR+8CPHQ0a3TfUCrLPHaMM+CCetLAJWt10llCD2CZFM1G2xY5b3
CYbeUGbj3eKfBCfooNkJErcXkW6sEFSKlHUtEnrWGul/oTvkUkfq1fASRvZsc5K/
7IOtQTHCxKngHg1r7WEU3eHzLJKrh3P6UsnDtAnEwPhN4obu0jSIAQbxlPNlXgGd
WlbKoOB0tXnAQQqiKA1TJBMCzEVVYb14VcySkpiiROHwFWUHnWVf5fKo+h3GIVWD
wYlfAFL0aSaevXPSNhT6
=UlxK
-----END PGP SIGNATURE-----