Vertrauensgrenzen von Configuration Manager: Befugnisse zuordnen

Warum die OU-Zuordnung keine Vertrauensgrenzen von Configuration Manager belegt

Vertrauensgrenzen von Configuration Manager folgen administrativen Befugnissen: Wer kann eine Verwaltungskomponente ändern, welche Ressourcen kann ein Bediener steuern und auf welchen Systemen verfügt eine Installationsidentität über lokale Rechte? Der Distinguished Name eines AD-Computers ist ein nützlicher Inventarbeleg. Ihn in eine OU namens Management zu verschieben, beantwortet diese Fragen jedoch nicht.

Beginnen Sie beim erkannten Computer und verfolgen Sie dann seine Befugnisse nach außen. Handelt es sich um einen Standortserver, einen SMS Provider-Host, ein anderes Standortsystem oder lediglich um einen verwalteten Client mit einem Produktnamen in seiner Beschreibung? Welche Personen und Dienstidentitäten administrieren ihn? Welche Systeme können diese Identitäten erreichen? Eine Prüfung der Vertrauensgrenzen ist erst vollständig, wenn derselbe Datensatz die Verwaltungsinfrastruktur mit ihren tatsächlichen Zielen verbindet.

Das Tier-Verwaltungsmodell für Active Directory und administrative Sitzungen liefert die übergeordneten Trennungsprinzipien. Diese Prüfung ergänzt eine produktspezifische Zuordnung der Befugnisse. Halten Sie beides zusammen: Eine OU-Konvention kann die Bereitstellung von Richtlinien unterstützen, ersetzt aber keine Belege darüber, wer Configuration Manager oder die von ihm verwalteten Systeme kontrolliert.

Funktionsweise: Provider-Zugriff, Datenbankbefugnisse und Reichweite zu Zielsystemen

Microsoft beschreibt getrennte Sicherheitsebenen. Der SMS Provider ermöglicht den Zugriff auf die Standortdatenbank über WMI und den Verwaltungsdienst. Provider-Zugriff und Berechtigungen für verwaltete Objekte sind unterschiedliche Fragen. Local System und der Configuration Manager setup user haben standardmäßig Befugnisse über alle Objekte der Standortdatenbank; andere administrative Benutzer unterliegen der rollenbasierten Verwaltung der Konsole. Rollen, Sicherheitsbereiche und Sammlungen bestimmen gemeinsam, was ein Benutzer anzeigen und verwalten kann. Diese Unterscheidungen stammen aus den Sicherheitsgrundlagen von Configuration Manager.

Erfassen Sie für die Prüfung drei Pfade unabhängig voneinander:

• Infrastrukturkontrolle: Identitäten, die den Provider-Host, den Standortserver oder die Datenbankinfrastruktur administrieren können.
• Produktadministration: Sicherheitsprinzipale, deren zugewiesene Berechtigungen Vorgänge an bestimmten Configuration Manager-Objekten und Zielsammlungen erlauben.
• Installationsbefugnisse: Konten mit Rechten auf Systemen, auf denen das Produkt einen Client oder eine Standortsystemkomponente installiert.

Dies ist ein Bewertungsmodell, keine Behauptung, dass jeder Configuration Manager-Bediener uneingeschränkte Windows-Administrationsrechte besitzt. Ermitteln Sie für jeden Pfad den erlaubten Vorgang und die betroffene Ressource. Schließen Sie aus der Möglichkeit, den Provider abzufragen, nicht, dass die Identität auf jedem Gerät Bereitstellungen ausführen kann.

Microsofts Kontenreferenz für Configuration Manager nennt konkrete Unterschiede. SMS Admins ist eine lokale Gruppe auf Provider-Computern; ihre WMI-Berechtigungen lassen sich mit dem MMC-Snap-In WMI Control prüfen. RBAC bestimmt weiterhin den Zugriff auf Konsolenobjekte. Das client push installation account benötigt die Mitgliedschaft in der lokalen Gruppe Administrators auf den Zielclients, nicht in Domain Admin; ohne konfiguriertes Konto versucht der Standort, sein Computerkonto zu verwenden. Das separate site system installation account benötigt lokale administrative Berechtigungen und das Benutzerrecht für Netzwerkzugriff auf den Ziel-Standortsystemen. Das network access account dient dem Ressourcenzugriff, nicht als Ausführungskontext für Software, Updates oder Tasksequenzen.

Diese Konten verdienen getrennte Zeilen, auch wenn dieselbe AD-Identität mehrere Funktionen erfüllt. Eine Bezeichnung wie „Dienstkonto“ verdeckt den Unterschied zwischen dem Herunterladen von Inhalten und der Administration eines Zielsystems. Umgekehrt belegen unterschiedliche Kontennamen keine Trennung, wenn die Konten gleichwertige Rechte auf denselben Computern erhalten.

Erkennung: Die Befugnismatrix aus Produktbelegen aufbauen

Schritt 1: Die tatsächliche Funktion des Kandidaten bestätigen

Bewahren Sie den LDAP-Befund, den Computer-DN, das passende Inventarfeld und das Prüfdatum auf. Bitten Sie den Produktverantwortlichen, die tatsächliche Funktion des Kandidaten und den zugehörigen Standort zu benennen. Gleichen Sie diese Antwort mit der bereitgestellten Produktkonfiguration und dem Hostinventar ab. Ist es lediglich ein Client, dokumentieren Sie, weshalb die Heuristik ihn erfasst hat; erfinden Sie keine Verwaltungsrolle, um den Befund zu rechtfertigen.

Listen Sie bei einer bestätigten Verwaltungskomponente die abhängigen Provider- und Datenbankhosts, Installationsidentitäten und administrativen Verantwortlichen auf. Kennzeichnen Sie ungeklärte Beziehungen als unbekannt. Ein Inventar, in dem ein Provider oder ein entferntes Standortsystem fehlt, kann einen vermeintlich engen Verwaltungsumfang sicherer erscheinen lassen, als er ist.

Schritt 2: Rollen, Sicherheitsbereiche und zugewiesene Sammlungen gemeinsam lesen

Folgen Sie Microsofts Verfahren zur Konfiguration der rollenbasierten Verwaltung. Öffnen Sie in der Konsole Administration > Security > Administrative Users, wählen Sie den Sicherheitsprinzipal aus und öffnen Sie Properties. Prüfen Sie Security Roles und Security Scopes, einschließlich der konfigurierten Zuordnung zwischen Rollen, Sicherheitsbereichen und Sammlungen. Um die Objektberechtigungen einer Rolle zu prüfen, wechseln Sie zu Administration > Security > Security Roles, wählen die Rolle aus, öffnen Properties und wählen die Registerkarte Permissions.

Prüfen Sie für Befugnisse über Sammlungen die Berechtigungen der Rolle für das Objekt Collection und die dem administrativen Benutzer zugewiesenen Sammlungen. Beziehen Sie auch Sammlungen ein, die durch diese zugewiesenen Sammlungen begrenzt sind. Microsoft nennt außerdem das Role-based administration and auditing tool zur Prüfung von Benutzern, Sammlungen und Sicherheitsbereichen.

Verwenden Sie diese Ansichten als Belege, nicht nur als Screenshots sprechender Namen. Erfassen Sie Kennungen, die relevanten erlaubten Aktionen, gruppenbasierte Zuweisungen und die für die Prüfung herangezogene Gerätemitgliedschaft. Ändert sich die Mitgliedschaft, muss die Befugniszuordnung erneut geprüft werden. Eine Sammlung namens „Servers“ belegt nicht, dass jedes Mitglied zur vorgesehenen Vertrauensstufe gehört.

Schritt 3: Installationskonfiguration und lokale Rechte auf Zielsystemen prüfen

Microsofts Verfahren zur Bereitstellung von Windows-Clients nennt den Konsolenpfad: Administration > Site Configuration > Sites, den Standort auswählen, dann Client Installation Settings > Client Push Installation. Prüfen Sie die Registerkarte Accounts sowie auf General die Einstellungen für automatische Installation, die ausgewählten Systemtypen und die Auswahl von Domänencontrollern. Das Verfahren dokumentiert auch die für ein einzelnes Gerät oder eine Sammlung gestartete Push-Installation.

Lesen Sie diese Konfiguration, bevor Sie eine Installation auslösen. Eine konfigurierte Zielauswahl ist ein Beleg für den Installationsablauf; prüfen Sie unabhängig davon, wo jede Identität tatsächlich lokale administrative Rechte besitzt. Unterscheiden Sie das konfigurierte client push account, den Rückgriff auf das Computerkonto und das site system installation account.

Erfassen Sie erfolgreiche und fehlgeschlagene Verifizierungen getrennt. Kann die lokale Gruppenmitgliedschaft auf einem Ziel nicht geprüft werden, kennzeichnen Sie dieses Ziel als unbekannt. Leiten Sie aus einem nicht erreichbaren Host keine fehlenden Rechte ab und aus einer erfolgreichen Prüfung auf einem repräsentativen Gerät keine Rechte auf allen Computern.

Schritt 4: Sicherheitsprinzipale mit verwalteten Systemen verbinden

Erstellen Sie eine Zeile pro Befugnispfad. Die folgende Tabelle ist eine Vorlage für die Prüfung, keine ermittelte Umgebung und keine Zusammenstellung von Standardberechtigungen:

Lesen Sie die Tabelle quer: Sicherheitsprinzipal → Rolle/Konto → Standort/Sammlung → verwaltete Systeme. Fragen Sie dann, welche Zeile zuvor getrennte Vertrauensstufen verbindet. Prüfen Sie kombinierte Zuweisungen, statt jede Rolle isoliert zu betrachten. Behalten Sie einen separaten Eintrag für eine unbekannte Zielmenge bei; eine leere Zelle darf niemals stillschweigend „kein Zugriff“ bedeuten.

Abhilfe: Befugnisse vor einer Änderung der OU-Zuordnung abstimmen (Remediation)

Schritt 1: Die beabsichtigte Grenze festlegen und den Ausgangszustand sichern

Definieren Sie gemeinsam mit den Infrastruktur- und Identitätsverantwortlichen, welche verwalteten Systeme zusammengehören und welche administrativen Pfade getrennt bleiben müssen. Vergleichen Sie diese beabsichtigte Grenze mit jeder Matrixzeile. Dokumentieren Sie für jede Abweichung den Grund, den Verantwortlichen und die zu ihrer Klärung benötigten Belege.

Sichern Sie vor Änderungen die bestehenden Rollenzuweisungen, die Installationskonfiguration, die Zielmitgliedschaften und die betrieblichen Abhängigkeiten. Wählen Sie einen Pilotumfang, der sowohl ein vorgesehenes Ziel als auch ein System außerhalb der Befugnisse des Bedieners enthält. Planen Sie für jede Änderung einen genehmigten Funktionstest und eine Rücknahme.

Schritt 2: Produktberechtigungen über die unterstützte Konsole einschränken

Passen Sie mit den bereits geprüften Eigenschaften des administrativen Benutzers die relevanten Zuordnungen von Rollen, Sicherheitsbereichen und Sammlungen an. Gewähren bestehende Rollen zu weitreichende Befugnisse, verwenden Sie Microsofts dokumentiertes Verfahren für benutzerdefinierte Rollen: Kopieren Sie eine Rolle unter Administration > Security > Security Roles, prüfen Sie ihre Objektberechtigungen und weisen Sie nur die benötigten Berechtigungen zu. Die Berechtigungen integrierter Rollen lassen sich nicht bearbeiten. Diese Vorgänge sind im Verfahren zur Konfiguration der rollenbasierten Verwaltung beschrieben.

Die Änderung sollte einen konkreten unerwünschten Vorgang oder eine Zielbeziehung entfernen. Prüfen Sie, dass die vorgesehene Administration weiterhin funktioniert und das ausgeschlossene System außerhalb der gewährten Befugnisse liegt. Behalten Sie die Infrastrukturadministration im Prüfumfang; allein die Einschränkung einer Konsolenzuweisung beseitigt keinen separaten Administrationspfad zum Host oder zur Datenbank.

Schritt 3: Installationsbefugnisse trennen, wenn ihre Reichweite die Grenze überschreitet

Vergleichen Sie für jede Installationsidentität ihre bestätigten lokalen Rechte mit der vorgesehenen Zielmenge. Schlagen Sie separate, angemessen begrenzte Identitäten vor, wenn ein Konto mehrere Vertrauensstufen abdeckt. Prüfen Sie das im Produkt konfigurierte Konto und die an jedem Ziel gewährten Berechtigungen; eine Änderung nur auf einer Seite lässt die Prüfung unvollständig.

Microsofts Kontenreferenz empfiehlt, dem client push account die lokale interaktive Anmeldung ausdrücklich zu verweigern. Sie dokumentiert außerdem eine Austauschfolge: Ein anders benanntes Konto erstellen, es der konfigurierten Liste hinzufügen, die AD-Replikation abwarten und dann das alte Konto außer Betrieb nehmen. Behandeln Sie dies als koordinierte Migration mit Verifizierung der Zielrechte, nicht als Anweisung zum Bereinigen von Konten oder Gruppen. Die site system installation identity benötigt eine eigene Zielprüfung. Folgen Sie den dokumentierten Kontoanforderungen für die tatsächlich verwendete Funktion.

Schritt 4: OU-Zuordnung, administrative Sitzungen und Datenflüsse abgleichen

Erst wenn die Befugniszuordnung schlüssig ist, sollten OU-Zuordnung, Delegierung, Richtlinien und administrative Einstiegspunkte mit dem vorgesehenen Entwurf verglichen werden. Betrachten Sie die Verwaltungshosts zusammen mit den Personen und Konten, die sie kontrollieren. Das Verschieben eines einzelnen Computerobjekts behebt kein Konto, das Rechte auf einer unbeabsichtigten Zielmenge behält.

Prüfen Sie den Transport als separate Kontrolle. Die GPO-Prüfungen für den Transport von WSUS-Metadaten behandeln den Schutz dieser Verbindung; sie belegen nicht, wer den SMS Provider administrieren kann oder was eine Installationsidentität kontrolliert. Behalten Sie beide Prüfungen mit getrennten Belegen und Schlussfolgerungen bei.

Schritt 5: Befunde mit Belegen schließen und Ausnahmen beibehalten

Erstellen Sie die Matrix nach dem Piloten und dem anschließenden Rollout neu. Fügen Sie jeder geänderten Zeile die neue Zuweisung, die aktuelle Zielmitgliedschaft, relevante Belege für lokale Rechte und das funktionale Ergebnis hinzu. Eine Ausnahme sollte den erforderlichen Vorgang, die betroffenen Systeme, den Verantwortlichen, kompensierende Maßnahmen und einen Auslöser für eine erneute Prüfung benennen. Eine ungeklärte Berechtigung oder ein nicht erreichbares Ziel bleibt unbekannt.

Definieren Sie Auslöser für eine weitere Prüfung: ein neuer Provider-Host, ein Standortsystem, eine Sammlungszuweisung, eine Installationsidentität oder eine verwaltete Vertrauensstufe. Eine Entscheidung über Grenzen bleibt nur vertretbar, solange die zugrunde liegende Befugniszuordnung mit der bereitgestellten Umgebung übereinstimmt.

Wie EtcSec dies erkennt

Die geprüfte etc-collector-Kontrolle heißt ANSSI_R49_R50_MGMT_CATEGORIZATION, am Collector-Commit 15fc6399c215eabc415c370b762303cfcd7a353a. Sie ist eine Inventar- und Namensheuristik, keine Prüfung der Configuration Manager-Autorisierung.

Ein Computer wird zum Kandidaten, wenn sein DN einem Eintrag im optionalen mgmt_systems entspricht oder wenn die in Kleinbuchstaben umgewandelte Kombination aus SAMAccountName, DNSHostName, Description und OperatingSystem einen dieser Marker enthält: sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack oder sentinelone.

Sie erzeugt einen Befund für Kandidaten, deren kleingeschriebener DN keines der Fragmente ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt oder ou=management enthält. Dies sind Teilzeichenfolgentests, keine Validierung der tatsächlichen Kontrollen einer OU. Wenn kein Kandidat diesen Test verfehlt, gibt Detect() nil zurück.

Die optionale Liste mgmt_systems stammt aus tier0_groups.yaml. Fehlt diese Datei, wird keine Anpassung geladen, die Liste bleibt leer und nur Namensheuristiken gelten, ohne Warnmeldung. Ist die Datei nicht lesbar oder ihr YAML fehlerhaft, schreibt die Engine eine Warnmeldung nach stderr und fährt mit den Standardwerten fort. Ein expliziter DN-Eintrag fügt einen Kandidaten hinzu; er belegt keine Produktbefugnisse und ersetzt nicht den OU-Teilzeichenfolgentest.

Der LDAP-Provider liefert Computerinventarfelder. Diese Kontrolle erfasst keine SMS Provider-Berechtigungen, Standortdatenbankbefugnisse, RBAC-Zuweisungen, Zielsammlungen oder Rechte von Installationskonten. Ein Clientname kann passen; ein tatsächlich mächtiges Verwaltungssystem kann übersehen werden; ein OU-Name kann den Teilzeichenfolgentest erfüllen, ohne Isolation durchzusetzen.

Nutzen Sie den Befund als Ausgangspunkt für die Befugnisprüfung. Klären Sie die Architekturfrage mit den Produkt- und Zielbelegen in der Matrix. Behalten Sie Unbekanntes und Ausnahmen bei, auch wenn die Namensheuristik keinen Befund mehr meldet.