Kerberos Fehler wenn Client im VPN

[Reingucker 3]

Uh, hab gar nicht mitbekommen dass du in der Zwischenzeit was geschrieben hast.

 

 

Du hast EINE Identität. Wer Du bist, entscheidet die Anmeldeinstanz, die diese Identität bestätigt. Fertich... Wenn das der TMG macht, dann bist Du halt Standalone-User. Wenn es ein DC macht (und Dir dann noch freundlicherweise ein TGT ausstellt), dann bist Du Domänenbenutzer. Der TMG muß in die Domäne, dann hat die liebe Seel' eine Ruhe :D

 

Aber er konnte doch auf Freigaben zugreifen und das geht mit dem TMG\User nicht, auch wenns gleicher Name/gleiches Passwort ist - hab ich alles getestet.

 

Er hat sich aber vorher am Client an der Dom angemeldet bevor er das VPN verband. Ich zitier mich mal

 

Edit last:

 

Jo, TGT. Aber das würde ja heißen dass nur noch der Client und der KDC über das VPN kommunizieren, ja der Client selbstständig auch den UPN der vorhergehenden Dom-Anmeldung schicken würde, und der VPN-User selbst für die TGS egal wäre - Hauptsache VPN-Verbindung steht und auf dem VPN-Client wurde sich vorher an der Dom angemeldet. Aber dann verstehe ich die Fehlermeldung beim Zugriff aufs Netlogon nicht. Ich muss ein VPN aufbauen zum testen...

 

 

Ist das wirklich so? Auf dem Client liegt das TGT und das KDC-Secret und der Client weiß auch den UPN und das Passwort - und der Client kommuniziert mit dem KDC und fordert die Tickets und bestätigt ect.? Es brauch dafür keinen User (außer halt um die Resource auszuwählen die angefordert werden soll)?

[Beetlejuice 11]

Moin,

 

Aber die tmg in die Domäne aufzunehmen birgt, meines Erachtens, große sicherheitsrisiken.

 

Grundlegend wollten wir eine 2 fache Autorisierung haben um von extern auf unsere internen Daten zugreifen zu können .

 

@daabm

Ok, das VVerhalten könnte ich mir vorstellen. Aber ist das dann nicht unlogisch dass ich mit der vpn Identität gegen die Domäne komme, und dennoch Tickets für Zugriffe auf Server-dienste bekomme, obwohl ich "primär" eine vpn Identität habe?

 

Da muss ja die "alte" ad Identität irgendwie noch eine Rolle spielen?

 

Da muss es doch was geben, was diesen Prozess beschreibt.

[NorbertFe 2.065]

Moin,

 

Aber die tmg in die Domäne aufzunehmen birgt, meines Erachtens, große sicherheitsrisiken.

 

Welche denn?

http://www.isaserver.org/articles-tutorials/configuration-security/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

 

Mal davon abgesehen, dass das Produkt sich in der Auslaufphase/im aussterben befindet und das viel eher ein Grund wäre, sich über die Sicherheit gedanken zu machen.

 

Bye

Norbert

[Beetlejuice 11]

Jetzt würden wir leicht vom Thema abweichen, aber welche wirklich guten alternativen für einen Ersatz gibt es denn für sie tmg.

[Reingucker 3]

Ok, das VVerhalten könnte ich mir vorstellen. Aber ist das dann nicht unlogisch dass ich mit der vpn Identität gegen die Domäne komme, und dennoch Tickets für Zugriffe auf Server-dienste bekomme, obwohl ich "primär" eine vpn Identität habe?

 

Da muss ja die "alte" ad Identität irgendwie noch eine Rolle spielen?

 

Da muss es doch was geben, was diesen Prozess beschreibt.

 

Wie ich oben schrieb, die Anmeldung an der Dom bleibt, trotz der späteren Anmeldung im VPN, auf dem Client und nur der Client handelt die tgt und tgs aus, Also ist der VPN-User selbst egal. Man beachte die "Renewable" und "Forwardable". Renewable Tickets brauchen keine neue Authentifizierung und Forwardable Tickets können über einen Proxy (ich nenne es mal so) bezogen werden, also in deinem Fall der TMG. Und das macht alles der Client.

 

http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx

 

Aber wie Norbert schon sagt: TMG läuft aus (oder ist schon) und UAG läuft auch aus, ist aber sowieso kein richtiger Ersatz für TMG.

[Beetlejuice 11]

Danke für eure fleißigen Rückmeldungen !!!

 

Wie schon gesagt, eine schöne alternative zur TMG habe ich bisher nicht gefunden.

 

Mal angenommen, ich binde die TMG in die Domäne oder lasse die VPN User per RADIUS an die Domäne authentifizieren.

Wir werden dazu separate Accounts anlegen, die dafür verwendet werden.

Mit welchen Anmeldedaten schlage ich dann bei den Windows Services (Fileserver usw.) auf ? Die von der bisherigen Client Anmeldung "hans.wurst" oder die aus dem VPN "vpn-hans.wurst"?

Am DC vermutlich mit dem VPN Account, welches ein Ticket auslöst. Habe ich dann verschiedene Tickets von 2 verschiedenen AD Benuztern? Welche hat vorrang?

 

Das hat ja dann auch Auswirkung auf die Zugriffsberechtigungen und Gruppenrichtlinien!

 

Fragen über Fragen..

[Reingucker 3]

Ne, der Radiusclient, also dein TMG, schickt die VPN-Anmeldung weiter an den Radius, in deinem Fall der NPS. Im NPS sind verschiedene Bedingungen definiert unter denen die Verbindung überhaupt stattfindet, z.B. hier im Bild

 

 

 

Und bei z.B. den Benutzergruppen wird geprüft, ob der bei der Anmeldung angegebene UPN+Pass (oder dom\user+pass) mit einem User in dieser AD-Gruppe übereinstimmt. Stimmt es überein (und alle anderen Bedingungen auch) dann wird der User als VPN-User unter der Identität des AD-Users und den sonstigen konfigurierten Einschränkungen zugelassen.

 

Aber ich komme erst heute Abend dazu alles mal aufzubauen und zu testen.

[Beetlejuice 11]

Hi,

 

ja das ist korrekt und habe ich auch so verstanden. Versuche grad selber das mit RADIUS nach zustellen.

 

Die Frage war eher so gemeint,

 

Mal angenommen, ich binde die TMG in die Domäne oder lasse die VPN User per RADIUS an die Domäne authentifizieren.

Wir werden dazu separate Accounts anlegen, die dafür verwendet werden.

Mit welchen Anmeldedaten schlage ich dann bei den Windows Services (Fileserver usw.) auf ? Die von der bisherigen Client Anmeldung "hans.wurst" oder die aus dem VPN "vpn-hans.wurst"?

Am DC vermutlich mit dem VPN Account, welches ein Ticket auslöst. Habe ich dann verschiedene Tickets von 2 verschiedenen AD Benuztern? Welche hat vorrang?

 

Nach der VPN Anmeldung sind beide Accounts in der AD. Der von der Windows Anmeldung und der aus der RADIUS Anmeldung.

[Reingucker 3]

Tja, gute Frage: Wo wird das TGT vom VPN-Radius-AD-User hinterlegt? Auf dem Radiusclient? Aber das muss ich alles erst noch testen. Vielleicht komm ich heute noch mit allen Varianten durch inklusive parallel laufende sniffs auf allen beteiligten Rechnern.

[Reingucker 3]

@Beetlejuice 

 

Sei froh dass du Zertifikate/sstp genommen hast für dein VPN. Ohne Zerts ist es....mh, da fehlt ein Smilie in der Sammlung...

[Reingucker 3]

Also Fakt ist dass der RAS-VPN-RADIUS-AD-User für Zugriffe genommen wird, auch wenn man sich am VPN-Client selbst noch mit einem anderen AD-User angemeldet hat.

 

Ich kann dir aber nicht sagen wo dieser VPN-AD-User sein tgt abspeichert. Ich hab bei allen beteiligten Rechnern mit klist nachgeschaut. Aber da sind natürlich immer nur die tgt von dem angemeldeten User weil ja das klist in dessen Umgebung ausgeführt wird.

 

Ich hab dann auch ne cmd unter system auf allen laufen lassen, aber da sind dann entsprechend nur die Tickets der Rechner -- klar, ist ja klist in deren Umgebung ausgeführt.

 

Ich hab dann auch geschaut ob ich irgendwie die Datenbank des KDC abfragen kann, hab aber im Internet nichts dazu gefunden. Und auch meine Suche mit ldp ob es vielleicht auch im AD irgendwo hinterlegt ist hat nichts gebracht. Ich weiß nicht wo der VPN-User das tgt hat.

 

Falls Jemand weiß wie man dem KDC seine Datenbank abfragen kann: Melden! 

 

Edit:

 

 

Hab mal ne cmd als vpn-user ausgeführt und darin dann klist gemacht - und da war es dann das tgt. Aber es waren nur zwei und ich denke dass es genau die zwei sind die es gibt wenn die cmd im Kontext des vpn-users ausgeführt wird. Aber der Zugriff auf eine Freigabe über vpn mit dem gleichen User taucht dort nicht auf obwohl der gleiche Client.

 

Edit:

 

Weiß Jemand wie man bei RAS-Radius-VPN splitt-tunneling machen kann?

 

Ah, schon klar, Häkchen raus.

bearbeitet 7. Februar 2015 von Reingucker

[Reingucker 3]

@Beetlejuice

 

Wie bringst du denn den CDP ins Internet?

 

Ich hab jetzt alles auf Zertifikate umgestellt, also RAS/NPS/NAP mit einer enterprise CA inklusive CDP über IIS. Musste ich ja sowieso machen weil ohne Zerts kein NAP (deswegen mein Grummeln weiter oben).

 

Es funktioniert alles zufriedenstellend. Die Frage ist: Wie kommen die Roadwarrior an den CDP um die Sperrliste zu überprüfen?

 

Beim ISA/TMG kann man ja die Webseite "spiegeln" und dann können die vom Internet darauf zugreifen. Der ISA überprüft ob der Zugriff in einer zulässigen Art ist und schickt dann die eigentliche Anforderung als TMG an die eigentliche Webseite intern, empfängt die Antwort und gibt dann die Antwort an den Roadwarrior weiter. Ist das selbe Prinzip wie mit OWA ect.

 

Wenn aber ISA/TMG nicht mehr supported wird, was macht man dann? Portforwarding (hahaha)? Hast du da schon eine Idee?

[NorbertFe 2.065]

ist doch nur ein http Pfad. Steht nirgends, dass der auf die ca zeigen muss. Und Tmg/isa ist auch nicht der einzige Reverse Proxy der Welt.

[Reingucker 3]

Hm, stimmt, dann müsste man die crl da immer hin kopieren wenn sich was geändert hat.

 

Edit:

 

Ich weiß auch nicht was sich die Ersteller der MOC-Bücher zu MCSA 2012 gedacht haben. Da kommt in 70-411 RAS\VPN\DirectAccess\NPS\NAP dran, aber erst in der 70-412 bekommt man erklärt wie Zertifikate funktionieren und eine Zertifizierungsstelle installiert und eingerichtet wird. 

bearbeitet 8. Februar 2015 von Reingucker

[NorbertFe 2.065]

Und nu?