Problem: Join Gives Error or Users Can Not Login Sometimes or Join Fails

[Christian_Voelker]

Problem:

Symptom 1:

Join gives an error or users can not login frequently.
User logon works for a while but fails suddenly. Different users are be affected but the users change. When trying to login through Windows they get “No Authentication Server available”.

Symptom 2:

The join of a system fails (likely in 98univention-samba4slavepdc-dns.inst, but not only) with the following written in the file /var/log/univention/join.log:

Failed to get Kerberos credentials, falling back to samba-tool: (3221225581, 'The attempted logon is invalid. This is either due to a bad username or authentication information.')

Investigation

Step 1

Check your DNS Settings.

How-To: Set Correct Nameserver and Forwarder Entries for UCS Servers

How to set correct nameserver and forwarder entries for UCS servers UCS (and ActiveDirectory) relies on reliable DNS resolving. It is very important to have DNS up and running correctly. Step 1: Set forwarder The forwarder will resolve all non-local domains so you will be able to access Internet services. You have to decide if you use the DNS server of your Internet provider or if you use some public available servers. Ideally, you should set at least a second forwarder as fallback in case of …

Step 2

Verify your to-be-joined computer can resolve domain controller DNS entries:

root@master:~# host gc._msdcs.$(ucr get domainname) 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

gc._msdcs.multi.ucs has address 10.250.200.101
gc._msdcs.multi.ucs has address 10.250.200.102
gc._msdcs.multi.ucs has address 10.250.200.100

Step 3

Check for legacy DNS zones.

root@ucs:~# univention-s4search CN=MicrosoftDNS --cross-ncs dn | grep -i "cn=system"
dn: DC=_msdcs,DC=multi.ucs,CN=MicrosoftDNS,CN=System,DC=multi,DC=ucs

There should NOT be a DC=_msdcs object entry below the CN=MicrosoftDNS,CN=System container.

Verify existence of additional zones by the DNS service in /var/log/daemon.log:

Mar 12 13:26:20 slave named[18248]: samba_dlz: Ignoring duplicate zone 'multi.ucs' from 'DC=@,DC=multi.ucs,CN=MicrosoftDNS,DC=DomainDnsZones,DC=multi,DC=ucs'
Mar 12 13:26:20 slave named[18248]: samba_dlz: Ignoring dnsZone _msdcs.multi.ucs

Step 4

The S4 connector by default synchronizes DNS entries from OpenLDAP to up-to-date location in Microsoft DNS. Previously (in Windows 2000) the DNS zones have been at a different location. Verify the S4 connector does not use legacy zones:

ucr get connector/s4/mapping/dns/position

Conclusion

There exists a duplicate zone in the legacy tree of CN=MicrosoftDNS,CN=System which gets loaded first by the named service. But as the S4 connector by default does not sync into the legacy tree this zone is very likely outdated.

Solution

Step 1

On the master (or @school-slave) migrate existing zone info to new location with the script migrate_legacy_dns_zones attached to
the Bug 43692 - Migrate Samba 4 DNS data from the legacy to the default partition. It is also essential that the unmodified script is used, please avoid Copy&Paste and rather use wget or similar methods.

Step 2

Now make sure the S4 connector does not sync to legacy branches:

ucr unset connector/s4/mapping/dns/position
systemctl restart univention-s4-connector

Step 3

If the issue still exists and you still find entries in your /var/log/daemon.log regarding duplicate zone, start over with step 1.
Remove the duplicate entry:

ldbdel -H /var/lib/samba/private/sam.ldb DC=_msdcs,DC=multi.ucs,CN=MicrosoftDNS,CN=System,DC=multi,DC=ucs
systemctl restart bind9

Now the join should be possible again and users should not notice any issues during logins.

---

legacy, dns , CN=MicrosoftDNS,CN=System , connector/s4/mapping/dns/position, migrate_legacy_dns_zones