Domain Join Ubuntu 22.04 - Failed (with updated Join Script)


its a never ending story.

The UCS Domain join client shall support 22.04 Ubuntu.
I quickly checked and installed a complete vanilla ubuntu 22.04 client.

On this machine i run

sudo add-apt-repository ppa:univention-dev/ppa
sudo apt-get update
sudo DEBIAN_FRONTEND=noninteractive apt-get install univention-domain-join

I started the client via the start menu and entered the Server’s IP, Admin and password.

And I get a failed join message again.

The domain join failed: The UCS master name ucs-1234.mydomain.intranet can not be resolved. 
Please check your DNS settings

Any suggestions?

nmcli is installed. i also added the server’s IP as DNS in the network manage gui of Ubuntu 22.04.

Please provide the output of the following commands:

nmcli -c
resolvectl status

Also see the files /var/log/univention/domain-join-gui.log (GUI) and /var/log/univention/domain-join-cli.log (CLI) for additional information.

Do you have (by chance) multiple DNS servers configured in your domain?

thank you for your fast reply!

nmcli -c

Missing argument for option -c

nmcli -c yes

$ nmcli -c yes
wlp7s0: verbunden zu MagentaWLAN-435M
    	"Qualcomm Atheros QCA9377"
    	wifi (ath10k_pci), 3C:91:80:77:FD:89, hw, mtu 1500
    	ip4-Vorgabe, ip6-Vorgabe
    	route4 metric 600
    	route4 default via metric 600
    	inet6 2003:d2:1f2e:ef93:e1b:9942:66af:3357/64
    	inet6 2003:d2:1f2e:ef93:dc60:4dcc:1f31:9fe1/64
    	inet6 fe80::689c:ffb5:f909:3e2b/64
    	route6 fe80::/64 metric 1024
    	route6 2003:d2:1f2e:ef93::/64 metric 600
    	route6 default via fe80::1 metric 600

p2p-dev-wlp7s0: nicht verbunden
    	wifi-p2p, hw

enp8s0: nicht verfügbar
    	"Realtek RTL8111/8168/8411"
    	ethernet (r8169), 98:FA:9B:18:BC:48, hw, mtu 1500

lo: nicht verwaltet
    	loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
    	domains: speedport.ip
    	interface: wlp7s0

    	servers: fe80::1
    	domains: speedport.ip
    	interface: wlp7s0

When i set the check box at the univention GUI with Set UCS DC as DNS Server.
it changes the DNS config

DNS configuration:
    	servers: [SERVER_IP]
    	domains: mydonaim.intranet
    	interface: wlp7s0

    	servers: fe80::1
    	domains: speedport.ip
    	interface: wlp7s0
resolvectl status

   	Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp8s0)
Current Scopes: none
 	Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp7s0)
	Current Scopes: DNS
     	Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::1
   	DNS Servers: fe80::1%22065
    	DNS Domain: speedport.ip

The log replies:

2022-11-23 22:18:04,316 userinfo WARNING Warning: /etc/ldap/ldap.conf already exists.
2022-11-23 22:18:04,318 userinfo WARNING Warning: /etc/sssd/sssd.conf already exists.
2022-11-23 22:18:04,321 userinfo WARNING Warning: /etc/krb5.conf already exists.
2022-11-23 22:18:04,322 userinfo INFO Created a backup of all configuration files, that will be modified at '/var/univention-backup/20221123211804_domain-join'.
2022-11-23 22:18:04,322 userinfo INFO changing network/dns configuration as requested.
2022-11-23 22:18:04,372 userinfo INFO Configuring ipv4 DNS servers for wlp7s0.
2022-11-23 22:18:04,401 userinfo INFO Applying new settings to wlp7s0.
2022-11-23 22:18:18,657 userinfo CRITICAL All nameservers failed to answer the query _domaincontroller_master._tcp.codenauten.intranet. IN SRV: Server UDP port 53 answered SERVFAIL
Traceback (most recent call last):
  File "/usr/sbin/univention-domain-join", line 458, in run
  File "/usr/lib/python3/dist-packages/univention_domain_join/distributions/", line 106, in join_domain
	DnsConfigurator(self.nameservers, self.domain).configure_dns()
  File "/usr/lib/python3/dist-packages/univention_domain_join/utils/", line 48, in root_wrapper
	return_value = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/", line 82, in configure_dns
  File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/", line 87, in check_if_dns_works
	resolver.query('_domaincontroller_master._tcp.%s.' % (self.domain,), 'SRV')
  File "/usr/lib/python3/dist-packages/dns/", line 1222, in query
	return self.resolve(qname, rdtype, rdclass, tcp, source,
  File "/usr/lib/python3/dist-packages/dns/", line 1173, in resolve
	(nameserver, port, tcp, backoff) = resolution.next_nameserver()
  File "/usr/lib/python3/dist-packages/dns/", line 626, in next_nameserver
	raise NoNameservers(request=self.request, errors=self.errors)
dns.resolver.NoNameservers: All nameservers failed to answer the query _domaincontroller_master._tcp.MYDOMAIN.intranet. IN SRV: Server UDP port 53 answered SERVFAIL

As novice it might be possible, that i configured multi DNS server somehow.
Thank you very very much for your support!

From this I deduce that you’re using some kind of “home router”, which serves you IP addresses via DHCP respective SLAAC for IPv6. Most of them also function as a DNS relay, e.g. they forward queries to some public DNS servers and pass through the response.

Your router respective any public DNS server will not know your “UCS Primary”: While DNS may resolve the name to IP or the reverse, any univention-domain-join-assistent (UDJA) must somehow discover the Primary: it guesses your domain name by doing a reverse-lookup of the IP address of your client respectively the IP addresses of your DNS servers. The domain name is derived from those FQHNs by stripping the respective host-names.
But then it still only knows the domain name, not the host-name of the Primary and its IP addresses.
In a regular UCS domain the Primary (and Backups and Replica) all function as DNS servers and provide a special DNS entry _domaincontroller_master._tcp of type SRV which points back to the Primary. When UCS is configured to also function as a DHCP server for your domain it announces itself as a DNS server, which then would that record, but your home-router does not.
UDJA tries to look up that SRV record via DNS at your home router, which does not have that entry — only your Primary does have it. Therefore auto-detection does not work and you must explicitly give UDJA the IP address of your Primary.

Maybe we should better document this or improve UDJA to do the auto-detection before-hand and force you to enter the Primary manually if auto-detection fails.

Thank you for this clarification.

Indeed the speedport was the home router, i was connected when i took the screenshot.

How can i check if the UCS server is configured as DNS?
When log in into the UCS WebGUI → network → external name server I see my server provider’s DNS IP.

However, i also tried the IP Address of the UCS in the UDJA instead of the hostname as well. Therefore the DNS does not need to resolve the hostname or do i miss something? But that aint worked as well.
(I also tried to change the DNS on the client’s network manager to the UCS IP ) .

@pmhahn thank you for your help

How can i check if the UCS server is configured as DNS?

There are 2 DNS settings:

  1. Your UCS systems (Primary, Backup, Replica, Server) have one which is required for the UCS system to resolve external addresses like er al. On top of that UCS adds data from its own zones, which other UCS systems need to communicate with each other.
  2. Your Ubuntu Clients have one: they should use the UCS systems to resolve IP addresses as only the UCS systems know of your domain; using an (external) DNS server here like your speedport home roter will lead to that resolution not working.

However, i also tried the IP Address of the UCS in the UDJA instead of the hostname as well. Therefore the DNS does not need to resolve the hostname or do i miss something?

Using names instead of plain IP addresses is important as SSL/TLS certificates work with names, not IP addresses (at least in UCS; theoretically you can add IP addresses to certificates, but no-one I know of does that.)
For the join process multiple connections to the Primary are initiated:

  1. an ssh connection to create the machine account on the Primary; that one works well with IP addresses, too.
  2. afterwards LDAP and Kerberos, which AFAIK require a name instead of IP addresses.

But that aint worked as well.

  1. check on the client that nmcli in the section DNS configuration reports your Primary to be used. That auto-detection should work.
  2. otherwise try sudo /usr/sbin/univention-domain-join-cli and specify --dc-ip IP --domain DOMAIN manually.

If 2. works but 1. still does not work, we can continue debugging from there. If you have the tool dig installed please check which of your servers is capable of resolving the SRV record:

dig -p 53 @ _domaincontroller_master._tcp.codenauten.intranet. srv  # ❓
dig -p 53 @ _domaincontroller_master._tcp.codenauten.intranet. srv  # ❌
dig -p 53 @IP.of.your.UCS _domaincontroller_master._tcp.codenauten.intranet. srv # ✅

The last one should work definitely, the middle one probably not, the first one is the most interesting one:
NetworkManager and systemd nowadays run a local DNS server on each host: This allows caching but is required to have a more flexible DNS configuration: Traditionally you had your /etc/resolv.conf file where you could name up to 3 DNS servers, all serving the same (public) data. With todays VPNs this is too inflexible as you want to delegate querying some domains to specific other servers and only use the “public” DNS servers for looking up the (public) rest.
What you basically need is to configure NetworkManager to “delegate” codenauten.intranet. to your UCS Primary. You can do this by creating a file like /etc/NetworkManager/dnsmasq.d/ucs.conf with content server=/codenauten.intranet/IP.of.your.UCS and doing a systemctl reload NetworkManager.service.

1 Like

Thank you very much!

With your explanations i started to understand the situation , at lest a bit.

  1. check on the client that nmcli in the section DNS configuration reports your Primary to be used. That auto-detection should work.

It is present in the nmcli.

DNS configuration:
        domains: codenauten.intranet
        interface: wlp7s0

        servers: fe80::1
        domains: speedport.ip
        interface: wlp7s0

But the UDJA does not work
No DNS record for DC master could be found.

  1. otherwise try sudo /usr/sbin/univention-domain-join-cli and specify --dc-ip IP --domain DOMAIN manually.

It returns, that the UCS master name ucs-1234.codenauten.intranet could not be resolved.

dig -p 53 @ _domaincontroller_master._tcp.codenauten.intranet. srv  # ❓
dig -p 53 @ _domaincontroller_master._tcp.codenauten.intranet. srv  # ❌
dig -p 53 @IP.of.your.UCS _domaincontroller_master._tcp.codenauten.intranet. srv # ✅

Surprisingly all of these seem to work. They return a bunch of information’s, which includes my UCS IP and a part which say 1 server found.

I also created a file


with the according content and performed the reload, but still the same issue.

As you already clarified so much things for me, i like to ask you about the different names i came across in UCS.

  • I got domain.intranet
  • I got ucs-1234.domain.intranet
  • I got my external domain sub.domain.tld which has a DNS entry and therefore points to IP of my UCS

Iam a bit confused about all of them, therefore i try all of them whenever iam in despair.

That looks okay to me.

strange; see below for the next step to manually resolve that name to an IP address.

By default the output of dig is very verbose and includes many sections; of interest is only the “ANSWER SECTION” which should have a line like

_domaincontroller_master._tcp.codenauten.intranet. 10800 IN SRV 0 0 0 ucs-1234.codenauten.intranet.

You can reduce the output of dig by inserting a +short just after the command. Of interest here is only that there is such a SRV record and that “fully qualified host name” (FQHN) it points to.

Next would then be to resolve the host-name from the SRV record to an IP address by doing:

dig +short -p 53 @ ucs-123.codenauten.intranet. any  # ❓
dig +short -p 53 @ ucs-123.codenauten.intranet. any  # ❌
dig +short -p 53 @IP.of.your.UCS ucs-1234.codenauten.intranet. any # ✅

Again this should return A records for an IPv4 addresses and/or AAAA records for IPv6 addresses.

Nit: I did non check if this is required, but the file suffix should be .conf with an additional f at the end; I goofed up the styling in my previous reply; now fixed.

  • domain.intranet is your domain name: it’s a hierarchical name-space which allows you (and anybody in the world) to group your devices under a common name. If others are supposed to use that name it must be registered at a public registrar, but as long as you use the name only internally you can mostly use any name you like, but make sure to not shadow any public domain like or
  • ucs-123.domain.intranet is a FQHN of one of your devices , e.g. your UCS server. It splits into the host-name ucs-123 in the domain named domainname.intranet.
  • sub.domain.tld is yet another name for your UCS server: Any device can have multiple names, e.g. multiple internal and multiple public names. The host does not care if it has multiple names: internally it has a hostname and one or more IP addresses. How they resolve to names is managed by DNS and might also depend on the actual DNS server you ask:
    • Any public DNS server probably knows nothing about domain.intranet and will not be able to resolve a IP address from a private address range like 192.168.2.X to any name.
    • Only your UCS server will know about domain.intranet and will be able to resolve its name ucs-1234.domain.intranet to its IP address 192.168.2.X.

It is perfectly normal for a device to have multiple names, but you have to make sure to communicate the right name to third-parties: If you give them your internal name, it will not work for them.
You also have to do additional work for SSL/TLS certificates as they work with names:

  • for your internal domain domain.intranett UCS will create a custom Certtificate Authority (CA) to be able to create certificates on demand: They are required to setup encrypted LDAP and HTTPS connections for internal communication.
  • for any external domain (sub.domain.tld) you have to get a valid certificate on your own, either by using Let’s encrypt or by getting one from some other accepted CA. This certificate then can be configured for Apache and other public visible servers so that clients can validate them when accessing your server via its public names.