oliver at itc.li
Tue Jun 17 16:10:08 GMT 2008
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
>>>>> 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
>>>> 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
>>> 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
> 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
>>>> 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
More information about the samba-technical