As a member of the Samba development team working on Samba4, I'm interested to try and gain some more integration with directory vendors, as we work out how our projects might work together.
I see Samba4 as a powerful addition to any directory or identity management solution, able to provide an AD Domain Controller-like front-end to Native windows clients. In particular, this is about deploying non-Microsoft directories on windows networks, without falling back to the 'MIT compatibility mode' or inter-realm trusts to handle the 'single sign on' and 'identity management part of it.
Samba4 is at this time able to act as an AD domain controller, including providing LDAP, Kerberos (including the PAC) and RPC logon services. We are accepted as AD by Win2k, WinXP and Win2k3 clients. (I am working on Mac/Samba/similar clients).
While Samba4 includes it's own LDAP server, we have made extensive provision to back our data onto something like Fedora Directory, but I want to work with fellow interested developers on the details: What would be reasonable for each end of the connection to do, particularly as we try and map behaviours/schemas/expectations.
Andrew Bartlett
Andrew Bartlett wrote:
While Samba4 includes it's own LDAP server, we have made extensive provision to back our data onto something like Fedora Directory, but I want to work with fellow interested developers on the details: What would be reasonable for each end of the connection to do, particularly as we try and map behaviours/schemas/expectations.
Hi Andrew!
What on earth made you all decide to write your own LDAP server when there are others available for free, which are already well tested and feature filled, as well as having plugin architectures (both FDS and OpenLDAP)? Just curious.
FDS has support for several types of plugins (pre-bind, post-bind, post-op, etc), and nearly all of the server's functionality is implemented with them. I am guessing that if Samba4 has special needs wrt behaviour from the LDAP server, then it's time to design and implement a "Samba 4 Plugin" for FDS (same things can be done for OpenLDAP, they are just called "overlays").
Plugin Programmers Guide:
http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html
I wrote an OpenLDAP -> FDS schema conversion tool and published it on the FDS wiki.
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
Feel free to include it in the examples/LDAP directory of Samba if you like.
BR, Mike
On Mon, 2005-11-07 at 15:12 +0200, Mike Jackson wrote:
Andrew Bartlett wrote:
While Samba4 includes it's own LDAP server, we have made extensive provision to back our data onto something like Fedora Directory, but I want to work with fellow interested developers on the details: What would be reasonable for each end of the connection to do, particularly as we try and map behaviours/schemas/expectations.
Hi Andrew!
What on earth made you all decide to write your own LDAP server when there are others available for free, which are already well tested and feature filled, as well as having plugin architectures (both FDS and OpenLDAP)? Just curious.
Samba has a long history of use of OpenLDAP as the standard backend behind Samba3 (of course any LDAP server would work, but OpenLDAP is what we documented, because it is free and included in most distributions). It caused us, and in particular our administrators a lot of pain, because of the separate configuration required.
In building Samba4 we looked at OpenLDAP (Fedora Directory was not Free Software at the time we started Samba4), and determined that while clearly possible, it would be very difficult to integrate into a single cohesive whole. (We know it is possible, because PADL's XAD is Samba3 +OpenLDAP+Proprietary bits, and it manages much of what Samba4's goals are)
We have some simple requirements on samba4: - Portable: Must, with a minimum of external libraries, build on a wide variety of unix and even non-unix platforms - Simple: Setup must be possible from the built-in web-based administration, as well as a single, simple config file. - Fast: Samba has always benefited from the speed of it's shared-memory databases. - Integrated: We needed consistent behaviour across the whole Samba4 suite of services. This included authentication in particular.
As such, we are not dependent on the administrator correctly configuring a backend directory on their platform correctly before we can even start, and we can self-configure those services.
More than all that however, we expected that we would have changes that we required that went beyond established plugin architectures, and as such could not afford to ship and maintain our own branch of OpenLDAP or indeed FDS.
Tridge then wrote ldb, and things ran from there...
FDS has support for several types of plugins (pre-bind, post-bind, post-op, etc), and nearly all of the server's functionality is implemented with them. I am guessing that if Samba4 has special needs wrt behaviour from the LDAP server, then it's time to design and implement a "Samba 4 Plugin" for FDS (same things can be done for OpenLDAP, they are just called "overlays").
So, the way I would like to have things work is to have Samba4 handle the details about authenticating users, perhaps much of the cn=configuration subtree, and suchlike. The backend LDAP server (such as FDS) might then handle the actual user and server entries, possibly not even in the same structure as Samba4 presents to windows clients.
Somewhere in there we would probably need schema translation (I presume an administrator choosing to run Samba4 against a backend LDAP would not want to be using the AD schema), as well the implementation of operational attributes etc. (There are quite a few of these, which we are just starting on now).
Another little detail that gets quite messy is NT ACLs on entries. We could evaluate these either in Samba4 (and act on the backend as a privileged user) or we might need to put that into another plugin.
Plugin Programmers Guide:
http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html
I wrote an OpenLDAP -> FDS schema conversion tool and published it on the FDS wiki.
http://www.directory.fedora.redhat.com/download/ol-schema-migrate.pl
Feel free to include it in the examples/LDAP directory of Samba if you like.
I'll take a look.
Andrew Bartlett
Hello. Sorry I haven't replied earlier - we have a major release coming up. I think we chatted several months ago.
FDS is also committed to working with Windows. We have our Windows Sync utility which uses DirSync to get the changes from Windows, and we use a replication changelog to push the changes from FDS to Windows using plain old ldap. For passwords, we have a password sync "plug-in" on windows that intercepts the plain text passwords and sends them to FDS. While the Windows Sync feature works ok, it's not perfect: 1) Relies on DirSync which up until recently was not a published spec (if you know where I can get the spec, I would be grateful) 2) Doesn't sync everything - some groups on AD are "virtual" e.g. the DomainUsers group - groups defined within the replicated suffix can have members outside of that sufffix - no support for schema changes (although we could just read the schema over LDAP as well, but that's a lot more work) 3) Is hard to set up - people seem to have a devil of a time figuring out things that the AD interface "hides" from you, like the DN of the domain administrator and things like that 4) No support for password policy and group policy - this will be hard to do
You guys seem to have solved 1 and 2. 3 I'll withhold judgement on :-)
So I think we still need to exchange data between Samba4 and FDS. We were trying to figure out how to solve 4 - we need to figure out a way to have a common consistent password policy across PAM, LDAP, Kerberos, and Windows. For Windows, we were going to try to figure out how to add that information to the sync protocol. For Kerberos, I don't know if you can get that information via gssapi, so we were going to try to use Heimdal and replace the backend (I think new versions of MIT Kerberos allow you to more easily plug-in another database backend).
So I guess there are a few ways for Samba4 and FDS to work together: 1) Use WinSync between Samba4 and FDS 2) Use some other protocol (FDS multi master repl? LCUP? LDAPSync? others?) 3) Configure Samba4 to use FDS as it's database Other ways? I'm certainly open to suggestions.
Andrew Bartlett wrote:
As a member of the Samba development team working on Samba4, I'm interested to try and gain some more integration with directory vendors, as we work out how our projects might work together.
I see Samba4 as a powerful addition to any directory or identity management solution, able to provide an AD Domain Controller-like front-end to Native windows clients. In particular, this is about deploying non-Microsoft directories on windows networks, without falling back to the 'MIT compatibility mode' or inter-realm trusts to handle the 'single sign on' and 'identity management part of it.
Samba4 is at this time able to act as an AD domain controller, including providing LDAP, Kerberos (including the PAC) and RPC logon services. We are accepted as AD by Win2k, WinXP and Win2k3 clients. (I am working on Mac/Samba/similar clients).
While Samba4 includes it's own LDAP server, we have made extensive provision to back our data onto something like Fedora Directory, but I want to work with fellow interested developers on the details: What would be reasonable for each end of the connection to do, particularly as we try and map behaviours/schemas/expectations.
Andrew Bartlett
-- Fedora-directory-devel mailing list Fedora-directory-devel@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel
On Mon, 2005-11-07 at 21:12 -0700, Richard Megginson wrote:
Hello. Sorry I haven't replied earlier - we have a major release coming up. I think we chatted several months ago.
FDS is also committed to working with Windows. We have our Windows Sync utility which uses DirSync to get the changes from Windows, and we use a replication changelog to push the changes from FDS to Windows using plain old ldap. For passwords, we have a password sync "plug-in" on windows that intercepts the plain text passwords and sends them to FDS. While the Windows Sync feature works ok, it's not perfect:
- Relies on DirSync which up until recently was not a published spec
(if you know where I can get the spec, I would be grateful) 2) Doesn't sync everything - some groups on AD are "virtual" e.g. the DomainUsers group - groups defined within the replicated suffix can have members outside of that sufffix - no support for schema changes (although we could just read the schema over LDAP as well, but that's a lot more work)
We are making good progress on DRSUAPI synchronisation, but the best sync AD -> Samba4 at the moment is the old netlogon, where we get the NT password hashes.
- Is hard to set up - people seem to have a devil of a time figuring
out things that the AD interface "hides" from you, like the DN of the domain administrator and things like that
That really shouldn't be anything more than an ldapsearch or a DsCracknames call on an autoconfiguration tool. (Samba4 has a DsCrackNames client, which makes things easier :-)
- No support for password policy and group policy - this will be hard to do
We don't have these either yet, but neither looks too hard...
You guys seem to have solved 1 and 2. 3 I'll withhold judgement on :-)
So I think we still need to exchange data between Samba4 and FDS. We were trying to figure out how to solve 4 - we need to figure out a way to have a common consistent password policy across PAM, LDAP, Kerberos, and Windows. For Windows, we were going to try to figure out how to add that information to the sync protocol. For Kerberos, I don't know if you can get that information via gssapi, so we were going to try to use Heimdal and replace the backend (I think new versions of MIT Kerberos allow you to more easily plug-in another database backend).
Heimdal does have a good LDAP backend, and it is the hdb layer that I have extended to build us the Samba4 KDC. (This is shipped 'in' Samba4, and is linked into the main binary, reads the main database by default etc).
So I guess there are a few ways for Samba4 and FDS to work together:
- Use WinSync between Samba4 and FDS
If it is a windows interface, then we should eventually support it, but it's not the way I want to crack this particular nut.
- Use some other protocol (FDS multi master repl? LCUP? LDAPSync?
others?)
Messy, but possible.
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I want Samba4 to use FDS as much as possible. We can then provide KDC and Windows Domain services on top of your database.
Andrew Bartlett
Andrew Bartlett wrote:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I want Samba4 to use FDS as much as possible. We can then provide KDC and Windows Domain services on top of your database.
That would be our choice as well. So how would this work? Samba would not use its built-in database, but would use FDS? And use LDAP as the interface? I think you mentioned something about ldb - is that an "ldap backend"? One thing to keep in mind is that we do not yet have support for ldapi, but I don't think it would be hard to add.
Andrew Bartlett
-- Fedora-directory-devel mailing list Fedora-directory-devel@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel
On Tue, 2005-11-08 at 19:33 -0700, Richard Megginson wrote:
Andrew Bartlett wrote:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I want Samba4 to use FDS as much as possible. We can then provide KDC and Windows Domain services on top of your database.
That would be our choice as well. So how would this work? Samba would not use its built-in database, but would use FDS? And use LDAP as the interface?
Yes. Indeed at a very conceptual level it would be much as Samba3 can use FDS now.
I think you mentioned something about ldb - is that an "ldap backend"?
ldb is two things: It is a tdb-based flat-file database with ldap properties, and it is a LDAP client implementation behind the same interface. As such, we can in theory direct any database to be backed either by LDAP (with some very large assumptions about the layout of the ldap server, and it's behaviour) or the flat file.
The work to be done here is to define those assumptions, and determine which side of the LDAP socket should modify the queries to make the other side's job easier.
One thing to keep in mind is that we do not yet have support for ldapi, but I don't think it would be hard to add.
Actually, neither does Samba4 (we switched from openldap client libs to our own, so lost that as well). It would be very worthwhile adding to both.
Andrew Bartlett
Andrew Bartlett wrote:
On Tue, 2005-11-08 at 19:33 -0700, Richard Megginson wrote:
Andrew Bartlett wrote:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I want Samba4 to use FDS as much as possible. We can then provide KDC and Windows Domain services on top of your database.
That would be our choice as well. So how would this work? Samba would not use its built-in database, but would use FDS? And use LDAP as the interface?
Yes. Indeed at a very conceptual level it would be much as Samba3 can use FDS now.
I think you mentioned something about ldb - is that an "ldap backend"?
ldb is two things: It is a tdb-based flat-file database with ldap properties, and it is a LDAP client implementation behind the same interface. As such, we can in theory direct any database to be backed either by LDAP (with some very large assumptions about the layout of the ldap server, and it's behaviour) or the flat file.
The work to be done here is to define those assumptions, and determine which side of the LDAP socket should modify the queries to make the other side's job easier.
Based upon your and Pete's recent emails, it seems that the schema/DIT translation would have to be done on the Samba side. That is, it doesn't sound like an LDAPv3 compliant server would be able to handle the "raw" LDAP from a Windows client. Perhaps as an ldb "plug-in"? That is, Samba would have to map the outgoing (to FDS or other ldap server) attributes/objectclasses to the more standard LDAP IETF ones. Is this something you guys already have, or does ldb already do this? Is this some code you would like some assistance with?
One thing to keep in mind is that we do not yet have support for ldapi, but I don't think it would be hard to add.
Actually, neither does Samba4 (we switched from openldap client libs to our own, so lost that as well). It would be very worthwhile adding to both.
Andrew Bartlett
-- Fedora-directory-devel mailing list Fedora-directory-devel@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel
On Wed, 2005-11-09 at 18:21 -0700, Richard Megginson wrote:
Andrew Bartlett wrote:
On Tue, 2005-11-08 at 19:33 -0700, Richard Megginson wrote:
I think you mentioned something about ldb - is that an "ldap backend"?
ldb is two things: It is a tdb-based flat-file database with ldap properties, and it is a LDAP client implementation behind the same interface. As such, we can in theory direct any database to be backed either by LDAP (with some very large assumptions about the layout of the ldap server, and it's behaviour) or the flat file.
The work to be done here is to define those assumptions, and determine which side of the LDAP socket should modify the queries to make the other side's job easier.
Based upon your and Pete's recent emails, it seems that the schema/DIT translation would have to be done on the Samba side.
Most of it, certainly. I expect that the eventual solution will be a bit of both, because some things will need to be in the data store, and other things will just be too expensive to handle on Samba's side. But basically, that is correct.
The main issue is in transactions for the write operations: Do you have transactions? A number of the operations we do imply changes across multiple records, so if Samba was to handle it, it would need to have a transaction. If FDS was to handle it, we would need to write a module there.
That is, it doesn't sound like an LDAPv3 compliant server would be able to handle the "raw" LDAP from a Windows client. Perhaps as an ldb "plug-in"? That is, Samba would have to map the outgoing (to FDS or other ldap server) attributes/objectclasses to the more standard LDAP IETF ones.
Exactly.
Is this something you guys already have, or does ldb already do this? Is this some code you would like some assistance with?
ldb has a good modules layer, for doing exactly this. We of course need help in the implementation of modules, and in everything else (we are a very small team on Samba4, and could certainly do with assistance from those with more of an LDAP background).
Andrew Bartlett
Em Terça 08 Novembro 2005 08:34, Andrew Bartlett escreveu:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I
You have lost me here. Why do you want FDS as your database and not, say, openldap? And what happened to the internal ldap server in samba4?
On Wed, 2005-11-09 at 21:22 -0200, Andreas Hasenack wrote:
Em Terça 08 Novembro 2005 08:34, Andrew Bartlett escreveu:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I
You have lost me here. Why do you want FDS as your database and not, say, openldap? And what happened to the internal ldap server in samba4?
So, Samba4's LDAP server is what will need to be seen by windows clients, as they have very, very specific requirements, not met by any existing free solutions.
However, Samba has the need for backend storage of it's data, and this can either be in a local flat file, or in *another* LDAP server. My hope is that this would allow Samba to be a front-end to a larger organisational directory, which is where I see FDS fitting in.
(I've not discussed OpenLDAP in this context yet, but no doubt I will have similar discussions with interested people on that team at some point).
Andrew Bartlett
Andrew Bartlett wrote:
On Wed, 2005-11-09 at 21:22 -0200, Andreas Hasenack wrote:
Em Terça 08 Novembro 2005 08:34, Andrew Bartlett escreveu:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I
You have lost me here. Why do you want FDS as your database and not, say, openldap? And what happened to the internal ldap server in samba4?
So, Samba4's LDAP server is what will need to be seen by windows clients, as they have very, very specific requirements, not met by any existing free solutions.
However, Samba has the need for backend storage of it's data, and this can either be in a local flat file, or in *another* LDAP server. My hope is that this would allow Samba to be a front-end to a larger organisational directory, which is where I see FDS fitting in.
(I've not discussed OpenLDAP in this context yet, but no doubt I will have similar discussions with interested people on that team at some point).
So, if I understand this well, for a fully integrated solution, you are going to have 2 LDAP servers, one is the internal built-in LDAP server for storing Windows client stuff, and a second LDAP server (FDS in this case), for everything.
If that's the case, why can't you come up with a schema (that can be added into any standard LDAP server) that will satisfy all Windows client needs, and put everything into FDS?
I'm lost too.
rgds
csp
-----Original Message----- From: fedora-directory-devel-bounces@redhat.com [mailto:fedora-directory-devel-bounces@redhat.com] On Behalf Of Chen Shaopeng Sent: Wednesday, November 09, 2005 4:22 PM To: Fedora Directory server developer discussion. Subject: Re: [Fedora-directory-devel] Fedora Directory and Samba4
So, if I understand this well, for a fully integrated solution, you are going to have 2 LDAP servers, one is the internal built-in LDAP server for storing Windows client stuff, and a second LDAP server (FDS in this case), for everything.
Actually I read that to mean they have a simple ldap db implementation which can also act as a proxy onto another ldap server _instead_ of storing things locally. Much like FDS can be made to proxy onto another ldap server.
If that's the case, why can't you come up with a schema (that can be added into any standard LDAP server) that will satisfy all Windows client needs, and put everything into FDS?
That would work perfectly if Active Directory acted like a perfect LDAP server. Unfortunately there are so many quirks and oddities* that I imagine the Samba team feel they need to support because AD clients will expect them to. I am not privvy to how closely the Samba team want to mimic AD, but even for some of the simpler things the question is: is it better to put it in the LDAP server where certain efficiencies can be obtained but limit your ability to server hop, or do you try to make any LDAP server look like AD from the proxy client side and pay the additional performance costs. Or perhaps there is middle ground. I suspect it is this that Andrew wishes to explore.
*a simple example: most LDAP servers will index the objectclass attribute by default to enable fast searching, AD however does not index objectclass, and further supplies a proprietary attribute (objectcategory) that performs exactly the same function as objectclass (in its entry class distinguishing capacity**), but works slightly differently (i.e. has weird matching rules) and _is_ indexed by default. If you are targetting AD for your client application which would you choose to use? Which do you think MS clients use? Syntax and Matching rules plugins could be written for FDS, but they don't exist now and they represent a deployment obstacle.
**the entry class distinguishing capacity of the objectclass attribute is further diminished in AD because according to it, computers are people too.
Pete Rowley wrote:
Actually I read that to mean they have a simple ldap db implementation which can also act as a proxy onto another ldap server _instead_ of storing things locally. Much like FDS can be made to proxy onto another ldap server.
Ok, my bad.
If that's the case, why can't you come up with a schema (that can be added into any standard LDAP server) that will satisfy all Windows client needs, and put everything into FDS?
That would work perfectly if Active Directory acted like a perfect LDAP server. Unfortunately there are so many quirks and oddities* that I imagine the Samba team feel they need to support because AD clients will expect them to. I am not privvy to how closely the Samba team want to mimic AD, but even for some of the simpler things the question is: is it better to put it in the LDAP server where certain efficiencies can be obtained but limit your ability to server hop, or do you try to make any LDAP server look like AD from the proxy client side and pay the additional performance costs. Or perhaps there is middle ground. I suspect it is this that Andrew wishes to explore.
*a simple example: most LDAP servers will index the objectclass attribute by default to enable fast searching, AD however does not index objectclass, and further supplies a proprietary attribute (objectcategory) that performs exactly the same function as objectclass (in its entry class distinguishing capacity**), but works slightly differently (i.e. has weird matching rules) and _is_ indexed by default. If you are targetting AD for your client application which would you choose to use? Which do you think MS clients use? Syntax and Matching rules plugins could be written for FDS, but they don't exist now and they represent a deployment obstacle.
**the entry class distinguishing capacity of the objectclass attribute is further diminished in AD because according to it, computers are people too.
Ok, not too familiar with the internals of AD, so I may speak thru my behind here.
Since we already have a posixAccount, an ntUser, etc, isn't it possible to add something similar, with all the quirks and oddities for an AD user account, and with all the weird matching rules? And maybe with the help of a few plugins? Or is the Windows client requirements so convoluted that it is near darn impossible to achieve with the current FDS or OpenLDAP?
I just downloaded Andrew's thesis yesterday, didn't have time to read yet (will do over the weekend).
I'd really love to see Samba4 act as an AD, and be transparent to all clients.
*note to self: need to learn more about this issue*
rgds
csp
-----Original Message----- From: fedora-directory-devel-bounces@redhat.com [mailto:fedora-directory-devel-bounces@redhat.com] On Behalf Of Chen Shaopeng Sent: Wednesday, November 09, 2005 5:38 PM To: Fedora Directory server developer discussion. Subject: Re: [Fedora-directory-devel] Fedora Directory and Samba4
Since we already have a posixAccount, an ntUser, etc, isn't it possible to add something similar, with all the quirks and oddities for an AD user account, and with all the weird matching rules? And maybe with the help of a few plugins? Or is the Windows client requirements so convoluted that it is near darn impossible to achieve with the current FDS or OpenLDAP?
I wouldn't say it were impossible, and FDS is remarkably suited as a starting point given it's plugin architecture and virtual attribute capability, but it is certainly not trivial. I suspect also that it is undesireable to spend too much time making one ldap server look like AD, when samba could make all ldap servers look like ad, and use additional ldap server support for the task where it is available i.e. concentrate on the things that kill performance as a result of being a proxy.
I just downloaded Andrew's thesis yesterday, didn't have time to read yet (will do over the weekend).
I'd really love to see Samba4 act as an AD, and be transparent to all clients.
*note to self: need to learn more about this issue*
rgds
csp
Chen Shaopeng http://www.idsignet.com
On Thu, 2005-11-10 at 08:22 +0800, Chen Shaopeng wrote:
Andrew Bartlett wrote:
On Wed, 2005-11-09 at 21:22 -0200, Andreas Hasenack wrote:
Em Terça 08 Novembro 2005 08:34, Andrew Bartlett escreveu:
- Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I
You have lost me here. Why do you want FDS as your database and not, say, openldap? And what happened to the internal ldap server in samba4?
So, Samba4's LDAP server is what will need to be seen by windows clients, as they have very, very specific requirements, not met by any existing free solutions.
However, Samba has the need for backend storage of it's data, and this can either be in a local flat file, or in *another* LDAP server. My hope is that this would allow Samba to be a front-end to a larger organisational directory, which is where I see FDS fitting in.
(I've not discussed OpenLDAP in this context yet, but no doubt I will have similar discussions with interested people on that team at some point).
So, if I understand this well, for a fully integrated solution, you are going to have 2 LDAP servers, one is the internal built-in LDAP server for storing Windows client stuff, and a second LDAP server (FDS in this case), for everything.
I'm not really talking about storage (but no doubt some data will be stored in samba-specific databases). A better expression would be 'filter for windows client stuff'. In an all-windows environment, only Samba would receive LDAP traffic, and pass it on to FDS in some form. In a mixed environment, both would listen (on different IPs naturally) and would give differently formatted answers to similar questions, to suit each respective client.
If that's the case, why can't you come up with a schema (that can be added into any standard LDAP server) that will satisfy all Windows client needs, and put everything into FDS?
Sure, and we know it is possible to build such a schema, and all the plugins (XAD has done so on OpenLDAP). But I wonder what would be the point. Why not just run windows, or Samba4 without a backend? Or the current messy sync scripts with real AD?
Unfortunately, I understand the schema windows uses is directly incompatible with IETF standards (they modified top) and the required plugins are fairly extensive.
I expect that those who have chosen FDS (or indeed any other backend) would have done so because they like to control their directories. I want Samba4 to enable that.
Andrew Bartlett
389-devel@lists.fedoraproject.org
-
Andreas Hasenack -
Andrew Bartlett -
Chen Shaopeng -
David Boreham -
Mike Jackson -
Pete Rowley -
Rich Megginson