|
|
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@xxxxxxxxx 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
|
|