Generating krb5.keytab

[Sergey Yanovich]

I apologize for failing to include the list into the cc field (I've 
probably pressed 'Reply' instead of 'Reply All'. As a result we've 
exchanged several private messages with Andrew, which should have been 
public. To partially fix that I am quoting last Andrew's message in full 
here. I can also resend all other, if it is OK,

Andrew Bartlett wrote:
> On Tue, 2008-06-17 at 11:36 +0300, Sergey Yanovich wrote:
>> Andrew Bartlett wrote:
>>> On Sat, 2008-06-14 at 16:04 +0300, Sergey Yanovich wrote:
>>>> I won't say so. IIUC, the current way to set/change password, is to 
>>>> supply an LDAP query, which will ask Kerberos to generate/update key, 
>>>> and will save the key to the LDAP. 
>>> The only 'ask Kerberos to' thing we do is call the kerberos string2key
>>> functions, then lay the keys out in the Microsoft format in the
>>> directory.  This is the password_hash LDB module.
>> I mean exactly this. LDAP controls the password setting/changing 
>> process, but the control may be transfered to the KDC.
> 
> No problem is computer science cannot be solved with another layer of
> abstraction.
> 
>>>> Quite different approach is to tell 
>>>> kadmind to do the key task, and have the kadmind store the key where it 
>>>> sees fit (including the same LDAP). IIUC (again), w32 boxes negotiate 
>>>> password change using DEC/RPC, so it is not completely necessary to use 
>>>> LDAP for this.
>>> See the (unused) password_sync ldb module if this is your desire.  LDB
>>> can then call anything you want.  However it won't help, as then you
>>> must also mirror all other changes (such as renames,
>>> servicePrincipalNames, userPrincipalNames etc) into your kerberos
>>> database. 
>> All that is explicitly named in brackets clearly belongs to Kerberos, so 
>> it would be quite natural to handle that info in kadmind, but not in the 
>> ldb. That is my main proposal.
> 
> But what would it achieve?  The KDC would still have to obey AD
> canonacolisation rules, and generate a PAC.  It can never be 'stock' or
> independent.

Canonicalization and PAC will become features of KDC, so ldb can be 
replaced with stock LDAP server.

>>> Finally, we want to be able to replicate the password outbound to a
>>> Microsoft server, so we decide to keep things simple, and just have the
>>> KDC read the same database as everyone else. 
>> If MS server requires that password is stored together with the key and 
>> user info in LDAP, then using the single database is a must. 
> 
> You could separate their storage, but they are replicated just like all
> other attributes.

For my goal, it isn't so much important what happens with the data after 
  it is written. The main focus is who writes it.

>> But it 
>> doesn't necessarily mean, that password must be stored by LDAP query.
>>
>> If w32 clients negotiate password change using DEC/RPC, smbd may invoke 
>> kadmin function instead of LDAP queries to do the job. This approach 
>> will also allow to use stock kadmin tools on the kadmind, which with the 
>> help of samba plug-in(s) will correctly stored everything in the LDAP. 
>> In this case LDAP may also be completely external. That is what I'm 
>> trying to achieve.
> 
> I don't quite see how this helps.  Using kadmin to modify an LDAP server
> that must by definition already contain all the other LDAP data?

Absolutely. All other data isn't critical. And it is possible to 
configure LDAP to only allow kadmin/admin at REALM.NET or an equivalent to 
access this fields.

>> I would like samba to use OpenLDAP externally, because I contemplate to 
>> provide LDAP export from my accounting database using mysql backend of 
>> OpenLDAP. If I also manage to provide data entry in LDAP form, the whole 
>> system will work as FOSS cross-platfom ERP+CRP+BI solution integrated 
>> with system user management facilities. Samba ability to use LDAP and 
>> KDC externally is crucial to achieve cross-platform integration with 
>> system user management.
> 
> 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.

Right now Samba4 cannot act as a LDAP client (like Samba3), because it 
is handling Kerberos administration using LDAP queries internally. And 
this type of solution is caused by lack of PAC/canonicalization support 
in stock KDCs.

So the first step is to teach KDC to do all this tasks, then to teach 
Samba4 to use external LDAP server as a client with Kerberos auth and 
encryption (ssl?).

> don't want to try and send the passwords back into the MySQL DB, then
> use the local_password ldb module, which avoids all the other problems,
> because it works across renames etc), but I offer you two things:  
> 
> Please bring this discussion back onto the public mailing lists and

Sure. My fault.

> please come back with patches.  I've pointed you at a number of
> different modules and hooks that I've already built to support this kind
> of thing, so demonstrating this should not be too hard. 

I am not close to have enough knowledge about Samba4 internals, yet, to 
begin patching it, ldb and Heimdal kadmin. And Samba3 netlogon patch 
taught me to ask before I begin doing anything this big :-)

So I am trying to figure out whether (1) my idea is doable, (2) the 
project needs it. I also understand that the time is scarce for 
everyone, not insist that my questions are answered and really 
appreciate all the answers.

Thanks for your time, Andrew. Cheers,

-- 
Sergey Yanovich