Andrew Bartlett schrieb:
you should have read the comments in the slapd.conf of earlier
samba4-versions - as this is not a final release of samba,
andrew and the others first had to try to get this whole thing working,
with the goal to use a standard
ldap server as a backend which can be used for other services too. as
andrew mentioned below, there -are-
solutions to get more granulated ACLs implemented, but this is surely
not the primary target at the moment.
On Wed, 2008-06-18 at 12:38 +0300, Sergey Yanovich wrote:
Andrew Bartlett wrote:
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:
On Tue, 2008-06-17 at 18:10 +0200, Oliver Liebel wrote:
you can connect directly via -h ldapi://<path to socket> or just use
another port, e.g.: -h ldap://<ip/fqhn>:9000/
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.
I'm still confused by how your KDC ideas fit into this (if you simply
Indeed, and this is how the LDAP backend works now (over LDAPI). You
could also have it listen on an IP alias.
access to * by * write
which isn't acceptable for a stand-alone server.
i agree with andrew. i dont see where this should lead to, since
back-sql for openldap is the
last thing to mention about in the moment, as it is still experimental,
slow and you bring a
new part into the whole construct, which will surely not stabilize it:
and at this stage it is surely no good idea to -extend- the existing
samba4 schema with some "helpful" things
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.
fur users. the main goal is to get samba4/ol work and replicate stable .