Generating krb5.keytab

[Oliver Liebel]

Sergey Yanovich schrieb:
> 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.
you can connect directly via -h ldapi://<path to socket>  or just use 
another port, e.g.: -h ldap://<ip/fqhn>:9000/

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

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.4165 from 17.06.2008
Virus news: www.antiviruslab.com