Generating krb5.keytab

[Sergey Yanovich]

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.

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

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.

-- 
Sergey Yanovich