[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Intergrate Heimdal's hdb-ldap and Samba




Andrew Bartlett <abartlet@samba.org> writes:

> On Mon, 2004-03-08 at 03:33, Love wrote:

>> But its not what the old code does, and I guess it might break for old
>> installations.
>
> Existing entries are not touched.  So it's probably more compatible than
> that the hdb changes :-)

Right, but the local "create/modify user script" at the site might get
confused. As I said before, I'll make it a runtime option (defaulting to
account).

> I think heimdal might need to move towards what Samba does, and have an
> 'add user script', if you really expect that the first entry in the LDAP
> directory for a user, will be the heimdal entry. 

What's wrong with "kadmin add user" now ? Is there anything else someone
want to add when creating a user ?

> In the real world, I would have expected that if a site is going to the
> pain of setting up LDAP (and it is a pain, no matter what we can do)
> that the entries for the accounts would probably already exist (for
> nss_ldap, for all the reasons that they wanted their data in a single
> place to start with).  As such, the 'account' stuff does not come into
> play, as the entry already exists.
>
> For those things that are new, I think 'account' (or another suitable
> compatible structural objectClass) is appropriate.  'person' to my mind
> is not.

I take your word for it. But I would feel much better if some other ldap
literate person spoke up and said what you said was right.

>> > For x.509 certificates, there is a objectClass
>> > (strongAuthenticationUser) and an attribute (userCertificate) for it
>> > already.
>> 
>> I was thinking more something like microsoft's
>> altSecurity(Identity|Principal) (?).

This is not really related to samba but... 

> So you don't want to store the certificate, just it's 'name' for later
> matching?

The entry look something like this, X509:<I>CN=Issuer<S>CN=Subject, so yes,
its both names (issuer, subject).

> I can't spot an existing standard way, but we should be sure
> of that before duplicating something.

I want to store the certificate as an alternative to altSecurityMumble
because for certain certificate you might not want to trust the CA, but the
smartcard with the certificate is just fine.

I could use the userCertificate, but should I really use that for acccess
control checks ?

So there are four ways I want to do check if the certificate is allowed to
use this principal.

match subject + issuer
match whole certificate
match SubjectAltName
match some site specific function mapping cert to principal via plugin

Love

PGP signature