abartlet at samba.org
Wed Jun 18 09:57:15 GMT 2008
On Wed, 2008-06-18 at 12:38 +0300, Sergey Yanovich wrote:
> Andrew Bartlett wrote:
> > On Tue, 2008-06-17 at 18:10 +0200, Oliver Liebel wrote:
> >>>> 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/
> > Indeed, and this is how the LDAP backend works now (over LDAPI). You
> > could also have it listen on an IP alias.
> That was my first idea. ldapi socket is a file and only available
> locally, right? But that's a minor issue, new port is a good workaround.
> Security is the major. When I provisioned Samba4 with OpenLDAP backed, I
> saw this in slapd.conf:
> access to * by * write
> which isn't acceptable for a stand-alone server.
Indeed. At some time in the future, I hope to change the binds Samba
uses from anonymous to using SASL external, over a ldapi socket, or
DIGEST-MD5 with a shared secret. We can then be granted and enforce
access in the same way Samba3 does (ie all directory operations as a
> 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).
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
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.
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
> 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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080618/9eb33902/attachment.bin
More information about the samba-technical