DMZ für ActiveDirectory-Anmeldung aufbohren?

[pete.db 10]

Hallo,

könnt ihr mit eure Erfahrungen zu folgendem Szenario schildern?

 

Ich habe in unserer DMZ einen SQL Server stehen, an dem sich Mitarbeiter mit ihrem AD-Account anmelden sollen.

AD befindet sich im internen Netz.

 

Bohre ich meine DMZ dafür soweit auf, dass ich die Anmeldung aus der DMZ zulasse oder stelle ich einen AD-Server in die DMZ und lasse nur die Replikation durch die Firewall?

 

Hab gehört, dass für die AD-Anmeldung knapp 15 Ports durchgeschleift werden müssen?!

 

Danke

pete

[B6n 10]

Hmm, also meine Meinung ist, dass ein Domänencontroller aber auch mal gar nichts in der DMZ zu suchen hat. Wozu hast Du denn dann eine DMZ?

 

Microsoft sagt:

 

Öffnen Sie die folgenden Ports für eingehenden Netzwerkverkehr, um für Computer mit dem Betriebssystem Windows 2000 Server eine Anmeldung bei der Domäne durch eine Firewall zu ermöglichen:• 53 (Transmission Control Protocol [TCP], User Datagram Protocol [uDP]) - Domain Name System (DNS) zu allen DNS-Servern, die in der IP-Konfiguration des Frontend-Servers aufgeführt sind.  
• 80 (TCP) - Wird von Exchange 2000 Outlook Web Access für den Zugriff auf die Kommunikation zwischen Exchange-Frontend- und -Backend-Servern benötigt.  
• 88 (Transmission Control Protocol [TCP], UDP) - Kerberos-Authentifizierung zu allen Domänencontrollern, die sich im selben Active Directory-Standort befinden wie der Exchange-Frontend-Server. 
• 123 (UDP) - Windows Time Synchronization Protocol (NTP) zu allen Domänencontrollern, die sich im selben Active Directory-Standort befinden wie der Exchange-Frontend-Server. Dieses Protokoll wird für Windows 2000-Anmeldefunktionen nicht benötigt, kann jedoch durch den Netzwerkadministrator gefordert oder konfiguriert werden.  
• 135 (TCP) - EndPointMapper (Endpunktzuordnung) zu allen Domänencontrollern, die sich im selben Active Directory-Standort befinden wie der Exchange-Frontend-Server. 
• 389 (TCP, UDP) - Lightweight Directory Access Protocol (LDAP) zu allen Domänencontrollern, die sich im selben Active Directory-Standort befinden wie der Exchange-Frontend-Server.  
• 445 (TCP) - Server Message Block (SMB) für Netlogon, LDAP-Konvertierung und die Erkennung für das verteilte Dateisystem (Distributed File System, DFS) von Microsoft zu allen Domänencontrollern, die sich im selben Active Directory-Standort befinden wie der Exchange-Frontend-Serverr.  
• 3268 (TCP) - LDAP zu globalen Katalogservern. 

[olc 18]

Hi,

 

wie B6n schon schrieb, wird im Normalfall kein DC in die DMZ gestellt. Dieses Szenario sollte man sich wirklich sehr genau überlegen...

 

Trotzdem der Hinweis, daß in der geposteten Portliste neben dem "verschobenen" DNS 53/UDP auch weitere dynamische RPC Ports freigegeben werden müssen, solltest Du die RPC Kommunikation nicht auf einen beschränkten Portbereich gebunden haben. Ohne die Portbindung muß der Portbereich 1024 - 65535/TCP ebenfalls freigegeben werden. Ist beispielsweise LDAP/S im Spiel, kommt noch Port 636 dazu.

 

Viele Grüße

olc

[pete.db 10]

Hmm,

danke erstmal für eure Antworten.

Zwischen den Zeilen (auch in anderen Infos zu dem Thema) kann mal lesen, dass sowas eher nicht das Mittel der Wahl zu sein scheint.

Entweder ich stellen einene DC in die DMZ (keine gute Idee) oder ich bohre 15 u.a. dynamische Löcher in meine Firewall (auch keine gute Idee).

 

Wie wird sowas sonst gelöst? Das kann doch eigentlich keine Ausnahmesituation sein.

 

Mir geht es darum, zwei Webserver in der DMZ zu haben, die sich ihre Daten von einem SQL Server holen (soweit ziemlich Standard). Soll ich nun eher den SQL Server ins interne Netz stellen und die Ports für SQL Anfragen von den Webservern weiterleiten?

Ich muss allerdings auch Benutzerrechte auf den Webservern vergeben (welcher Entwickler darf in welches Web Daten uploaden). Dies soll auch alles über die AD-Konten gehen...

 

pete

[olc 18]

Hi Pete,

 

das haben wir nicht nur "zwichen den Zeilen" geschrieben, sondern ganz klar und deutlich gesagt. ;)

 

Der Webserver gehört in die DMZ, der SQL-Server kann durchaus im geschützten Netzwerk stehen. Soweit ich weiß, setzen viele größere Instalklationen eine solche Konfiguration ein.

 

Das Aktualisieren der Daten muß nicht über Shares mit AD-Anbindung erfolgen. FTP kann hier eine Alternative sein - jedoch ist ohne Anbindung an die AD eine eigene Benutzerverwaltung angesagt.

 

Theoretisch wäre es möglich, in die DMZ z.B. eine ADAM Installation zu packen, die die LDAP Daten der entsprechenden Benutzer aus der AD zieht. Hierfür muß "nur" LDAP Traffic in die DMZ gestattet sein. Die Benutzerauthentifizierung könnte dann gegen das LDAP Verzeichnis gehen.

 

Die Benutzerdaten liegen dann jedoch ebenfalls in der DMZ, was auch wieder nicht gewünscht ist. Hier könnte man jedoch mittels ISA o.ä. über Proxy-Objekte in der ADAM Instanz etwas Sicherheit schaffen. Ein IT-Systemhaus in Deiner Umgebung kann Dir hier vielleicht weiterhelfen und ein Projekt dafür ausarbeiten.

 

Viele Grüße

olc

[pete.db 10]

Also der ADAM hört sich recht gut an. Kannte ich bislang noch gar nicht.

 

Je länger ich über das Problem nachdenke, desto mehr drängt sich mir die Frage auf, wie das sonst gelöst wird.

Es geht mir hier ja auf lange Sicht nicht mehr "nur" um die reinen Webserver.

Was ist mit Webs, die "Integrated Security nutzen?

Was ist mit SharePoint und/oder OWA vom Exchange?

Alles Dienste, die in eine DMZ gehören, an denen sich Anwender aber über ihre AD-Konten anmelden...

[NorbertFe 2.027]

Was ist mit SharePoint und/oder OWA vom Exchange?

 

Dafür gibts den ISA von MS der das sehr gut löst (reverse Proxy), und Features bietet, die wenige der Konkurrenz können.

 

Ansonsten schau dir bspw. von Citrix mal XenApp an, die haben auch für die DMZ eine Komponente entwickelt, um auf die Server im LAN zuzugreifen.

 

Bye

Norbert

[olc 18]

Hi,

 

im Grunde gibt es für solche Szenarien drei Möglichkeiten (neben anderen, jedoch werden die folgenden drei wahrscheinlich am häufigsten eingesetzt):

 

1. Im Normalfall ist es z.B. bei Exchange / OWA nicht (mehr) empfohlen, die Systeme in die DMZ zu stellen, sondern ins interne oder ein "Dienste"-Netz. Ich weiß nicht, inwieweit sich das mit Exchange 2007 geändert hat, da hier ja mehr Exchange Rollen existieren als nur Front-End und Back-End.

Bei Applikationsservern wird oftmals versucht, die "ausliefernden Systeme" in eine DMZ zu stellen (z.B. Webserver, siehe oben), die Datenbank jedoch ins interne Netz bzw. besser in ein "Dienste"-Netz.

 

2. Wie Norbert schon sagte, bietet der ISA Server z.B. einige Varianten, ein solches Szenario zu ermöglichen. Daher auch mein Hinweis oben.

Schau einmal in das folgende Whitepaper, da wird das Thema SharePoint in DMZ plus ISA besprochen: Download details: SharePoint Portal Server 2003 Document: Deploying on an Extranet by Using ISA Server 2000 and ISA Server 2004

 

3. Terminalservices sind auch eine Variante, jedoch wird hier meist vorher eine VPN-"Einwahl" in das (DMZ-) Netz genutzt, so daß sich das Szenario ein wenig verändert.

 

Viele Grüße

olc

[NorbertFe 2.027]

3. Terminalservices sind auch eine Variante, jedoch wird hier meist vorher eine VPN-"Einwahl" in das (DMZ-) Netz genutzt, so daß sich das Szenario ein wenig verändert.

 

Deswegen ja Citrix. Nix mit VPN. Kost allerdings auch ein paar Taler.

 

Bye

Norbert

[olc 18]

Hi Norbert,

 

soweit ich weiß nutzt Cirtix (und andere Systeme) auch einen eigenen Client, der dann eine verschlüsselte Verbindung zum Terminalserver aufbaut. Es handelt sich also hierbei auch um ein VPN.

 

Viele Grüße

olc

[NorbertFe 2.027]

Hi Norbert,

 

soweit ich weiß nutzt Cirtix (und andere Systeme) auch einen eigenen Client, der dann eine verschlüsselte Verbindung zum Terminalserver aufbaut. Es handelt sich also hierbei auch um ein VPN.

 

Viele Grüße

olc

 

Hi,

 

So betrachtet dann schon, allerdings sprichst du bei Citrix nicht direkt mit dem Terminalserver, sondern über einen Proxy (Presentationserver und Nachfolger [keine Ahnung wie das Ding schon wieder heißt ;)])

Und zur Not tuts auch ein Java Client, also auch ohne Installation usw.

 

Bye

Norbert

[nerd 28]

(Presentationserver und Nachfolger [keine Ahnung wie das Ding schon wieder heißt ;)])

Und zur Not tuts auch ein Java Client, also auch ohne Installation usw.

 

Off-Topic:

gibts einen Nachfolger zum Presentation server - ich würde nur noch das Citrix Access Gateway kennen - aber das schaltet man normal vor einen Presentation server...

[NorbertFe 2.027]

Off-Topic:

gibts einen Nachfolger zum Presentation server - ich würde nur noch das Citrix Access Gateway kennen - aber das schaltet man normal vor einen Presentation server...

 

Off-Topic:

Muß ich morgen mal fragen. Aber irgendwie benennen die im Moment ja alles um.

[pete.db 10]

Hallo,

danke erstmal für eure Infos. Ich werde heute mal die AD/AM Installation austesten.

Sehe ich das richtig, dass ich den AD/AM-Dienst auf einem Server in der DMZ installiere, dann die Instanz mit meinem ActiveDirectory repliziere (bzw. die Daten in AD/AM einlese).

Wenn ich dann auf einem Server in der DMZ eine Freigabe einrichte und eine Berechtigung für einenn Benutzer vergeben will, wähle ich den Benutzer über das AD/AM aus, und nicht mehr über die Domänencontroller?

Woher merken die DMZ-Server, dass sie die AD/AM Instalz fragen müssen und nicht mehr die DCs?

Genau so die Authentifikation.

Wenn ich mich von extern an einem Web anmelde, wird die Authentifikation über den AD/AM an die internen DCs weitergereicht, richtig?

 

Oder habe ich hier irgendwas völlig falsch verstanden?

 

Grüße

pete

–

bzw. ist es überhaupt notwendig, dass ich die User vom AD in AD/AM importiere/synchronisiere?

Kann ich nicht auch über die MS-UserProxy.ldf die Anmeldungen einfach an einen Domänencontroller im internen Netz durchreichen?

 

pete

[olc 18]

Hallo Pete,

 

ganz so einfach ist es dann doch nicht, daher mein Hinweis auf ein Systemhaus Deiner Wahl. ;)

 

Du kannst die Systeme in der DMZ nicht so einfach gegen die ADAM / AD LDS Instanz authentifizieren - das muß ggf. eine LDAP Applikation erledigen. Deshalb schrieb ich auch, daß Du ggf. einen FTP Server verwenden solltest, der die Berechtigungen und Zugriffe regelt.

 

Ob Du die Authentifizierung dann (nach Anbindung der Applikation) mittels Proxy-Objekt erledigst, ist eine Abwägungsfrage - schließlich öffnest Du damit eine direkte Tür in Dein internes Netzwerk (zu den DCs). Natürlich ist das auch bei einer Synchronisierung der Fall - jedoch kann man dies recht starkk einschränken, was die Zeit etc. betrifft. Ob das tatsächlich ein Sicherheitsgewinn ist, darüber läßt sich sicherlich streiten... ;)

 

Viele Grüße

olc