131993
Goto Top

Domänen Authentifizierung über Internet

Hallo,

ich stehe aktuell vor einem Problem. Ich bin auf der suche nach einem Sicheren Weg wie sich meine Clients vom Internet aus über das Internet (ohne VPN) mit der Domäne zur Authentifizierung, Kennwort Änderung und Group Policy Aktualisierung verbinden können.
Ein weg auf den ich bis jetzt gestoßen bin währe dem Domain Controller eine Öffentliche IPv4 (und ggf. IPv6; NAT wird von MS ja nicht supported) zuzuweisen (Wir haben einen größeren Pool zur Verfügung) und anschließend Kerberos über die HW-Firewall (Zwecks IPSec Authentifizierung) erlauben + IPSec auf der Windows Firewall für LDAP, GC, SMB over IP, RPC und DNS konfigurieren.

Ist das ein gangbarer weg, oder würdet ihr das anders umsetzen?
Ziel ist es zukünftig ohne VPN (manueller Verbindungsaufbau mit User Authentifizierung) eine Verbindung herzustellen (bzw. Gruppenrichtlinien Updates, Kennwort Änderungen, Kerberos Authentifizierung für div. Server) und die Geräte besser verwalten zu können ohne die Sicherheit zu kompromittieren.

- EditorialBagPipe

Content-Key: 325443

Url: https://administrator.de/contentid/325443

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: 131381
131381 04.01.2017 aktualisiert um 13:39:05 Uhr
Goto Top
Hi.
DirectAccess verwenden. Das läuft transparent auf Port 443.
Ein weg auf den ich bis jetzt gestoßen bin währe dem Domain Controller eine Öffentliche IPv4 (und ggf. IPv6; NAT wird von MS ja nicht supported) zuzuweisen
Um Gottes Willen, bloß nicht.

Gruß mik
Mitglied: 131993
131993 04.01.2017 aktualisiert um 13:40:02 Uhr
Goto Top
Um Gottes Willen, bloß nicht.
Wieso? Kerberos ist für unsichere Umgebungen ausgelegt und der Rest wäre IPSec verschlüsselt...
Außerdem währe ja trotzdem noch eine Firewall dazwischen.
Mitglied: Pjordorf
Pjordorf 04.01.2017 um 13:39:25 Uhr
Goto Top
Hallo,

Zitat von @131993:
Ein weg auf den ich bis jetzt gestoßen bin währe dem Domain Controller eine Öffentliche IPv4 (und ggf. IPv6; NAT wird von MS ja nicht supported) zuzuweisen (Wir haben einen größeren Pool zur Verfügung) und anschließend Kerberos über die HW-Firewall (Zwecks IPSec Authentifizierung) erlauben + IPSec auf der Windows Firewall für LDAP, GC, SMB over IP, RPC und DNS konfigurieren.
Da werden sich aber viele dann freuen, und du kennst die noch nicht einmal.... Wahnsinn
Direct Access? oder VPN...

Gruß,
Peter
Mitglied: 131381
131381 04.01.2017 aktualisiert um 13:46:43 Uhr
Goto Top
Nun ich will nicht alle DDoSe direkt am DC abfackeln müssen. Ein DC kommt niemals direkt per Port-Forward ans Netz auch wenn da eine HW-Firewall davor steht.

DirectAccess ist hier unter Windows das Mittel der Wahl wenn kein VPN gewünscht ist.
Mitglied: 131993
131993 04.01.2017 aktualisiert um 13:48:37 Uhr
Goto Top
Zitat von @Pjordorf:
Da werden sich aber viele dann freuen, und du kennst die noch nicht einmal.... Wahnsinn
Kannst du mir erklären, wie hier jemand fremdes Zugriff erhalten sollte?
Kerberos ist ja auch über unsichere Netze Sicher und der Rest ist ja mittels IPSec Authentifiziert (Kerberos) und Verschlüsselt. Also habe ich ja genauso wie bei VPN einen Verschlüsselte und Authentifizierte Verbindung.
Ist ja fast das gleiche wie VPN mittels L2TP over IPSec, oder nicht?
Direct Access? oder VPN...
Muss ich mir ansehen.

Es würde mich aber dennoch interessieren, wieso das von mir beschriebene Szenario unsicher sein sollte.
Mitglied: GuentherH
GuentherH 04.01.2017 um 14:18:13 Uhr
Goto Top
Es würde mich aber dennoch interessieren, wieso das von mir beschriebene Szenario unsicher sein sollte.

Schon einmal selbst überlegt, was du da tun möchtest. Es geht ja nicht nur um die Authentifizirung sondern auch um die zusätzlichen Ports die du für die Gruppenrichtlinien benötigen würdest.

Eine einfache Suche nach "firewall gruppenrichtlinien ports" sollte eigenlich reichen um festzustellen, dass du da mit deinen Wünschen daneben bist. Im Prinzip kannst du bei der Anzahl der benötigten Ports die FW gleich abdrehen. face-wink

Entweder VPN oder Direct Access, je nachdem was du machen willst, das ist für dein Vorhaben geeignet.

LG Günther
Mitglied: Chonta
Chonta 04.01.2017 um 14:19:22 Uhr
Goto Top
Hallo,

ihr verschlüsselt also eueren LAN-Trafik für alle Geräte per IPSec?
Da müssen ja die Cleints schon vor Dmänenbeitritt mit Zertifikaten ausgerüstet sein.
Sicher das es kein Fallback gibt, wenn Geräte ohne IPSec ankommen?

Stichwort Multihomed DC.
Allein wenn ich mir versuche vorzustellen den DC direkt ins Internet zu stellen, rollen sich mir die Fußnägel hoch.
Selbst MS macht das mit deren MietAD nicht so.

Gruß

Chonta
Mitglied: 131993
131993 04.01.2017 um 17:55:03 Uhr
Goto Top
Zitat von @GuentherH:
Eine einfache Suche nach "firewall gruppenrichtlinien ports" sollte eigenlich reichen um festzustellen, dass du da mit deinen Wünschen daneben bist. Im Prinzip kannst du bei der Anzahl der benötigten Ports die FW gleich abdrehen. face-wink
Diese Ports hätte ich ja nicht pauschal freigegeben, sondern nur authentifiziert und verschlüsselt über IPSec.

Zitat von @Chonta:
ihr verschlüsselt also eueren LAN-Trafik für alle Geräte per IPSec?
Da müssen ja die Cleints schon vor Dmänenbeitritt mit Zertifikaten ausgerüstet sein.
Sicher das es kein Fallback gibt, wenn Geräte ohne IPSec ankommen?
Von Extern währen ja nur Kerberos und IPSec auf die anderen Ports erlaubt. Somit kommt auch keine Nicht authentifizierte Verbindung zum DC durch.

Ich verstehe eure bedenken leider immer noch nicht ganz. Kennt jemand eine konkrete Schwachstelle, wenn doch alle Verbindungen außer Kerberos über einen IPSec Tunnel zum DC kommen?
Mitglied: 131381
131381 04.01.2017 aktualisiert um 18:25:18 Uhr
Goto Top
Zitat von @131993:
Von Extern währen ja nur Kerberos und IPSec auf die anderen Ports erlaubt. Somit kommt auch keine Nicht authentifizierte Verbindung zum DC durch.
Und wie soll der IPSec Client mit dem DC initial eine Verbindung aufbauen wenn du das auch schon unterbinden willst? face-smile

Ich verstehe eure bedenken leider immer noch nicht ganz. Kennt jemand eine konkrete Schwachstelle, wenn doch alle Verbindungen außer Kerberos über einen IPSec Tunnel zum DC kommen?
DDoS und kommende Sicherheitslücken denen der Server dann unmittelbar ausgesetzt ist. Ist doch wie bei WebCams die direkt am Netz hängen. Und ein DC gehört prinzipiell einfach niemals direkt über eine direkte Brücke mit dem Internet verbunden. Für sowas stehen dedizierte Geräte in einer DMZ.
Deine DCs sind das Herz deines Netzwerks und sollten dementsprechend auch behandelt und geschützt werden. Denn ist einmal nur ein einziger DC kompromittiert ist es dein ganzes Netzwerk!

Das was du da vorhast ist ja auch nichts anderes als ein VPN, wenn du also schon Port 500 öffnest kannst du auch gleich ein abgesichertes VPN für deine Clients auf dem Gateway oder einer Firewall erstellen in dem sie in einem separaten Subnetz nur deinen DC erreichen!!

Direkt Access wurde genau für diese Zwecke erfunden damit mobile User ihre GPOs und Richtlinien ziehen können und läuft auch noch auf Hotspottauglichen Ports (443) im Gegensatz zu deinem IPSec-Tunnel der auf Port 500 festgedängelt ist.
Zusätzlich braucht sich der Client um keine Verbindung mehr zu kümmern da der DirectAccess-Tunnel automatisch immer dann aufgebaut sobald der User nicht im internen Netzwerk ist, komfortabler geht's nun wirklich nicht.
Mitglied: 131993
131993 04.01.2017 um 18:26:27 Uhr
Goto Top
Zitat von @131381:

Zitat von @131993:
Von Extern währen ja nur Kerberos und IPSec auf die anderen Ports erlaubt. Somit kommt auch keine Nicht authentifizierte Verbindung zum DC durch.
Und wie soll der IPSec Client mit dem DC initial eine Verbindung aufbauen wenn du das auch schon unterbinden willst? face-smile

Die IPSec Authentifizierung würde ja über Kerberos laufen, was wiederum nicht über IPSec laufen würde.

Das was du da vorhast ist ja auch nichts anderes als ein VPN, wenn du also schon Port 500 öffnest kannst du auch gleich ein abgesichertes VPN für deine Clients auf dem Gateway oder einer Firewall erstellen in dem sie in einem separaten Subnetz nur deinen DC erreichen!!
Und der Unterschied in Punkto Sicherheit ist welcher?

Direkt Access wurde genau für diese Zwecke erfunden damit mobile User ihre GPOs und Richtlinien ziehen können und läuft auch noch auf Hotspottauglichen Ports (443) im Gegensatz zu deinem IPSec-Tunnel der auf Port 500 festgedängelt ist.
Hast du eine gute Anleitung für eine minimale Testimplementierung von DirectAccess?
Stimmt, das mit den WiFi-Hotspots hatte ich bis jetzt nicht bedacht.
Mitglied: 131381
131381 04.01.2017 aktualisiert um 18:35:02 Uhr
Goto Top
Zitat von @131993:
Die IPSec Authentifizierung würde ja über Kerberos laufen, was wiederum nicht über IPSec laufen würde.
IMHO nicht praktikabel und vernünftig managebar.
Das was du da vorhast ist ja auch nichts anderes als ein VPN, wenn du also schon Port 500 öffnest kannst du auch gleich ein abgesichertes VPN für deine Clients auf dem Gateway oder einer Firewall erstellen in dem sie in einem separaten Subnetz nur deinen DC erreichen!!
Und der Unterschied in Punkto Sicherheit ist welcher?
Dein DC hängt nicht direkt am Netz und ist Sicherheitslücken in den Windows-Diensten nicht direkt schutzlos ausgeliefert. Das interne absichern macht man normalerweise über VLANs in welche man die VPN-User sperrt und das auf einem Device in der DMZ!

Direkt Access wurde genau für diese Zwecke erfunden damit mobile User ihre GPOs und Richtlinien ziehen können und läuft auch noch auf Hotspottauglichen Ports (443) im Gegensatz zu deinem IPSec-Tunnel der auf Port 500 festgedängelt ist.
Hast du eine gute Anleitung für eine minimale Testimplementierung von DirectAccess?
https://www.microsoft.com/en-us/download/details.aspx?id=29031
https://technet.microsoft.com/de-de/library/dn614138(v=ws.11).aspx

Damit solltest du dich aber intensiv beschäftigen, denn mal schnell ist das auch nicht aufgesetzt und die Technik dahinter sollte erst verstanden werden, denn es gibt hier ein paar Fallstricke, deswegen ist ausführliches Einlesen Pflicht.
Wenn es dann läuft ist es aber das komfortabelste Setup für die Clients.