FAQ

The questions and answers on this page have been extracted from the Samba technical mailing list.

General

Can I use Samba 4.0 as an AD DC on my production server right now?

We have now released Samba 4.0, and a number of users have it in use in a production environment. All the features from the Samba 3.6 series are now available, for example, the file server in the smbd binary.

Of course, normal Systems Administration caution is generally advised, as an AD Domain is the central hub for authentication on a network, as is participation on our mailing lists to discuss any issues that arise.

We do however encourage people to try Samba 4.0 as an AD DC, report bugs, and give feedback.

When will Samba 4.0 releases be made?

For the current Samba 4.0 and 4.x release plans, please see Samba Release Planning.

How to do or fix ... in an outdated Samba version?

Often people are asking for help/support for very outdated versions on the mailing lists or other places. You should really consider of moving to a recent version (best would be to the latest version of the current series). Every release of Samba improves its features, fix many bugs and add more compatibility. In many cases the problems, people are having with their old versions, doesn't exist any more in the meantime. Also you have a much better chance to get responses by other users and developers on the mailing lists, etc.

If you are required to run an outdated version, that was shipped with your distributation but which is out of the maintainance by Samba, you should contact your vendor (Redhat, SuSE, etc.) for support.

See the Samba Release Planning page to get an overview, which versions are still maintainanced.

Replication

Is directory replication supported by a Samba AD DC?

Yes. Everything that is done inside the directory (user/group management, ACL changes, etc.), is replicated to other DC.

Is SysVol share replication supported by a Samba AD DC?

It's currently not implemented. But as workaround you can replicate changes e. g. with rsync. Depending on the kind of workaround you choose, you maybe have to do changes only on one DC, if your tool doesn't support bi-directional replication.

How do I get DNS failover in a Multi-DC environment?

• First you setup your additional DC according to the Samba AD DC HowTo. You just skip the provisioning/upgrading part.

• Then join your new DC to the domain. See Join Samba as an additional DC.

• In the output of "samba-tool drs showrepl" you can see, that the DNS partition is replicated too, if everything was successfull.

• At last you have to configure your clients to use the DNS on that additional DC, of course.

Trusts

Does Samba support trust relationship with AD?

Trusts are currently not finished implemented. Samba can be trusted, but can't trust yet.

GPO

Is it possible to set user specific password policies in Samba4 (e. g. on a OU-base)?

Samba can't handle GPO restrictions. You have to use 'samba-tool domain passwordsettings' to change password policies. But this only applies on domain level.

Background: The password settings have to be used and validated by the server. Otherwise a modified Windows client or a Unix client (which doesn't handle GPOs) could bypass these settings. But Samba can't evaluate and apply GPO restrictions. It only serves GPOs via the SysVol share.

LDAP backend

Will Samba 4 have a built-in, full fledged LDAP server?

Yes. While we certainly won't compare ourselves with the standards-based products from other vendors (our aim is to please AD clients first, and hopefully do so while complying with the standards), it will include an LDAPv3 server.

Why is the LDAP backend (used so successfully in classic Samba domains) not supported with the AD DC?

We certainly appreciate the bind that the LDAP server situation puts our administrators in. We went to great lengths to try and avoid this, but were unable to make it work, while also supporting features such as DRS replication, and many of the finer points of AD's LDAP server. The biggest killer for the feature was the need for runtime schema translation, or for the administrator to load the AD schema and layout on their external LDAP server (which rather defeats the purpose).

The there are three ways out of this difficult situation

• continue to use Samba as a 'classic' domain controller as-is using smbd/nmbd (this code remains and remains supported).
• Add schema extensions to our LDAP server (disabled by default, but supported), and cope with the AD-specified layout restrictions.
• Somehow sync Samba with an existing LDAP server.

There are major challenges with synchronisation of directories - but it certainly may be an option in some situations.

We certainly understand that it appears almost rude, on the face of it, to step up from being an equal partner in the unix-LDAP ecosystem supporting a number of different directory servers to demanding that everyone else use only our internal server. We do wish it didn't have to be this way, and we have left in (with tests) as much of the code we used for the LDAP backend experiment as is possible, in case somehow someone builds a workable use case in the future.

Is it planned to support openLDAP as backend again?

An LDAP backend to the AD DC is not a viable proposition at this point in time, as even with the addition of massive extra resources trying to revive it would create an incredible distraction.

The biggest issue is that a significant part of the complexity of the AD DC turns out to be in our ldb modules. Creating a general-purpose, OpenLDAP backed AD DC would involve rewriting many of these modules as OpenLDAP overlays, outside the standard Samba programming environment.

Totally removing the LDAP listener would require rewriting even more code than that, and would (based on the past experience of Luke Howard's XAD) require extensive patches to OpenLDAP.

Specific issues include the metadata required for both DRS replication and dirsync, schema manipulation, transactions, Access Control Lists, impersonation (if Samba still operated as an LDAP proxy) or authentication (if OpenLDAP was the LDAP listener) and AD-specific matching rules.

The components of LDAP that are left unaltered, after all this is done, are actually the easy bits, as is seen by the relative simplicity of ldb itself.

Finally, as mentioned in the previous question, even if this was all done, the schema would still be the AD schema, which removes the advantage of doing all that work in the first place.

The team has decided not to peruse this as a development avenue, and no viable approach to re-opening this functionality has been proposed, but where it does not compromise development, the technical doors open for some special case development here have been left open, with code and tests remaining in the tree.

Schemas

Will it also be possible in the future to extend the server by loading user defined schema's?

Yes, user-defined schema may be loaded into the Samba 4.0 AD DC. It is experimental, so you must set

dsdb:schema update allowed = yes

in the smb.conf to permit it.