olc

Sofern das A-G-DL-P onzept sauber umgesetzt wurde, brauchst Du nicht auf der Zielressource prüfen, welche Zugriffe existieren. Du kannst es schlicht anhand der Gruppenmitgliedschaften evaluieren. Aber ja, das ist die rein technische Betrachtung. Workflows und Prozessmanagement sind eine andere Ebene dabei. P.S.: ADUC ist tot. ADAC/PowerShell lebt. Viele Grüße olc

Ok, angekommen. :) Hat Microsoft, die "Mitigation" heißt Bitlocker. Na ja, leider auch nicht wirklich. Es gibt ein ähnliches Angriffsszenario auch für Kerberos, siehe Stichwort "Golden Ticket": http://rycon.hu/papers/goldenticket.html :) Ja, dann aber gleich beim Fundament anstatt ein paar Fenster ins Leere zu bauen. :) Bitte verzeih mir da meine Erbsenzählerei - leider sehe ich nur allzu häufig den "Vorsatz" es besser zu machen, um dann schlußendlich (wenn überhaupt) bei halbgaren Umsetzungen zu landen, bei denen sich die Firmen dann noch einreden, sie wären nun "sicher" (Zitat) oder hätten das Sicherheitsniveau spürbar angehoben. Meine persönliche Erfahrung ist: ehrlich sein, egal wie schmerzhaft es ist. Solange wir uns noch gegenseitig einreden, es würde alles nicht so schlimm werden, wird sich nichts ändern. Siehe mein Zitat oben zu den beiden Kategorien von IT-Netzwerken. Nicht paranoid sein, aber auch nicht vollkommen naiv. Letzteres ist zumindest meiner Erfahrung nach die Regel. Und/oder noch renitent dazu. :) Soll ich jetzt mal provozieren und "A-G-DL-P" einwerfen? *duckundweg* Viele Grüße olc

...schau Dir PtH einmal genauer an. :) Etwa hier: http://en.wikipedia.org/wiki/Pass_the_hash http://www.microsoft.com/en-us/download/details.aspx?id=36036 Viele Grüße olc

Ah, ok. Kenne die Veranstaltung und den Inhalt. :) Es gibt dazu eine nette Aussage (sicher nicht neu, aber ich finde sie gut): Es existieren genau zwei Arten von IT-Umgebungen In Kategorie 1 wissen die Verantwrtlichen davon, daß sie von Malware befallen oder alternativ gehackt (APT) wurden (oder beides). In Kategorie 2 wissen sie es nicht. Eine Kategorie 3 gibt es nicht. ;) Gibt es das jemals...? :) Zumal sich Angriffsvektoren ja mit den Gegenmaßnahmen ändern... Bin ich vollkommen bei Dir. Jede Maßnahme ist für sich genommen erst einmal eine gute Maßnahme. Ich weiß natürlich nicht woher ihr kommt (historisch betrachtet in Bezug auf IT-Security) - sicher ist das ein erster guter Start, aber mittelfristig reicht das eben (leider) nicht. Verstehe mich nicht falsch - ich sitze nicht im Elfenbein-Turm. Es muß nur immer klar sein, daß die ganzen "halben" Maßnahmen schlicht fast nichts bringen. Solange nicht fundamentale Änderungen im Betrieb von IT-Umgebungen stattfinden, in Bezug auf die Prozesse, Administration, die Benutzer als auch eingesetzter Technik, sind die "Zäune" immer zu niedrig. Punkt. :) Gibt noch mehr und ähnliche Systeme, je nach Anwendungszweck. Microsoft Consulting hat da soweit ich weiß auch eine Lösung gebaut, FIM basierend. Weiß nicht, ob da auch lokale Kennwörter geändert werden. "CyberArk" hat auch in die Richtung etwas. Nein, ist es nicht. Denn wenn Du erst ein Benutzer-Ticket hast, bist Du durch mit dem Thema. Game Over. Viele Grüße olc

Moin, moin, Ist ein aktuelles und interessantes Thema... :) Des Teufels Advokat: ob diese "Lösungen" dann wirklich "sicherer" sind...? :) Ok, Du hattest eingangs explizit erwähnt, daß die Notebook-Systeme "offline" / ohne Netzwerk sind. Das hatte ich dahingehend interpretiert, daß es Dir auch um diesen konkreten Punkt geht. Mein Fehler, es war eine Annahme. Ok, der Vollständigkeit halber sei dann aber auch gesagt, daß das nur ein ganz kleiner Teil der ganzen PtH Geschichte ist. Du scheibst weiter unten, daß es Dir grundsätzlich um unterschiedliche Kennwörter geht - volle Zustimmung hierbei. Wenn Du das aber in Deinem beschriebenen Szenario in den Kontext von PtH hebst, möchte ich widersprechen. :) Denn "nur" das Setzen von Kennwörtern löst das Problem nicht, solange administrative Gruppenmitglieder Anmeldungen am Zielsystem durchführen können. Das sind ja nur sehr bedingt lokale Administratoren. ...und sie melden sich (remote) an den Systemen auch interaktiv an, korrekt? Das ist ein Problem im Kontext von PtH. Siehe oben. Ich stimme Dir zu, es ist eine sinnvolle und "erste" Maßnahme. Aber adressiert es wirklich das Problem? Meines Erachtens wirklich nur sehr, sehr begrenzt. Definitiv. Und genau daher müssen sie mit betrachtet werden. Und ja, ich weiß daß das wirklich nicht einfach ist. Aber die Weichen müssen eben gestellt werden. Das ist absolut sinnvoll und valide. :) Definitiv. +1 +1 Ja, ich verstehe das. Mir wiederum ist wichtig darzustellen, daß Du damit den Schweizer Käse nur um ein Loch erleichterst, er aber dennoch genauso duftet wie vorher. ;) Ein Beispiel wäre Lieberman: http://www.liebsoft.com/Random_Password_Manager/ Was keine Empfehlung darstellt, sondern nur ein Beispiel. :) Das Produkt tut auch etwas mehr als "nur" Kennwörter ändern (lokal und AD), es geht um "temporäre" Gruppenmitgliedschaften usw. Ok, danke auch dafür! Mein IE hat mir schlicht keinerlei Zitate angezeigt, Chrome tut es aber. Dann klappt es auch. :) Viele Grüße (und viel Erfolg ;)) olc

Hi Norbert, ich hab das Gefühl, daß wir uns hier bald im Kreis drehen... ;) Darum hier mein finales Statement zu diesen Punkten - denn ich gehe davon aus, daß sie korrekt ankamen. ;) Zu #1: Es gibt am Markt diverse Drittanbieter, die solche Lösungen anbieten. Microsoft kann auch keine Lösungen für jedwede Fragestellung anbieten - Kritik also in allen Ehren, aber es ist eben wie es ist. Und ja, ich stimme Dir zu: die Idee als solches ist smart, dem habe ich auch nicht widersprochen. Ich habe lediglich auf eine bisher nicht genannte Ebene hingewiesen, die insbesondere bei Sicherheitsdiskussionen zentrale Bedeutung hat. Zu #2: Ggf. muß der Ansatz verändert werden - siehe meine Fragen an Robert. Es geht mir also wie so häufig nicht darum, eine Lösung für eine Fragestellung zu finden, bei dem Ursache und Wirkung verwechselt wird. BTW: wie kann man hier zitieren? Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile. P.S.: So, nun wird es Zeit für Dein letztes Wort dazu. ;) Viele Grüße olc

Hi Norbert, ohne die Diskussion hier abgleiten lassen zu wollen: nur das letzte Wort zu haben, ist kein Argument. ;) :P Zu Deinem Punkt 1: Wenn ich die Sicherheit erhöhen will stellt sich die Frage, wie ich das tue. Nutze ich ein Tool dafür (neben Prozessen usw.), muß ich sicherstellen, daß dieses Tool meinen Sicherheitsanforderungen gerecht wird. Ob ein Tool auf Codeplex dem entspricht, muß ich bewerten. Das ist mein Argument, nicht mehr und nicht weniger. :) Zu Deinem Punkt 2: Klar, aber das Anliegen des TO ist recht eindeutig und daher ist der Zeitraum, wie lange die Systeme offline sind, ein durchaus wichtiger Bewertungspunkt. Denn die Zeit, die bis zu einer Kennwortänderung vergeht, ist auch bei PtH sehr relevant. Viele Grüße olc

Hi Robert, die Lösung von Norbert ist tatsächlich ganz nett, auch wenn es offiziell nur ein "Sample" ist und sicher offene Fragen dazu existieren. Wenn die PCs jedoch meist "offline" sind wird es grundsätzlich schwer, die Kennwörter zu ändern und zentral zu hinterlegen (in welcher Art auch immer). Davon einmal ab zwei Rückfragen: #1: Wer genau hat das administrativen Zugriff und wie findet die Rollentrennung auf den Systemen statt? #2: Welche Domain-Accounts melden sich außer den lokalen Konten an den Systemen an (Admins, Service Accounts usw.)? In Bezug auf PtH eine nicht unwichtige Fragestellung. :) Als grundlegende Aussage, egal ob die lokalen Administratoren-Kennwörter unterschiedlich sind auf den Maschinen oder nicht: die Ebene der Workstations läßt sich kaum langfristig schützen, je nach Umgebung. Das heißt Ihr müßt sinnvoll diese "low security" Systeme von den "high security" Systemen trennen(!) durch Zonenmodelle. P.S.: Auch wenn es ein anderes Angriffsszenario (Stichwort "Golden TGT") ist - auch Kerberos ist in ähnlicher Art angreifbar. Nur als Hinweis, da Du lediglich LM/NTLM angesprochen hast. :) Viele Grüße olc

Hi, davon abgesehen, daß eine 100% Kopie der AD zumindest den reinen AD-Teil an Tests gut abdecken kann, gibt es auch ein, zwei Gegenargumente: Security: ist die Testumgebung mindestens genauso "abgesichert" (physisch, logische Zugriffe usw.) wie die produktive AD ? Kannst Du wirklich 100% sicherstellen, daß es keinen Netzwerkkontakt der beiden Umgebungen gibt und geben wird? Wie hältst Du nach der initialen Installation der "Spiegelumgebung" die ADs synchron usw. usf. Die Alternative zu einem Klon, der übrigens zumindest offiziell durch die meisten technischen Microsoft Mitarbeiter NICHT empfohlen wird, wer das Übertragen aller relevanten Einstellungen aus der Produktion in die Testumgebung. Dazu gehören unter anderem die Einstellungen, die Du oben erwähnt hast und sicher noch ein paar mehr. Das müßte gescriptet werden und ist mit einigem Aufwand verbunden, zugegeben. Viele Grüße olc

Hi, um ehrlich zu sein mag ich diese Diskussion nicht unbedingt weiterführen - ich denke ich habe oben alles gesagt, was für eine Bewertung notwendig ist. Wir drehen uns im Kreis. Wenn die Sicherheitsanforderungen Deiner Firma eine online Root CA für korrekt befinden, richte es gern so ein. Ich gehe davon aus, daß Ihr diese Sicherheitsanforderungen vorher definiert habt. Die einzige Aussage, die für mich in diesem Kontext dann noch Sinn hat, lautet: Ihr braucht eigentlich keine PKI, denn offensichtlich geht es nicht darum, das Sicherheitsniveau spürbar anzuheben. Wozu dann die Mühe, überhaupt eine PKI zu betreiben? P.S.: Alle(!) relevanten Guides zu PKI sprechen von einer offline Root CA. Wozu also diese Grundsatzdiskussion? Viele Grüße olc

:)

Hi, wie genau möchtest Du das Root CA Zertifikat zurückziehen...? ;) Der Unterschied zwischen einer Root CA und einer Sub/Intermediate/Issuing CA ist schlicht der, daß die Root CA Deine Wurzelinstanz ist. Ist diese kompromittiert, ist die ganze PKI nicht mehr vertrauenswürdig. Und das stellt Dich vor große Probleme, denn Du hast keine Instanz mehr, die dieses Vertrauen "beenden" (revozieren) könnte. Ist "nur" eine Sub/Intermediate/Issuing CA betroffen, die Root CA jedoch nicht, läßt sich das Vertrauen in die PKI weiter erhalten, nämlich über den Rückruf des Zertifikats (und damit der ausgestellten Zertifikate) der kompromittierten CA. Die Root CA ist also in einer PKI der schützenswerteste Punkt. Systeme, die online betrieben werden, haben per se größere Angriffspunkte als offline geschaltene Systeme. Das liegt in der Natur der Sache. Ich sage nicht, daß sie damit grundsätzlich "sicher" wären, nur sind die Angriffspunkte andere bzw. sind diese verschoben. Viele Grüße olc

Hi, 3. Treffer bei der Suchmaschine meiner Wahl: http://powershell.com/cs/media/p/30201.aspx ;) . Viele Grüße olc

Hi, in welchem Status befinden sich denn die Verbindungen? FIN_WAIT? Es gibt verschiedene Parameter, sie die jeweiligen TCP Timeouts bestimmen (siehe HKLM/System/CurrentControlSet/Services/TCPIP/Parameters). Aber da solltest Du nach Möglichkeit nicht herumschrauben. ;). Ggf. hält auch ein Filtertreiber (z.B. Firewall oder Virenscanner) den Socket fest. Ein Neustart löst das "Problem". Bei dem Thema: was genau ist eigentlich das Problem? ;) Viele Grüße olc

Mi Micha, Du hast da meines Erachtens einen Denkfehler. :) Die offline Root CA sorgt ja gerade dafür, daß Deine PKI Struktur nicht(!) oder nur mit enormen Aufwand kompromittiert werden kann. Sie online zu betreiben erhöht den Angriffsvektor massiv, was Du per Definition der Root CA (Wurzelvertrauen) verhindern möchtest. Viele Grüße olc

Hi Uwe, kannst Du einmal ein ipconfig /all von dem System posten? Ggf. anonymisieren, bitte jedoch nicht den ersten Teil bis zum Doppelpunkt. Viele Grüße olc

Ergänzend: http://blogs.technet.com/b/deds/archive/2009/08/31/hinweise-zur-einfuehrung-bzw-aktivierung-von-kennwortrichtlinien.aspx Absatz: Update 10.09.2009 Viele Grüße olc

Nein - es ist nicht "oversized". Du mußt Dein angestrebtes Sicherheitsniveau definieren und davon abhängig machen, wie Du die PKI betreiben möchtest. Es gibt im Kern eigentlich so gut wie kein Szenario, in dem eine offline Root CA keinen Sinn haben würde. Du betreibst eine PKI per Definition, um die Gesamtsicherheit in Deiner Umgebung zu steigern. Eine online Root CA setzt genau dieses Sicherheitsniveau wieder herunter. Ich würde soweit gehen zu sagen, daß Du Dir dann auch gleich die PKI sparen kannst - was sicherlich etwas übertrieben ist, den Hintergrund jedoch recht gut darstellt. Viele Grüße olc

Hi, starte LDP.exe und verbinde Dich mit dem Knoten "CN=Policies,CN=SYSTEM,DC=<domain>,DC=<tld>". Dort gehst Du jede GUID durch und schaust, welche der GUIDs Dir keine Attribute anzeigen, sprich Du kein Leserecht hast. Diese GUIDs (=GPOs) versorgst Du dann per Rechtsklick --> Advanced --> SACL (glaub ich) und gibst Deinem Administrativen Benutzer wieder Zugrff auf die jeweiloge GPO. Dann kannst Du die GPOs wieder mit der GPMC verwalten. Achtung: - Nur dem administrativen Benutzer READ+WRITE Rechte geben, nicht "APPLY" für ihn oder andere Benutzer. Sonst greifen die GPOs wieder, was Du nicht möchtest. - Zusätzlich beachte, daß im SYSVOL ebenso die alten GPOs liegen (sprich der Group Policy Template Teil). D.g. bearbeite die GPOs nach dem Setzen der ACLs wieder in der GPMC - dort sollte beim Klicken einer entsprechenden GPO der Hinweis kommen, daß das AD Objekt nicht mit dem SYSVOL Objekt (ACLs) übereinstimmt. Klicke hier "OK", um das wieder gerade zu ziehen. Die Links der betreffenden GPOs zu löschen ist eine sinnvolle Idee - jedoch nur, wenn Du nicht das gesamte Attribut leerst, sondern nur diejenigen GUIDs entfernst, die zu den "problematischen" GPOs gehören... Warte also lieber, bis Du sie wieder normal mit der GPMC bearbeiten kannst nach der LDP Aktion. :) Viele Grüße olc

Hi, wie ist es mit so etwas in der Art? $services = Get-WmiObject -Query "Select StartMode, State, Name From Win32_Service" $services | ForEach-Object { if ($_.startmode -eq "Auto" -AND $_.state -ne "Running") {write-warning $_.name}} Viele Grüße olc P.S.: Du weisst, dass es nicht immer ein Problem sein muss, wenn so ein Dienst nicht läuft? Was konkret möchtest Du mit der Information erreichen bzw. was davon ableiten?

Das ist der aktuellste Microsoft-Artikel dazu: http://technet.microsoft.com/en-us/library/hh994562(v=ws.10).aspx Viele Grüße olc

Vielen Dank für Deine Rückmeldung. :) Viele Grüße olc

Hi, nur der Vollständigkeit halber - das AdminCount Attribut selbst wirkt sich nicht auf den AdminSDHolder Prozess aus. Das Attribut gibt nur einen Status und hat keinen Einfluss auf das Schützen oder nicht-Schützen von Accounts. Zur Dokumentation bzw. besseren Nachvollziehbarkeit: http://gallery.technet.microsoft.com/scriptcenter/Reset-AD-adminCount-195bf65e Viele Grüße olc

..der Haken "Register this connection's addresses in DNS" in den TCP/IP Einstellungen der Netzwerkkarte ist gesetzt? Viele Grüße olc

Hi, schau einmal hier hinein, beschreibt in etwa das Szenario: http://support.microsoft.com/kb/295049/en-us Ansonsten als Hintergrund-Informationen: http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx Viele Grüße olc