Freigeben über

Vorgehensweise zur Wiederherstellung nach einem GoldenGMSA-Angriff

  • Artikel

In diesem Artikel wird ein Ansatz zum Reparieren der Anmeldeinformationen eines gruppenverwalteten Dienstkontos (gMSA) beschrieben, das von einem Gefährdungsvorfall für Domänencontrollerdatenbanken betroffen ist.

Symptome

Eine Beschreibung eines Golden gMSA-Angriffs finden Sie im folgenden Semperis-Artikel:

Einführung in den Golden GMSA Angriff

Die Beschreibung im obigen Artikel ist genau. Der Ansatz zum Beheben des Problems besteht darin, das Microsoft Key Distribution Service (kdssvc.dll, auch als KDS bezeichnete) Stammschlüsselobjekt und alle GMSAs zu ersetzen, die das kompromittierte KDS-Stammschlüsselobjekt verwenden.

Weitere Informationen

Bei einem erfolgreichen Angriff auf eine gMSA ruft der Angreifer alle wichtigen Attribute des KDS-Stammschlüsselobjekts und die Sid Attribute msds-ManagedPasswordID eines gMSA-Objekts ab.

Das msds-ManagedPasswordID Attribut ist nur für eine schreibbare Kopie der Domäne vorhanden. Wenn die Datenbank eines Domänencontrollers verfügbar gemacht wird, ist daher nur die Domäne, auf der der Domänencontroller gehostet wird, für den Golden gMSA-Angriff geöffnet. Wenn sich der Angreifer jedoch bei einem Domänencontroller einer anderen Domäne in der Gesamtstruktur authentifizieren kann, verfügt der Angreifer möglicherweise über ausreichende Berechtigungen, um den Inhalt zu msds-ManagedPasswordIDerhalten. Der Angreifer könnte diese Informationen dann verwenden, um einen Angriff auf GMSAs in zusätzlichen Domänen zu erstellen.

Um zusätzliche Domänen Ihrer Gesamtstruktur zu schützen, nachdem eine Domäne verfügbar gemacht wurde, müssen Sie alle GMSAs in der offengelegten Domäne ersetzen, bevor der Angreifer die Informationen verwenden kann. In der Regel wissen Sie nicht, welche Details verfügbar gemacht wurden. Daher wird empfohlen, die Auflösung auf alle Domänen der Gesamtstruktur anzuwenden.

Als proaktive Maßnahme kann die Überwachung verwendet werden, um die Belichtung des KDS-Stammschlüsselobjekts nachzuverfolgen. Eine Systemzugriffssteuerungsliste (SACL) mit erfolgreichen Lesevorgängen kann im Container "Stammschlüssel" platziert werden, der die Überwachung erfolgreicher Lesevorgänge für das msKds-RootKeyData Attribut der msKds-ProvRootKey Klasse ermöglicht. Diese Aktion bestimmt die Belichtungslandschaft des Objekts in Bezug auf einen Golden gMSA-Angriff.

Notiz

Die Überwachung hilft nur, einen Onlineangriff auf die KDS-Stammschlüsseldaten zu erkennen.

Sie können den ManagedPasswordIntervalInDays Parameter auf 15 Tage festlegen oder beim Erstellen eines gMSA einen geeigneten Wert auswählen, da der ManagedPasswordIntervalInDays Wert schreibgeschützt wird, nachdem ein gMSA erstellt wurde.

Im Falle einer Kompromittierung kann diese Einstellung die nächste Rollzeit reduzieren.

Die theoretische Anzahl von gMSA wird reduziert, um zwischen dem Datum der wiederhergestellten Sicherung und dem Ende der Datenbankexposition oder zumindest die Dauer des Risikofensters neu zu erstellen, bis diese GMSAs-Roll, wenn Sie mit Szenario 1 fortfahren.

Hier ist ein Beispielszenario:

  1. Nach einer Datenbankexposition führen Sie die Wiederherstellung in "Tag D" aus.

  2. Die wiederhergestellte Sicherung stammt aus D-15.

    Notiz

    D-15 bedeutet den Tag, der 15 Tage vor "Tag D" liegt.

  3. Der gMSA-Wert ManagedPasswordIntervalInDays ist 15.

  4. gMSAs sind vorhanden und verfügen über rolld D-1.

  5. Neuere gMSAs wurden aus D-10 erstellt.

  6. Der Kompromiss tritt auf D-5 auf, und einige GMSAs wurden an diesem Datum erstellt.

Dies sind die Ergebnisse:

  1. gMSAs, die zwischen D und D-5 erstellt wurden, sind nicht betroffen*.

  2. GMSAs, die zwischen D-15 (sicherung wiederhergestellt) und D-5 (Kompromittierung)* erstellt wurden, müssen neu erstellt werden, oder die Risikofenster müssen angenommen werden, wenn Sie von D+5 bis D+10 warten können. Zum Beispiel:

    • Bei D+5 müssen gMSAs, die auf D-10 erstellt wurden, neu erstellt werden.
    • Bei D+10 müssen gMSAs, die auf D-5 erstellt wurden, neu erstellt werden.

    *Hängt vom genauen Zeitpunkt der Kompromittierung oder Sicherung ab.

Hier ist eine Beispielzeitachse:

Diagramm einer Beispiel-GMSAs-Zeitachse.

Für das Debuggen können Sie die Ereignis-IDs für das Ereignisprotokoll "System", "Sicherheit", "Verzeichnisdienste" und "Security-Netlogon" überprüfen.

Weitere Informationen zu einer Kompromittierung finden Sie unter Verwenden von Microsoft- und Azure-Sicherheitsressourcen zur Wiederherstellung von systemischen Identitätskompromittierungen.

Lösung

Um dieses Problem zu beheben, verwenden Sie je nach Situation einen der folgenden Ansätze. Die Ansätze umfassen das Erstellen eines neuen KDS-Stammschlüsselobjekts und das Neustarten des Microsoft Key Distribution Service auf allen Domänencontrollern der Domäne.

Szenario 1: Sie verfügen über zuverlässige Informationen darüber, welche Informationen verfügbar gemacht wurden und wann

Wenn Sie wissen, dass die Exposition vor einem bestimmten Datum aufgetreten ist und dieses Datum vor dem ältesten gMSA-Kennwort liegt, das Sie haben, können Sie das Problem beheben, ohne die gMSAs neu zu erstellen, wie in der nachstehenden Prozedur gezeigt.

Der Ansatz besteht darin, ein neues KDS-Stammschlüsselobjekt zu erstellen, das dem Angreifer unbekannt ist. Wenn die gMSAs ihr Kennwort rollieren, werden sie mit dem neuen KDS-Stammschlüsselobjekt verschoben. Um gMSAs zu beheben, die kürzlich ihr Kennwort mithilfe des alten KDS-Stammschlüssels rolliert haben, ist eine autorisierende Wiederherstellung erforderlich, um eine Kennwortaktualisierung unmittelbar nach der Wiederherstellung zu erzwingen.

Notiz

  • Sie müssen GMSAs nicht manuell reparieren, die nach Beendigung der Active Directory-Domäne Services (AD DS)-Datenbankexposition erstellt wurden. Der Angreifer kennt die Details dieser Konten nicht, und die Kennwörter für diese Konten werden basierend auf dem neuen KDS-Stammschlüsselobjekt neu generiert.
  • Sie sollten das gMSA-Objekt im "Wartungsmodus" betrachten, bis die Prozedur abgeschlossen ist, und mögliche Fehler ignorieren, die mit den Konten im Ereignisprotokoll "System", "Sicherheit", "Verzeichnisdienste" und "Security-Netlogon" gemeldet werden.
  • In der Anleitung wird davon ausgegangen, dass die gMSAs untergeordnete Objekte des Containers für verwaltete Dienstkonten sind. Wenn Sie die Konten in benutzerdefinierte übergeordnete Container verschoben haben, müssen Sie die Schritte im Zusammenhang mit dem Container "Verwaltete Dienstkonten " auf der gMSA in diesen Containern ausführen.
  • Eine autorisierende Wiederherstellung setzt alle Attribute zurück, die zum Zeitpunkt der Sicherung enthalten waren, einschließlich der Konten, die zum Abrufen der gMSA-Anmeldeinformationen (PrincipalsAllowedToRetrieveManagedPasswordgMSA) berechtigt sind.

Führen Sie in der Domäne mit den gMSAs, die Sie reparieren möchten, die folgenden Schritte aus:

  1. Nehmen Sie einen Domänencontroller offline, und isolieren Sie ihn aus dem Netzwerk.

  2. Stellen Sie den Domänencontroller aus einer Sicherung wieder her, die vor der Gefährdung der AD DS-Datenbank erstellt wurde.

    Wenn das Kennwortintervall für die gMSAs länger als das Alter der Sicherung ist, können Sie das Fenster tolerieren, in dem das vorherige Schlüsselmaterial noch funktioniert. Wenn Sie nicht so lange warten können und die übereinstimmende ältere Sicherung zu viele GMSAs fehlt, müssen Sie den Plan zu Szenario 2 wechseln.

  3. Führen Sie einen autoritativen Wiederherstellungsvorgang im Container "Verwaltete Dienstkonten" der Domäne aus. Stellen Sie sicher, dass der Wiederherstellungsvorgang alle untergeordneten Objekte der Container enthält, die diesem Domänencontroller zugeordnet sein können. In diesem Schritt wird der Status der letzten Kennwortaktualisierung zurückgesetzt. Wenn ein Dienst das Kennwort das nächste Mal abruft, wird das Kennwort basierend auf dem neuen KDS-Stammschlüsselobjekt auf ein neues aktualisiert.

  4. Beenden und deaktivieren Sie den Microsoft Key Distribution Service auf dem wiederhergestellten Domänencontroller.

  5. Führen Sie auf einem anderen Domänencontroller die Schritte unter Erstellen des KDS-Stammschlüssels für Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    Notiz

    In der Produktionsumgebung müssen Sie 10 Stunden warten, um sicherzustellen, dass der neue KDS-Stammschlüssel verfügbar ist. Überprüfen Sie das EffectiveTime Attribut, um zu wissen, wann der neue KDS-Stammschlüssel verwendet werden kann.

  6. Starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern neu.

  7. Erstellen Sie ein neues gMSA. Stellen Sie sicher, dass das neue gMSA das neue KDS-Stammschlüsselobjekt verwendet, um den Wert für das msds-ManagedPasswordID Attribut zu erstellen.

    Notiz

    Dieser Schritt ist optional, ermöglicht ihnen jedoch zu überprüfen, ob der neue KDS-Stammschlüssel derzeit verwendet und im Microsoft Key Distribution Service verwendet wird.

  8. Überprüfen Sie den msds-ManagedPasswordID Wert der ersten gMSA, die Sie erstellt haben. Der Wert dieses Attributs ist Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

    Gehen Sie beispielsweise davon aus, dass das KDS-Stammschlüsselobjekt folgendes CNaufweist.

    Screenshot, der den Wert des CN-Attributs eines KDS-Stammschlüsselobjekts zeigt.

    Ein mit diesem Objekt erstelltes gMSA weist einen msds-ManagedPasswordID Wert auf, der dem folgenden ähnelt.

    Screenshot des Werts des MsDS-ManagedPasswordId-Attributs eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

    In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

    Wenn die erste von Ihnen erstellte gMSA den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs auch den neuen Schlüssel.

  9. Deaktivieren und beenden Sie den Microsoft Key Distribution Service auf allen Domänencontrollern.

  10. Stellen Sie die Verbindung wieder her, und bringen Sie den wiederhergestellten Domänencontroller wieder online. Stellen Sie sicher, dass die Replikation funktioniert.

    Jetzt werden die autorisierende Wiederherstellung und alle anderen Änderungen (einschließlich der wiederhergestellten gMSAs) repliziert.

  11. Aktivieren und starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern erneut. Die geheimen Schlüssel der wiederhergestellten gMSAs werden rolliert, und neue Kennwörter werden basierend auf dem neuen KDS-Stammschlüsselobjekt auf Anforderung erstellt.

    Notiz

    Wenn die gMSAs wiederhergestellt, aber nicht verwendet werden und der PrincipalsAllowedToRetrieveManagedPassword Parameter aufgefüllt ist, können Sie das Test-ADServiceAccount Cmdlet auf dem wiederhergestellten gMSA ausführen, indem Sie einen Prinzipal verwenden, der das Kennwort abrufen darf. Wenn eine Kennwortänderung erforderlich ist, führt dieses Cmdlet die gMSAs in den neuen KDS-Stammschlüssel ein.

  12. Stellen Sie sicher, dass alle gMSAs rolld ausgeführt wurden.

    Notiz

    Die gMSA ohne den PrincipalsAllowedToRetrieveManagedPassword aufgefüllten Parameter wird nie rollt.

  13. Löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  14. Starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern neu.

Szenario 2: Sie kennen nicht die Details des KDS-Stammschlüsselobjekts, und Sie können nicht warten, bis Kennwörter rollt.

Wenn Sie nicht wissen, welche Informationen verfügbar gemacht wurden oder wann sie verfügbar gemacht wurde, ist eine solche Exposition möglicherweise Teil einer vollständigen Exposition Ihrer Active Directory-Gesamtstruktur. Dies kann eine Situation schaffen, in der der Angreifer Offlineangriffe auf alle Kennwörter ausführen kann. In diesem Fall sollten Sie eine Gesamtstrukturwiederherstellung ausführen oder alle Konto-Kennwörter zurücksetzen. Das Wiederherstellen der gMSAs in einen sauberen Zustand ist Teil dieser Aktivität.

Während des folgenden Prozesses müssen Sie ein neues KDS-Stammschlüsselobjekt erstellen. Anschließend verwenden Sie dieses Objekt, um alle gMSAs in den Domänen der Gesamtstruktur zu ersetzen, die das verfügbar gemachte KDS-Stammschlüsselobjekt verwenden.

Notiz

Die folgenden Schritte ähneln dem Verfahren, das sich in den ersten Schritten mit Gruppenverwalteten Dienstkonten befindet. Es gibt jedoch einige wichtige Änderungen.

Führen Sie folgende Schritte aus:

  1. Deaktivieren Sie alle vorhandenen gMSAs, und markieren Sie sie als Zu entfernende Konten. Legen Sie dazu für jedes Konto das userAccountControl Attribut auf 4098 fest (dieser Wert kombiniert WORKSTATION_TRUST_ACCOUNT- und ACCOUNTDISABLE-Flags (deaktiviert).

    Sie können ein PowerShell-Skript wie das folgende verwenden, um die Konten festzulegen:

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. Verwenden Sie einen einzelnen Domänencontroller, und führen Sie die folgenden Schritte aus:

    1. Führen Sie die Schritte unter Erstellen des KDS-Stammschlüssels für Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    2. Starten Sie den Microsoft Key Distribution Service neu. Nach dem Neustart nimmt der Dienst das neue Objekt auf.

    3. Sichern Sie DNS-Hostnamen und Dienstprinzipalnamen (SPNs), die jedem zu entfernenden gMSA zugeordnet sind.

    4. Bearbeiten Sie die vorhandenen gMSAs, um die SPNs- und DNS-Hostnamen zu entfernen.

    5. Erstellen Sie neue gMSAs, um die vorhandenen gMSAs zu ersetzen. Sie müssen auch mit den DNS-Hostnamen und SPNs konfiguriert werden, die Sie soeben entfernt haben.

      Notiz

      Außerdem müssen Sie alle Berechtigungseinträge mithilfe der direkt entfernten gMSA-SIDs überprüfen, da sie nicht mehr aufgelöst werden können. Wenn Sie einen Zugriffssteuerungseintrag (Access Control Entry, ACE) ersetzen, sollten Sie Gruppen zum Verwalten von gMSA-Berechtigungseinträgen verwenden.

  3. Überprüfen Sie die neuen gMSAs, um sicherzustellen, dass sie das neue KDS-Stammschlüsselobjekt verwenden. Gehen Sie dazu wie folgt vor:

    1. Notieren Sie sich den CN Wert (GUID) des KDS-Stammschlüsselobjekts.

    2. Überprüfen Sie den msds-ManagedPasswordID Wert der ersten gMSA, die Sie erstellt haben. Der Wert dieses Attributs ist Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

      Gehen Sie beispielsweise davon aus, dass das KDS-Stammschlüsselobjekt folgendes CNaufweist.

      Screenshot des Werts des CN-Attributs eines KDS-Stammschlüsselobjekts.

      Ein mit diesem Objekt erstelltes gMSA weist einen msds-ManagedPasswordID Wert auf, der dem Bild ähnelt.

      Screenshot des Werts des MsDS-ManagedPasswordId-Attributs eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

      In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

      Wenn die erste von Ihnen erstellte gMSA den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs auch den neuen Schlüssel.

  4. Aktualisieren Sie die entsprechenden Dienste, um die neuen gMSAs zu verwenden.

  5. Löschen Sie die alten GMSAs, die das alte KDS-Stammschlüsselobjekt verwendet haben, mithilfe des folgenden Cmdlets:

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. Löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  7. Starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern neu.

Szenario 3: Rücktritt eines Domänenadministrators, zur Zeit wurden keine Informationen gestohlen, und Sie können warten, bis Kennwörter rollt.

Wenn ein Mitglied mit hoher Berechtigung mit Domänenadministratoren oder gleichwertigen Rechten abgetreten ist, gibt es zur Zeit keine Nachweise für die Gefährdung des KDS-Stammschlüssels, und Sie können sich ein Zeitfenster für das Rollieren von Kennwörtern leisten. Sie müssen die gMSAs nicht neu erstellen.

Als präventive Maßnahme muss der KDS-Stammschlüssel bereitgestellt werden, um Angriffe nach der Ausbeutung zu verhindern. Beispielsweise hat sich ein ehemaliger Domänenadministrator als Schurken erwiesen und einige Sicherungen aufbewahrt.

Ein neues KDS-Stammschlüsselobjekt wird erstellt, und gMSAs werden natürlich rollieren.

Notiz

Eine Kompromittierung im Zusammenhang mit einem Domänenadministrator finden Sie in Szenario 1 oder Szenario 2 entsprechend den verfügbar gemachten Informationen, und befolgen Sie die lokalen Wartungsaktivitäten unter "Verwenden von Microsoft- und Azure-Sicherheitsressourcen, um die Wiederherstellung von systemischen Identitätskompromittierungen zu unterstützen".

Führen Sie in der Domäne mit den GMSAs, die Sie rollieren möchten, die folgenden Schritte aus:

  1. Führen Sie auf einem Domänencontroller die Schritte unter Erstellen des KDS-Stammschlüssels für Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    Notiz

    In der Produktionsumgebung müssen Sie 10 Stunden warten, um sicherzustellen, dass der neue KDS-Stammschlüssel verfügbar ist. Überprüfen Sie das EffectiveTime Attribut, um zu wissen, wann der neue KDS-Stammschlüssel verwendet werden kann.

  2. Starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern neu.

  3. Erstellen Sie ein neues gMSA. Stellen Sie sicher, dass das neue gMSA das neue KDS-Stammschlüsselobjekt verwendet, um den Wert für das msds-ManagedPasswordID Attribut zu erstellen.

    Notiz

    Dieser Schritt ist optional, ermöglicht ihnen jedoch zu überprüfen, ob der neue KDS-Stammschlüssel derzeit verwendet und im Microsoft Key Distribution Service verwendet wird.

  4. Überprüfen Sie den msds-ManagedPasswordID Wert der ersten gMSA, die Sie erstellt haben. Der Wert dieses Attributs ist Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

    Gehen Sie beispielsweise davon aus, dass das KDS-Stammschlüsselobjekt folgendes CNaufweist.

    Screenshot des Werts des CN-Attributs eines KDS-Stammschlüsselobjekts.

    Eine gMSA, die mit diesem Objekt erstellt wird, weist einen msds-ManagedPasswordID Wert auf, der der folgenden Abbildung ähnelt.

    Screenshot des Werts des MsDS-ManagedPasswordId-Attributs eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

    In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

    Wenn die erste von Ihnen erstellte gMSA den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs auch den neuen Schlüssel.

  5. Je nach nächstem Kennwortroll werden die geheimen Schlüssel der gMSAs natürlich rollt, und neue Kennwörter werden basierend auf dem neuen KDS-Stammschlüsselobjekt auf Anfrage erstellt.

    Notiz

    Wenn verwendete gMSAs rolld ausgeführt wurden, aber nicht verwendete GMSAs mit demselben Rollintervall nicht vorhanden sind und der PrincipalsAllowedToRetrieveManagedPassword Parameter aufgefüllt ist, können Sie das Test-ADServiceAccount Cmdlet ausführen. Es verwendet einen Prinzipal, der das gMSA-Kennwort abrufen darf, und dieser Schritt verschiebt dann die gMSA in den neuen KDS-Stammschlüssel.

  6. Stellen Sie sicher, dass alle gMSAs rolld ausgeführt wurden.

    Notiz

    Die gMSA ohne den PrincipalsAllowedToRetrieveManagedPassword Parameter wird niemals rollieren.

  7. Nachdem alle gMSAs für das neue KDS-Stammschlüsselobjekt rolliert wurden, löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  8. Starten Sie den Microsoft Key Distribution Service auf allen Domänencontrollern neu.

References

Übersicht über gruppenverwaltete Dienstkonten

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.