LDAP PDB and IDMAP design and implemenation

[Ronny Bremer]

>In particular, it seems rather limited in what it can do - we seem
>unable to modify an existing mapping, and we do not pay correct
>attention to existing entries in LDAP when we do!

We also need to think about people with an already deployed LDAP
directory to add Samba to it. In that case, UID's might already exist,
as they are used for Linux/Unix access of those DN's, so the required
posixAccount attributes are filled.

>  - All new user entries are added under the 'ldap user suffix'
>  - All new machines entires are added under the 'ldap machine
suffix'
>  and so for groups, idmap and machines.

Maybe we should also provide a way to restrict Samba from adding to the
LDAP store. Some LDAP administrators are worried about adding account
through Samba, as there is no way to place them correctly into the LDAP
tree. They can, of course, move the user afterwards, but in many cases
they like to control who goes where in the first place.

>  - Allow modification of idmap entires

I need to do more research here.

>  - Wherever possible, annotate existing DNs when adding idmap
entires,
>rather than adding new entries under the 'idmap suffix'.

This seems to conflict with your suggestion of using the Domain SID as
the CN (see below).
Usually, users are created in LDAP with their "login id" as the cn, so
it gets mapped to "uid" for Unix/Linux login purposes. There are
differences, however. Many ADS administrator use the Full user Name as
the CN, so it shows up in their User/Group Management tool in a more
descriptve way.

If you wanna modify existing entries (which I would strongly suggest,
in order to remove redundancy and also to be compliant with existing
LDAP tree designs) we should not count on being able to use the SID as a
CN.

>    - This should means that if the user has a unix account, we put
the
>sambaSid on that entry, rather than a new DN.  Things should then
work
>quite well if the user gets a sambaSamAccount on that DN later.
>    - Likewise for a sambaSamAccount without a UID yet - it should
have
>the uid stored on the same DN, for ease of tracking - this will mean
>that with the easily scripted addition of required unix attributes,
the
>entry will be ready for use with nss_ldap (I expect this to be a
common
>configuration).

Agreed.

>Finally, (and more controversially) I would suggest that we change
the
>way the idmap entires are store in LDAP to use the DOMAIN SID as the
DN
>component, not the unix userid.
>
>Generally in idmap, it is the Domain SID that is the descriptive
aspect
>of the entry, and there is a proposal to have such a domain sid map
to
>both a unix UID and a unix GID.  Even if this is never taken up, it
>would seem to be better to allow for this change now, rather than
>figuring it out later.
>
>This would make the DN:
>
>sambaSID=S-1-5-21-4117985702-3860941512-23890400-512,ou=idmap,dc=bartlett,dc=house.

See note above.

Just my 2 cents.

Ronny