DNS-Probleme in Samba/AD Domänen
falls DNS-Einträge nicht aufgelöst werden können oder Adressen von Windows-Client-Systemen im DNS nicht aktuell zu sein scheinen, kann dies unterschiedliche Ursachen haben. Um den Ursprung des Problems einzugrenzen, ist es sinnvoll, im ersten Schritt die Datei ‘/var/log/daemon.log’ zu prüfen. Beim Neustart des DNS-Server-Prozesses bind9 gibt dieser dort Meldungen darüber aus, welche Zonen-Daten in Samba/AD gefunden wurden und welche er verwendet. Microsoft hat im Laufe der AD-Versionen zwei unterschiedliche Speicherorte für DNS-Zonen im Active Directory verwendet. In UCS-Domänen mit Samba/AD Domänencontrollern, die vor UCS 3.1 installiert wurden, wird der alte Speicherort (umgangssprachlichpre-W2k3 genannt) verwendet. In UCS-Domänen die mit UCS 3.1 oder später installiert worden sind, werden hingegen andere Speicherorte in Samba/AD verwendet. Bei Domänen, die von UCS 3.1 aktualisiert wurden, und wo dann im Laufe der Zeit neue UCS-Server installiert wurden, kann es zu Problemen kommen, falls der S4-Connector einen anderen Speicherort berücksichtigt als der bind9 DNS-Server. In speziellen Fällen kann es sogar sein, dass DNS-Records aus der _msdcs Sub-Zone nicht mehr vom DNS-Server aufgelöst werden können, obwohl sie in der Zone vorhanden sind.
Wenn man DNS-Probleme hat und beim Neustart von bind9 sich folgende Zeilen im ‘/var/log/daemon.log’ findet, dann ist es sinnvoll in die Analyse unten einzusteigen:
Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: pre-W2k3 zone found
Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: Ignoring dnsZone _msdcs.domain.intranet
Falls sich solche Zeilen nicht finden, dann ist dieser Artikel nicht relevant.
Analyse
Nun sollte man im DNS-Backend, also im Samba/AD, die DNS-Zonen und ~Einträge prüfen
univention-s4search --cross-ncs objectClass=dnsZone dn
Hier kann es nun vorkommen, dass beispielsweise die Reverse-Zone unter CN=MicrosoftDNS,CN=System,DC=domaene,DC=intranet liegt - es können aber auch einfach nur verschiedene Einträge (z.B. Service-Records) sein. Diese müssen nun in den korrekten Abschnitt im DNS verschoben werden.
Lösung
Achtung: diese Lösung ist veraltet. Bitte erstmal die Schritte aus diesem Artikel verfolgen:
==========vvvvvvvvvvv========== depricated ==========vvvvvvvvv=================
Zunächst erzeugt man aus OpenLDAP heraus ein Backup
univention-ldapsearch -LLLo ldif-wrap=no -b cn=dns,$( ucr get ldap/base ) >ucs_dns_full.ldif
Dann löscht man die fehlerhaften Einträge aus Samba/AD
ldbedit -H /var/lib/samba/private/sam.ldb --cross-ncs
Dadurch werden zwar auch die Einträge, über die Replikation, im OpenLDAP entfernt, dafür haben wir aber oben das Backup angelegt welches wir jetzt wieder importieren
ldapadd -h localhost -p 7389 -D "cn=admin,$( ucr get ldap/base )" -y /etc/ldap.secret -f ucs_dns_full.ldif
Jetzt werden die Einträge auch wieder in Samba/AD repliziert, diesmal aber an die richtige Stelle.
Der Neustart des bind9 sollte jetzt die beiden oben erwähnten Zeilen nicht mehr schreiben.