Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OpenLDAP and Samba4
3 views
Skip to first unread message
Howard Chu
Apr 17, 2013, 5:58:29 PM4/17/13
to
Hey there list, Andrew... I keep meaning to have this discussion with Andrew
and then it always slips by, but this time for sure.
I'll keep this short - my colleagues at Symas want to know what it will take
to bring OpenLDAP up to date to be usable directly by Samba as a first-class
recommended option, not just "yeah that should work but..." I've reviewed some
of the previous discussions on this topic in the archives, but I suspect some
of those points are now out of date.
I recall that we need to implement LDAP Transaction support, but of course
that's just one of many missing features. Also, are there developers on the
Samba team who can spend some time with us to make sure that what we write
actually fits with how Samba uses things?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
and then it always slips by, but this time for sure.
I'll keep this short - my colleagues at Symas want to know what it will take
to bring OpenLDAP up to date to be usable directly by Samba as a first-class
recommended option, not just "yeah that should work but..." I've reviewed some
of the previous discussions on this topic in the archives, but I suspect some
of those points are now out of date.
I recall that we need to implement LDAP Transaction support, but of course
that's just one of many missing features. Also, are there developers on the
Samba team who can spend some time with us to make sure that what we write
actually fits with how Samba uses things?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Martin Simons
Apr 17, 2013, 6:29:10 PM4/17/13
to
Dear Howard,
> Hey there list, Andrew... I keep meaning to have this discussion with
> Andrew and then it always slips by, but this time for sure.
Thank you for reraising the issue, because the ldap compliancy of Samba4
has never stopped worrying me.
Andrew gave me a very polite answer to my post 2013-02-12 at 12:06 +0100:
Thanks for taking the time to write. We know that this area is of great
concern to administrators, and it is also a great concern to members of
the Samba team.
> I'll keep this short - my colleagues at Symas want to know what it will
> take to bring OpenLDAP up to date to be usable directly by Samba as a
> first-class recommended option, not just "yeah that should work but..."
> I've reviewed some of the previous discussions on this topic in the
> archives, but I suspect some of those points are now out of date.
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
Still, like you, I am left with the same feeling that AD compliance
comes first and LDAP compliance is in the balance and depends on
additional funding.
I advocate LDAP compliance in the first place and an additional and
optional AD compliance sponsored by those who feel they should do so. I
do not get the point of sacrificing Open Standards compliance in favor
of a company owned standard for a platform that clearly is loosing more
ground by the day.
This is my original post:
Dear All,
Jeremy Allison had an excellent presentation of Samba4 at Fosdem yesterday.
After his talk I spoke briefly to him about the interoperability between
Samba4 and LDAP, because this seems to exist no longer. The onliest
possibility left is dumping am LDAP database to an ldif file and then
upload it to the AD compatible Samba4 server.
The issue is towards the LDAP version that Samba4 is compatible with. As
we know LDAP now uses the Provider Consumer model instead of the Master
Slave model. Samba now operates on a Master Master principle, the
standard of which is not clear to me.
Samba4 would have a so called classic mode that would allow to use it as
a file server still in combination with a standardized LDAP server. This
feature however needs to be tested more thoroughly it seems, it is not
proven yet.
The need for a Samba server that interacts is obvious, since the LDAP
service is used by a abundant number of services that interact with it.
I name a couple of services I personally have experience with: Zarafa
mail server and SugarCRM.
I do not want to set the Samba house to fire, because it is very deer to
me, but I feel a strong interest in having Samba interoperate with the
standard LDAP service. I want to involve in order to guarantee this in
the long run.
I will be in Los Angeles as of February 22th in order to attend Scale11
and I am prepared to meet any of you people up to march 1st, in order to
see whatever contribution I should make.
Best regards,
Martin.
+31 6 5156 7029
> Hey there list, Andrew... I keep meaning to have this discussion with
> Andrew and then it always slips by, but this time for sure.
has never stopped worrying me.
Andrew gave me a very polite answer to my post 2013-02-12 at 12:06 +0100:
Thanks for taking the time to write. We know that this area is of great
concern to administrators, and it is also a great concern to members of
the Samba team.
> I'll keep this short - my colleagues at Symas want to know what it will
> take to bring OpenLDAP up to date to be usable directly by Samba as a
> first-class recommended option, not just "yeah that should work but..."
> I've reviewed some of the previous discussions on this topic in the
> archives, but I suspect some of those points are now out of date.
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
comes first and LDAP compliance is in the balance and depends on
additional funding.
I advocate LDAP compliance in the first place and an additional and
optional AD compliance sponsored by those who feel they should do so. I
do not get the point of sacrificing Open Standards compliance in favor
of a company owned standard for a platform that clearly is loosing more
ground by the day.
This is my original post:
Dear All,
Jeremy Allison had an excellent presentation of Samba4 at Fosdem yesterday.
After his talk I spoke briefly to him about the interoperability between
Samba4 and LDAP, because this seems to exist no longer. The onliest
possibility left is dumping am LDAP database to an ldif file and then
upload it to the AD compatible Samba4 server.
The issue is towards the LDAP version that Samba4 is compatible with. As
we know LDAP now uses the Provider Consumer model instead of the Master
Slave model. Samba now operates on a Master Master principle, the
standard of which is not clear to me.
Samba4 would have a so called classic mode that would allow to use it as
a file server still in combination with a standardized LDAP server. This
feature however needs to be tested more thoroughly it seems, it is not
proven yet.
The need for a Samba server that interacts is obvious, since the LDAP
service is used by a abundant number of services that interact with it.
I name a couple of services I personally have experience with: Zarafa
mail server and SugarCRM.
I do not want to set the Samba house to fire, because it is very deer to
me, but I feel a strong interest in having Samba interoperate with the
standard LDAP service. I want to involve in order to guarantee this in
the long run.
I will be in Los Angeles as of February 22th in order to attend Scale11
and I am prepared to meet any of you people up to march 1st, in order to
see whatever contribution I should make.
Best regards,
Martin.
+31 6 5156 7029
Jeremy Allison
Apr 17, 2013, 8:13:17 PM4/17/13
to
On Wed, Apr 17, 2013 at 02:58:29PM -0700, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion
> with Andrew and then it always slips by, but this time for sure.
>
> Hey there list, Andrew... I keep meaning to have this discussion
> with Andrew and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it
> will take to bring OpenLDAP up to date to be usable directly by
> Samba as a first-class recommended option, not just "yeah that
> should work but..." I've reviewed some of the previous discussions
> on this topic in the archives, but I suspect some of those points
> are now out of date.
>
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
Thanks for bringing this up Howard (disclaimer, I met Howard
> will take to bring OpenLDAP up to date to be usable directly by
> Samba as a first-class recommended option, not just "yeah that
> should work but..." I've reviewed some of the previous discussions
> on this topic in the archives, but I suspect some of those points
> are now out of date.
>
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
over lunch at the Linux Foundation Collaboration Summit and
asked him to raise this :-).
I'd love to get the OpenLDAP developers more engaged with
Samba Active Directory as now we have a working implementation
we can actually create a laundry list of issues we need to
address in order to integrate a full AD-DC with OpenLDAP.
Cheers,
Jeremy.
C.J. Adams-Collier KF7BMP
Apr 17, 2013, 10:35:25 PM4/17/13
to
have enough capacity in the hypervisor for another debian machine, an
interest in setting up a domain controller at ad0.colliertech.org, and
enough know-how to build from HEAD. or trunk. or master. or whatever
the cool kids call it these days.
I'm a big fan of all of your work and very much appreciate you putting
so much energy in to such an interesting problem.
Cheers,
C.J.
Matthieu Patou
Apr 19, 2013, 12:23:08 AM4/19/13
to
Hello Howard,
On 04/17/2013 02:58 PM, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion with
> Andrew and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it
> will take to bring OpenLDAP up to date to be usable directly by Samba
> as a first-class recommended option, not just "yeah that should work
> but..." I've reviewed some of the previous discussions on this topic
> in the archives, but I suspect some of those points are now out of date.
>
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
Andrew B. is off this week but we discussed this subject several time.
So 1st of all the biggest question is why do we want that ?
Due to AD constraints it means that when openldap is the backend for
Samba AD it has to be dedicated to Samba all access should be done
through Samba because any change made through DCERPC servers (Netlogon,
DRS, LSA, ...) must be seen immediately in the LDAP server and also the
other way around.
Also as there is huge constraints on how the partitions must be
organized and how the schema must be structured so you can also forget
(correct me if I'm wrong) the idea of upgrading an openldap installation
to give a Samba AD personality.
Second concern is the LDAP transaction so that we can honor LDB
transaction on this backend, this is required in order to support
correctly DRS replication (AD to AD replication).
Third concern is automated testing, currently every single commit the
samba repository yield a set of tests to reduce the risk of regression.
For the moment tests only use the latest and greatest version of LDAP
and our internal LDAP server. If Openldap is added as another backend we
need to understand how do we integrate this so that we always do some
tests against the Openldap backend. It might mean linking with our
socket_wrapper library.
For the moment I have nothing that comes to my memory but maybe some
other stuff will come back to my memory.
Matthieu.
On 04/17/2013 02:58 PM, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion with
> Andrew and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it
> will take to bring OpenLDAP up to date to be usable directly by Samba
> as a first-class recommended option, not just "yeah that should work
> but..." I've reviewed some of the previous discussions on this topic
> in the archives, but I suspect some of those points are now out of date.
>
> I recall that we need to implement LDAP Transaction support, but of
> course that's just one of many missing features. Also, are there
> developers on the Samba team who can spend some time with us to make
> sure that what we write actually fits with how Samba uses things?
So 1st of all the biggest question is why do we want that ?
Due to AD constraints it means that when openldap is the backend for
Samba AD it has to be dedicated to Samba all access should be done
through Samba because any change made through DCERPC servers (Netlogon,
DRS, LSA, ...) must be seen immediately in the LDAP server and also the
other way around.
Also as there is huge constraints on how the partitions must be
organized and how the schema must be structured so you can also forget
(correct me if I'm wrong) the idea of upgrading an openldap installation
to give a Samba AD personality.
Second concern is the LDAP transaction so that we can honor LDB
transaction on this backend, this is required in order to support
correctly DRS replication (AD to AD replication).
Third concern is automated testing, currently every single commit the
samba repository yield a set of tests to reduce the risk of regression.
For the moment tests only use the latest and greatest version of LDAP
and our internal LDAP server. If Openldap is added as another backend we
need to understand how do we integrate this so that we always do some
tests against the Openldap backend. It might mean linking with our
socket_wrapper library.
For the moment I have nothing that comes to my memory but maybe some
other stuff will come back to my memory.
Matthieu.
Jeremy Allison
Apr 19, 2013, 12:59:40 PM4/19/13
to
On Thu, Apr 18, 2013 at 09:23:08PM -0700, Matthieu Patou wrote:
>
> So 1st of all the biggest question is why do we want that ?
Resources. We don't have the resources to support an LDAP
>
> So 1st of all the biggest question is why do we want that ?
server long term. Howard, via OpenLDAP does. He
wants OpenLDAP to be *the* AD LDAP server, and is willing
to work with us in order to get the code changes we need
integrated. I'd like to take him up on that offer.
> Due to AD constraints it means that when openldap is the backend for
> Samba AD it has to be dedicated to Samba all access should be done
> through Samba because any change made through DCERPC servers
> (Netlogon, DRS, LSA, ...) must be seen immediately in the LDAP
> server and also the other way around.
the LDAP store, that's understood. Remember, Luke Howard
already did this for XAD.
> Also as there is huge constraints on how the partitions must be
> organized and how the schema must be structured so you can also
> forget (correct me if I'm wrong) the idea of upgrading an openldap
> installation to give a Samba AD personality.
> Second concern is the LDAP transaction so that we can honor LDB
> transaction on this backend, this is required in order to support
> correctly DRS replication (AD to AD replication).
> Third concern is automated testing, currently every single commit
> the samba repository yield a set of tests to reduce the risk of
> regression. For the moment tests only use the latest and greatest
> version of LDAP and our internal LDAP server. If Openldap is added
> as another backend we need to understand how do we integrate this so
> that we always do some tests against the Openldap backend. It might
> mean linking with our socket_wrapper library.
the cooperation of the OpenLDAP coders.
Jeremy.
Luke Howard
Apr 19, 2013, 1:16:14 PM4/19/13
to
On 19/04/2013, at 6:59 PM, Jeremy Allison <j...@samba.org> wrote:
>> Due to AD constraints it means that when openldap is the backend for
>> Samba AD it has to be dedicated to Samba all access should be done
>> through Samba because any change made through DCERPC servers
>> (Netlogon, DRS, LSA, ...) must be seen immediately in the LDAP
>> server and also the other way around.
>
> Sure - we would have to back-end DCERPC services onto
> the LDAP store, that's understood. Remember, Luke Howard
> already did this for XAD.
-- Luke
Matthieu Patou
Apr 19, 2013, 4:14:06 PM4/19/13
to
On 04/19/2013 09:59 AM, Jeremy Allison wrote:
> On Thu, Apr 18, 2013 at 09:23:08PM -0700, Matthieu Patou wrote:
>> So 1st of all the biggest question is why do we want that ?
> Resources. We don't have the resources to support an LDAP
> server long term.
Do you know what is our LDAP server ?
> On Thu, Apr 18, 2013 at 09:23:08PM -0700, Matthieu Patou wrote:
>> So 1st of all the biggest question is why do we want that ?
> Resources. We don't have the resources to support an LDAP
> server long term.
The LDAP server of samba is just a couple of files:
source4/ldap_server/ldap_server.h
source4/ldap_server/ldap_bind.c
source4/ldap_server/ldap_extended.c
source4/ldap_server/ldap_backend.c
source4/ldap_server/wscript_build
source4/ldap_server/ldap_server.c
And even with openldap backend this code is exercised.
The biggest part of our "LDAP" code is in the ldb modules unless I
misunderstood something and either with tdb or openldap as the backend
we will have to support this.
I'm sure someone will object with the LDAP controls, but the truth is
that most of the AD controls need such intimate knowledge of the
database that they can't be implemented in the backend they have to be
in the samdb.
> Howard, via OpenLDAP does. He
> wants OpenLDAP to be *the* AD LDAP server, and is willing
> to work with us in order to get the code changes we need
> integrated. I'd like to take him up on that offer.
Ok I want to see what is the proposal but if it's "just" to have
> wants OpenLDAP to be *the* AD LDAP server, and is willing
> to work with us in order to get the code changes we need
> integrated. I'd like to take him up on that offer.
openldap as the backend for ldb database I think it has almost no value.
>> Due to AD constraints it means that when openldap is the backend for
>> Samba AD it has to be dedicated to Samba all access should be done
>> through Samba because any change made through DCERPC servers
>> (Netlogon, DRS, LSA, ...) must be seen immediately in the LDAP
>> server and also the other way around.
> Sure - we would have to back-end DCERPC services onto
> the LDAP store, that's understood. Remember, Luke Howard
> already did this for XAD.
>
>> Samba AD it has to be dedicated to Samba all access should be done
>> through Samba because any change made through DCERPC servers
>> (Netlogon, DRS, LSA, ...) must be seen immediately in the LDAP
>> server and also the other way around.
> Sure - we would have to back-end DCERPC services onto
> the LDAP store, that's understood. Remember, Luke Howard
> already did this for XAD.
>
>> Also as there is huge constraints on how the partitions must be
>> organized and how the schema must be structured so you can also
>> forget (correct me if I'm wrong) the idea of upgrading an openldap
>> installation to give a Samba AD personality.
> Let's discuss with Howard.
Let me restate that we need to understand why this has value for us
>> organized and how the schema must be structured so you can also
>> forget (correct me if I'm wrong) the idea of upgrading an openldap
>> installation to give a Samba AD personality.
> Let's discuss with Howard.
or/and our users and this has to be tangible.
>
>> Second concern is the LDAP transaction so that we can honor LDB
>> transaction on this backend, this is required in order to support
>> correctly DRS replication (AD to AD replication).
> Again, Howard is willing to add what we need.
Yeah this seems to be quite achievable.
>> Second concern is the LDAP transaction so that we can honor LDB
>> transaction on this backend, this is required in order to support
>> correctly DRS replication (AD to AD replication).
> Again, Howard is willing to add what we need.
>
>> Third concern is automated testing, currently every single commit
>> the samba repository yield a set of tests to reduce the risk of
>> regression. For the moment tests only use the latest and greatest
>> version of LDAP and our internal LDAP server. If Openldap is added
>> as another backend we need to understand how do we integrate this so
>> that we always do some tests against the Openldap backend. It might
>> mean linking with our socket_wrapper library.
> This is code-mongering, fidley, but doable. We can do this if we have
> the cooperation of the OpenLDAP coders.
Ok in computer science everything is possible the question is what is
>> Third concern is automated testing, currently every single commit
>> the samba repository yield a set of tests to reduce the risk of
>> regression. For the moment tests only use the latest and greatest
>> version of LDAP and our internal LDAP server. If Openldap is added
>> as another backend we need to understand how do we integrate this so
>> that we always do some tests against the Openldap backend. It might
>> mean linking with our socket_wrapper library.
> This is code-mongering, fidley, but doable. We can do this if we have
> the cooperation of the OpenLDAP coders.
the piratical solution for this. So this must be addressed and a quite
detailed proposal has to be made.
If I take the example of Bind9 which is not completely a 1st class
citizen DNS server, we are "supporting" version 9.8 (n - 1) and version
9.9 (version n) not all the distribution have the version 9.8 (debian
stable has 9.7 for the moment) and most of the "server class" distro has
only 9.8.
Back to Openldap it would mean that we would have to test on the stable
version and on the latest dev one and cross the finger to not require
too much the features in the dev version.
Matthieu.
--
Matthieu Patou
Samba Team
http://samba.org
Jeremy Allison
Apr 19, 2013, 5:55:23 PM4/19/13
to
On Fri, Apr 19, 2013 at 01:14:06PM -0700, Matthieu Patou wrote:
> The biggest part of our "LDAP" code is in the ldb modules unless I
> misunderstood something and either with tdb or openldap as the
> backend we will have to support this.
I'd still rather that code be in OpenLDAP rather
> The biggest part of our "LDAP" code is in the ldb modules unless I
> misunderstood something and either with tdb or openldap as the
> backend we will have to support this.
than Samba :-).
> Ok I want to see what is the proposal but if it's "just" to have
> openldap as the backend for ldb database I think it has almost no
> value.
we want. We want better integration - both
sides will need to change.
> Let me restate that we need to understand why this has value for us
> or/and our users and this has to be tangible.
> Ok in computer science everything is possible the question is what
> is the piratical solution for this. So this must be addressed and a
> quite detailed proposal has to be made.
Yep. This conversation is meant not as a "we'll do
> is the piratical solution for this. So this must be addressed and a
> quite detailed proposal has to be made.
this tomorrow" kind of thing, more of a "how do we
get there" conversation.
When I spoke to Howard I made it clear that this
wasn't in the 4.0.x timeframe, nor even in the 4.1.x
timeframe - more likely a Samba 5.x release, however
I still think it's a good goal to move towards.
> If I take the example of Bind9 which is not completely a 1st class
> citizen DNS server, we are "supporting" version 9.8 (n - 1) and
> version 9.9 (version n) not all the distribution have the version
> 9.8 (debian stable has 9.7 for the moment) and most of the "server
> class" distro has only 9.8.
with us to make them our "preferred" DNS server,
OpenLDAP have. That's the difference to me :-).
> Back to Openldap it would mean that we would have to test on the
> stable version and on the latest dev one and cross the finger to not
> require too much the features in the dev version.
of both Samba and OpenLDAP. This is going to take
a while if we can get there at all.
Jeremy.
Gémes Géza
Apr 20, 2013, 1:32:23 AM4/20/13
to
Hi,
Sorry to express my own opinion as not a samba team member or regular
developer (few small patches doesn't count), but instead of trying to
use OpenLDAP as a backend for samba, wouldn't be useful to try to use
tdb/ldb as the backend for OpenLDAP and to see what other changes are
needed in order to have it listen on 389/tcp and 636/tcp on behalf of
Samba, something like the s3fs setup?
Cheers
Geza Gemes
developer (few small patches doesn't count), but instead of trying to
use OpenLDAP as a backend for samba, wouldn't be useful to try to use
tdb/ldb as the backend for OpenLDAP and to see what other changes are
needed in order to have it listen on 389/tcp and 636/tcp on behalf of
Samba, something like the s3fs setup?
Cheers
Geza Gemes
Luke Howard
Apr 20, 2013, 6:17:44 AM4/20/13
to
On 20/04/2013, at 7:32 AM, Gémes Géza <ge...@kzsdabas.hu> wrote:
> Sorry to express my own opinion as not a samba team member or regular developer (few small patches doesn't count), but instead of trying to use OpenLDAP as a backend for samba, wouldn't be useful to try to use tdb/ldb as the backend for OpenLDAP and to see what other changes are needed in order to have it listen on 389/tcp and 636/tcp on behalf of Samba, something like the s3fs setup?
However: Howard and the OpenLDAP team have invested a lot in backend database design (see back-mdb) and I would expect they'd like to leverage this, not just the protocol front-end.
-- Luke
Gémes Géza
Apr 20, 2013, 10:04:46 AM4/20/13
to
Cheers
Geza Gemes
Simo
Apr 20, 2013, 10:19:44 AM4/20/13
to
On 04/20/2013 06:17 AM, Luke Howard wrote:
> On 20/04/2013, at 7:32 AM, Gémes Géza <ge...@kzsdabas.hu> wrote:
>
>> Sorry to express my own opinion as not a samba team member or regular developer (few small patches doesn't count), but instead of trying to use OpenLDAP as a backend for samba, wouldn't be useful to try to use tdb/ldb as the backend for OpenLDAP and to see what other changes are needed in order to have it listen on 389/tcp and 636/tcp on behalf of Samba, something like the s3fs setup?
> That's not a bad idea: enforce the “business logic” (i.e. SAM constraints, etc) in the actual backend database itself, rather than in the layer between the protocol and the backend database. (We did something similar, but much simpler, with the NetInfo backend for OpenLDAP some years ago.)
>
> However: Howard and the OpenLDAP team have invested a lot in backend database design (see back-mdb) and I would expect they'd like to leverage this, not just the protocol front-end.
Not only them, I would really like to use OpenLDAP infinitely more
> On 20/04/2013, at 7:32 AM, Gémes Géza <ge...@kzsdabas.hu> wrote:
>
>> Sorry to express my own opinion as not a samba team member or regular developer (few small patches doesn't count), but instead of trying to use OpenLDAP as a backend for samba, wouldn't be useful to try to use tdb/ldb as the backend for OpenLDAP and to see what other changes are needed in order to have it listen on 389/tcp and 636/tcp on behalf of Samba, something like the s3fs setup?
> That's not a bad idea: enforce the “business logic” (i.e. SAM constraints, etc) in the actual backend database itself, rather than in the layer between the protocol and the backend database. (We did something similar, but much simpler, with the NetInfo backend for OpenLDAP some years ago.)
>
> However: Howard and the OpenLDAP team have invested a lot in backend database design (see back-mdb) and I would expect they'd like to leverage this, not just the protocol front-end.
efficient code for Samba itself.
We do have a working system but it has been always prototype level code
when it comes to performance, and our focus should be functionality not
wasting years in performance tuning, especially given that work has
already been done in OpenLDAP.
I would use LDB as a backend as a transition method and slowly but
steadily migrate one module after the other into an OpenLDAP overlay.
OpenLDAP also already solved properly multithreading issues, something
our current LDAP backend is not good at either. So there are many
reasons to move to a mature technology now that the exploration and
experimentation phase to find out AD peculiarities is basically over.
We know what we need now, it is mostly not blind development anymore.
Simo.
Matthieu Patou
Apr 20, 2013, 1:28:05 PM4/20/13
to
> Sorry to express my own opinion as not a samba team member or regular
> developer (few small patches doesn't count), but instead of trying to
> use OpenLDAP as a backend for samba, wouldn't be useful to try to use
> tdb/ldb as the backend for OpenLDAP and to see what other changes are
> needed in order to have it listen on 389/tcp and 636/tcp on behalf of
> Samba, something like the s3fs setup?
Why not but I'm far from being convinced of the interest of this the
> developer (few small patches doesn't count), but instead of trying to
> use OpenLDAP as a backend for samba, wouldn't be useful to try to use
> tdb/ldb as the backend for OpenLDAP and to see what other changes are
> needed in order to have it listen on 389/tcp and 636/tcp on behalf of
> Samba, something like the s3fs setup?
core of our LDAP server is pretty thin and everything is then most of
the heavy lifting is done in samdb, so there would be ihmo not so much
advantage of doing so.
Matthieu
Gémes Géza
Apr 20, 2013, 1:55:13 PM4/20/13
to
and the possibility to better analyze the performance implications. At
the same time porting samdb to another storage database (e.g. to mdb
used by OpenLDAP) while beeing a huge task could be also interesting
performance wise. I don't see any other way to compare (stock) OpenLDAP
and the built in LDAP server performance-wise, because the functionality
differences they represent today.
Just my 2c's.
Cheers
Geza Gemes
Matthieu Patou
Apr 20, 2013, 2:19:43 PM4/20/13
to
On 04/20/2013 07:19 AM, Simo wrote:
> On 04/20/2013 06:17 AM, Luke Howard wrote:
>> On 20/04/2013, at 7:32 AM, Gémes Géza <ge...@kzsdabas.hu> wrote:
>>
> On 04/20/2013 06:17 AM, Luke Howard wrote:
>> On 20/04/2013, at 7:32 AM, Gémes Géza <ge...@kzsdabas.hu> wrote:
>>
>>> Sorry to express my own opinion as not a samba team member or
>>> regular developer (few small patches doesn't count), but instead of
>>> trying to use OpenLDAP as a backend for samba, wouldn't be useful to
>>> try to use tdb/ldb as the backend for OpenLDAP and to see what other
>>> changes are needed in order to have it listen on 389/tcp and 636/tcp
>>> on behalf of Samba, something like the s3fs setup?
>>> regular developer (few small patches doesn't count), but instead of
>>> trying to use OpenLDAP as a backend for samba, wouldn't be useful to
>>> try to use tdb/ldb as the backend for OpenLDAP and to see what other
>>> changes are needed in order to have it listen on 389/tcp and 636/tcp
>>> on behalf of Samba, something like the s3fs setup?
>> That's not a bad idea: enforce the “business logic” (i.e. SAM
>> constraints, etc) in the actual backend database itself, rather than
>> in the layer between the protocol and the backend database. (We did
>> something similar, but much simpler, with the NetInfo backend for
>> OpenLDAP some years ago.)
>>
>> However: Howard and the OpenLDAP team have invested a lot in backend
>> database design (see back-mdb) and I would expect they'd like to
>> leverage this, not just the protocol front-end.
>
> Not only them, I would really like to use OpenLDAP infinitely more
> efficient code for Samba itself.
Patch are welcomed !
>> constraints, etc) in the actual backend database itself, rather than
>> in the layer between the protocol and the backend database. (We did
>> something similar, but much simpler, with the NetInfo backend for
>> OpenLDAP some years ago.)
>>
>> However: Howard and the OpenLDAP team have invested a lot in backend
>> database design (see back-mdb) and I would expect they'd like to
>> leverage this, not just the protocol front-end.
>
> Not only them, I would really like to use OpenLDAP infinitely more
> efficient code for Samba itself.
> We do have a working system but it has been always prototype level
> code when it comes to performance, and our focus should be
> functionality not wasting years in performance tuning, especially
> given that work has already been done in OpenLDAP.
>
> I would use LDB as a backend as a transition method
So using LDB as the backend to openLDAP is for the moment something that
> code when it comes to performance, and our focus should be
> functionality not wasting years in performance tuning, especially
> given that work has already been done in OpenLDAP.
>
> I would use LDB as a backend as a transition method
we haven't done, I'm not saying it's not possible but for the moment we
have nothing, the only thing that we had once was openLDAP as the
backend of LDB. As the discussion seems to be going on I have the
impression that it's not the way we want to go, and that's a good news
because this way hasn't a lot of value to me.
Using LDB-TDB as the backend to OL is maybe not too complicated and
shouldn't require LDAP transactions as LDB-TDB supports them and they
are required for the RPC code.
> and slowly but steadily migrate one module after the other into an
> OpenLDAP overlay.
would help migrating to a mdb backend.
In my opinion moving to an MDB backend or samdb being an OL overlay is a
huge rewrite of our code, nothing impossible but I'd like to remind the
quote of Jeremy: "How many of you know project that have succeeded doing
a rewrite from scratch", because although we have separate modules they
are pretty much interdependent.
To my candide eyes it looks like proposing the same thing that was
proposed a couple of years ago for migrating from smbd to ntvfs.
While some spend time migrating the current samdb will change in order
to fix bugs or implement still missing features this has to be put into
the equation.
> OpenLDAP also already solved properly multithreading issues, something
> our current LDAP backend is not good at either. So there are many
> reasons to move to a mature technology now that the exploration and
> experimentation phase to find out AD peculiarities is basically over.
>
> We know what we need now, it is mostly not blind development anymore.
if our current implementation had a perfect feature match with the other
implementation as far as I'm concerned I'm more interested to add new
features, fix bugs, fix performance issues that won't be fixed
automatically by moving to overlays rather than doing the move to OL,
but if other wants to do it why not although I didn't had the impression
that we had so many resources idle to handle this task.
Matthieu.
Howard Chu
Apr 20, 2013, 2:28:36 PM4/20/13
to
> Date: Sat, 20 Apr 2013 16:04:46 +0200
> From: G?mes G?za <ge...@kzsdabas.hu>
> 2013-04-20 12:17 keltez?ssel, Luke Howard ?rta:
>> > On 20/04/2013, at 7:32 AM, G?mes G?za <ge...@kzsdabas.hu> wrote:
>> >
>>>>> Sorry to express my own opinion as not a samba team member or
>>>>> regular
developer (few small patches doesn't count), but instead of trying to use
OpenLDAP as a backend for samba, wouldn't be useful to try to use tdb/ldb as
the backend for OpenLDAP and to see what other changes are needed in order to
have it listen on 389/tcp and 636/tcp on behalf of Samba, something like the
s3fs setup?
>>> That's not a bad idea: enforce the ?business logic? (i.e. SAM
>> >
>>>>> Sorry to express my own opinion as not a samba team member or
>>>>> regular
developer (few small patches doesn't count), but instead of trying to use
OpenLDAP as a backend for samba, wouldn't be useful to try to use tdb/ldb as
the backend for OpenLDAP and to see what other changes are needed in order to
have it listen on 389/tcp and 636/tcp on behalf of Samba, something like the
s3fs setup?
constraints, etc) in the actual backend database itself, rather than in the
layer between the protocol and the backend database. (We did something
similar, but much simpler, with the NetInfo backend for OpenLDAP some years ago.)
>>>
>>> However: Howard and the OpenLDAP team have invested a lot in backend
database design (see back-mdb) and I would expect they'd like to leverage
this, not just the protocol front-end.
>> >
layer between the protocol and the backend database. (We did something
similar, but much simpler, with the NetInfo backend for OpenLDAP some years ago.)
>>>
>>> However: Howard and the OpenLDAP team have invested a lot in backend
database design (see back-mdb) and I would expect they'd like to leverage
this, not just the protocol front-end.
>> >
>> > -- Luke
> Switch from tdb to mdb perhaps?
(mdb is now called LMDB, to avoid confusion with Microsoft Access mdb etc.)
> Switch from tdb to mdb perhaps?
This has been discussed privately. It is unfortunately not a slam dunk today
due to concerns about 32 bit compatibility. Since LMDB works by directly
referencing data thru a memory map, it can't manage more than ~2GB on a 32 bit
machine. This has not been a concern to us in OpenLDAP because most server
deployments are on 64 bit hardware these days. The notable exception,
smartphones, rarely have databases bigger than a few MB in size.
We recognize that LMDB may not be practical for some 32 bit embedded servers
that Samba targets. We anticipate that 64 bit ARM will replace these devices
soon and the problem will go away.
>
> Cheers
>
> Geza Gemes
Gémes Géza
Apr 20, 2013, 4:10:26 PM4/20/13
to
to complex requirements), at least not before arm64 will become a commodity.
Cheers
Geza Gemes
Matthieu Patou
Apr 20, 2013, 4:34:51 PM4/20/13
to
database means hundreds of users so it could be still meaningful for
small appliances using 32 bit ARM.
Matthieu.
Volker Lendecke
Apr 21, 2013, 3:31:11 AM4/21/13
to
On Fri, Apr 19, 2013 at 02:55:23PM -0700, Jeremy Allison wrote:
> On Fri, Apr 19, 2013 at 01:14:06PM -0700, Matthieu Patou wrote:
>
> > The biggest part of our "LDAP" code is in the ldb modules unless I
> > misunderstood something and either with tdb or openldap as the
> > backend we will have to support this.
>
> I'd still rather that code be in OpenLDAP rather
> than Samba :-).
What do you exactly mean by this? There's quite a bit of
> On Fri, Apr 19, 2013 at 01:14:06PM -0700, Matthieu Patou wrote:
>
> > The biggest part of our "LDAP" code is in the ldb modules unless I
> > misunderstood something and either with tdb or openldap as the
> > backend we will have to support this.
>
> I'd still rather that code be in OpenLDAP rather
> than Samba :-).
logic in the ldb modules that need to be part of the LDAP
operations but that are definitely AD specific. I'd host
most of that inside the Samba source code and load as
modules into OpenLDAP.
Another concern Tridge had with OpenLDAP was configuration
complexity, but that was well before the config-ldap stuff.
I think nowadays we could fire off a slapd and configure it
completely via some privileged socket, right?
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de
Volker Lendecke
Apr 21, 2013, 3:36:58 AM4/21/13
to
On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
> >and slowly but steadily migrate one module after the other into an
> >OpenLDAP overlay.
> Pardon my stupidity but I'm not understanding how the OL with LDB
> this would help migrating to a mdb backend.
> In my opinion moving to an MDB backend or samdb being an OL overlay
> is a huge rewrite of our code, nothing impossible but I'd like to
> remind the quote of Jeremy: "How many of you know project that have
> succeeded doing a rewrite from scratch", because although we have
> separate modules they are pretty much interdependent.
So what we need is a possibly hackish way to make this work
> >and slowly but steadily migrate one module after the other into an
> >OpenLDAP overlay.
> Pardon my stupidity but I'm not understanding how the OL with LDB
> this would help migrating to a mdb backend.
> In my opinion moving to an MDB backend or samdb being an OL overlay
> is a huge rewrite of our code, nothing impossible but I'd like to
> remind the quote of Jeremy: "How many of you know project that have
> succeeded doing a rewrite from scratch", because although we have
> separate modules they are pretty much interdependent.
*now* with all the modules work on top off a slapd. If the
transactions are a concern, hack them into an extended
operation. Even if they stall all of the rest of OpenLDAP,
it won't be worse than what we have now. Then go and migrate
modules step by step. At some point in the future we then
might be able to make slapd listen itself on 389, but on the
way there we will benefit from OpenLDAP's better database
performance. If we have to solve module dependencies on
their way, that's going to be good for the code.
Yoann Gini
Apr 21, 2013, 4:44:19 AM4/21/13
to
Hello,
As I said before on the list, I’m a french sys admin and also a developer, specialized on OS X and OS X Server. This conversation is interesting and please, allow me to give you the consumer point of view. (And forgive me for my english.)
I’ve read all your comments about OpenLDAP or not OpenLDAP as backend for Samba4.
The one saying « we should keep our own LDAP server because is only made with fee files » scares me, if OpenLDAP is heavy and have a lot of overlay it’s because we need it in the real world, seeing this kind of comments on the list remember me why a lot of people on the sys admin side would prefer to buy a Windows Server instead of playing with Samba4.
I don’t know how AD work and how Samba4 work, but I’ve a deep knowledge of OS X directory service and UNIX systems, so what’s come next is purely a theoretical point of view about software architecture and what should be done if you want to give a good answer to the market needs.
Network who aren’t based on Microsoft AD nowadays are mainly build with OpenLDAP, Kerberos (MIT or Heimdal) and SASL, but that’s not the only solution. We have other LDAP server, the most recognized after OpenLDAP is eDirectory from Novell. And after that we can also have some custom system that you don’t want to use (French university offer you a lot of surprises).
What I’m trying to say is simple, assuming people gonna move on their whole directory service on your hands because you say it’s better won’t work, like saying to use OpenLDAP with your specific backend when people already have existing working setup. It’s a too heavy modification of a core service of a network to be accepted by 80% of IT guys and CTO.
At this days, Samba4 answer to the needs « I want and Active Directory for free ». But in the real world, that not the question coming from IT, the real question is « I want an adapter to connect Windows clients to my Directory Service ». One of the answer to the real question is pGina for example, it simple but widely used in educational network even if it only do windows logon.
Today you’ve a working code and a deep knowledge of how AD work, that greats, really greats, you’ve done a impressive work, but IMHO it’s only the R part of R&D. What you need to do now it develop your system to fit in many situation as possible.
An other company was in the same situation some years ago: Apple. When they’ve build their directory services in 2000 the requirements was to be able to be connected to whatever IT guys have and with many level of personalization.
On a OS X client, the whole identity management go through a specific process, DirectoryService[1] (or opendirectoryd depending of the version), this process is only here to translate the Apple API to any kind of backend, based on plug-in. Whit it we can connect our OS X to anything we want. By default Apple support local XML file, NIS, LDAP and AD. For other system, Apple have published the API to create plug-in, and for example, Novell used this possibility to create one for eDirectory.
On a sys admin side, when we integrate OS X client to a custom LDAP schema who don’t fit with the Apple needs, we have many options to answer the problems without heavy modification of the system.
The base is on the LDAP plug-in, we can create our own mapping config, saying the username isn’t uid but the mail field for example. We can also define some static and dynamic mapping on the client side. We can set the GID for all user to a specific value if the LDAP don’t have it. We can set the home folder to /Users/<uid> to compose it if we need.
When we’ve done our custom mapping, again, we’ve got options to deploy it. We can get the XML config file and copy it to all clients, or we can save it in a specific cn of the LDAP tree, allowing new clients to just bind and download mapping without any user interactions.
When come the time to manage our clients and put some MCX (the OS X world equivalent of GPO), again, we’ve multiple options. MCX are simple XML file stored in a specific LDAP field for users, groups and computers. If we want, we can extend the LDAP schema to add some apple- field to support our MCX and that’s done. But if we don’t want it, we have an other solution, use two LDAP server in the same time on OS X Client. The first with users identities on the existing LDAP server and the other one, on OS X Server if we want, contains augmented entries with extended field for management only (that what we call the golden triangle or magical triangle in OS X world).
For me, this is the nicer solution to handle directory service, it’s complex, but as an OS X sys admin I’ve never have a case where I’ve said « I can’t connect OS X to your system ».
IMHO, if you with Samba4 want to be THE option to _integrate_ Windows clients to existing directory service, you need to follow a path like that. You need to build an abstract system based on backend plugin with a full documentation, examples and possibilities. And you need to use it to your own needs.
Don’t assume it will be OpenLDAP, don’t assume you will have password hash in the LDAP, it can be in an other custom datastore, don’t assume sys admin will move on your system just because you say it’s better.
Sys admin aren’t stupid people. Try to build the more flexible solution who fit in many case, even if sometime you can’t provide some features. If in some case you can provide user and group but no GPO or not as good as you want, explain why, explain workaround but let your system work in a degraded setup. That will allow your clients to test it and see how it work without having to move all critical service on your hands.
My 2 cents,
Yoann.
[1] http://www.opensource.apple.com/source/DirectoryService/DirectoryService-621.12/
As I said before on the list, I’m a french sys admin and also a developer, specialized on OS X and OS X Server. This conversation is interesting and please, allow me to give you the consumer point of view. (And forgive me for my english.)
I’ve read all your comments about OpenLDAP or not OpenLDAP as backend for Samba4.
The one saying « we should keep our own LDAP server because is only made with fee files » scares me, if OpenLDAP is heavy and have a lot of overlay it’s because we need it in the real world, seeing this kind of comments on the list remember me why a lot of people on the sys admin side would prefer to buy a Windows Server instead of playing with Samba4.
I don’t know how AD work and how Samba4 work, but I’ve a deep knowledge of OS X directory service and UNIX systems, so what’s come next is purely a theoretical point of view about software architecture and what should be done if you want to give a good answer to the market needs.
Network who aren’t based on Microsoft AD nowadays are mainly build with OpenLDAP, Kerberos (MIT or Heimdal) and SASL, but that’s not the only solution. We have other LDAP server, the most recognized after OpenLDAP is eDirectory from Novell. And after that we can also have some custom system that you don’t want to use (French university offer you a lot of surprises).
What I’m trying to say is simple, assuming people gonna move on their whole directory service on your hands because you say it’s better won’t work, like saying to use OpenLDAP with your specific backend when people already have existing working setup. It’s a too heavy modification of a core service of a network to be accepted by 80% of IT guys and CTO.
At this days, Samba4 answer to the needs « I want and Active Directory for free ». But in the real world, that not the question coming from IT, the real question is « I want an adapter to connect Windows clients to my Directory Service ». One of the answer to the real question is pGina for example, it simple but widely used in educational network even if it only do windows logon.
Today you’ve a working code and a deep knowledge of how AD work, that greats, really greats, you’ve done a impressive work, but IMHO it’s only the R part of R&D. What you need to do now it develop your system to fit in many situation as possible.
An other company was in the same situation some years ago: Apple. When they’ve build their directory services in 2000 the requirements was to be able to be connected to whatever IT guys have and with many level of personalization.
On a OS X client, the whole identity management go through a specific process, DirectoryService[1] (or opendirectoryd depending of the version), this process is only here to translate the Apple API to any kind of backend, based on plug-in. Whit it we can connect our OS X to anything we want. By default Apple support local XML file, NIS, LDAP and AD. For other system, Apple have published the API to create plug-in, and for example, Novell used this possibility to create one for eDirectory.
On a sys admin side, when we integrate OS X client to a custom LDAP schema who don’t fit with the Apple needs, we have many options to answer the problems without heavy modification of the system.
The base is on the LDAP plug-in, we can create our own mapping config, saying the username isn’t uid but the mail field for example. We can also define some static and dynamic mapping on the client side. We can set the GID for all user to a specific value if the LDAP don’t have it. We can set the home folder to /Users/<uid> to compose it if we need.
When we’ve done our custom mapping, again, we’ve got options to deploy it. We can get the XML config file and copy it to all clients, or we can save it in a specific cn of the LDAP tree, allowing new clients to just bind and download mapping without any user interactions.
When come the time to manage our clients and put some MCX (the OS X world equivalent of GPO), again, we’ve multiple options. MCX are simple XML file stored in a specific LDAP field for users, groups and computers. If we want, we can extend the LDAP schema to add some apple- field to support our MCX and that’s done. But if we don’t want it, we have an other solution, use two LDAP server in the same time on OS X Client. The first with users identities on the existing LDAP server and the other one, on OS X Server if we want, contains augmented entries with extended field for management only (that what we call the golden triangle or magical triangle in OS X world).
For me, this is the nicer solution to handle directory service, it’s complex, but as an OS X sys admin I’ve never have a case where I’ve said « I can’t connect OS X to your system ».
IMHO, if you with Samba4 want to be THE option to _integrate_ Windows clients to existing directory service, you need to follow a path like that. You need to build an abstract system based on backend plugin with a full documentation, examples and possibilities. And you need to use it to your own needs.
Don’t assume it will be OpenLDAP, don’t assume you will have password hash in the LDAP, it can be in an other custom datastore, don’t assume sys admin will move on your system just because you say it’s better.
Sys admin aren’t stupid people. Try to build the more flexible solution who fit in many case, even if sometime you can’t provide some features. If in some case you can provide user and group but no GPO or not as good as you want, explain why, explain workaround but let your system work in a degraded setup. That will allow your clients to test it and see how it work without having to move all critical service on your hands.
My 2 cents,
Yoann.
[1] http://www.opensource.apple.com/source/DirectoryService/DirectoryService-621.12/
Gémes Géza
Apr 21, 2013, 4:46:51 PM4/21/13
to
which are more than inflexible with their requirements about what they
expect to find via LDAP calls. So if you want them integrated without
deploying pGina based tricks you have to follow the AD schema byte by
byte. I know that moving from OpenLDAP to Samba AD is a not so smooth,
but rather painful experience (I've migrated from to Samba AD from Samba
(classic) + OpenLDAP + Heimdal during last summer and still have to
maintain the OpenLDAP directory because of some services (I'm glad none
of them is doing user authentication to have to synchronize passwords
between) which couldn't be migrated to AD schema (missing development
resources (read time)) yet (ISC DHCPD is a notable example).
In the case OpenLDAP is going to replace (e.g. as an optional component
like BIND9-DLZ now) the built in LDAP server you shouldn't expect
compatibility with existing installations, as the schema will have to be
the AD one.
Your example citing Apple and their implementation of user
authentication/authorization/account setup should have been followed by
M$ 13 years ago, and now we wouldn't need AD. Unfortunately that is not
the case, and thus in order to satisfy Windows clients out of the box
the AD schema must be used regardless if the LDAP would be served by the
internal LDAP server or OpenLDAP.
Cheers
Geza Gemes
Matthieu Patou
Apr 21, 2013, 6:00:26 PM4/21/13
to
On 04/21/2013 12:36 AM, Volker Lendecke wrote:
> On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
>>> and slowly but steadily migrate one module after the other into an
>>> OpenLDAP overlay.
>> Pardon my stupidity but I'm not understanding how the OL with LDB
>> this would help migrating to a mdb backend.
>> In my opinion moving to an MDB backend or samdb being an OL overlay
>> is a huge rewrite of our code, nothing impossible but I'd like to
>> remind the quote of Jeremy: "How many of you know project that have
>> succeeded doing a rewrite from scratch", because although we have
>> separate modules they are pretty much interdependent.
> So what we need is a possibly hackish way to make this work
> *now* with all the modules work on top off a slapd. If the
> transactions are a concern, hack them into an extended
> operation. Even if they stall all of the rest of OpenLDAP,
> it won't be worse than what we have now.
Can you develop this point, why the current situation is that bad ?
> On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
>>> and slowly but steadily migrate one module after the other into an
>>> OpenLDAP overlay.
>> Pardon my stupidity but I'm not understanding how the OL with LDB
>> this would help migrating to a mdb backend.
>> In my opinion moving to an MDB backend or samdb being an OL overlay
>> is a huge rewrite of our code, nothing impossible but I'd like to
>> remind the quote of Jeremy: "How many of you know project that have
>> succeeded doing a rewrite from scratch", because although we have
>> separate modules they are pretty much interdependent.
> So what we need is a possibly hackish way to make this work
> *now* with all the modules work on top off a slapd. If the
> transactions are a concern, hack them into an extended
> operation. Even if they stall all of the rest of OpenLDAP,
> it won't be worse than what we have now.
> Then go and migrate
> modules step by step. At some point in the future we then
> might be able to make slapd listen itself on 389, but on the
> way there we will benefit from OpenLDAP's better database
> performance. If we have to solve module dependencies on
> their way, that's going to be good for the code.
Do not think that we have module dependencies like that just for the
> modules step by step. At some point in the future we then
> might be able to make slapd listen itself on 389, but on the
> way there we will benefit from OpenLDAP's better database
> performance. If we have to solve module dependencies on
> their way, that's going to be good for the code.
sake of being fun, part of it is dictated by the complexity of AD.
Andrew Bartlett
Apr 21, 2013, 7:47:37 PM4/21/13
to
On Sun, 2013-04-21 at 09:31 +0200, Volker Lendecke wrote:
> On Fri, Apr 19, 2013 at 02:55:23PM -0700, Jeremy Allison wrote:
> > On Fri, Apr 19, 2013 at 01:14:06PM -0700, Matthieu Patou wrote:
> >
> > > The biggest part of our "LDAP" code is in the ldb modules unless I
> > > misunderstood something and either with tdb or openldap as the
> > > backend we will have to support this.
> >
> > I'd still rather that code be in OpenLDAP rather
> > than Samba :-).
>
> What do you exactly mean by this? There's quite a bit of
> logic in the ldb modules that need to be part of the LDAP
> operations but that are definitely AD specific. I'd host
> most of that inside the Samba source code and load as
> modules into OpenLDAP.
>
> Another concern Tridge had with OpenLDAP was configuration
> complexity, but that was well before the config-ldap stuff.
> I think nowadays we could fire off a slapd and configure it
> completely via some privileged socket, right?
When we had the OpenLDAP backend, we solved the configuration complexity
> On Fri, Apr 19, 2013 at 02:55:23PM -0700, Jeremy Allison wrote:
> > On Fri, Apr 19, 2013 at 01:14:06PM -0700, Matthieu Patou wrote:
> >
> > > The biggest part of our "LDAP" code is in the ldb modules unless I
> > > misunderstood something and either with tdb or openldap as the
> > > backend we will have to support this.
> >
> > I'd still rather that code be in OpenLDAP rather
> > than Samba :-).
>
> What do you exactly mean by this? There's quite a bit of
> logic in the ldb modules that need to be part of the LDAP
> operations but that are definitely AD specific. I'd host
> most of that inside the Samba source code and load as
> modules into OpenLDAP.
>
> Another concern Tridge had with OpenLDAP was configuration
> complexity, but that was well before the config-ldap stuff.
> I think nowadays we could fire off a slapd and configure it
> completely via some privileged socket, right?
simply by writing out the configuration files. While it was what
started the whole LDB thing, that isn't what concerns me most about this
at this time.
As you say, most of the logic in being an AD DC turns out to live in our
LDB modules. LDAP isn't a bolt-on - heck, even Kerberos bolts on more
than LDAP does!
The idea of uprooting that working module stack is what doesn't appeal
to me. There is a very, very long road between 'working demo' (it might
take less than a week to hack us back to the state we had this as a
experimental feature) and 'works for all the corner cases'. At a point
where we are focussing on supporting our users in production, I'm not at
all keen on replacing another core component. Even the much-demanded
replacement of winbind looms larger than I'm comfortable with at this
point.
Howard and I go back a long time, and I'm always happy to talk about
this effort, because we didn't document very clearly why we found it to
be a dead-end at the time. But I don't want to raise any false hopes -
most of the 3 years I spent at Red Hat was on the premise that an LDAP
backend was the future direction for the then 'Samba4' project, but I
just couldn't make it work.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Andrew Bartlett
Apr 21, 2013, 7:55:36 PM4/21/13
to
On Sun, 2013-04-21 at 15:00 -0700, Matthieu Patou wrote:
> On 04/21/2013 12:36 AM, Volker Lendecke wrote:
> > On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
> >>> and slowly but steadily migrate one module after the other into an
> >>> OpenLDAP overlay.
> >> Pardon my stupidity but I'm not understanding how the OL with LDB
> >> this would help migrating to a mdb backend.
> >> In my opinion moving to an MDB backend or samdb being an OL overlay
> >> is a huge rewrite of our code, nothing impossible but I'd like to
> >> remind the quote of Jeremy: "How many of you know project that have
> >> succeeded doing a rewrite from scratch", because although we have
> >> separate modules they are pretty much interdependent.
> > So what we need is a possibly hackish way to make this work
> > *now* with all the modules work on top off a slapd. If the
> > transactions are a concern, hack them into an extended
> > operation. Even if they stall all of the rest of OpenLDAP,
> > it won't be worse than what we have now.
> Can you develop this point, why the current situation is that bad ?
This is how I feel about this situation. I know it would be really cool
> On 04/21/2013 12:36 AM, Volker Lendecke wrote:
> > On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
> >>> and slowly but steadily migrate one module after the other into an
> >>> OpenLDAP overlay.
> >> Pardon my stupidity but I'm not understanding how the OL with LDB
> >> this would help migrating to a mdb backend.
> >> In my opinion moving to an MDB backend or samdb being an OL overlay
> >> is a huge rewrite of our code, nothing impossible but I'd like to
> >> remind the quote of Jeremy: "How many of you know project that have
> >> succeeded doing a rewrite from scratch", because although we have
> >> separate modules they are pretty much interdependent.
> > So what we need is a possibly hackish way to make this work
> > *now* with all the modules work on top off a slapd. If the
> > transactions are a concern, hack them into an extended
> > operation. Even if they stall all of the rest of OpenLDAP,
> > it won't be worse than what we have now.
> Can you develop this point, why the current situation is that bad ?
to involve Howard more in our efforts, but for better or worse, we have
a working, tested and production solution. We could perhaps do with
improving the efficiency of the very base level of LDB, but I'm actually
very happy with where we are. It is quite complex code, but it has an
extensive test-suite, isn't costing us a lot of energy in it's current
state, and handles things like full AD ACLs based on the PAC, besides
many other quite-non-standard behaviours.
> > Then go and migrate
> > modules step by step. At some point in the future we then
> > might be able to make slapd listen itself on 389, but on the
> > way there we will benefit from OpenLDAP's better database
> > performance. If we have to solve module dependencies on
> > their way, that's going to be good for the code.
> Do not think that we have module dependencies like that just for the
> sake of being fun, part of it is dictated by the complexity of AD.
modules I would perhaps combine are linked_attributes and
repl_meta_data, but repl_meta_data is quite large enough on it's own.
Volker Lendecke
Apr 22, 2013, 2:22:14 AM4/22/13
to
On Sun, Apr 21, 2013 at 03:00:26PM -0700, Matthieu Patou wrote:
> On 04/21/2013 12:36 AM, Volker Lendecke wrote:
> >On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
> >>>and slowly but steadily migrate one module after the other into an
> >>>OpenLDAP overlay.
> >>Pardon my stupidity but I'm not understanding how the OL with LDB
> >>this would help migrating to a mdb backend.
> >>In my opinion moving to an MDB backend or samdb being an OL overlay
> >>is a huge rewrite of our code, nothing impossible but I'd like to
> >>remind the quote of Jeremy: "How many of you know project that have
> >>succeeded doing a rewrite from scratch", because although we have
> >>separate modules they are pretty much interdependent.
> >So what we need is a possibly hackish way to make this work
> >*now* with all the modules work on top off a slapd. If the
> >transactions are a concern, hack them into an extended
> >operation. Even if they stall all of the rest of OpenLDAP,
> >it won't be worse than what we have now.
> Can you develop this point, why the current situation is that bad ?
I can't point at specific problems right now, but that is
> On 04/21/2013 12:36 AM, Volker Lendecke wrote:
> >On Sat, Apr 20, 2013 at 11:19:43AM -0700, Matthieu Patou wrote:
> >>>and slowly but steadily migrate one module after the other into an
> >>>OpenLDAP overlay.
> >>Pardon my stupidity but I'm not understanding how the OL with LDB
> >>this would help migrating to a mdb backend.
> >>In my opinion moving to an MDB backend or samdb being an OL overlay
> >>is a huge rewrite of our code, nothing impossible but I'd like to
> >>remind the quote of Jeremy: "How many of you know project that have
> >>succeeded doing a rewrite from scratch", because although we have
> >>separate modules they are pretty much interdependent.
> >So what we need is a possibly hackish way to make this work
> >*now* with all the modules work on top off a slapd. If the
> >transactions are a concern, hack them into an extended
> >operation. Even if they stall all of the rest of OpenLDAP,
> >it won't be worse than what we have now.
> Can you develop this point, why the current situation is that bad ?
mainly because I have not yet seen larger environments with
AD. However, my recent experience with tuning the SMB and
cluster environment is that even a much older and more
widely used code basis (smbd) can hold really bad and hard
to overcome surprises. So I would really like to stand on
OpenLDAP's shoulders to see farther.
Yoann Gini
Apr 22, 2013, 3:01:38 AM4/22/13
to
Le 21 avr. 2013 à 22:46, Gémes Géza <ge...@kzsdabas.hu> a écrit :
> Unfortunately Samba as an AD DC has to satisfy (also) Windows clients which are more than inflexible with their requirements about what they expect to find via LDAP calls.
Andreas Schneider
Apr 22, 2013, 7:12:04 AM4/22/13
to
On Friday 19 April 2013 09:59:40 Jeremy Allison wrote:
> > It might mean linking with our socket_wrapper library.
>
> This is code-mongering, fidley, but doable. We can do this if we have
> the cooperation of the OpenLDAP coders.
JFYI: I've created a version of the socket_wrapper library you can LD_PRELOAD.
> > It might mean linking with our socket_wrapper library.
>
> This is code-mongering, fidley, but doable. We can do this if we have
> the cooperation of the OpenLDAP coders.
I wanted to be able to use it in other projects with daemons I don't build.
Code:
http://git.cryptomilk.org/projects/socket_wrapper.git/
Example:
http://git.cryptomilk.org/projects/socket_wrapper.git/tree/example/openssh.sh
Cheers,
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
Samba Team a...@samba.org
www.samba.org
Volker Lendecke
Apr 22, 2013, 7:16:18 AM4/22/13
to
On Mon, Apr 22, 2013 at 01:12:04PM +0200, Andreas Schneider wrote:
> On Friday 19 April 2013 09:59:40 Jeremy Allison wrote:
> > > It might mean linking with our socket_wrapper library.
> >
> > This is code-mongering, fidley, but doable. We can do this if we have
> > the cooperation of the OpenLDAP coders.
>
> JFYI: I've created a version of the socket_wrapper library you can LD_PRELOAD.
> I wanted to be able to use it in other projects with daemons I don't build.
>
> Code:
>
> http://git.cryptomilk.org/projects/socket_wrapper.git/
>
> Example:
>
> http://git.cryptomilk.org/projects/socket_wrapper.git/tree/example/openssh.sh
Is it possible to run the full Samba autobuild cycle with
> On Friday 19 April 2013 09:59:40 Jeremy Allison wrote:
> > > It might mean linking with our socket_wrapper library.
> >
> > This is code-mongering, fidley, but doable. We can do this if we have
> > the cooperation of the OpenLDAP coders.
>
> JFYI: I've created a version of the socket_wrapper library you can LD_PRELOAD.
> I wanted to be able to use it in other projects with daemons I don't build.
>
> Code:
>
> http://git.cryptomilk.org/projects/socket_wrapper.git/
>
> Example:
>
> http://git.cryptomilk.org/projects/socket_wrapper.git/tree/example/openssh.sh
this and a Samba version compiled without the socket
wrapper?
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 G�ttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG G�ttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de
Andreas Schneider
Apr 22, 2013, 7:27:32 AM4/22/13
to
On Monday 22 April 2013 13:16:18 Volker Lendecke wrote:
> On Mon, Apr 22, 2013 at 01:12:04PM +0200, Andreas Schneider wrote:
> > On Friday 19 April 2013 09:59:40 Jeremy Allison wrote:
> > > > It might mean linking with our socket_wrapper library.
> > >
> > > This is code-mongering, fidley, but doable. We can do this if we have
> > > the cooperation of the OpenLDAP coders.
> >
> > JFYI: I've created a version of the socket_wrapper library you can
> > LD_PRELOAD. I wanted to be able to use it in other projects with daemons
> > I don't build.
> >
> > Code:
> >
> > http://git.cryptomilk.org/projects/socket_wrapper.git/
> >
> > Example:
> >
> > http://git.cryptomilk.org/projects/socket_wrapper.git/tree/example/openssh
> > .sh
> Is it possible to run the full Samba autobuild cycle with
> this and a Samba version compiled without the socket
> wrapper?
Yes, it should be. I haven't had the time to change 'selftest' to use this
> On Mon, Apr 22, 2013 at 01:12:04PM +0200, Andreas Schneider wrote:
> > On Friday 19 April 2013 09:59:40 Jeremy Allison wrote:
> > > > It might mean linking with our socket_wrapper library.
> > >
> > > This is code-mongering, fidley, but doable. We can do this if we have
> > > the cooperation of the OpenLDAP coders.
> >
> > JFYI: I've created a version of the socket_wrapper library you can
> > LD_PRELOAD. I wanted to be able to use it in other projects with daemons
> > I don't build.
> >
> > Code:
> >
> > http://git.cryptomilk.org/projects/socket_wrapper.git/
> >
> > Example:
> >
> > http://git.cryptomilk.org/projects/socket_wrapper.git/tree/example/openssh
> > .sh
> Is it possible to run the full Samba autobuild cycle with
> this and a Samba version compiled without the socket
> wrapper?
version with LD_PRELOAD.
You just need to make sure all executeables are started with this. Maybe it is
enough to just set it once in selftest and it will just work.
I need to make uid wrapper and nss wrapper LD_PRELOADable too. Maybe I can do
it during SambaXP.
Volker Lendecke
Apr 22, 2013, 7:33:39 AM4/22/13
to
separation of concerns that might be worthwhile to add
permanently to Samba.
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de
Andreas Schneider
Apr 22, 2013, 7:43:02 AM4/22/13
to
Jeremy Allison
Apr 22, 2013, 12:57:19 PM4/22/13
to
It would be *wonderful* to move that code out of
Samba and into an external library.
Jeremy.
Jeremy Allison
Apr 22, 2013, 12:58:58 PM4/22/13
to
On Mon, Apr 22, 2013 at 09:47:37AM +1000, Andrew Bartlett wrote:
>
> Howard and I go back a long time, and I'm always happy to talk about
> this effort, because we didn't document very clearly why we found it to
> be a dead-end at the time. But I don't want to raise any false hopes -
> most of the 3 years I spent at Red Hat was on the premise that an LDAP
> backend was the future direction for the then 'Samba4' project, but I
> just couldn't make it work.
Thanks Andrew, I think that's a very reasonable concern.
>
> Howard and I go back a long time, and I'm always happy to talk about
> this effort, because we didn't document very clearly why we found it to
> be a dead-end at the time. But I don't want to raise any false hopes -
> most of the 3 years I spent at Red Hat was on the premise that an LDAP
> backend was the future direction for the then 'Samba4' project, but I
> just couldn't make it work.
I am just hoping to jump-start the conversation again as
there seems to be more interest on the OpenLDAP side on
seeing what needs to be done in order to make this work.
Cheers,
Jeremy.
Gémes Géza
Apr 22, 2013, 1:27:00 PM4/22/13
to
those used by OpenLDAP or any other implementation. So bringing over
ldif export files form existing LDAP directories won't work without
changes, and could even need some patches for the software which used them.
Matthieu Patou
Apr 23, 2013, 12:56:34 AM4/23/13
to
On 04/22/2013 02:55 PM, Yoann Gini wrote:
>
> For my understanding of the AD system, the mains differences are the GPO applied to OU (but I don’t know how it’s saved and I’m curious about that) and some custom unique ID like de SID who look like to have a algorithmic conception.
>
> Mapping userPrincipalName to uid and userAccountControl to static value or to a microsoft-userAccountControl field is not a big deal for a system administrator.
>
> Conflicting attributes are just a question of mapping and you have the control on that point, you can translate on with some config file conflicting attributes. For things who don’t exist or exit in a bad format, we can handle a schema extension and an integration into the existing admin tools (for example to translate a password expiration date to a pwdLastSet boolean).
>
> Providing the content is the role of the system administrator, not yours. What you have to do on your side is asking us what you need and allowing us to map some names to fit your needs in our schema.
A couple of problem that can arise:
* CN is mono valuated in AD, OpenLDAP hasn't this limitation so if your
current setup has object with two CN you're done.
* source4/setup/schema-map-openldap-2.3 indicate there is quite common
attributes that are in *conflict* ie.
#MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
#defaultGroup has a conflicting OID
1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
So your existing schema and your data have attributes with this OID then
it would mean something else in the "AD" view and in the "other view"
and even worse this could lead to AD constraint failure (not in the
schema) but one explained in one of the 20+ pdf documentation related to
AD (ie. MS-ADTS).
If you have a custom schema it starts to be much worse, you don't have
to search a very long time: ISC DHCP extension for LDAP:
https://github.com/dcantrell/ldap-for-dhcp/blob/master/dhcp.schema
It has an schema attribute dhcpSubnet with OID
2.16.840.1.113719.1.203.6.3, but in default AD schema it's
1.2.840.113556.1.4.705 so if you try to import AD schema it won't work.
You can tweak it but then replication with other AD servers is unlikely
to work.
Matthieu.
> Le 22 avr. 2013 à 19:27, Gémes Géza <ge...@kzsdabas.hu> a écrit :
>
>> Lots of attributes are different (conflicting) in the AD schema from those used by OpenLDAP or any other implementation. So bringing over ldif export files form existing LDAP directories won't work without changes, and could even need some patches for the software which used them.
> Attribute composition or replacement to deal with that kind of situation are something that we are used to…
>
>> Lots of attributes are different (conflicting) in the AD schema from those used by OpenLDAP or any other implementation. So bringing over ldif export files form existing LDAP directories won't work without changes, and could even need some patches for the software which used them.
>
> For my understanding of the AD system, the mains differences are the GPO applied to OU (but I don’t know how it’s saved and I’m curious about that) and some custom unique ID like de SID who look like to have a algorithmic conception.
>
> Mapping userPrincipalName to uid and userAccountControl to static value or to a microsoft-userAccountControl field is not a big deal for a system administrator.
>
> Conflicting attributes are just a question of mapping and you have the control on that point, you can translate on with some config file conflicting attributes. For things who don’t exist or exit in a bad format, we can handle a schema extension and an integration into the existing admin tools (for example to translate a password expiration date to a pwdLastSet boolean).
>
> Providing the content is the role of the system administrator, not yours. What you have to do on your side is asking us what you need and allowing us to map some names to fit your needs in our schema.
A couple of problem that can arise:
* CN is mono valuated in AD, OpenLDAP hasn't this limitation so if your
current setup has object with two CN you're done.
* source4/setup/schema-map-openldap-2.3 indicate there is quite common
attributes that are in *conflict* ie.
#MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
#defaultGroup has a conflicting OID
1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
So your existing schema and your data have attributes with this OID then
it would mean something else in the "AD" view and in the "other view"
and even worse this could lead to AD constraint failure (not in the
schema) but one explained in one of the 20+ pdf documentation related to
AD (ie. MS-ADTS).
If you have a custom schema it starts to be much worse, you don't have
to search a very long time: ISC DHCP extension for LDAP:
https://github.com/dcantrell/ldap-for-dhcp/blob/master/dhcp.schema
It has an schema attribute dhcpSubnet with OID
2.16.840.1.113719.1.203.6.3, but in default AD schema it's
1.2.840.113556.1.4.705 so if you try to import AD schema it won't work.
You can tweak it but then replication with other AD servers is unlikely
to work.
Matthieu.
Gémes Géza
Apr 23, 2013, 12:32:18 AM4/23/13
to
2013-04-22 23:55 keltezéssel, Yoann Gini írta:
> Le 22 avr. 2013 à 19:27, Gémes Géza <ge...@kzsdabas.hu> a écrit :
>
>> Lots of attributes are different (conflicting) in the AD schema from those used by OpenLDAP or any other implementation. So bringing over ldif export files form existing LDAP directories won't work without changes, and could even need some patches for the software which used them.
> Attribute composition or replacement to deal with that kind of situation are something that we are used to…
>
> For my understanding of the AD system, the mains differences are the GPO applied to OU (but I don’t know how it’s saved and I’m curious about that) and some custom unique ID like de SID who look like to have a algorithmic conception.
>
> Mapping userPrincipalName to uid and userAccountControl to static value or to a microsoft-userAccountControl field is not a big deal for a system administrator.
>
> Conflicting attributes are just a question of mapping and you have the control on that point, you can translate on with some config file conflicting attributes. For things who don’t exist or exit in a bad format, we can handle a schema extension and an integration into the existing admin tools (for example to translate a password expiration date to a pwdLastSet boolean).
>
> Providing the content is the role of the system administrator, not yours. What you have to do on your side is asking us what you need and allowing us to map some names to fit your needs in our schema.
GPOs are saved as files in a subfolder of the sysvol share
> Le 22 avr. 2013 à 19:27, Gémes Géza <ge...@kzsdabas.hu> a écrit :
>
>> Lots of attributes are different (conflicting) in the AD schema from those used by OpenLDAP or any other implementation. So bringing over ldif export files form existing LDAP directories won't work without changes, and could even need some patches for the software which used them.
> Attribute composition or replacement to deal with that kind of situation are something that we are used to…
>
> For my understanding of the AD system, the mains differences are the GPO applied to OU (but I don’t know how it’s saved and I’m curious about that) and some custom unique ID like de SID who look like to have a algorithmic conception.
>
> Mapping userPrincipalName to uid and userAccountControl to static value or to a microsoft-userAccountControl field is not a big deal for a system administrator.
>
> Conflicting attributes are just a question of mapping and you have the control on that point, you can translate on with some config file conflicting attributes. For things who don’t exist or exit in a bad format, we can handle a schema extension and an integration into the existing admin tools (for example to translate a password expiration date to a pwdLastSet boolean).
>
> Providing the content is the role of the system administrator, not yours. What you have to do on your side is asking us what you need and allowing us to map some names to fit your needs in our schema.
Mapping user account related attributes was never (at least not
recently) a problem on *nix, but there are other kinds of data which can
be stored in a directory and not all software support mapping. Some
simply expect a given attribute, and if that conflicts (already exist
with different type, or EqualityMatch, etc.) with the AD schema imposed
attribute you need to modify the given software.
Regards
Geza Gemes
Luke Howard
Apr 23, 2013, 10:54:29 AM4/23/13
to
> * CN is mono valuated in AD, OpenLDAP hasn't this limitation so if your current setup has object with two CN you're done.
There's a difference, of course, between migrating existing OpenLDAP deployments or just supporting OpenLDAP for new (or Samba4) ones. That would be a good thing to clarify goal-wise.
As Jeremy pointed out, it is definitely possible to have OpenLDAP enforce the AD DIT constraints. And, although my memory is hazy, I'm pretty sure that eDirectory supports multi-valued CNs and I don't actually remember any problems with Novell's DSfW vis-a-vis this.
> It has an schema attribute dhcpSubnet with OID 2.16.840.1.113719.1.203.6.3, but in default AD schema it's 1.2.840.113556.1.4.705 so if you try to import AD schema it won't work. You can tweak it but then replication with other AD servers is unlikely to work.
When I was at Novell, we did a couple of things: if you came in on a non-AD port (e.g. 1389), or if you used a particular LDAP control, all of the dynamic AD mapping would be turned off. So you would get something that looked a lot closer to a normal LDAP server (obviously, still with a lot of extra attributes). We had far greater conflicts with attribute and class names than the typical OpenLDAP deployment (but on the other hand, eDirectory has a richer and more abstracted data model; the LDAP server was really just a protocol front-end).
-- Luke
Andrew Bartlett
May 17, 2013, 7:44:56 PM5/17/13
to
On Wed, 2013-04-17 at 14:58 -0700, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
> and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it will take
> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
> recommended option, not just "yeah that should work but..." I've reviewed some
> of the previous discussions on this topic in the archives, but I suspect some
> of those points are now out of date.
I've been thinking about ways we could better work with OpenLDAP, as I
talk more and more with Samba users who can't just drop their existing
configurations, or don't want to migrate their unix-like world to AD,
even if provided by Samba.
There are many tools to sync directories, and while I dislike that as a
concept, they are part of the world we work in. What they generally
miss is a good way to handle passwords, and there is where I thought we
might be able to make some positive progress.
In particular, I'm wondering about having Samba sync either the
plaintext password (when sent to us during a password change) or an
appropriate password hash to OpenLDAP, and have OpenLDAP send us the
plaintext password if it does the change.
For real-time both-directions sync of real passwords with policy
enforcement:
I'm thinking something like this:
- password change proposed to Samba
- verify Samba would accept password
- (maybe - transactions over network ops are bad) start Samba
transaction
- ask openldap to change password
- set password in Samba
- (maybe) commit samba transaction
and in the reverse:
- password change proposed to OpenLDAP
- verify OpenLDAP would accept password
- (maybe) start OpenLDAP transaction
- ask Samba to change password
- set password in OpenLDAP
- (maybe) commit OpenLDAP transaction
I would propose that we use an extended operation (perhaps based on the
existing one) to do the password change, but extended so that OpenLDAP
and Samba know if it is a password change or set, but without seeing the
old password.
That way, OpenLDAP and Samba can both veto a password, keep applying
policy and hopefully things can't get out of sync.
For situations where Samba is the master, or where AD is the master, and
Samba is just part of a broader AD domain, I wondered if we could have:
- password change proposed to samba
- verify Samba accepts password
- send the aes256-cts-hmac-sha1-96 hash to OpenLDAP
(this hash chosen as all current AD servers can generate it, and it
is salted unlike previous AD keys)
- set password in samba
For replicated from another AD:
- when password change noticed
- send the aes256-cts-hmac-sha1-96 hash to OpenLDAP
For the reverse:
- password change proposed to OpenLDAP
- send password change to samba
- wait for return of aes256-cts-hmac-sha1-96 hash
What do you think? Once password changes 'just work', I think some of
the other pain points become much easier, for dual-directory
situations.
Thanks,
> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
> and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it will take
> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
> recommended option, not just "yeah that should work but..." I've reviewed some
> of the previous discussions on this topic in the archives, but I suspect some
> of those points are now out of date.
I've been thinking about ways we could better work with OpenLDAP, as I
talk more and more with Samba users who can't just drop their existing
configurations, or don't want to migrate their unix-like world to AD,
even if provided by Samba.
There are many tools to sync directories, and while I dislike that as a
concept, they are part of the world we work in. What they generally
miss is a good way to handle passwords, and there is where I thought we
might be able to make some positive progress.
In particular, I'm wondering about having Samba sync either the
plaintext password (when sent to us during a password change) or an
appropriate password hash to OpenLDAP, and have OpenLDAP send us the
plaintext password if it does the change.
For real-time both-directions sync of real passwords with policy
enforcement:
I'm thinking something like this:
- password change proposed to Samba
- verify Samba would accept password
- (maybe - transactions over network ops are bad) start Samba
transaction
- ask openldap to change password
- set password in Samba
- (maybe) commit samba transaction
and in the reverse:
- password change proposed to OpenLDAP
- verify OpenLDAP would accept password
- (maybe) start OpenLDAP transaction
- ask Samba to change password
- set password in OpenLDAP
- (maybe) commit OpenLDAP transaction
I would propose that we use an extended operation (perhaps based on the
existing one) to do the password change, but extended so that OpenLDAP
and Samba know if it is a password change or set, but without seeing the
old password.
That way, OpenLDAP and Samba can both veto a password, keep applying
policy and hopefully things can't get out of sync.
For situations where Samba is the master, or where AD is the master, and
Samba is just part of a broader AD domain, I wondered if we could have:
- password change proposed to samba
- verify Samba accepts password
- send the aes256-cts-hmac-sha1-96 hash to OpenLDAP
(this hash chosen as all current AD servers can generate it, and it
is salted unlike previous AD keys)
- set password in samba
For replicated from another AD:
- when password change noticed
- send the aes256-cts-hmac-sha1-96 hash to OpenLDAP
For the reverse:
- password change proposed to OpenLDAP
- send password change to samba
- wait for return of aes256-cts-hmac-sha1-96 hash
What do you think? Once password changes 'just work', I think some of
the other pain points become much easier, for dual-directory
situations.
Thanks,
Howard Chu
May 18, 2013, 1:15:04 PM5/18/13
to
Andrew Bartlett wrote:
> On Wed, 2013-04-17 at 14:58 -0700, Howard Chu wrote:
>> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
>> and then it always slips by, but this time for sure.
>>
>> I'll keep this short - my colleagues at Symas want to know what it will take
>> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
>> recommended option, not just "yeah that should work but..." I've reviewed some
>> of the previous discussions on this topic in the archives, but I suspect some
>> of those points are now out of date.
>
> I've been thinking about ways we could better work with OpenLDAP, as I
> talk more and more with Samba users who can't just drop their existing
> configurations, or don't want to migrate their unix-like world to AD,
> even if provided by Samba.
>
> There are many tools to sync directories, and while I dislike that as a
> concept, they are part of the world we work in. What they generally
> miss is a good way to handle passwords, and there is where I thought we
> might be able to make some positive progress.
>
> In particular, I'm wondering about having Samba sync either the
> plaintext password (when sent to us during a password change) or an
> appropriate password hash to OpenLDAP, and have OpenLDAP send us the
> plaintext password if it does the change.
Sounds like a good first step. One question, Microsoft already provides an
> On Wed, 2013-04-17 at 14:58 -0700, Howard Chu wrote:
>> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
>> and then it always slips by, but this time for sure.
>>
>> I'll keep this short - my colleagues at Symas want to know what it will take
>> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
>> recommended option, not just "yeah that should work but..." I've reviewed some
>> of the previous discussions on this topic in the archives, but I suspect some
>> of those points are now out of date.
>
> I've been thinking about ways we could better work with OpenLDAP, as I
> talk more and more with Samba users who can't just drop their existing
> configurations, or don't want to migrate their unix-like world to AD,
> even if provided by Samba.
>
> There are many tools to sync directories, and while I dislike that as a
> concept, they are part of the world we work in. What they generally
> miss is a good way to handle passwords, and there is where I thought we
> might be able to make some positive progress.
>
> In particular, I'm wondering about having Samba sync either the
> plaintext password (when sent to us during a password change) or an
> appropriate password hash to OpenLDAP, and have OpenLDAP send us the
> plaintext password if it does the change.
agent that runs on AD DCs to export password modifications (to a corresponding
Unix listener). Should we use the same protocol as this agent? I've looked at
it a few times, and thought about implementing the listener directly in slapd.
Andrew Bartlett
May 20, 2013, 6:23:25 PM5/20/13
to
in situations where we have a mix of Samba and Windows AD, or pure
Windows AD. It certainly would be very useful to have Samba implement
the Windows half of the protocol, as folks do ask for this feature
often.
I'm actually particularly keen on my second proposal, because it doesn't
need an 'all change' to get the passwords out, doesn't need all DCs that
could change the password to run it, and if the domain is recent enough,
and a failure can be fixed by just re-reading the AD directory.
Andrew Bartlett
May 21, 2013, 8:07:07 PM5/21/13
to
On Wed, 2013-04-17 at 14:58 -0700, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
> and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it will take
> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
> recommended option, not just "yeah that should work but..." I've reviewed some
> of the previous discussions on this topic in the archives, but I suspect some
> of those points are now out of date.
>
> I recall that we need to implement LDAP Transaction support, but of course
> Hey there list, Andrew... I keep meaning to have this discussion with Andrew
> and then it always slips by, but this time for sure.
>
> I'll keep this short - my colleagues at Symas want to know what it will take
> to bring OpenLDAP up to date to be usable directly by Samba as a first-class
> recommended option, not just "yeah that should work but..." I've reviewed some
> of the previous discussions on this topic in the archives, but I suspect some
> of those points are now out of date.
>
> that's just one of many missing features. Also, are there developers on the
> Samba team who can spend some time with us to make sure that what we write
> actually fits with how Samba uses things?
Just looping back to the top, to fill the list in.
I've just had a great chat with Howard about his plans. He is well
aware of the limitations, and why we didn't proceed with this. I tried
valiantly to dissuade him, but he remains as keen as ever! :-)
The difference this time is that where before we asked for small changes
in OpenLDAP and tried to make it work as much as we could, Howard and
Symas is qualified to bring a chainsaw to the OpenLDAP side to add in
any an all hooks that an integrated solution might need.
For example, he seems open to having OpenLDAP use gensec rather than
re-implementing that via raw GSSAPI or SASL. That safes him a bunch of
work and pain, and means any eventual system will be internally
consistent for authentication.
I'm sure this work will require changes on the Samba side too, but we
have had this almost work once before, and Symas proposes to apply
significant qualified resources to both the Samba and OpenLDAP sides, so
there is hope.
I still only give Howard and Symas a 50/50 chance of succeeding, but he
is incredibly keen to give this a try, and while I retain my
reservations I will do my best not to get in their way.
(And if you feel an urge to take on this kind of challenge, I'm sure
Symas is going to need some experienced Samba/C/LDAP engineers)
0 new messages