Windows computer's join to UCS fails

UCS can offer Active Directory (AD) services. Thus, Windows computers can join the domain in the same way as joining a Microsoft based Active Directory domain. An unsuccessful join can occur for various reasons. The following steps should be checked in case the join fails.

1. An Active Directory Domain Controller for the domain could not be contacted.

In case a message similar to “An Active Directory Domain Controller for the domain could not be contacted.” is shown,

Screenshot from_B_ 2017-10-31 15-04-13
Below are details of the above message:
The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain “nosamba.intranet”:

The error was: "DNS name does not exist."
(error code 0x0000232B RCODE_NAME_ERROR)
The query was for the SRV record for _ldap._tcp.dc._msdcs.nosamba.intranet
Common causes of this error include the following:
The DNS SRV records required to locate a AD DC for the domain are not registered in DNS. These records are registered with a DNS server automatically when a AD DC is added to a domain. They are updated by the AD DC at set intervals. This computer is configured to use DNS servers with the following IP addresses:
One or more of the following zones do not include delegation to its child zone:
(the root zone)

The following steps should then be checked:

  • Is the domain name inserted correctly?

  • Is the DNS server entered correctly in the Windows client network setting? Normally, it should be the IP address of the UCS server.

  • Is the UCS server available for the Windows client? This can be verified via ping.
    - Ping both the IP address and the server name.
    - ping the domain name.
    - Use the NSLookup tool to verify that DNS entries are correctly registered in DNS
    - Also on the Windows command line (cmd) we can use the following command to querry the domainname.
    > nslookup set type=all

  • Is Samba installed on the UCS server and are the services Samba and Bind up and running?

1.  root@ucsMaster1:~#  dpkg -l univention-samba4       
     ii  univention-sam 6.0.10-44A~4 amd64        UCS - Samba4 integration package

2.     root@ucs-9735:~# /etc/init.d/samba-ad-dc status 
       ● samba-ad-dc.service - LSB: start Samba daemons for the AD DC
       Loaded: loaded (/etc/init.d/samba-ad-dc)
       Active: active (running) since Fr 2017-10-27 12:57:03 CEST; 2min 11s ago
       CGroup: /system.slice/samba-ad-dc.service
          ├─11618 /usr/sbin/samba -D
          ├─11622 /usr/sbin/samba -D
          ├─11623 /usr/sbin/samba -D
          ├─11624 /usr/sbin/samba -D
          ├─11625 /usr/sbin/smbd -D --option=server role check:inhibit=yes -...
          ├─11626 /usr/sbin/samba -D
          ├─11627 /usr/sbin/samba -D
          ├─11628 /usr/sbin/samba -D
          ├─11629 /usr/sbin/samba -D
          ├─11630 /usr/sbin/samba -D
          ├─11631 /usr/sbin/samba -D
          ├─11632 /usr/sbin/winbindd -D --option=server role check:inhibit=y...
          ├─11633 /usr/sbin/samba -D
          ├─11634 /usr/sbin/samba -D
          ├─11640 /usr/sbin/smbd -D --option=server role check:inhibit=yes -...
          ├─11641 /usr/sbin/smbd -D --option=server role check:inhibit=yes -...
          ├─11643 /usr/sbin/winbindd -D --option=server role check:inhibit=y...
          └─11644 /usr/sbin/smbd -D --option=server role check:inhibit=yes -...

          Okt 27 12:57:03 ucs-9735 samba-ad-dc[11610]: Starting Samba AD DC daemon: samba.
           Okt 27 12:57:03 ucs-9735 systemd[1]: Started LSB: start Samba daemons for t...C.
          Hint: Some lines were ellipsized, use -l to show in full.

3.     root@ucs-9735:~# /etc/init.d/bind9 status
        ● bind9.service - LSB: bind9 Domain Name Server (DNS)
        Loaded: loaded (/etc/init.d/bind9)
       Drop-In: /run/systemd/generator/bind9.service.d
       Active: active (exited) since Fr 2017-10-27 12:59:04 CEST; 5min ago

       Okt 27 12:59:04 ucs-9735 bind9[13187]: Starting bind9 Domain Name Server (D...4.
       Okt 27 12:59:04 ucs-9735 systemd[1]: Started LSB: bind9 Domain Name Server ...).
        Hint: Some lines were ellipsized, use -l to show in full.

How Windows client computers joins a domain.

The process of a Windows client joining a UCS domain, requires the use of a DNS server. This server contains the record for each DC in the domain. In the client computer, some informations are entered that will help it locate a domain controller. These informations include:

  • the client’s local IP address, which is used to determine the client’s Active Directory site membership.
  • a DNS server address. and
  • the desired domain name.

When the join button is clicked the Netlogon service on the client uses the collected information to look up a domain controller for the specified domain, following the steps below:

  1. Netlogon queries the configured DNS server to get the service resource (SRV) records and host (A) records from the DNS that corresponds to the DC for the desired domain. This records must exist in DNS as they are created automatically in a UCS DC when SAMBA AD DC is installed.
  2. The DNS then replies with the SRV and host details. The general form of the SRV record is _service-_protocol.domainnane. In our case the client querries for _ldap._tcp.dc._mscds.domainname . If there are more than one DC, the query result will be a list of DC host names with the associated A records. The client then sends an LDAP search query, via UDP, to each domain controller to see if they are operational. All this information is cached by Netlog for later use if the DC in question is shutdown.
  3. After the AD DCs are located, the client uses LDAP to access Active Directory on a domain controller, preferably one in the client’s own subnet or the configured PDC (primary domain controller: The first DC in the Domain on which Samba AD DC is installed) for the domain.
  4. When the connection is made to the desired dc an account will be generated in LDAP and the client transmits the desired info, i.e computer name and IP address to it. The join is accomplished as a password for the computer account and kerberos key is generate, with these credentials, it can know authenticate into the domain. This whole information will be transmitted to the system joining the domain as a script and it is saved in the netlogon service cache. The client will continue to use that domain controller for future contacts (unless the domain controller becomes unavailable).
  • There is a UCS Help-script that helps to test if the DNS entry has automatically been generated. It is important to see if it generates errors e.g. reports about “some missing dns configuration”.
    #  cd /usr/share/univention-samba4/scripts
    # ./
  • We can test to see if the UCS host name is resolvable, i.e. does it resolve to the correct IP address?
    # host  $(hostname -f)
    root@ucsMaster1:~# host -t srv _ldap._tcp.`dnsdomainname`
    _ldap._tcp.testing.intranet has SRV record 0 100 389 ucsMaster1.testing.intranet.

2. The specified server can not perform the requested operation:

The following message may appear after a successful domain join;

Failed to change the DNS name for the primary domain in this computer 
"'. Name "domain.local" is maintained. 
Error: The specified server can not perform the requested operation.

This indicates a successful domain join, but the Windows client could not register its IP address in the DNS for its host name. There can be a number of reasons for this:

By default Windows clients attempt to register their IP address with the DNS server after every system starts. This procedure can be done manually in one of the following ways:

  • in the Windows command line we can force host record registration by using:
    ipconfig /registerdns
  • Otherwise, the DNS entries can be edited via the DNS module of the Univention Management Control by deleting the DNS (host record) record and run ipconfig /registerdns .
  • The domain controller service registration can be forced by stoping and starting the Netlogon service.


If join is still not successful despite the above measures, then it is important to take the following steps to check the log files for errors:

  1. On a terminal in the DC Master , increase the log level with the following command
     # ucr set samba4/debug/level=5
  2. Then restart the Samba service
     #  /etc/init.d/samba-ad-dc restart
  3. The following log files can then be viewed which are generated during the join.
     #  less  /var/log/samba/log.samba
  4. At the end of the analysis, the debug level should be reset. The default debug level is 1
    #  ucr unset samba4/debug/level
    #  /etc/init.d/samba-ad-dc restart
    root@ucsMaster1:~# ucr get samba/debug/level

Tcpdump can be used as a debugging tool, to check the network transmission between the AD DC and the windows client.

  • It can be installed by the following command

    univention-install tcpdump
  • To trace samba traffic of all clients

    tcpdump -p -s 0 -w FILENAME  
  • To capture packets coming only from a specific IP e.g. our Windows client Machine with IP address

    tcpdump -p -s 0 -w FILENAME src host

    where FILENAME is a .pcap file that will be created, and the output is then written into it for futher analysis.

  • To read and analyze the file that just created execute:

    tcpdump -r FILENAME

For more information on tcpdump:

For more information on how windows joins a domain: