2
Vertrauensstellung zwischen zwei W2K8R2-Domänen mittels DNS
Hallo, ich habe mal wieder ein Problem:
Unser Netzwerk besteht aus mehreren Netzwerksegmenten. In dem internen Segment (privater Adressbereich) befindet sich bereits eine aktive Windows 2008 R2 Domäne mit DNS-Servern. In der DMZ (öffentlicher Adressbereich) soll nun eine zweite Domäne eingerichtet werden. Die Domänencontroller sind soweit installiert, allerdings bekomme ich Probleme bei der Herstellung einer Vertrauensstellung.
Im Moment ist auf allen DNS-Servern die jeweils eigene Zone als AD-integrierte primäre Zone festgelegt. Die DNS-Zone der jeweils anderen Domäne ist als Sekundäre Zone (nicht AD-integriert) eingerichtet. Die Zonenübertragung klappt soweit ohne Probleme und ein nslookup auf die FQDN der Domänen klappt auch gegenseitig (es werden die IP-Adressen der Domänencontroller zurückgegeben).
Wenn ich nun probiere eine Vertrauensstellung unter dem FQDN herzustellen (xy.local) dauert es einen kurzen Moment und dann bietet er mir nur an eine Bereichsvertrauensstellung zu erstellen. Als zweiten Punkt könnte ich nochmal eine Windows-Domäne auswählen (wieder xy.local) allerdings findet er sie hier auch nicht und bricht dann ab.
Wo genau könnte hier der Fehler liegen? Die beiden Netzwerke sind mittels Firewall getrennt, gibt es hier noch spezielle Ports die geöffnet werden müssen oder liegt eine Fehlkonfiguration des DNS vor?
Wenn ich nun probiere eine Vertrauensstellung unter dem FQDN herzustellen (xy.local) dauert es einen kurzen Moment und dann bietet er mir nur an eine Bereichsvertrauensstellung zu erstellen. Als zweiten Punkt könnte ich nochmal eine Windows-Domäne auswählen (wieder xy.local) allerdings findet er sie hier auch nicht und bricht dann ab.
Wo genau könnte hier der Fehler liegen? Die beiden Netzwerke sind mittels Firewall getrennt, gibt es hier noch spezielle Ports die geöffnet werden müssen oder liegt eine Fehlkonfiguration des DNS vor?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 191239
Url: https://administrator.de/contentid/191239
Printed on: April 25, 2024 at 18:04 o'clock
2 Comments
Latest comment
Moin,
Hort sich zuerstmal nach nem port problem und firewall an.
Welche ports sind denn offen?
Hort sich zuerstmal nach nem port problem und firewall an.
Welche ports sind denn offen?
Wir haben soweit eigentlich alle Ports geöffnet, die auf folgender Microsoft Seite angegeben sind: http://support.microsoft.com/kb/179442/de-de#method3
Port(s) Clients Server-Port Service
49152-65535/UDP 123/UDP W32Time
49152-65535/TCP 135/TCP RPC-Endpunktzuordnung
49152-65535/TCP 464/TCP/UDP Kerberos-Kennwortänderung
49152-65535/TCP 49152-65535/TCP RPC für LSA, SAM, Netlogon ()
49152-65535/TCP/UDP 389/TCP/UDP LDAP
49152-65535/TCP 636/TCP LDAP-SSL
49152-65535/TCP 3268/TCP LDAP-GC
49152-65535/TCP 3269/TCP LDAP-GC-SSL
53, 49152-65535/TCP/UDP 53/TCP/UDP DNS
49152-65535/TCP 49152-65535/TCP FRS-RPC ()
49152-65535/TCP/UDP 88/TCP/UDP Kerberos
49152-65535/TCP/UDP 445/TCP SMB
49152-65535/TCP 49152-65535/TCP DFSR-RPC (**)
Port(s) Clients Server-Port Service
49152-65535/UDP 123/UDP W32Time
49152-65535/TCP 135/TCP RPC-Endpunktzuordnung
49152-65535/TCP 464/TCP/UDP Kerberos-Kennwortänderung
49152-65535/TCP 49152-65535/TCP RPC für LSA, SAM, Netlogon ()
49152-65535/TCP/UDP 389/TCP/UDP LDAP
49152-65535/TCP 636/TCP LDAP-SSL
49152-65535/TCP 3268/TCP LDAP-GC
49152-65535/TCP 3269/TCP LDAP-GC-SSL
53, 49152-65535/TCP/UDP 53/TCP/UDP DNS
49152-65535/TCP 49152-65535/TCP FRS-RPC ()
49152-65535/TCP/UDP 88/TCP/UDP Kerberos
49152-65535/TCP/UDP 445/TCP SMB
49152-65535/TCP 49152-65535/TCP DFSR-RPC (**)
