Joining a Samba DC to an Existing Active Directory: Difference between revisions
Mmuehlfeld (talk | contribs) m (Fix link) |
Mmuehlfeld (talk | contribs) m (Fix links) |
||
Line 88: | Line 88: | ||
By default, the first Domain Controller in a domain automatically acts as a DNS server for AD based zones. For failover reasons, it is recommended to have at least two DC's providing AD DNS services. |
By default, the first Domain Controller in a domain automatically acts as a DNS server for AD based zones. For failover reasons, it is recommended to have at least two DC's providing AD DNS services. |
||
If you plan to join the additional Domain Controller with BIND as the DNS backend, you have to [[ |
If you plan to join the additional Domain Controller with BIND as the DNS backend, you have to [[Configure_BIND_as_backend_for_Samba_AD|setup BIND as AD backend]] first. If you use the internal or use no local DNS, no further steps are required. |
||
Line 207: | Line 207: | ||
* Realm: Kerberos Realm |
* Realm: Kerberos Realm |
||
* DNS backend: You have to choose whether to use the Internal DNS server (SAMBA_INTERNAL), BIND9 (BIND9_DLZ) or no DNS backend (NONE). The Internal DNS is the default and the best choice for simple DNS requirements. It doesn't need any further action. For complex DNS requirements, BIND9_DLZ is recommended. Don't use BIND9_FLATFILE! It's not documented or supported! See [[ |
* DNS backend: You have to choose whether to use the Internal DNS server (SAMBA_INTERNAL), BIND9 (BIND9_DLZ) or no DNS backend (NONE). The Internal DNS is the default and the best choice for simple DNS requirements. It doesn't need any further action. For complex DNS requirements, BIND9_DLZ is recommended. Don't use BIND9_FLATFILE! It's not documented or supported! See [[Configure_BIND_as_backend_for_Samba_AD|Configure BIND as backend for Samba AD]] for further information about using BIND. The DNS backend choice made during the provisioning isn't permanent. [[Changing_the_DNS_backend|It can be changed afterwards]]. |
||
* Site: If you have setup Active Directory Sites, it's possible, to directly join a new DC into a specified AD site. |
* Site: If you have setup Active Directory Sites, it's possible, to directly join a new DC into a specified AD site. |
Revision as of 17:48, 25 August 2015
Introduction
As well as the ability to join an Active Directory as a Member Server, it is also possible to join as a Domain Controller.
The process of joining a Samba 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.
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.
Server information
This documentation uses the following configuration/settings:
Existing DC in the domain: Hostname: DC1 IP: 10.99.0.1 DC is also a DNS server: yes Domain information: DNS Domain Name: samdom.example.com NT4 Domain Name (NETBIOS): SAMDOM Kerberos Realm: SAMDOM.EXAMPLE.COM Domain Administrator: Administrator Domain Administrator Password: passw0rd DC additionally joined to the domain: Hostname: DC2 IP Address: 10.99.0.2 Installation Directory: /usr/local/samba/
Versions
This documentation is frequently updated to reflect the latest changes. Please see the Samba Release Planning for more specifics.
Please review the release notes for the version you have installed. It may contain important information, not yet reflected in this documentation.
Prerequisites
- The domain must be at least at forest functional level „2003 native“ (not interim!), to join a Samba DC.
- The forests schema must be maximum at version 47 (Server 2008 R2). Later schemas are not supported at the moment and cause Samba to fail during the join. If your forest is Samba driven, the schema version is 47. Only if you have Windows DCs, this has to be checked, by running on a Windows DC:
> dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Base -attr objectVersion
Installation
Different ways to install
Always check the OS Requirements for dependencies and recommendations.
You have a few options to install Samba:
- Build Samba yourself.
- Install binary distribution packages. Make sure, that you use a recent Samba installation with Active Directory Domain Controller capabilities!
- Install from SerNet Enterprise Samba package.
Paths
Take care when running Samba commands, if you also have a previous version of Samba installed! To avoid inadvertently running the wrong version of a program, you should consider putting the „/usr/local/samba/bin/“ and „/usr/local/samba/sbin/“ directories at the beginning of your $PATH variable.
You can see what version of Samba and client tools, if any, is in your „$PATH“ variable by running:
# samba -V # smbclient -V
Preparing the host for the domain join
Local DNS server
By default, the first Domain Controller in a domain automatically acts as a DNS server for AD based zones. For failover reasons, it is recommended to have at least two DC's providing AD DNS services.
If you plan to join the additional Domain Controller with BIND as the DNS backend, you have to setup BIND as AD backend first. If you use the internal or use no local DNS, no further steps are required.
Verify /etc/hosts
Verify that the local hostname isn't resolved to 127.0.0.1 in /etc/hosts:
127.0.0.1 localhost.localdomain localhostDC2.samdom.example.com DC210.99.0.2 DC2.samdom.example.com DC2
If the local hostname is resolved to 127.0.0.1, Samba would use this IP for the various DC DNS entries. This would prevent clients from reaching this Domain Controller!
DNS resolving
Configure the host, you want to join as an additional Domain Controller, to use a DNS server that is able to resolve zones from the Active Directory. On Linux and Unixes, this is typically done by adding a „nameserver“ and „search domain“ entry to to /etc/resolv.conf:
nameserver 10.99.0.1 search samdom.example.com
Consult your distributions documentation for configuring the usage of a DNS server.
To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:
# host -t A DC1.samdom.example.com DC1.samdom.example.com has address 10.99.0.1
Kerberos
- Add the following content to /etc/krb5.conf:
[libdefaults] dns_lookup_realm = false dns_lookup_kdc = true default_realm = SAMDOM.EXAMPLE.COM
- Verify the correct Kerberos setup by obtaining a ticket:
# kinit administrator Password for administrator@SAMDOM.EXAMPLE.COM: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administrator@SAMDOM.EXAMPLE.COM Valid starting Expires Service principal 09.11.2014 17:34:09 10.11.2014 03:34:09 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM renew until 10.11.2014 17:34:07
Join the existing domain as a Domain Controller
Before you start the joining, make yourself familiar with the parameters and options of „samba-tool domain join“:
# samba-tool domain join --help
Expecially the following two options are required, if your future Domain Controllers have multiple NICs. Because „samba-tool“ would auto-choose one of the IPv4/IPv6 addresses, if multiple where found, it might be necessary to bind Samba to the desired interfaces using
--option="interfaces=lo eth0" --option="bind interfaces only=yes"
Join the existing domain (parameter explanation below):
# samba-tool domain join samdom.example.com DC -Uadministrator --realm=samdom.example.com --dns-backend=BIND9_DLZ Finding a writeable DC for domain 'samdom.example.com' Found DC dc1.samdom.example.com Password for [WORKGROUP\administrator]: passw0rd workgroup is SAMDOM realm is samdom.example.com checking sAMAccountName Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com Setting account password for DC2$ Enabling account Adding DNS account CN=dns-DC2,CN=Users,DC=samdom,DC=example,DC=com with dns/ SPN Setting account password for dns-DC2 Calling bare provision No IPv6 address will be assigned Provision OK for domain DN DC=samdom,DC=example,DC=com Starting replication Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0] Analyze and apply schema objects Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0] Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0] Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0] Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0] Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[28/0] Replicating critical objects from the base DN of the domain Partition[DC=samdom,DC=example,DC=com] objects[98/98] linked_values[23/0] Partition[DC=samdom,DC=example,DC=com] objects[395/297] linked_values[23/0] Done with always replicated NC (base, config, schema) Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[41/41] linked_values[0/0] Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0] Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[38/19] linked_values[0/0] Committing SAM database Sending DsReplicateUpdateRefs for all the replicated partitions Setting isSynchronized and dsServiceName Setting up secrets database Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC
Parameter explanations:
- Domain: AD Domain Name
- Server Role: „DC“ for Domain Controller
- Username: Account that is allowed to join new Domain Controllers. Typically it is the Domain Administrator.
- Realm: Kerberos Realm
- DNS backend: You have to choose whether to use the Internal DNS server (SAMBA_INTERNAL), BIND9 (BIND9_DLZ) or no DNS backend (NONE). The Internal DNS is the default and the best choice for simple DNS requirements. It doesn't need any further action. For complex DNS requirements, BIND9_DLZ is recommended. Don't use BIND9_FLATFILE! It's not documented or supported! See Configure BIND as backend for Samba AD for further information about using BIND. The DNS backend choice made during the provisioning isn't permanent. It can be changed afterwards.
- Site: If you have setup Active Directory Sites, it's possible, to directly join a new DC into a specified AD site.
Check DNS entries
For a successful setup and failover purposes, it is required, that all important DNS records are added to the DNS zones. Check, if the important DNS records are existing and if not (see Bug #10928), add them manually. Don't skip this step!
Adaptations for the BIND DNS backend
This step can be skipped if the DC was joined with SAMBA_INTERNAL or without DNS backend.
Workaround: Fix keytab permissions
This workaround is required, until Bug #10881 is solved for the version of Samba you're running!
Fix permissions on the 'dns.keytab' file, to allow BIND to read this file:
# chmod 640 /usr/local/samba/private/dns.keytab # chgrp named /usr/local/samba/private/dns.keytab
Note: If you use Samba packages (Distro or from other sources), make sure that the account BIND uses, is able to reach the dns.keytab file. Some package installations set too restrictive permissions on the folders.
Otherwise, BIND will not able to update your zone(s)! One of the results is, that 'samba_dnsupdate' can't add e. g. the important DNS entries, that clients use, to locate the new DC. In case of an failure of your other DC, domain logons using your new DC wouldn't be possible!
Enable the BIND9_DLZ module, suitable to the BIND version
Make sure, that the correct BIND9_DLZ module for your BIND version is enabled in /usr/local/samba/private/named.conf. Uncomment the module for your BIND version and comment the other:
dlz "AD DNS Zone" { # For BIND 9.8.0 database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so"; # For BIND 9.9.0 # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so"; };
The example above enables the module for BIND 9.8.x (default).
GID mappings of built-in groups
There are current issues with GID mappings of built-in groups. The GIDs of groups owning files and directories on in the sysvol folder may differ between Domain Controllers. Currently Samba doesn't provide a replication of these GIDs.
Use the following workaround, if you encounter any problems:
- Shutdown Samba on the new joined Domain Controller.
- Create a hot-backup of idmap.ldb on the first Domain Controller:
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb
- Move the backup file „/usr/local/samba/private/idmap.ldb.bak“ to "/usr/local/samba/private" on the newly joined Domain Controller and remove the .bak suffix, this will replace the original file.
- Start Samba on the new joined Domain Controller again.
- Reset the ACLs on the local sysvol folder of the new joined Domain Controller:
# samba-tool ntacl sysvolreset
Start Samba
To start the Samba Active Directory Domain Controller in „standard“ mode, which is suitable for production use, run
# samba
Samba doesn't yet have init scripts included. You can find examples on the Samba Init-Script page.
Directory replication
A few minutes after you have started Samba, connections with other DC will be established automatically.
# samba-tool drs showrepl Default-First-Site-Name\DC2 DSA Options: 0x00000001 DSA object GUID: df4bdd8c-abc7-4779-b01e-4dd4553ca3e9 DSA invocationId: 8e30d69f-c20f-4744-9833-5b050e611375 ==== INBOUND NEIGHBORS ==== CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful 0 consecutive failure(s). Last success @ Sun Nov 9 19:56:07 2014 CET DC=DomainDnsZones,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ Sun Nov 9 19:56:06 2014 CET was successful 0 consecutive failure(s). Last success @ Sun Nov 9 19:56:06 2014 CET CN=Configuration,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful 0 consecutive failure(s). Last success @ Sun Nov 9 19:56:07 2014 CET DC=ForestDnsZones,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful 0 consecutive failure(s). Last success @ Sun Nov 9 19:56:07 2014 CET DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ Sun Nov 9 19:56:13 2014 CET was successful 0 consecutive failure(s). Last success @ Sun Nov 9 19:56:13 2014 CET ==== OUTBOUND NEIGHBORS ==== CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Configuration,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=samdom,DC=example,DC=com Default-First-Site-Name\DC1 via RPC DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) ==== KCC CONNECTION OBJECTS ==== Connection -- Connection name: 5745d481-1d26-48f4-ab65-273263e28a45 Enabled : TRUE Server DNS name : DC1.samdom.example.com Server DN name : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com TransportType: RPC options: 0x00000001 Warning: No NC replicated for Connection!
Depending on your replication settings - if defined - it may take a few minutes until all connections are established. So please be patient! On the long shot that the outbound connections aren't established automatically - even not after several minutes - you can force the replication (generally not necessary!). See samba-tool drs replicate.
Note about the„Warning: No NC replicated for Connection!“ line: It can be safely ignored. See FAQ: Message: Warning: No NC replicated for Connection!
Start BIND
Please check (samba-tool drs showrepl), that the DC=ForestDnsZones,DC=samdom,DC=example,DC=com and DC=DomainDnsZones,DC=samdom,DC=example,DC=com partitions are already replicated!
If so, it's time to start BIND now, if you have a BIND9_DLZ backend.
Follow-Up on /etc/resolv.conf
Now the DNS on your new Domain Controller is working, it is recommended to add it to /etc/resolv.conf.
It is best practice to have more than one nameserver entry in the Domain Controllers /etc/resolv.conf! This is in case of a dns failure where the DC cannot resolve the AD zones, this would cause several other services that rely on DNS to fail e.g. directory replication.
So you should always rely on at least two DNS servers, that are both able to resolve the AD DNS zones.
/etc/resolv.conf on DC2 nameserver 10.99.0.1 nameserver 127.0.0.1 search samdom.example.com /etc/resolv.conf on DC1 nameserver 10.99.0.2 nameserver 127.0.0.1 search samdom.example.com
If you have more than two Domain Controllers, then you should think in a circle. The following example supposes an additional Domain Controller DC3 to have the IP 10.99.0.3:
/etc/resolv.conf on DC1 nameserver 10.99.0.2 nameserver 10.99.0.3 search samdom.example.com /etc/resolv.conf on DC2 nameserver 10.99.0.3 nameserver 10.99.0.1 search samdom.example.com /etc/resolv.conf on DC3 nameserver 10.99.0.1 nameserver 10.99.0.2 search samdom.example.com
This will prevent the DC's suffering DNS islanding.
SysVol replication
Currently replication of the SysVol share isn't implemented. If you make any changes on that share, you have to keep them in sync on all your Domain Controllers. An example, how to achieve this automatically, is provided in the SysVol Replication documentation.
Testing directory replication
To check that replication is working correctly between your two domain controllers, try adding/modifying e. g. a user on one DC using either the Samba command line tools or the Windows GUI admin tools. Then check that the changes shows up within a few seconds on the other Domain Controller.
ldapcmp
You may wish to use samba-tool ldapcmp to verify that the same data is being served from all Domain Controllers.
Troubleshooting
If you encounter any problems when using the documentation, see the Samba AD DC Troubleshooting page.