lindner

Ja, ist aktuell. In der alten Version des AD's mit der gleichen version von Pingcastle erhalte ich dahingehend auch keine Meldung. Das kann eigentlich kein Bug sein :/

Hm, da magst Du Recht haben. Ist halt nur nervig, da PingCastle in der Kategorie ganz schön viele Minuspunkte vergibt :/ Wenn es meine OCD nun gar nicht mehr hergibt, das "Problem" zu ignorieren, wäre mein Ansatz mit dem Ex- und Import des ADs durchführbar?

Die Berechtigungseinträge der OUs werden mir angezeigt, aber keiner, in der meine gesuchte SID vorkommt. Wenn Pingcastle nun irgendeine Fantasie-SID anzeigen würde, würde ich auch an einen Bug denken. Aber da mir ja hier genau jene kürzlich gelöschte SID angezeigt. Das ist schon auffällig. (Edit: Außerdem ist dies noch nicht der Fall, wenn ich in der VM aus der Datensicherung von vor einem Monat Pingcastle durchlaufen lasse. Es muss also am AD liegen) Mich wundert nur einfach, wie Pingcastle das wissen kann, denn ich sehe diese SID ja auch nirgendwo. "Schwer"?! Was ist denn das für eine Übersetzung Habe es gerade probiert - es führt zu dem gleichen Ergebnis, wie über den Menü-Weg, den ich vorher beschrieb.

Och Manno... Auch mit ldp.exe erhalte ich keine Informationen über meine ominöse SID. Ich habe es über die Features "Durchsuchen - Sicherheit - Sicherheitsbeschreibung" und "Durchsuchen - Sicherheit - Benutzerrechte" probiert. Dort kann ich dann die erwarteten Einstellungen, die ich aus der AD-Verwaltung kenne, sehen. Gibt es dort noch weitere hilfreiche Features, die ich übersehen habe? Mit DSrevoke komme ich ebenfalls nícht weiter - das Tool zeigt mir einfach überhaupt kein Output an. Ich erhalte Fehlermeldungen, wenn ich den Befehl falsch eingebe, aber kein Output, wenn ich ihn richtig eingebe *confused*. Speichert das Programm den Report an eine Stelle, die ich nicht kenne? Ich hatte zwischenzeitlich eine Idee: Ich habe zum Testen den DC mal aus der Datensicherung von vor einem Monat geladen (als VM-Kopie). Führe ich Pingcastle dort aus, erhalte ich die Beanstandungen nicht. Irgendwas hat sich zwischenzeitlich also geändert. Ist es möglich, das AD aus dieser Maschine zu exportieren und in meinen "richtigen" DC wieder zu importieren? Geht das A) technisch und B) lässt es Dinge wie z.B. Vertrauensstellungen intakt?

Screenshot anbei. Im November wechselt die Geschäftsführung. Dann wird das definitiv geändert Mit DSRevoke probiere ich derzeit noch herum, ist nicht gerade intuitiv das Teil... Ah, das könnte vielleicht erklären, warum es zwei verschiedene Ergebnisse gibt, oder? Das versuche ich mal.

Nein, es ist nur ein DC.

Mir gelingt es, die betreffende Gruppe mit DSACLS anzuzeigen. Unter den dort aufgeführten Rechten ist jedoch meine geisterhafte SID wieder nicht dabei. Ich verzweifle...

Das tool kannte ich noch nicht - ich probier's. Vielen Dank! Ach Mist, dsrevoke arbeitet nur mit Prinzipalnamen, nicht aber mit SID's :(

Ja, das führt PingCastle auch aus. Es nennt mir die betreffende SID, die entsprechenden Rechte und die betreffende OU. Ich begreife nur nicht, wie PingCastle das sehen kann, ich aber nicht. Zapft denn PingCastle das AD anders an als z.B. die AD msc? Aber mal anders gefragt: Gibt es in der Powershell einen Befehl in der Art "Entferne alle Berechtigungen von SID XY auf OU soundso"?

Ja, das kenne ich auch so. Eine Idee, warum PingCastle da etwas feststellt, ich aber nichts sehen kann?

Moin, ich verwende PingCastle, um unser Active Directory zu härten. Mir wird dort eine Situation genannt, bei der ich Unterstützung benötige. Die Meldung: "Presence of unknown account in delegation" (also in etwa Delegierungen eines unbekannten Accounts vorhanden) Mir wird dazu eine SID genannt, anhand derer ich ermitteln konnte, dass es sich hier um Berechtigungen einer Benutzergruppe handelt, die wir kürzlich entfernt haben. Die Benutzergruppe ist mittlerweile aus dem AD Papierkorb dauerhaft entfernt. Trotzdem scheinen die Berechtigungen noch zu existieren. Nun die Krux: Checke ich die entsprechenden OU's, werden mir die genannten Berechtigungen nicht angezeigt, da diese Gruppe ja nicht mehr existiert. Wie entferne ich nun diese Überbleibsel? Sie werden mir auch nicht angezeigt, wenn ich über die Powershell alle Berechtigungseinstellungen der entsprechenden OU anzeigen lasse. Ich bin ratlos - kann jemand helfen? Liebe Grüße, Jan

Meines Erachtens ist es der Domain-Admin. Zumindest das einzige Administratorkonto, dass es hier gibt.

Davon hatte ich bisher immer abgesehen, aus Angst, dann irgendwie eine Sicherheitslücke aufzureißen. Ich habe es jetzt mal ausprobiert, aber keinen Erfolg. Irgendwo ist da der Wurm drin... Anbei zwei Screenshots vom obersten Domänenknoten: Im ersten sieht man, dass ich Vollzugriff für den Administrator eingestellt habe: Im zweiten ist jedoch ersichtlich, dass der Vollzugriff dann wieder eingeschränkt ist: Wie komme ich der Ursache auf den Grund?

So, ich hoffe, ich kann das hier irgendwie sinnvoll ausdrücken... Aufgrund @cj_berlin's Hinweis, dass es hier um das setzen von Bits im Attribut userAccountControl geht, habe ich versuchsweise mal die direkte Manipulation probiert. Hier habe ich keinen Zugriff, was ja zu erwarten war (Screenshot anhängend). In den Sicherheitseinstellungen des Nutzers, den ich verändern will, kann ich sehen, dass die Berechtigung "userAccountControl schreiben" gesetzt ist (Screenshot anhängend). In meinem Denken würde dies bedeuten, dass ich Zugriff auf das Feld habe, denn dieser Bereich heißt ja "effektive Berechtigungen" - ich gehe also davon aus, dass ein Ausschluß auf Domänenebene hier auch zu einem roten Kreuz führen würde. Dennoch bin ich an den root-Knoten gegangen um zu prüfen, ob dort irgendeine Art von Verbot existiert. Dort finde ich dann beim Effektiven Zugriff allerdings gar keine Erwähnung des Feldes userAccountControl. Ich habe ein paar andere Felder gefunden, die zwar etwas mit Kennwörtern zu tun haben, aber meines Erachtens unpassend sind (2 weitere Screenshots anhängend). Zumindest kann ich sehen, dass gewisse Verbote existieren, wie z.B. "Alle erweiterten Rechte", was auch immer das ist. Aber: Wenn nun kein explizites Verbot für "userAccountControl" existiert, SOLLTE ich doch eigentlich Zugriff haben, oder? Oder sind auf Root-Ebene manche Berechtigungen in Grüppchen zusammengefasst, deren Namen ich bloß nicht kenne? Findet sich das gesuchte Recht vielleicht in etwas anderem wie "erweiterte Rechte" (nur als Beispiel)? Muss ich entlang des Baumes auch alle untergeordneten Objekte der Baumstruktur in Richtung meines zu verändernden Benutzers auf Verbote kontrollieren?

Stimmt, da war was mit den Token. Ist lange her, dass ich mich damit herumärgern musste GPResult habe ich durchlaufen lassen und das Ergebnis ist deckungsgleich mit meinem Screenshot. Die RSAT kannte ich noch gar nicht - wie praktisch! Leider habe ich auch darüber den gleichen Fehler. Ich werde mich jetzt durch die Berechtigungen auf Domänen-Ebene durchwühlen, das sind ja eine ganze Menge mit sehr kryptischen Namen :(