Re: Heimdal/OpenLDAP/Samba howto and bugreport

[Love <lha@stacken.kth.se>]

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.

>> There are several possible ways to configure this, I think the things that
>> needs to able to be tweeked are:
>> heimdal add base
>> samba add base
> Q: How should the kdc know when it's supposed to add a sambauser and a
> heimdaluser?
>
> 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.

etc.

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 ?

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

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

Love

PGP signature