Generating krb5.keytab

[Oliver Liebel]

Andrew Bartlett schrieb:
> 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.
>>     
>
>   
you should have read the comments in the slapd.conf of earlier 
samba4-versions  - as this is not a final release of samba,
andrew and the others first had to try to get this whole thing working, 
with the goal to use a standard
ldap server as a backend which can be used for other services too. as 
andrew mentioned below, there -are-
solutions to get more granulated ACLs implemented, but this is surely 
not the primary target at the moment.
> 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.
>   
i agree with andrew. i dont see where this should lead to, since 
back-sql for openldap is the
last thing to mention about in the moment, as it is still experimental, 
slow and you bring a
new part into the whole construct, which will surely not stabilize it: 
an rdbms.
and at this stage it is surely no good idea to -extend- the existing 
samba4 schema with some "helpful" things
fur users. the main goal is to get samba4/ol work and replicate stable .

> Andrew Bartlett
>
>