Reingucker

@MrNight Wenn du unbedingt Fuddel haben möchtest, dann aktivierst du das LAN-Routing und den NAT im RRAS. Den NAT auf die Netzwerkkarte die zur Fritzbox geht. Weiterhin nimmst du auf der Nic zur Fritzbox unter den IP4-Eigenschaften/DNS das Häkchen bei "diese Adresse im DNS registrieren" raus und trägst auf dieser auch die Fritzbox als Standardgateway ein. In der Firewall in der erweiterten Sicherheit und da unter Eigenschaften (rechts in der Spalte) für das DOM-Profil nur die Netzwerkkarte für das LAN (unter "anpassen"). Und für das Profil "öffentlich" trägst du nur die Netzwerkkarte zur Fritzbox ein, und im Profil "privat" trägst du gar keine Nic ein. Im DNS dann unter Eigenschaften-Weiterleitungen trägst du einen DNS, entweder von deinem ISP oder den Google-DNS 8.8.8.8 ein, oder Beide. Gar keinen Eintragen geht auch wenn das Häkchen "Stammhinweise verwenden" gesetzt ist, aber dann nervst du die Root-Server mit Abfragen die sehr wahrscheinlich schon im Speicher deines ISP-DNS liegen. Und auf der Fritzbox solltest du schon mal eine statische, permanente Route zu deinem LAN-Netz mit Gateway auf die Nic des Servers die zur Fritz geht, falls du später noch irgendwelche Zugriffe von Außen geplant hast. Und nochmal alle Posts vor meinem Post lesen.

Der AD-User wird zwar primär für die Freigabe verwendet - er kommt aber nicht über das VPN. Das sieht man im vid wenn ich auch den AD-User User1 explizit als Anmeldung für den Zugriff auf die Freigabe angebe: Obwohl er Zugriffsrechte hat kommt er nicht drauf! Also ist der lokale AD-User für Zugriffe über die VPN-Verbindung keine Gefahr. Einzige Ausnahme sind das NETLOGON wie ich in meinem Film gezeigt habe. Da kommt der AD-User mit Hilfe des Computerkontos, dem VPN-Client an dem er angemeldet ist, drauf. Ist schön zu sehen finde ich. Ja, das sollte man wissen. Ich teste das gleiche Szenario in den nächsten Tagen auch mit DirectAccess. Da dürfte das Problem dann nicht mehr auftauchen.

Moin, ich habe sowohl ohne Userangabe auf die Freigabe zugegriffen als auch mit Userangabe. Ohne Userangabe wird ja der am Rechner angemeldete User, in diesem Fall User1, dazu benutzt die Verbindung herzustellen. Das sieht man dann ja in den Logs wo überall User1 drin steht. Ich stelle es auch gleich nochmal so nach wie du beschrieben hast. Wird ein kleinerer Video und dürfte damit auf youtube rauf kommen. Btw, es sind 20 min Maxgröße für Film bei youtube. War früher nicht. Daher sind auch die neusten Kinofilme dort in viele 20 min Teile zerlegt.

So, ich hab das jetzt doch schon gestern Abend nochmal durchgespielt.Hab mir von der Heise Seite einen Bildschirmaufzeichner geholt und hab das Video aufgenommen. Alles schick. Dann hab ich es auf Youtube hochgeladen (70 minuten), dann wurde es bearbeitet (10 min), und dann kam die Meldung dass das Format nicht unterstützt wird. Tja, es wurde im avi+ Format aufgezeichnet. Ok. Hab ich es in wmv convertiert (35 min) und dann dieses hochgeladen (70 min) und dann wurde es bearbeitet und es plöpte die Meldung "Film zu lang, veröffentlichung abgelehnt" auf. Hä? 23 Minuten Film zu lang? Tja, und da hab ich jetzt keinen Bock mehr auf youtube. Ich habe es auf eine Webseite von mir gestellt und wer es sich anschauen möchte kann es ja runter laden. Und wer nicht, der nicht. Ist mir schnurz jetzt. www.linuzdreck.de/0002.wmv

Ohne NAP. Also einfach nur RAS-Radius-SSTP-VPN-NPS.

Hm. Ich hatte auf der Freigabe/ntfs den am Client angemeldeten AD-User als Vollzugriff und den VPN-AD-User als variablen Zugriff (von alles bis garnix). Und der Zugriff auf die Freigabe war dann immer von den Berechtigungen des VPN-AD-Users abhängig. Und der stand auch immer im log. Und wenn der am Client angemeldete AD-User überhaupt nicht in der Freigabe/ntfs eingetragen war, dann ging der VPN-AD-User trotzdem mit seinen entsprechenden Berechtigungen. Also ziemlich konträr zu deinen Erfahrungen. Ok, heute komme ich nicht mehr dazu, aber ich werde morgen Abend das nochmal alles durchspielen und Video davon machen. Kann ja auch sein dass ich irgendwas falsch eingestellt habe. Wüsste aber nicht was, zumal ja auch das VPN ect. gar nicht gehen würde wenn ich da etwas falsch gemacht hätte.

Wa? Ich habe exakt das gleiche Experiment durchgeführt. Ein AD-User meldet sich auf dem Client am AD an und stellt dann unter einem anderen AD-User eine VPN-Verbindung mit authentifizierung an der Dom her. Und ich bekam bei klist eben NICHT die Tickets des VPN-AD-Users sondern nur die Tickets des welcher sich an dem Client angemeldet hat. Mein VPN-User habe ich auf Freigaben in der Dom zugreifen lassen (mal Vollzugriff/mal ändern/mal lesen/mal kein Zugriff). Und selbst wenn sich der VPN-AD-User auf die Freigabe drauf kam oder auch nicht, so sah ich im log immer welcher User es war. Und trotzdem bekam er kein Ticket. Konnte aber auf die Freigabe zugreifen wenn zugriff erlaubt. Mach doch mal die Überwachung rein und schau welcher User da auf die Freigabe zugreift. Es ist nicht der am Client angemeldete User. Es ist der VPN-User. Sollte eigentlich durch setzen der Zugriffsberechtigungen klar werden aber im log hast du es dann nochmal schriftlich. Und dafür bekommt der VPN-User kein Ticket. Mit dem NETLOGON scheint es nochmal etwas anderes zu sein, wie du auch in deinem ersten Post festgestellt hast. Das habe ich nicht probiert.

Was ist denn mit ADFS 3.0 und Webanwendungsproxy? Laut den Büchern die ich hier habe soll das den TMG so ziemlich ersetzen. Oder im net: http://asichel.de/2014/01/03/server-2012-r2-webanwendungsproxy-mit-exchange-2013/ http://blogs.technet.com/b/jrosen/archive/2013/12/28/setting-up-windows-application-proxy-for-exchange-2013.aspx http://office365support.ca/configuring-windows-nlb-for-ad-fs-2-0/ http://blog.atwork.at/post/2014/09/03/ADFS-3-0-und-TLS-1-2.aspx

Ja, schon, aber wo die VPN-User-Tickets abgelegt werden kann man nicht mit klist sehen. Zumindest ich nicht :) Hm, also intern eine Enterprise CA und die externen VPNs/WEB mit einem Zertifikat von irgendeiner Klitsche welche am besten auch standardmäßig in den Browsern eingetragen ist. Ok, da hat man zumindest das Problem mit dem durchreichen des CDP nicht.

Ja, da spart man sich sicher einiges an Arbeit. Vielleicht. Wenn ich intern noch jede Menge mit Zertifikaten abdecke dann kann ich mir vorstellen dass es dann einiges an Mehraufwand wird als wenn man eine eigene Zert hat. Also bei splitt-tunnel gibt es eigentlich kein Problem wenn man die Firmennetze explizit per Route durch das VPN schickt. Die Tickets der VPN-User wirst du nicht sehen, außer du schaust in die Kerberos-Datenbank. Das scheint aber nur mit Linux/Unix zu gehen. Für in die Datenbank des MS-Kerberos rein zu schauen hab ich noch nichts gefunden. Und was nehmt ihr statt dessen? Es müsste ja irgendwas sein womit all die Erleichterung durch einbinden ins MS-AD dann auch gehen.

Hallo dshell, ich bin z.B. Einer der die Weiterbildung zum MCSA vom Arbeitsamt bezahlt bekommt. Ohne Vorwissen geht MCSA 2012 nur schwer und oberflächlich und gerade so durch die Prüfung, außer man investiert ein Jahr Vollzeit. Aber da du ja schon seit NT4 die Serverseite verfolgst und auch bei 2008 schon Einblick hattest, da würde ich sagen du kannst es auch nur mit Büchern/youtube/Internet schneller schaffen. Allerdings brauchst du unbedingt eine 2012 R2 Testumgebung. In den Büchern/youtube wird schon an die einzelnen Themen rangeführt und die Standardeinstellungen besprochen, aber in den Prüfungen kommen dann auch einige Fragen die etwas außerhalb des Standards liegen. Also testen, testen, testen um wenigstens zwei-/dreimal alle Funktionen der einzelnen Programme erfolgreich eingestellt/ausgeführt zu haben. Wenn du mit NT4/2008 schon gearbeitet hast, wirst du den 2012 R2 mögen. Ist mMn angenehm mit zu arbeiten und macht auch irgendwie Spass. Edit: Und viele Fragen mit Powershell/cmd da ja Microsoft davon ausgeht dass der Core-Server so administriert wird.

Pegida? Neee, schwacher Scherz :) Wenn man in so einem Weiterbildungskurs den MCSA 2012 nach den MOC-Büchern macht, und das dann noch innerhalb kürzester Zeitvorgaben, dann ist das nun mal nicht so schön. OK, für mich ist es nicht so schlimm weil ich ja eh immer alles durchteste und dann das im Kurs Fehlende selbst dazulerne. Mir tun die Anderen im Kurs irgendwie leid.

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.

@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?

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.

@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...

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.

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.

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.

Uh, hab gar nicht mitbekommen dass du in der Zwischenzeit was geschrieben hast. 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 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)?

Ist es nicht das Gleiche wie wenn man sich am AD anmeldet, aber dann unter einem anderen Namen auf eine Freigabe zugreift? Hm, ja, interessant. Vielleicht steht da "Jeder" drin oder es ist wegen den gleichlautenden Namen, den "Cname". Was dann allerdings eine heftige Sicherheitslücke wäre. Vielleicht checked Kerberos erst nicht ob der User in der eigenen Domäne ist, sondern nur auf den Namen. Und wenns den Namen gibt, dann wird nachgeprüft ob es auch die richtige Domäne ist. Und wenns den Namen nicht gibt, dann wird auch erst dann geprüft welche Domäne es ist - könnte ja noch eine Vertrauensstellung sein. Und beim Serviceticket/AccessToken zählt nur ob Kerberos den Namen bestätigen kann? Neee, das wäre doch zu heftig. Dann steht hoffentlich doch "Jeder" drin :rolleyes: Edit2: Tja, ich brauch einen Rechner in einer Arbeitsgruppe, etwas social engineering um einen gültigen Anmeldenamen zu bekommen, ein Programm das Passwörter generiert und Zugang Zum LAN. Und der Acc dürfte noch nicht mal gesperrt werden im AD weil ich es ja gegen Freigaben probieren würde. Kann doch nicht wahr sein! Oder überseh ich hier was? Edit2: Puuhh, es geht nicht. @Beetlejuice Client: hans.wurst @ DEV.DOMAIN.DE Damit warst du auf dem VPN-Client an der Dom angemeldet. Müsste man noch wissen wie genau dein Versuchsaufbau/Netz ect. aussah. 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...

Jawoll! Habs gestern auch nochmal überflogen ;)

Ich stell mir dass so vor dass man da, wo man sich anmeldet, als User existiert. Wobei der Ort, an dem der Anmeldevorgang, das Eintippen der Credentials, statt findet, völlig egal ist. Melde ich mich im AD an, bin ich im AD. Melde ich mich lokal an, bin ich lokal. Und melde ich mich über VPN an einem VPN-Server an, bin ich auf dem VPN-Server. Ist irgendwie immer noch wie damals. Die Logon-User von heute sind die modernere Version der "dumb Terminals" von damals.

Ah, ok, 8.1 hab ich dann überlesen.

Ah, das ist natürlich die supercoole all in one Anleitung :jau: