DNS-Probleme nach AD-Takeover

vmayer · December 17, 2015, 2:46pm

Liebes Forum,

nach einem AD-Takover eines zugegebenermaßen vermutlich nicht sehr gepflegten AD aus einem 2008er-Windows hat fast alles auch funktioniert. Fast deswegen, weil leider das Neuaufnehmen einer Windows-Arbeitsstation in die Samba4-AD-Domäne des UCS-Servers mit der immer gleichen Fehlermeldung scheitert, dass nämlich der SRV-Record _ldap._tcp.dc._msdcs.domaene.local. nicht auflösbar sei.

Eine Abfrage mit dig bestätigt das:

[code]root@ucs-srv1:~# dig _ldap._tcp.dc._msdcs.domaene.local. srv

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _ldap._tcp.dc._msdcs.domaene.local. srv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29169
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.domaene.local. IN SRV

;; Query time: 11 msec
;; SERVER: 192.168.1.30#53(192.168.1.30)
;; WHEN: Thu Dec 17 15:24:28 2015
;; MSG SIZE rcvd: 54[/code]

Der entsprechende Eintrag ist aber gleichwohl im LDAP vorhanden:

[code]root@ucs-srv1:~# univention-ldapsearch relativeDomainName=_ldap._tcp.dc._msdcs

extended LDIF

LDAPv3

base <dc=domaene,dc=local> (default) with scope subtree

filter: relativeDomainName=_ldap._tcp.dc._msdcs

requesting: ALL

_ldap._tcp.dc._msdcs, domaene.local, dns, domaene.local

dn: relativeDomainName=_ldap._tcp.dc._msdcs,zoneName=domaene.local,cn=dns,dc
=domaene,dc=local
objectClass: top
objectClass: dNSZone
objectClass: univentionObject
univentionObjectType: dns/srv_record
sRVRecord: 0 100 389 ucs-srv1.domaene.local.
dNSTTL: 10800
relativeDomainName: _ldap._tcp.dc._msdcs
zoneName: domaene.local

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1[/code]

Was kann da passiert sein bzw. wo stehe ich da auf dem Schlauch?

Gruß, V. Mayer

Moritz_Bunkus · January 4, 2016, 3:25pm

Moin,

welches DNS-Backend ist eingestellt? Dafür bitte mal die Ausgabe von »ucr get dns/backend« posten.

Weiterhin interessant, ob im Samba 4 der Eintrag auch existiert. Dazu bitte mal »univention-s4search dc=_ldap._tcp.dc._msdcs« ausführen und Ergebnis posten. Danke.

vmayer · January 4, 2016, 4:09pm

Das scheint doch einen Hinweis auf das Problem zu geben:

[code]root@ucs-srv1:~# ucr get dns/backend
samba4
root@ucs-srv1:~# univention-s4search dc=_ldap._tcp.dc._msdcs
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

Referral

ref: ldap://domaene.local/CN=Configuration,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=DomainDnsZones,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=ForestDnsZones,DC=domaene,DC=local

returned 3 records

0 entries

3 referrals

[/code]

Gruß, V. Mayer

Moritz_Bunkus · January 4, 2016, 4:13pm

Moin,

jau. Das DNS-Backend == samba4 sagt, dass der DNS-Server seine Einträge direkt aus dem Samba4-Verzeichnis bezieht und nicht aus dem LDAP-Verzeichnis. Dass dieser Eintrag im Samba 4 nicht existiert ist ausgesprochen unschön.

Prüfen Sie bitte mal, ob es Rejects bei der Samba4-Synchronisation gibt: »univention-s4connector-list-rejected«. Falls welche gefunden werden: siehe hier

Eine relativ einfache Möglichkeit, das Syncen dieses Eintrages erneut anzustoßen, ist ihn auf LDAP-Seite zu verändern. Also einfach mal in der UDM den Eintrag heraussuchen, kurz ändern (z.B. die TTL), speichern, und gleichzeitig die Logdateien (allen voran »/var/log/univention/connector-s4.log«) beobachten.

Gruß,
Moritz

vmayer · January 4, 2016, 5:05pm

[quote=“Moritz Bunkus”]Dass dieser Eintrag im Samba 4 nicht existiert ist ausgesprochen unschön.

Prüfen Sie bitte mal, ob es Rejects bei der Samba4-Synchronisation gibt: »univention-s4connector-list-rejected«. Falls welche gefunden werden: siehe hier
[/quote]

Da gab es einen Reject, der mir aber damit nichts zu tun zu haben scheint. Nach der Anleitung aus der SDB konnte ich ihn entfernen und jetzt ist auch Ruhe im Log.

[quote=“Moritz Bunkus”]Eine relativ einfache Möglichkeit, das Syncen dieses Eintrages erneut anzustoßen, ist ihn auf LDAP-Seite zu verändern. Also einfach mal in der UDM den Eintrag heraussuchen, kurz ändern (z.B. die TTL), speichern, und gleichzeitig die Logdateien (allen voran »/var/log/univention/connector-s4.log«) beobachten.
[/quote]

Das ergibt dann auch die zu erwartende Reaktion im Log:

04.01.2016 17:43:22,51 LDAP (PROCESS): sync from ucs: [ dns] [ modify] dc=_ldap._tcp.dc,dc=_msdcs.domaene.local,cn=microsoftdns,dc=forestdnszones,DC=domaene,DC=local 04.01.2016 17:43:22,57 LDAP (PROCESS): sync from ucs: [ dns] [ modify] dc=@,dc=domaene.local,cn=microsoftdns,dc=domaindnszones,DC=domaene,DC=local 04.01.2016 17:43:23,250 LDAP (PROCESS): sync to ucs: [ dns] [ modify] zonename=domaene.local,cn=dns,dc=domaene,dc=local 04.01.2016 17:43:23,265 LDAP (PROCESS): sync to ucs: [ dns] [ add] relativeDomainName=@._msdcs,zonename=domaene.local,cn=dns,dc=domaene,dc=local

Leider ändert das aber nichts an der dennoch nicht funktionierenden DNS-Auflösung bzw. am Ergebnis von univention-s4search wie oben. Hm, wie geht’s weiter?

Gruß, V. Mayer

Moritz_Bunkus · January 5, 2016, 8:09am

Hmm, schade, ich hatte gehofft, beim Verändern würde ein nicht existierender Eintrag angelegt werden. Wohl nicht.

Dann halt die Holzhammermethode: merken Sie sich die Daten des Eintrags im LDAP (z.B. mit einem Screenshot), löschen Sie den Eintrag und legen Sie ihn erneut an. Was passiert dann?

vmayer · January 11, 2016, 6:24pm

Jetzt wird’s “lustig”. Das hat leider auch nicht geholfen, aus dem connector-s4.log

11.01.2016 19:15:17,316 LDAP (PROCESS): sync from ucs: [ dns] [ delete] dc=_ldap._tcp.dc,dc=_msdcs.domaene.local,cn=microsoftdns,dc=forestdnszones,DC=domaene,DC=local 11.01.2016 19:15:17,331 LDAP (PROCESS): sync from ucs: [ dns] [ modify] dc=@,dc=domaene.local,cn=microsoftdns,dc=domaindnszones,DC=domaene,DC=local 11.01.2016 19:15:18,520 LDAP (PROCESS): sync to ucs: [ dns] [ delete] relativeDomainName=_ldap._tcp.dc DEL:d58a8353-5390-40b1-a882-2505f84ed908,zonename=domaene.local,cn=dns,dc=domaene,dc=local 11.01.2016 19:15:18,527 LDAP (PROCESS): sync to ucs: [ dns] [ modify] zonename=domaene.local,cn=dns,dc=domaene,dc=local 11.01.2016 19:15:18,542 LDAP (PROCESS): sync to ucs: [ dns] [ add] relativeDomainName=@._msdcs,zonename=domaene.local,cn=dns,dc=domaene,dc=local 11.01.2016 19:17:03,32 LDAP (PROCESS): sync from ucs: [ dns] [ add] DC=_ldap._tcp.dc,DC=_msdcs.domaene.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=domaene,DC=local 11.01.2016 19:17:03,44 LDAP (PROCESS): sync from ucs: [ dns] [ modify] dc=@,dc=domaene.local,cn=microsoftdns,dc=domaindnszones,DC=domaene,DC=local 11.01.2016 19:17:04,233 LDAP (PROCESS): sync to ucs: [ dns] [ modify] relativedomainname=_ldap._tcp.dc._msdcs,zonename=domaene.local,cn=dns,dc=domaene,dc=local 11.01.2016 19:17:04,243 LDAP (PROCESS): sync to ucs: [ dns] [ modify] zonename=domaene.local,cn=dns,dc=domaene,dc=local 11.01.2016 19:17:04,257 LDAP (PROCESS): sync to ucs: [ dns] [ add] relativeDomainName=@._msdcs,zonename=domaene.local,cn=dns,dc=domaene,dc=local

Und dennoch:

[code]root@ucs-srv1:~# univention-s4search dc=_ldap._tcp.gc._msdcs
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

Referral

ref: ldap://domaene.local/CN=Configuration,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=DomainDnsZones,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=ForestDnsZones,DC=domaene,DC=local

returned 3 records

0 entries

3 referrals

[/code]

Ich bleibe ratlos.

Gruß, V. Mayer

Moritz_Bunkus · January 12, 2016, 7:56am

Das sieht so aus, als würde Samba selber dafür sorgen, dass der Eintrag _ldap existiert. Warum? Keine Ahnung, dafür kenne ich mich leider auf der AD-Seite zu wenig aus.

Was Sie mal probieren können, ist mit den Windows-eigenen AD-Tools den DNS-Eintrag für _ldap zu ändern. Das geschieht dann im Samba-LDAP und sollte automatisch ins UCS-LDAP synchronisiert werden.

Moritz_Bunkus · January 12, 2016, 8:04am

Stopp. Bevor Sie manuell modifizieren, posten Sie bitte nochmal mehr Infos:

Anschneinend trägt Samba im _ldap-Eintrag automatisch alle Namen aller registrierten DCs ein. Bitte posten Sie mal die Ausgabe desn folgenden Befehls: »univention-s4search dc=_ldap._tcp.dc._msdcs dnsRecord|ldapsearch-wrapper|ldapsearch-decode64« Dieser wird leicht komische (binäre) Daten enthalten, nicht wundern.

Weiterhin hätte ich gerne die Ausgabe dieses Befehls: »univention-s4search -b “OU=Domain Controllers,$(ucr get ldap/base)” dn«

Meine Vermutung ist, dass irgendwie noch ein Eintrag für einen (alten?) DC im Samba existiert, und dass dieser DC nun mal nicht mehr läuft und/oder sein Name im DNS nicht mehr auflösbar ist.

Danke.

vmayer · January 12, 2016, 12:17pm

Das Problem scheint grundlegenderer Natur zu sein. Hier:

[code]root@ucs-srv1:~# univention-s4search dc=_ldap._tcp.dc._msdcs dnsRecord|ldapsearch-wrapper|ldapsearch-decode64
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

Referral

ref: ldap://domaene.local/CN=Configuration,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=DomainDnsZones,DC=domaene,DC=local

Referral

ref: ldap://domaene.local/DC=ForestDnsZones,DC=domaene,DC=local

returned 3 records

0 entries

3 referrals[/code]

Und hier:

[code]root@ucs-srv1:~# univention-s4search -b “OU=Domain Controllers,$(ucr get ldap/base)” dn
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

record 1

dn: CN=UCS-SRV1,OU=Domain Controllers,DC=domaene,DC=local

record 2

dn: CN=RID Set,CN=UCS-SRV1,OU=Domain Controllers,DC=domaene,DC=local

record 3

dn: OU=Domain Controllers,DC=domaene,DC=local

returned 3 records

3 entries

0 referrals[/code]

Gruß, V. Mayer

PS: Zwischendurch übrigens mal allerherzlichsten Dank für die geduldige Hilfe!

Moritz_Bunkus · January 12, 2016, 12:23pm

Können sie mit univention-s4search überhaupt das Samba-LDAP durchsuchen?

vmayer · January 12, 2016, 12:27pm

Ja, das geht, bei nur univention-s4search kommt ziemlich viel an konkreten Directory-Inhalten raus.

Gruß, V. Mayer

Moritz_Bunkus · January 13, 2016, 3:46pm

Moin,

OK das ist alles nicht so einfach Das kann noch einiges an Nachforschen erfordern.

Welche UCS-Version verwenden Sie?

Weiterhin bitte mal die Ausgabe von folgenden Befehlen anhängen:

»univention-s4search dc=_ldap._tcp.dc --cross-ncs«
»service bind9 restart« und anschließend »grep named /var/log/syslog« (nur die Ausgabe vom »grep« ist hier relevant; der Restart sorgt nur dafür, dass gewisse, beim Starten ausgegebene Meldungen auch wirklich in /var/log/syslog stehen)

Danke.

Gruß,
mosu

vmayer · January 18, 2016, 7:06pm

[quote=“Moritz Bunkus”]Moin,

OK das ist alles nicht so einfach Das kann noch einiges an Nachforschen erfordern.

Welche UCS-Version verwenden Sie?
[/quote]
Moin Herr Bunkus,

aktuell ist es noch 4.0-4

zu 1.:

[code]root@ucs-srv1:~# univention-s4search dc=_ldap._tcp.dc --cross-ncs
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

record 1

dn: DC=_ldap._tcp.dc,DC=_msdcs.domaene.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=domaene,DC=local
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160111181703.0Z
whenChanged: 20160111181703.0Z
uSNCreated: 8713
uSNChanged: 8713
showInAdvancedViewOnly: TRUE
name: _ldap._tcp.dc
objectGUID: 94d49c0c-7c4b-4815-9ddc-81a2d560cd99
dnsRecord:: base64maskiertxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,DC=domaene,DC=local
dc: _ldap._tcp.dc
distinguishedName: DC=_ldap._tcp.dc,DC=_msdcs.domaene.local,CN=MicrosoftDNS,
DC=ForestDnsZones,DC=domaene,DC=local

returned 1 records

1 entries

0 referrals[/code]

und zu 2.:

Jan 18 20:00:42 ucs-srv1 named[15970]: shutting down Jan 18 20:00:42 ucs-srv1 named[15970]: stopping command channel on 127.0.0.1#953 Jan 18 20:00:42 ucs-srv1 named[15970]: no longer listening on ::#53 Jan 18 20:00:42 ucs-srv1 named[15970]: no longer listening on 127.0.0.1#53 Jan 18 20:00:42 ucs-srv1 named[15970]: no longer listening on 10.11.x.y#53 Jan 18 20:00:42 ucs-srv1 named[15970]: no longer listening on 10.12.x.y#53 Jan 18 20:00:42 ucs-srv1 named[15970]: no longer listening on 192.168.x.y#53 Jan 18 20:00:42 ucs-srv1 named[15970]: samba_dlz: shutting down Jan 18 20:00:42 ucs-srv1 named[15970]: exiting Jan 18 20:00:48 ucs-srv1 named[7097]: starting BIND 9.8.4-rpz2+rl005.12-P1 -c /etc/bind/named.conf.samba4 -f -d 0 Jan 18 20:00:48 ucs-srv1 named[7097]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' '--with-dlz-dlopen' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' Jan 18 20:00:48 ucs-srv1 named[7097]: ---------------------------------------------------- Jan 18 20:00:48 ucs-srv1 named[7097]: BIND 9 is maintained by Internet Systems Consortium, Jan 18 20:00:48 ucs-srv1 named[7097]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Jan 18 20:00:48 ucs-srv1 named[7097]: corporation. Support and training for BIND 9 are Jan 18 20:00:48 ucs-srv1 named[7097]: available at https://www.isc.org/support Jan 18 20:00:48 ucs-srv1 named[7097]: ---------------------------------------------------- Jan 18 20:00:48 ucs-srv1 named[7097]: adjusted limit on open files from 4096 to 1048576 Jan 18 20:00:48 ucs-srv1 named[7097]: found 24 CPUs, using 24 worker threads Jan 18 20:00:48 ucs-srv1 named[7097]: using up to 4096 sockets Jan 18 20:00:48 ucs-srv1 named[7097]: loading configuration from '/etc/bind/named.conf.samba4' Jan 18 20:00:48 ucs-srv1 named[7097]: reading built-in trusted keys from file '/etc/bind/bind.keys' Jan 18 20:00:48 ucs-srv1 named[7097]: using default UDP/IPv4 port range: [1024, 65535] Jan 18 20:00:48 ucs-srv1 named[7097]: using default UDP/IPv6 port range: [1024, 65535] Jan 18 20:00:48 ucs-srv1 named[7097]: listening on IPv6 interfaces, port 53 Jan 18 20:00:48 ucs-srv1 named[7097]: listening on IPv4 interface lo, 127.0.0.1#53 Jan 18 20:00:48 ucs-srv1 named[7097]: listening on IPv4 interface eth2, 10.11.12.100#53 Jan 18 20:00:48 ucs-srv1 named[7097]: listening on IPv4 interface eth3, 10.12.11.100#53 Jan 18 20:00:48 ucs-srv1 named[7097]: listening on IPv4 interface br0, 192.168.1.30#53 Jan 18 20:00:48 ucs-srv1 named[7097]: generating session key for dynamic DNS Jan 18 20:00:48 ucs-srv1 named[7097]: sizing zone task pool based on 1 zones Jan 18 20:00:48 ucs-srv1 named[7097]: Loading 'samba4.zone' using driver dlopen Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: WARNING: No path in service IPC$ - making it unavailable! Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: NOTE: Service IPC$ is flagged unavailable. Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: started for DN DC=domaene,DC=local Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: starting configure Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: trying partition 'CN=MicrosoftDNS,CN=System,DC=domaene,DC=local' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: configured writeable zone '1.168.192.in-addr.arpa' 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: trying partition 'CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: configured writeable zone 'domaene.local' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: trying partition 'CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: configured writeable zone 'dev' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: trying partition 'CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: configured writeable zone 'fun' Jan 18 20:00:48 ucs-srv1 named[7097]: samba_dlz: Ignoring dnsZone _msdcs.domaene.local Jan 18 20:00:48 ucs-srv1 named[7097]: set up managed keys zone for view _default, file 'managed-keys.bind' Jan 18 20:00:48 ucs-srv1 named[7097]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 0.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 127.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 254.169.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: D.F.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 8.E.F.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 9.E.F.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: A.E.F.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: B.E.F.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jan 18 20:00:48 ucs-srv1 named[7097]: command channel listening on 127.0.0.1#953 Jan 18 20:00:48 ucs-srv1 named[7097]: managed-keys-zone ./IN: loaded serial 0 Jan 18 20:00:48 ucs-srv1 named[7097]: running

Bei dem Ausschnitt aus dem Syslog habe ich jetzt nur mal den Teil nach dem Restart angegeben.

Gruß, V. Mayer

stoeckigt · January 20, 2016, 5:26pm

Hallo V. Mayer,

die Meldung “pre-W2k3 zone found” zeigt, dass das dlz_bind9 Modul unterhalb der DN ‘CN=MicrosoftDNS,CN=System,DC=domaene,DC=local’ eine DNS-Zone gefunden hat:

Daraufhin ignoriert der C-Code die’ _msdcs’ Partition, die vom AD-System unter ‘DC=ForestDnsZones’ abgelegt wurde:

Bitte posten Sie mal die Ausgabe des folgenden Befehls:

univention-s4search --cross-ncs objectClass=dnsZone dn

Anhand der Ausgabe entscheidet sich wie hier weiter verfahren werden kann.

Mit freundlichem Gruß
Nico Stöckigt

vmayer · January 20, 2016, 5:32pm

stoeckigt:

Bitte posten Sie mal die Ausgabe des folgenden Befehls:
univention-s4search --cross-ncs objectClass=dnsZone dn
Anhand der Ausgabe entscheidet sich wie hier weiter verfahren werden kann.

Moin zusammen, das ist doch mal ein Hinweis!

Hier:

[code]root@ucs-srv1:~# univention-s4search --cross-ncs objectClass=dnsZone dn
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS

record 1

dn: DC=domaene.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local

record 2

dn: DC=RootDNSServers,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local

record 3

dn: DC=custom1,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local

record 4

dn: DC=custom2,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domaene,DC=local

record 5

dn: DC=_msdcs.domaene.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=domaene,DC=local

record 6

dn: DC=…TrustAnchors,CN=MicrosoftDNS,DC=ForestDnsZones,DC=domaene,DC=local

record 7

dn: DC=1.168.192.in-addr.arpa,CN=MicrosoftDNS,CN=System,DC=domaene,DC=local

record 8

dn: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domaene,DC=local

returned 8 records

8 entries

0 referrals[/code]

Gruß, V. Mayer

stoeckigt · January 21, 2016, 9:10am

Der Eintrag ‘1.168.192.in-addr.arpa’ muß von ‘CN=System’ nach ‘CN=DomainDnsZones’ verschoben werden. Zwar ist auch der Eintrag ‘RootDNSServers’ an der gleichen Stelle, er sollte aber nicht verschoben werden sondern genau da verbleiben.

Da ein ldbrename nicht funktioniert muss man den Eintrag mit ldbsearch kopieren, die CN korrigieren und über ldbadd wieder hinzufügen. Da auch eventuelle Leafs mit angepasst werden müssen, empfiehlt es hier ein kleines Script zu verwenden.
Wenn nach einem Neustart des Nameservers alles wie gewünscht funktioniert, kann man den alten Eintrag entfernen.

Mit freundlichem Gruß
Nico Stöckigt