ASA und Server 2008 AD-Connect

[Zweckoptimist 10]

Hallo zusammen! :)

 

Ich versuche schon seit längerem unseren neuen Webserver

aus der DMZ heraus mit unserem AD zu verbinden

(..zur Abfrage der FTP-berechtigten User).

Dazu habe ich ihn zum Memberserver gemacht und kann mich

auch dort anmelden und alles einstellen solange ich die hier

aufgeführten Ports 'UND (!) TCP (all) bzw. IP (all)' zwischen

dem WEB und zwei DCs aktiviert habe:

TCP + UDP: DNS (53), WINS (42), NetBIOS (137), SMB (445),

NTP (123), Kerberos (88 + 464), LDAP (389 + 636)

CIFS (445), RPC (135), SNMP (161 + 162), WinIntNS (1512)

Nur TCP: NetBIOS (139), RS (1025), CR (507), GC (3268 + 3269)

LSAR (691), ASP.Net (42424)

Nur UDP: Kerberos (750), NetBIOS (138)

 

Für den AD-Connect fehlt mir jedoch ein Port. Mit TCP (all) oder IP (all)

bekomme ich dort bei der Anmeldung 1 Hit und finde den Port nicht heraus.

 

Den dynamischen Portbereich habe ich mit

Netsh int, ipv4 set dynamicport tcp start=5000 num=5100 und

Netsh int, ipv4 set dynamicport udp start=5000 num=5100

auf dem Server selbst zu begrenzen versucht und die Range auch

so auf der ASA eingetragen, jedoch bekomme ich dort keinen Treffer.

 

Auch wenn ich eine tcp-udp-Range von 1-1023 und eine von 1024-65535

eingebe (ich wollte es nach und nach eingrenzen) gibt es dort keinen Treffer.

 

Die Anmeldung dauert 4 1/2 Minuten und ich kann die User aus

dem AD so nicht abfragen. Lediglich, wie gesagt bei aktiviertem

TCP (all) bzw. IP (all) bekomme ich dort den Treffer und bin umgehend

verbunden.

 

Welcher Port fehlt mir oder wo liegt mein Denkfehler?

Jemand eine Idee?

 

Gruß

Christian

[Wordo 11]

Ich hab hier auch ne MS-Trust Gruppe, da is noch Port 390 (TCP und UDP), NTP (123/UDP) und ICMP any dabei.

Vielleicht hilfts ja ... :)

[blackbox 10]

Hast du einfach mal bei einem "all" das ganze mit Tracen gelassen - dann siehst du doch welche Ports. Ich würde jedoch nicht aus einer DMZ auf eine AD so zugreifen - sondern sich da was anderes einfallen lassen - den dann macht die ganze DMZ keinen so richtigen Sinn mehr - da man wenn man auf dem Server ist und der Client in der AD ist - man sehr schön die AD auslesen kann.

[Zweckoptimist 10]

Danke für Deine schnelle Antwort! :)

 

ICMP any hatte ich vergessen zu posten.

 

Sah auch zunächst gut aus mit dem Port 390, nach einem

Neustart jedoch wieder das gleiche Problem.. :(

[blackbox 10]

Siehst du den im Logging an der ASA was - das ein Port geblockt wird ?

[Zweckoptimist 10]

Nun, grundsätzlich hast Du schon recht,

aber wir haben zahlreiche Benutzer die

sich für verschiedene Dienste über das

AD anmelden und wir somit eine einheitliche

Benutzerverwaltung haben.

Das würden wir gerne auf dem Webserver ebenfalls

haben um dort nicht lokale User pflegen zu müssen.

Daher versuche ich nur die nötigsten Ports dafür

zu öffnen.

ggf. würde ich auch mit ADLDS da ran gehen,

wenn ich den Connect kriegen würde... :cool:

[Zweckoptimist 10]

Grundsätzlich gibt es zwar schon eine 'any -> dc deny-Regel'

aber auf Deinen Tip hin habe ich mal eine 'Web -> dc' (deny)

hinzugefügt und bekomme bei einer Anmeldung 16 hits..

[blackbox 10]

Dann solltest du im Logging das ganze auch sehen - am besten auf die IP des Webservers filtern

[Otaku19 33]

das ist definitv ein Fall für capture :) da sieht man gleich welche Pakete da vom Webserver an der ASA ankommen...oder ob auf irgendwelchen merkwürdigen Ports vom AD Antworten kommen.

Anahnd dieser Infos packet-tracer starten und schon weiß man wo es hakt

[Zweckoptimist 10]

Ok, danke. ich probiere das mal und berichte dann wieder :)

 

Gruß

Christian

[Zweckoptimist 10]

So, die Ports konnte ich nun auf ein Minimum eingrenzen:

 

TCP/UDP 135 - RPC Cert Services

UDP 53 - DNS

TCP 445 - SMB (input)

TCP/UDP 123 - NTP

TCP 507 - Content Replication

TCP 88 - Kerberos v5

TCP/UDP 389 - LDAP

und

TCP 49100-49199

 

Mit diesen Einstellungen bekomme ich keinen Treffer mehr

auf der Deny-Regel und kann mich problemlos mit dem AD

verbinden. :)

 

Danke für Eure Hilfe.

 

Grüße

[Otaku19 33]

jetzt weißt du auch warum man im Netzwerk dann immer von diesem "elenden Windows Mist" spricht wenn da zig verschiedene Ports aufgerissen werden :) aber der "elende SAP Mist" ist noch viel schlimmer ;) ein Hoch auf auf object-groups !