131993
04.01.2017, aktualisiert um 13:38:20 Uhr
2514
11
0
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
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
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 325443
Url: https://administrator.de/forum/domaenen-authentifizierung-ueber-internet-325443.html
Ausgedruckt am: 13.04.2025 um 20:04 Uhr
11 Kommentare
Neuester Kommentar
Hi.
DirectAccess verwenden. Das läuft transparent auf Port 443.
Gruß mik
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
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.
Hallo,
Direct Access? oder VPN...
Gruß,
Peter
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.... WahnsinnEin 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.
Direct Access? oder VPN...
Gruß,
Peter
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.
DirectAccess ist hier unter Windows das Mittel der Wahl wenn kein VPN gewünscht ist.
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?Da werden sich aber viele dann freuen, und du kennst die noch nicht einmal.... Wahnsinn
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.
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.
Entweder VPN oder Direct Access, je nachdem was du machen willst, das ist für dein Vorhaben geeignet.
LG Günther
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
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
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.
Diese Ports hätte ich ja nicht pauschal freigegeben, sondern nur authentifiziert und verschlüsselt über IPSec.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.
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.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?
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?
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? 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?
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.
Zitat von @131381:
Die IPSec Authentifizierung würde ja über Kerberos laufen, was wiederum nicht über IPSec laufen würde.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? Von Extern währen ja nur Kerberos und IPSec auf die anderen Ports erlaubt. Somit kommt auch keine Nicht authentifizierte Verbindung zum DC durch.
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.
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.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?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.
