Generating krb5.keytab

[Andrew Bartlett]

On Wed, 2008-06-18 at 12:38 +0300, Sergey Yanovich wrote:
> Andrew Bartlett wrote:
> > On Tue, 2008-06-17 at 18:10 +0200, Oliver Liebel wrote:
> > 
> >>>> I'm still confused by how your KDC ideas fit into this (if you simply
> >>> mysql-backend of OpenLDAP allows to store/fetch LDAP data to/from 
> >>> MySQL database. It allows arbitrary database schema, and uses a 
> >>> mapping to link LDAP schema field with database tables. It isn't 
> >>> working with dynamic schema changes, but should be just fine for a 
> >>> static schema, that Samba4 uses. I am going to extend Samba4 schema 
> >>> with additional data that may come handy to the users. To actually 
> >>> achieve that, I need to be able to connect to the OpenLDAP directly, 
> >>> which is currently not working with Samba4, because the OpenLDAP acts 
> >>> as backend to Samba4, and Samba occupies LDAP designated ports.
> >> you can connect directly via -h ldapi://<path to socket>  or just use 
> >> another port, e.g.: -h ldap://<ip/fqhn>:9000/
> > 
> > Indeed, and this is how the LDAP backend works now (over LDAPI).  You
> > could also have it listen on an IP alias. 
> 
> That was my first idea. ldapi socket is a file and only available 
> locally, right? But that's a minor issue, new port is a good workaround. 
> Security is the major. When I provisioned Samba4 with OpenLDAP backed, I 
> saw this in slapd.conf:
> 
> access to * by * write
> 
> which isn't acceptable for a stand-alone server.

Indeed.  At some time in the future, I hope to change the binds Samba
uses from anonymous to using SASL external, over a ldapi socket, or
DIGEST-MD5 with a shared secret.  We can then be granted and enforce
access in the same way Samba3 does (ie all directory operations as a
privileged user). 

> Real access control is done by Samba4, and this needs to change to allow 
> direct access to the LDAP backend as a server. In this case, the backend 
> ceases to be a backend as such. Server-backend paradigm is replaced by 
> client-server paradigm (like in Samba3).

If you want windows clients to talk to what they think is AD, then the
LDAP server must be Samba4.  The client-server paradigm is there for a
reason. 

It would be a very bad idea (ie, it would break) for clients to talk
directly to a non Samba4 LDAP server, while thinking they are part of a
Samba4 AD domain.  

However, if you wished the LDAP backend to enforce access as the actual
user, I would be happy to see patches to implement LDAP or SASL proxy
authorization. 

> In turn, that this cannot be achieved without reorganizing Kerberos 
> handling inside Samba. At the same time, this isn't about adding new 
> features, just refactoring, and since Samba has a great test suit, it 
> can be done in a controlled and predictable manner.

You make good points, and seem to be getting to grip with how Samba4's
LDAP backend arrangements are managed, but I still fail to see what this
has to do with Kerberos.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080618/9eb33902/attachment.bin