Joining a Samba DC to an Existing Active Directory: Difference between revisions

From SambaWiki
m (Change link)
m (Add UID/GID Sync for AD DC)
Line 183: Line 183:
An example way how to achieve this, you can find in the [[SysVol_Replication|SysVol Replication Howto]].
An example way how to achieve this, you can find in the [[SysVol_Replication|SysVol Replication Howto]].

== Note if you AD DC is Samba ==

There are UID/GID issue for the built-in Users/Groups on sysvol when our DC are Samba
As we have yet a method to replicate the UID/GID from the existing Samba DC.
Please try the following

# Stop All Samba AD DC
# copy the /var/lib/samba/private/idmap.ldb to the new Samba AD DC
# restart Samba AD DC

== Report your success/failure! ==
== Report your success/failure! ==

Revision as of 17:56, 2 October 2014

Samba4 joining a domain as a DC

As of Samba4 alpha11, Samba4 has the ability to join an existing Active Directory domain as an additional domain controller. The process of joining a Samba4 server to an existing domain is a bit different to provisioning a new domain. This process is the equivalent of the 'dcpromo' command on Windows servers.

This HOWTO will assume you had configured and installed Samba in the default location of /usr/local/samba. It assumes you are joining Samba to an existing domain called ''.

Please note that the following steps are the same regardless of whether you are joining Samba to an existing Windows based domain or an existing Samba based domain.

Getting ready for joining Samba as a DC to an existing domain

  • You need to install Samba as a DC, as described in the Samba AD DC HowTo, but don't do the provision/classicupgrade step. If you choose BIND as DNS backend, instead of the internal DNS, then you, of course, have to finish this before you continue. Depending on your needs, you can have different backends on each of your DC.
  • You should remove any existing smb.conf in /usr/local/samba/etc/.
  • Be sure, that you have your setup your existing domain correctly as your default realm in /etc/krb5.conf with the following options:
 dns_lookup_realm = true
 dns_lookup_kdc = true
 default_realm = SAMDOM.EXAMPLE.COM
  • You should then test to make sure that DNS and kerberos are setup correctly to point at your existing domain controller. Test that it is all working by trying a kinit as a domain administration:
# kinit administrator
Password: XXXXXXXX
  • klist should should give you an output like the following:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal:

Valid starting     Expires            Service principal
11/11/12 17:29:51  11/12/12 03:29:51  krbtgt/
       renew until 11/12/12 17:29:49
  • Once all that is setup you can move on to the join domain step.

Joining the existing domain as a DC

  • Make sure, that your /etc/resolv.conf contains at least one „nameserver“ entry, pointing to a DNS, that can resolve your Samba AD zone(s). Example:
  • Run the following command as root:
# bin/samba-tool domain join DC -Uadministrator
Since samba4 rc2 the internal DNS server is default. If you want to join this or a higher version with using BIND as DNS backend, use the following command:
# bin/samba-tool domain join DC -Uadministrator --dns-backend=BIND9_DLZ
  • During the join, you should see a set of debug messages about replicating the domains content, like this:
Partition[CN=Configuration,DC=samba,DC=example,DC=com] objects[1614/1614] linked_values[28/0]
  • At the end, you will see a message like this:
Joined domain SAMBA (SID S-1-5-21-3565189888-2228146013-2029845409) as a DC
  • Now you have joined your Samba4 server to your existing domain.

Check required DNS entries of the new host

  • Before you start samba, you should check, if the new DCs DNS entries are set correctly during joining. This doesn't currently work 100% and have to be done manually in that case.
  • From the new host, try to resolve its hostname:
# host -t A
If this fails, you have to add the A record by hand. Run on your existing DC:
# samba-tool dns add IP-of-your-DNS-server DC2 A IP-of-the-DC-you-had-joined -Uadministrator
  • Also you should check, if the objectGUID is resolvable to the new hostname. For that, run
# ldbsearch -H /usr/local/samba/private/sam.ldb '(invocationid=*)' --cross-ncs objectguid
to find out the objectGUID of the new server. The command should give you an output like
# record 1
dn: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samba,DC=example,DC=com
objectGUID: 737506d0-bfe6-40c8-815d-08c3dff7a67f
In this case, 737506d0-bfe6-40c8-815d-08c3dff7a67f is the objectGUID of the new DC, we'll query with the following command:
# host -t CNAME
This should output you the alias (CNAME) of this entry pointing to your new DC name.
If this record is also missing, you have to add it, too:
# samba-tool dns add IP-of-your-DNS 737506d0-bfe6-40c8-815d-08c3dff7a67f CNAME -Uadministrator
If you are running BIND as DNS backend and still can't resolve the new added DNS entries, see BIND DNS backend: New added DNS entries are not resolvable.
  • Now it's time to put a „nameserver“ entry of your new DC in your /etc/resolv.conf (if you don't have joined the new DC with „--dns-backend=none“). Example:

It should be noted that although DNS replication is active, additional DNS configurations such as forwarders are not copied. See Configure DNS for more details.

Starting Samba

You start samba as a DC in the same way that you start it as a normal server, just run the command 'samba' from the sbin directory of your installation.

When you first start Samba as a new DC in an existing Windows domain, you may find errors messages like these in the samba log file:

UpdateRefs failed with WERR_DS_DRA_BAD_NC/NT code 0xc00020f8 for CN=RID Manager$,CN=System,DC=samba,DC=example,DC=com

This is caused by the Windows domain controller that haven't yet run its Knowledge Consistency Checker (KCC), which means it has not yet created connections to the new Samba DC.

To fix this, you can either run "repadmin /kcc" on the Windows DC as an administrator, or you can use the samba-tool command to do the same thing, like this:

# samba-tool drs kcc -Uadministrator

You should then check that replication between the Windows DC and the Samba DC is working correctly by using:

# samba-tool drs showrepl

DSA Options: 0x00000001
DSA object GUID: 737506d0-bfe6-40c8-815d-08c3dff7a67f
DSA invocationId: eb242434-ca7e-4da7-9b1d-b289ba1922e9


       Default-First-Site-Name\DC1 via RPC
               DSA object GUID: 25e33532-42f2-4082-b9f4-072f9108b565
               Last attempt @ Sun Nov 11 18:02:02 2012 CET was successful
               0 consecutive failure(s).
               Last success @ Sun Nov 11 18:02:02 2012 CET

       Default-First-Site-Name\DC1 via RPC
               DSA object GUID: 25e33532-42f2-4082-b9f4-072f9108b565
               Last attempt @ Sun Nov 11 18:02:02 2012 CET was successful
               0 consecutive failure(s).
               Last success @ Sun Nov 11 18:02:02 2012 CET

Testing Directory Replication

To check that replication is working correctly between your two domain controllers, try adding a user on the Samba DC using either the Samba command line tools, or the Windows GUI admin tools. Then check that the user shows up within a few seconds on your Windows domain controller.

Similarly, try modifying a user on the Windows domain controller and check that the modifies show up correctly on the Samba server


You may wish to use ldapcmp to verify that the same data is being served from all domain controllers.

A Note on SysVol replication

Currently the replication of the SysVol share isn't implemented. If you make any changes on that share, you have to keep the shares on all your DCs in sync manually (e. g. with an rsync cronjob). An example way how to achieve this, you can find in the SysVol Replication Howto.

Note if you AD DC is Samba

There are UID/GID issue for the built-in Users/Groups on sysvol when our DC are Samba As we have yet a method to replicate the UID/GID from the existing Samba DC. Please try the following

  1. Stop All Samba AD DC
  2. copy the /var/lib/samba/private/idmap.ldb to the new Samba AD DC
  3. restart Samba AD DC

Report your success/failure!

Samba4 as a replicating domain controller is still developing rapidly, and we like to hear from users about their successes and failures. While Samba4 is still in rc state we would encourage you to report both your successes and failures to the samba-technical mailing list on

Please be aware that Samba4 is not complete, so you should deploy it carefully until it is ready for production.

FSMO role transfer

You can transfer FSMO roles from an existing DC to a Samba AD DC, by seizing them from your Samba AD machine:

# samba-tool fsmo seize --role=....

You can seize all five roles: rid, schema, naming, pdc and infrastructure (you can use "--role=all" to seize all at once).

Note: The role seizing function was broken in the past (Bug report 9461). This was fixed in 4.0.10/4.1.0. If you are running an affected version, you should consider upgrading first!

A note on DNS updates

As of Samba4 alpha12 Samba4 has the ability to automatically update a Windows or bind9 DNS server with the correct set of DNS entries when it becomes a domain controller.

For this to work correctly between Samba and Windows you may find that you need a set of 5 patches to bind9. Those patches are located in the examples/bind9-patches directory of the Samba4 source tree. The patches have been submitted to the bind9 developers and will be incorporated in the future release of bind, but in the meantime you should be able to build bind9 yourself from sources and apply the patches.

The way the automatic DNS updates works is that Samba regularly (every 10 minutes) calls out to the samba_dnsupdate script that is installed along with Samba. That script reads a template file of DNS names to update in the DNS zone from /usr/local/samba/private/dns_update_list.

The contents of this file look like this:

A                                                        ${DNSDOMAIN} $IP
A                                                        ${HOSTNAME} $IP
CNAME ${NTDSGUID}._msdcs.${DNSDOMAIN}                    ${HOSTNAME}
SRV _kerberos._tcp.${SITE}._sites.dc._msdcs.${DNSDOMAIN} ${HOSTNAME} 88
SRV _ldap._tcp.${SITE}._sites.dc._msdcs.${DNSDOMAIN}     ${HOSTNAME} 389
SRV _kerberos._tcp.dc._msdcs.${DNSDOMAIN}                ${HOSTNAME} 88
SRV _ldap._tcp.dc._msdcs.${DNSDOMAIN}                    ${HOSTNAME} 389
SRV _ldap._tcp.${DOMAINGUID}.domains._msdcs.${DNSDOMAIN} ${HOSTNAME} 389
SRV _ldap._tcp.${SITE}._sites.gc._msdcs.${DNSDOMAIN}     ${HOSTNAME} 3268
SRV _ldap._tcp.gc._msdcs.${DNSDOMAIN}                    ${HOSTNAME} 3268
SRV _ldap._tcp.pdc._msdcs.${DNSDOMAIN}                   ${HOSTNAME} 389
SRV _gc._tcp.${SITE}._sites.${DNSDOMAIN}                 ${HOSTNAME} 3268
SRV _kerberos._tcp.${SITE}._sites.${DNSDOMAIN}           ${HOSTNAME} 88
SRV _ldap._tcp.${SITE}._sites.${DNSDOMAIN}	          ${HOSTNAME} 389
SRV _gc._tcp.${DNSDOMAIN}                                ${HOSTNAME} 3268
SRV _kerberos._tcp.${DNSDOMAIN}                          ${HOSTNAME} 88
SRV _kpasswd._tcp.${DNSDOMAIN}                           ${HOSTNAME} 464
SRV _ldap._tcp.${DNSDOMAIN}                              ${HOSTNAME} 389
SRV _kerberos._udp.${DNSDOMAIN}                          ${HOSTNAME} 88
SRV _kpasswd._udp.${DNSDOMAIN}                           ${HOSTNAME} 464

at runtime, Samba will substitute the variables in this file, and call out to the bind9 nsupdate command using the -g option to enable TSIG-GSS DNS updates. It will only make updates for DNS names that it detects are not currently correctly set.

You can add your own names to dns_update_list list if you want, and Samba will add those on the DNS server. You may also choose not to use TSIG-GSS and instead use a fixed DNS key setup in another bind9 server. To do that you will need to modify the 'nsupdate' command that Samba runs, which is settable using the "nsupdate command" smb.conf option. The default is "/usr/bin/nsupdate -g"

The $IP entries for A records are replaced with the IP interface addresses that Samba detects at runtime, based on the "interfaces=" smb.conf option.

Joining a domain as a RODC (Status for a work in progress)

For the TODO list see Support RODC TODO

Main features implemented

  • Joining as a RODC to Windows DC

To do that one should do a samba-tool join (or samba-tool domain join), something like this:

sudo bin/samba-tool join RODC -U Administrator --password=%password --target-dir=/home/ant/

or (for newer versions of Samba):

sudo bin/samba-tool domain join RODC -U Administrator --password=%password --targetdir=/home/ant/
  • Preloading users for RODC

Users' passwords are not cached by default in a RODC environment. To accomplish that, one should perform the following actions:

  1. Add desired users to the "Allowed RODC Password Replication Group"
  2. Add trusted sources to the "Password Replication Policy" under RODC properties
  3. You must preload users in your RODC with
sudo /bin/samba-tool rodc preload myuser
  • Added support for RODC FAS
  • Added support for unidirectional replication
  • Added support for read-only database

Main features in the TODO list

  • Support Administrator role separation
  • Support Credential caching
  • Join Windows as a RODC in Samba4 domain - blocked by kerberos tgt stuff.


Message: "Failed to find our own NTDS Settings invocationId in the ldb!" during joining

Check if you have an existing smb.conf and remove it befor joining.

Message: Warning: No NC replicated for Connection!

When Samba registers for replication, there are a couple of flags that aren't correctly set. That's what the DRS command shows: They are not set. It's pretty harmless and you can ignore this warning.