Re: Heimdal/OpenLDAP/Samba howto and bugreport

[Tarjei Huse <tarjei@nu.no>]

On Mon, 2004-05-31 at 14:32, Love wrote:
> Tarjei Huse <tarjei@nu.no> writes:
> 
> > I think a good principle for getting this to work is that all
> > configuration options should have sensible defaults.
> 
> Yes, the goal should be to have no configuration, but this is not
> realistic, as a ad client though, windows gets quite close.
True, all you have to do is add the machine to the domain and log in.
Nice.

> > Q.2: Are there any good reasons for having to add a sambauser via the
> > KDC-code? Isn't this done easier and better via other channels?
> I guess there isn't a good reason to add samba-users from heimdal, so
> "samba add base" can go.

> I've been toying with the idea of having an LDAP admin interface. I've been
> looking on windows ad and what problems you get when writing a client. Some
> of the problems are are policy where principals are going to be created.
> So you really might want to have several places where principals gets added
> in the tree, so you can delegate responsiblity of the tree/principal
> namespace to other administators.
> lha/admin@SU.SE can create host/hummel.it.su.se@SU.SE that ends up in
>   ou=hummel.it.su.se,dc=computers,dc=it,dc=su,dc=se. etc
> lha/admin@SU.SE can create user principal <userid> that ends up in
>   uid=<userid>,dc=it,dc=su,dc=se.

As long as all this is in OpenLDAP this could be done by openldap ACLs
and/or ACIs (runtime configurable accesscontrolls).

As such it would be better IMHO to write a good client than place too
much work on the serverside.

> This all quickly get very complicated, and I'm not sure its worth writing a
> configuration language for it, but rather just add hooks to exteral
> programs/shared objects to return the policy.

> Also there is the problem with clients modifying the LDAP tree directly,
> like in windows, there needs to be a way for the client to figure out where
> the users can create principal so it has a decent chance of doing the right
> thing, first problem I can think of is what DN should the client use when
> creating a entry ?

Client connects with kerberos auth, and adds an entry via ldap, then
sets password via ldap_extended_op or via kerberos. 


> >> structural object name
> > IMHO, this should be like today: use account as base and do not bother
> > much with modifying it. Let the sambacode search for sambaSAMAccount
> > instead of the account objectclass.
> But its not for searching, its for creating new entries.
> But you are right, the samba compat code should need to care about the
> structural object that is used.

> >> search base
> > Yes this should be the most important configuration attribute IMHO. 
> Yes, but isn't this implicit by the base attribute today (in the
> [kdc]database = { dbname = ldap:search-base } attribute.
I think this is a good way. As long as there is a way to separate out
where heimdal should add it's entries so that isn't the base.

> >> search filter, with two parameters, long principal name and optional short
> >>    search filter is both samba and heimdal search filters
> >> All these should be configurable per ldap database (not for the whole
> >> backend).
> > I'm not sure what you're going after here, but I'm thinking that the
> > databasedefinition could be something like this:
> Its more of a configurable search string. How can the ldap backend code be
> sure that there is a mapping between uid=<U> and <U>@REALM ? It does that
> assumption today. If the user is allowed to configure the search filter,
> this can at least be configured around.
> 	ldap-search-filter = (|(&(objectclass=krb5Principal)(krb5PrincipalName=$pricipal))(&(objectclass=sambaSamAccount)(uid=$userid)))
> But I'm not sure how do do this, and if this sensable defaults.
IMHO it looks ok. I've been thinking that we should have just a comma
separated list of what to search for, but we may just as well have the
user construct the filter for us (and this filter looks ok). 

The best way might be if we automaticly add the last part if use-samba =
yes, and that we thus have two filteroptions, one for samba and one for
heimdal. If someone comes up with a third filter they want to add later
this will not break anything.

But for me one ldap-search-filter option is just as good if the
suggested filter is the one suggested above.

What about a default base for adding heimdalentries that is != the
searchbase?

Tarjei



> 
> Love