Finally got my domain controller working (ran a takeover then had to do some fixes), now the domain is working well, but my clients don’t seem to be registering in the UCS server’s DNS. Old records are still there, and new ones aren’t being created. In one case, I actually deleted the old DNS record and had to re-add the machine to the domain, but it still didn’t create a new record. I also ran “ipconfig /registerdns” several times, to no avail.

So what might I be missing here? The primary DNS server for the client is the UCS domain controller as well, there is a secondary server as well and I’ll probably try taking that out to see what happens. Also UCS is NOT managing DHCP; my Cisco router hands out DHCP addresses.

I’d appreciate your ideas!

-Dan

Hey,

DHCP shouldn’t matter regarding DNS.

First of all please verify that UCS is using Samba4 as the DNS backend and not LDAP. Run “ucr get dns/backend”. What does it output?

Next: have a look at /var/log/syslog. Whenever a Windows client updates its DNS records you should see entries such as the following:

Sep 30 08:13:32 trinculo named[3156]: samba_dlz: starting transaction on zone bs.linet-services.de Sep 30 08:13:32 trinculo named[3156]: samba_dlz: allowing update of signer=BIERTE\$\@BS.LINET-SERVICES.DE name=BIERTE.bs.linet-services.de tcpaddr= type=AAAA key=1016-ms-7.19-140747ad.c1bc7979-83c6-11e6-0884-…/160/0 Sep 30 08:13:32 trinculo named[3156]: samba_dlz: allowing update of signer=BIERTE\$\@BS.LINET-SERVICES.DE name=BIERTE.bs.linet-services.de tcpaddr= type=A key=1016-ms-7.19-140747ad.c1bc7979-83c6-11e6-0884-…/160/0 Sep 30 08:13:32 trinculo named[3156]: client 10.199.92.10#53166: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'BIERTE.bs.linet-services.de' AAAA Sep 30 08:13:32 trinculo named[3156]: samba_dlz: subtracted rdataset BIERTE.bs.linet-services.de 'BIERTE.bs.linet-services.de.#0111200#011IN#011AAAA#0112001:1640:141:2:…' Sep 30 08:13:32 trinculo named[3156]: client 10.199.92.10#53166: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'BIERTE.bs.linet-services.de' A Sep 30 08:13:32 trinculo named[3156]: samba_dlz: subtracted rdataset BIERTE.bs.linet-services.de 'BIERTE.bs.linet-services.de.#0111200#011IN#011A#01110.199.92.10' Sep 30 08:13:32 trinculo named[3156]: samba_dlz: added rdataset BIERTE.bs.linet-services.de 'BIERTE.bs.linet-services.de.#0111200#011IN#011A#01110.199.92.10' Sep 30 08:13:32 trinculo named[3156]: samba_dlz: committed transaction on zone bs.linet-services.de

Kind regards,
mosu

Thanks mosu. The backend is indeed samba4, however I checked the syslog and saw some interesting output:

root@xs1-ucsdc:~# cat /var/log/syslog | grep samba_dlz Sep 30 06:27:01 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 06:27:01 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 06:50:47 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 06:50:47 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 07:03:52 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 07:03:52 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 07:07:00 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 07:07:00 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 07:21:43 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 07:21:43 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 07:27:01 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 07:27:01 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 07:50:47 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 07:50:47 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 08:03:52 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 08:03:52 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 08:07:00 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 08:07:00 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 08:21:43 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 08:21:43 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 08:27:01 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 08:27:01 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 08:50:47 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 08:50:47 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 09:03:52 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 09:03:52 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 09:07:00 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 09:07:00 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 09:16:33 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 09:16:33 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home Sep 30 09:21:43 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 09:21:43 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home

The last logged instance of this was just about 3 minutes ago local time when I logged into a couple computers here. I’m thinking that might be a coincidence.

Looking closer at the tail of syslog, I see this:

Sep 30 09:21:43 xs1-ucsdc named[9090]: samba_dlz: starting transaction on zone t4dlab.home Sep 30 09:21:43 xs1-ucsdc named[9090]: client 10.1.110.21#57924: update 't4dlab.home/IN' denied Sep 30 09:21:43 xs1-ucsdc named[9090]: samba_dlz: cancelling transaction on zone t4dlab.home

So why is samba4 denying DNS updates?

Hey,

well, those are DNS updates to the zone itself. Those are denied here, too. I didn’t include those entries in my example messages from my log files, though. Here’s a more complete example from our server:

Sep 30 15:13:19 trinculo named[3156]: samba_dlz: starting transaction on zone bs.linet-services.de Sep 30 15:13:19 trinculo named[3156]: client 2001:1640:141:2:…#57487: update 'bs.linet-services.de/IN' denied Sep 30 15:13:19 trinculo named[3156]: samba_dlz: cancelling transaction on zone bs.linet-services.de Sep 30 15:13:19 trinculo named[3156]: samba_dlz: starting transaction on zone bs.linet-services.de Sep 30 15:13:19 trinculo named[3156]: samba_dlz: allowing update of signer=talisker\$\@BS.LINET-SERVICES.DE name=talisker.bs.linet-services.de tcpaddr= type=AAAA key=420-ms-7.1-5880.a7b995c9-870f-11e6-3099-…/160/0 Sep 30 15:13:19 trinculo named[3156]: samba_dlz: allowing update of signer=talisker\$\@BS.LINET-SERVICES.DE name=talisker.bs.linet-services.de tcpaddr= type=A key=420-ms-7.1-5880.a7b995c9-870f-11e6-3099-…/160/0 Sep 30 15:13:19 trinculo named[3156]: samba_dlz: allowing update of signer=talisker\$\@BS.LINET-SERVICES.DE name=talisker.bs.linet-services.de tcpaddr= type=AAAA key=420-ms-7.1-5880.a7b995c9-870f-11e6-3099-…/160/0 Sep 30 15:13:19 trinculo named[3156]: samba_dlz: allowing update of signer=talisker\$\@BS.LINET-SERVICES.DE name=talisker.bs.linet-services.de tcpaddr= type=A key=420-ms-7.1-5880.a7b995c9-870f-11e6-3099-…/160/0 Sep 30 15:13:19 trinculo named[3156]: client 2001:1640:141:2:c9a5:c736:175e:5577#51018: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'talisker.bs.linet-services.de' AAAA Sep 30 15:13:19 trinculo named[3156]: samba_dlz: subtracted rdataset talisker.bs.linet-services.de 'talisker.bs.linet-services.de.#0111200#011IN#011AAAA#0112001:1640:141:2:…' Sep 30 15:13:19 trinculo named[3156]: client 2001:1640:141:2:c9a5:c736:175e:5577#51018: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'talisker.bs.linet-services.de' A Sep 30 15:13:19 trinculo named[3156]: samba_dlz: subtracted rdataset talisker.bs.linet-services.de 'talisker.bs.linet-services.de.#0111200#011IN#011A#01110.199.92.129' Sep 30 15:13:19 trinculo named[3156]: client 2001:1640:141:2:c9a5:c736:175e:5577#51018: updating zone 'bs.linet-services.de/NONE': adding an RR at 'talisker.bs.linet-services.de' AAAA Sep 30 15:13:19 trinculo named[3156]: samba_dlz: added rdataset talisker.bs.linet-services.de 'talisker.bs.linet-services.de.#0111200#011IN#011AAAA#0112001:1640:141:2:…' Sep 30 15:13:19 trinculo named[3156]: client 2001:1640:141:2:c9a5:c736:175e:5577#51018: updating zone 'bs.linet-services.de/NONE': adding an RR at 'talisker.bs.linet-services.de' A Sep 30 15:13:19 trinculo named[3156]: samba_dlz: added rdataset talisker.bs.linet-services.de 'talisker.bs.linet-services.de.#0111200#011IN#011A#01110.199.92.129' Sep 30 15:13:19 trinculo named[3156]: samba_dlz: committed transaction on zone bs.linet-services.de

What should work, though, and what doesn’t seem to be attempted in the first place in your case, are updates to the host’s DNS entry.

Can you please try re-joining one machine to the domain and see whether that makes a difference?

Kind regards,
mosu

Interesting…actually all of the machines I have on my domain had to be re-added anyway after I did my domain takeover because they didn’t trust the UCS domain controller. So basically I’ve already re-added every domain machine to the domain, AFTER I finally got the domain controller side working properly yesterday. It was at that point that I noticed DNS wasn’t updating.

Hey,

well, a proper takeover should not leave the clients in a state where they don’t trust the new DC. Quite the opposite: one of the goals of AD takeover is not having to re-join all the clients, and that usually works just fine if the procedure is followed properly (e.g. shutting down all old DCs at the appropriate moment, re-booting any client running at that moment).

Anyway. Do I understand you correctly that you have already re-joined the clients successfully, but that they won’t update their DNS entries regardless?

Kind regards,
mosu

Sorry for the delay, it’s been a crazy week!

I have indeed re-joined all the clients, but none of them are registering in DNS. Active directory login works great, but DNS is not updating. I can even delete old DNS entries and they never re-appear (for a machine that is online and joined to the domain).

OK, so after being away from it a couple days, I’m noticing something really odd…

If I go into the server and look at the DNS clients, I see some of my machines are missing (as I suspected, because I deleted them and they did not renew). However, it seems that if I try to resolve these machines by name on other machines in the domain, the name resolution works. So for example, UCS doesn’t show a DNS entry for xs1-cent1, but if I try to ping xs1-cent1 from another domain client, it returns the correct IP address.

I do have a secondary DNS server but it’s not yet on the domain (basic local DNS on an Ubuntu server). Not quite sure what’s happening here…

Can you please run “ipconfig /registerdns” on such a Windows client (as administrator)? And then look at both the Linux server’s syslog as well as the Windows client’s event logs and see if there’s anything shedding some light on this?

Additionally please log in to the UMC and navigate to your DHCP settings: “Domain” → “DHCP” → click on the object for your domain → “Policies”. Here expand the section labeled “Policy: DHCP Dynamic DNS”. Is a policy selected there? What are the settings shown?

Ok, when I run ipconfig /registerdns, I see this in the event viewer:

[code]Log Name: System
Source: Microsoft-Windows-DNS-Client
Date: 10/10/2016 10:26:07 AM
Event ID: 8020
Task Category: (1028)
Level: Warning
Keywords:
User: NETWORK SERVICE
Computer: xs1-cent1.t4dlab.home
Description:
The system failed to register host (A or AAAA) resource records (RRs) for network adapter
with settings:

       Adapter Name : {71BBF026-08F7-4A54-BBE2-D98EB8A03D08}
       Host Name : xs1-cent1
       Primary Domain Suffix : t4dlab.home
       DNS server list :
         	10.1.110.3, 172.31.0.1, 8.8.4.4
       Sent update to server : <?>
       IP Address(es) :
         10.1.110.24

The reason the system could not register these RRs during the update request was because of a system problem. You can manually retry DNS registration of the network adapter and its settings by typing ‘ipconfig /registerdns’ at the command prompt. If problems still persist, contact your DNS server or network systems administrator. See event details for specific error code information.
Event Xml:



8020
0
3
1028
0
0x4000000000000000

3746


System
xs1-cent1.t4dlab.home



{71BBF026-08F7-4A54-BBE2-D98EB8A03D08}
xs1-cent1
t4dlab.home
10.1.110.3, 172.31.0.1, 8.8.4.4
<?>
10.1.110.24
9001

[/code]

Note that 10.1.110.3 is my UCS server.

Here’s what I find in syslog when I grep for the IP address 10.1.110.24:

Oct 10 09:27:02 xs1-ucsdc named[9090]: client 10.1.110.24#60664: update 't4dlab.home/IN' denied

I’m not using DHCP on the UCS server so there are no policies currently.

Hey,

OK.

The thing is that your client doesn’t even attempt to do a secure DNS update; otherwise you’d see more messages in /var/log/syslog from bind & its samba backend. It’s therefore likely that this is not a problem on the server’s side, but on the client’s.

Please make sure the following is the case on your test client:

The only IPv4 DNS server configured is the address of the UCS DC Master, either via DHCP or by setting it statically. See the output of “ipconfig /all” to verify. If it’s currently using a different DNS server please change it to the UCS DC Master’s address for the duration of the tests.

Please also make sure that the “DNS suffix” is the same as the domain your Active Directory structure is using.

Kind regards,
mosu

Hey,

additionally please review in-depth articles such as the first answer in this post. All those are things that can only be verified by having access to those machines — meaning you. I cannot really be of further assistance, I’m afraid.

Kind regards,
mosu

But why would the DNS server deny the update request? The Windows event viewer shows attempts by the machine several times per day, but they all fail for the same reason, and the DNS server (UCS) seems to be denying the request. UCS also shows a warning when I log in stating “Caution! The DNS service record for the UCS Master was not found in the DNS server.” This still seems to point to a problem with UCS.

The DNS suffix on my client is correct, and the client has three DNS servers (via DHCP), but the primary DNS is the UCS master.

Hey,

hmm you’re right, I seem to have mis-read the logs you’ve posted earlier. It’s quite possible the client attempts a secure update, that fails.

I’ve asked the Univention support for tips on this subject, and they’ve pointed me to a number of (open) bug reports. Maye one of those might be of use to you, too:

[ul][li]wrong owner sid for samba4 dns object after ad-takeover -> ddns update fails[/li]
[li]DDNS-Update bei zusätzlicher IP wird nicht revidiert[/li]
[li]DDNS update with wrong ownersid[/li]
[li]DDNS PTR update fails if IP is reused by other client[/li]
[li]DDNS update of Samba/AD doesn’t delete dnsRecord from dNSTombstoned Objects[/li][/ul]

Univention’s also working on a command-line based version of a basic health check. It’s work in progress, but you could give it a try, too. See this bug for the script. Please post its output here, especially the section about DNS entries.

Kind regards,
mosu

Thanks! The bug reports didn’t exactly seem to match what I’m seeing here, but the health check script did seem to have some interesting error messages:

[code]root@xs1-ucsdc:~# ./univention-check-health
Joined successfully
Ping to winbindd succeeded
checking the NETLOGON for domain[T4DLAB] dc connection to “xs1-ucsdc.t4dlab.home” succeeded
checking the trust secret for domain T4DLAB via RPC calls succeeded
ERROR: This Samba process 8869 is missing: notify-daemon
ERROR: Kerberos authentication via krb5.keytab against local SMBD doesn’t work
kinit: krb5_init_creds_set_keytab: Failed to find dns-xs1-ucsdc@T4DLAB.HOME in keytab FILE:/var/lib/samba/private/dns.keytab (unknown enctype)
ERROR: DNS update via Kerberos doesn’t work on this server
ERROR: The following objects have internal UDM SIDs

dn: cn=VPN Admins,cn=groups,dc=t4dlab,dc=home
sambaSID: S-1-4-5086

Default-First-Site-Name\XS1-UCSDC
DSA Options: 0x00000001
DSA object GUID: 18d26ee9-32e1-4521-b87f-cb6ced7afa36
DSA invocationId: 67b75ef4-353c-4320-b4ff-2bad5458b8e6

==== INBOUND NEIGHBORS ====

==== OUTBOUND NEIGHBORS ====

==== KCC CONNECTION OBJECTS ====

gc._msdcs.t4dlab.home has address 10.1.99.3
gc._msdcs.t4dlab.home has address 10.1.110.3
gc._msdcs.t4dlab.home has address 172.31.0.3
_gc._tcp.t4dlab.home has SRV record 0 100 3268 xs1-ucsdc.t4dlab.home.
_ldap._tcp.gc._msdcs.t4dlab.home has SRV record 0 100 3268 xs1-ucsdc.t4dlab.home.
_ldap._tcp.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_ldap._tcp.dc._msdcs.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_ldap._tcp.pdc._msdcs.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_ldap._tcp.1aeb0be7-ba60-4e94-a1a6-e688d7810418.domains._msdcs.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_kerberos._tcp.dc._msdcs.t4dlab.home has SRV record 0 100 88 xs1-ucsdc.t4dlab.home.
_kerberos._tcp.t4dlab.home has SRV record 0 100 88 xs1-ucsdc.t4dlab.home.
_kerberos._udp.t4dlab.home has SRV record 0 100 88 xs1-ucsdc.t4dlab.home.
_kpasswd._tcp.t4dlab.home has SRV record 0 100 464 xs1-ucsdc.t4dlab.home.
_kpasswd._udp.t4dlab.home has SRV record 0 100 464 xs1-ucsdc.t4dlab.home.
Located DC ‘xs1-ucsdc’ in site ‘Default-First-Site-Name’
18d26ee9-32e1-4521-b87f-cb6ced7afa36._msdcs.t4dlab.home is an alias for xs1-ucsdc.t4dlab.home.

Records for site Default-First-Site-Name:

_ldap._tcp.Default-First-Site-Name._sites.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.t4dlab.home has SRV record 0 100 389 xs1-ucsdc.t4dlab.home.
_kerberos._tcp.Default-First-Site-Name._sites.t4dlab.home has SRV record 0 100 88 xs1-ucsdc.t4dlab.home.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.t4dlab.home has SRV record 0 100 88 xs1-ucsdc.t4dlab.home.

Optional GC Records for site Default-First-Site-Name:

_gc._tcp.Default-First-Site-Name._sites.t4dlab.home has SRV record 0 100 3268 xs1-ucsdc.t4dlab.home.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.t4dlab.home has SRV record 0 100 3268 xs1-ucsdc.t4dlab.home.
_kerberos.t4dlab.home descriptive text “T4DLAB.HOME”
[/code]

Looks like maybe Kerberos is problematic? Also I noticed it says “Default-First-Site-Name” instead of “t4dlab.home”, which is the domain name I’m using.

[quote=“dbsoundman”]ERROR: Kerberos authentication via krb5.keytab against local SMBD doesn't work kinit: krb5_init_creds_set_keytab: Failed to find dns-xs1-ucsdc@T4DLAB.HOME in keytab FILE:/var/lib/samba/private/dns.keytab (unknown enctype) ERROR: DNS update via Kerberos doesn't work on this server[/quote]

That first message is very bad indeed, and the third one is most likely a direct result. It also matches what you’ve described in your posts so far.

I don’t have a good suggestion for how to fix this. However, there is the possibility to re-provision Samba 4 from the data in the master’s LDAP directory. As this re-builds the whole Samba 4 data the Kerberos thing might get fixed, too. However, I don’t know what kind of an effect this will have on existing Windows clients. But it most likely won’t get worse than it already is; Kerberos is a central component of any Active Directory domain and it not working is basically the sky falling down.

A safer but or course more expensive option is to contact Univention’s Professional Services (their support) and letting them fix this.

That’s normal. The default/first site in any Active Directory domain is always called “Default-First-Site-Name”.

Thanks for all your help, I gave up and reinstalled UCS and created a new domain controller. I didn’t have much to lose at this point, and now things seem to be working!

That’s a sensible solution, too. Sorry you had to go through all that extra work.