Generating krb5.keytab

[Sergey Yanovich]

Andrew Bartlett wrote:
>> 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).

Start quote (1) ==

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

End quote (1) ==

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

Isn't (1) the answer here?

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

It is a decent chuck of work, but I am working on locating resources for 
it (and even the bigger change). It's no big secret that it's hard to 
find a properly licensed MS server in Russia, which is a criminal 
offense at the same time, and many would be happy to say goodbye to this 
lock-in.

-- 
Sergey Yanovich