Should we keep the Samba4 LDAP backend?

Fri Apr 1 04:47:08 MDT 2011

On 01/04/2011 13:54, Tomasz Czapiewski wrote:
> On Fri, 1 Apr 2011, Andrew Bartlett wrote:
>
>> On Fri, 2011-04-01 at 12:55 +0400, Gennady G. Marchenko wrote:
>>> Andrew!
>>>
>>>     I think  ldap backend in Samba4 must be kept. There are many a
>>> priceless features that supported by openldap and users can use it
>>> transparently (many type of TRANSPARENT replication, integration of 
>>> many
>>> services (company's internal too) in one LDAP entry and more and more)
>>> without changing code of high level application (such as samba4).
>>>
>>> I planned to move all deployed application from smb3->smb4 and I will
>>> fail that at all (!) if you remove ldap backend from samba4 :( I don't
>>> think I am here alone.
>>
>> I should be clear, because I think there is some confusion.  There are
>> some important facts here:
>> - The Samba4 LDAP backend never worked.  It looked like it might work,
>> but there were always problems, things that could not be easily
>> supported.
>> - The Samba4 LDAP backend was unsafe.  Samba4 relies on having
>> transaction support in it's backend database.  The LDAP backend just
>> bluffed and ignored that.
>> - The Samba4 LDAP backend never used the same schema as Samba3 or
>> typical LDAP installations, so a direct migration has never been
>> possible (it uses the AD schema).  Attempts to write mapping backends
>> between samba3 and Samba4/AD failed (Red Hat made a serious attempt).
>> - Samba4 will always provide it's own LDAP server, as is required to be
>> an AD server, and will provide that on port 389 as normal.  The LDAP
>> backend was never directly able to be accessed by clients, so no plan to
>> use or not use Samba4 should be impacted by this.
>>
>> I know OpenLDAP and Fedora DS/389 are great LDAP servers, but they are
>> not well suited to being AD-like LDAP servers in the modal Samba4 uses
>> because they don't support key features like AD-interoperable
>> replication.
>>
>> Andrew Bartlett
>>
>
> Could you help me understand what can or can't be done using LDB 
> backend of Samba4?
>
> I've post mail with question if my plan is possible to achieve using 
> Samba4. I'll quote it at the end of this email.
> I have probably misunderstood LDAP vs LDB backend naming.
Basically LDB is a LDAP like database, that is useful for answering LDAP 
request or even for internal querying of the database (you write your 
query like LDAP queries more or less).
Then LDB can use different backend to store this information (sqlite 
databases, tdb files, LDAP, ...). Why we started to use LDAP as a 
backend was the capacity to have replication for free as openldap and 
389 LDAP both support them. The LDAP backend was a kind of embedded LDAP 
server dedicated to samba4 needs for data storage.

> Could you answer me what of these could be done using LDAP or LDB 
> backends? What can't be done if you'll drop LDAP backend?
To my mind there is no LDB backend, it's a TDB backend for storing LDB 
data, the confusion comes that this TDB files (see 
http://en.wikipedia.org/wiki/Tdb and http://tdb.samba.org for more 
information).
What can't be done: nothing but more and more confusion as people who 
have something on openldap or 389ldap and read that samba4 support those 
backend thinks that "oh well I can samba as a domain controller to my 
LDAP and keep my specific schema and application working, it's LDAP 
after all".

> (other services, like dhcp, dns, mail, jabber are as much important as 
> Samba is and it's integration would be great)
So Samba4 provide a LDAP server in all the case whatever the backend you 
use, the important thing to understand is that the base schema is the 
schema of Active Directory that can be not compatible with your current 
schema or with the schema.

So if your schema is compatible you can do it, if not you can't. As 
Microsoft as diverted a bit from the standard their is some attributes 
that are in conflict (same OID but different attribute name, for instance).
For information I do all my mail aliasing and virtual mailbox 
translation with samba4 and postfix and without any modification of the 
schema. So it should be possible, I never tried to do Bind-sdb with 
samba4, it could be worth trying it.
Quote mail from Feb 16 2011:
> -------------------------------------------------------------------------
> Subject: Samba4 Alpha 15 as LDAP server authentication for other services
>
> Hi,
> I'm planning to use Samba Alpha 15 not only for Active Directory but 
> extend it's schema for use it's backend for other services like:
> a) hardware:
> - switches that have option for LDAP (getting MAC addresses of 
> machines and set them to VLANs),
> - UTM that has both LDAP and AD options (here it would be both users 
> and machines for network access),
> - network printers with LDAP or AD usage options (for binding access 
> to specific users, not important to have that),
> - network scanners with LDAP usage option (not sure if I need it),
Does it need a specific schema, have you seen that this schema is 
working on a MS AD server if so then it will work with samba, if you 
don't know well provision your samba server and try to apply your 
schema, if it works then it should work (we might have bugs but they can 
be fixed).
> b) software:
> - Postfix and Cyrus as mail server (authenticate users and get/set 
> their e-mail adresses) [top priority],
What do you mean by setting email address ?
I use Samba4 with Cyrus and support the following configuration:

sasl_mech_list: GSSAPI PLAIN LOGIN

Basically it's saslauthd that works for cyrus, saslauthd is configured 
for using pam and kerberos and pam use kerberos (strange logic I don't 
remember why it's like this, as far as I remember the standalone 
kerberos mode is for supporting the case when you are doing GSSAPI and 
the kerberos via PAM for the LOGIN or PLAIN mode) .

Postfix use also saslauthd with the same configuration but with another 
instance of saslauthd so that the socket is not the same.
> - Squid proxy server (access for AD users, to track sites visited by 
> users),
Works but not on the same server as the active directory because s4's 
ntlm_auth didn't work correctly so far.
> - ejabberd Jabber server (users and passwords) [top priority],
Don't know but is ejabberd using pam ?
> - Bind9 DNS server (network names for workstations and site domain, 
> site domain might be outside in typical bind config and delegation files)
Not sure I understand the question, but you can configure bind so that 
either the workstation updates it's forward and reverse zone or the DHCP 
server do it (interim mode).
> - DHCP server (MACs for machines and some options for network boot, 
> might be outside of AD in case of problems(?))
>
Works, it's not stored in the LDAP (in Microsoft AD it's not too).
> As for AD, I'll have PCs with Windows XP and Windows 7 workstations 
> and I need:
> - GPO [top priority]
Works
> - roaming profiles with registry, Desktop, Documents, application 
> settings keept on server, without storing files on workstation disks, 
> [top priority],
Works but replication don't so you have to setup your own (csync, rsync 
are your friend).
> - only network printers, no need to share printers by workstations or 
> server, [top priority for using network printers by direct connections 
> to their IPs
> at 9100 port]
> - block USB storage driver for workstations
GPO
> - enforce proxy settings
GPO, or configuration files for firefox and opera (don't know for more 
exotic like chrome or safari).
>
> I have few Linux servers and workstations, too that I might connect to 
> LDAP of Samba4, but that's not a priority now.
Configure samba3's winbind server on them.

> I've read wiki info about different backends like OpenLDAP or 
> Fedora_DS and it's restrictions...
> But what about Samba4 builtin LDAP backend? Would such configuration 
> work now on it?
> How does builtin LDAP backend now behave when extending it's schema 
> for other services?
> Can I achieve it with Samba4 at current state?
>
> As for password for other services, it's not necessary to use Samba4 
> AD paswords, such passwords might be created at profile creating using 
> scripts, but
> only need to bind them to AD users objects.
I don't think it's a problem but be careful on how it's stored in the AD.

HTH
Matthieu.
-- 

Matthieu Patou
Samba Team        http://samba.org
Private repo      http://git.samba.org/?p=mat/samba.git;a=summary