oliver at itc.li
Wed Jun 18 10:32:05 GMT 2008
Andrew Bartlett schrieb:
> 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.
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.
> 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
> privileged user).
>> 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.
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
fur users. the main goal is to get samba4/ol work and replicate stable .
> Andrew Bartlett
More information about the samba-technical