• Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQActive Directory FAQ
  • Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN

Group Managed Service Accounts

Okt 16, 2015 (Letztes Update) | Posted by Peter Schäfer KnowHow, Konfiguration |

 

Group Managed Service Accounts

Bereits im Artikel über ADFS 3.0 berichtet, werden unter Windows Server 2012 auch Group Managed Service Accounts (GMSA) unterstützt. Das Kennwort dieser Konten wird automatisch vom AD generiert. In diesem Artikel beschreibe ich, welche Szenarien damit gelöst werden, welche Anwendungen möglich sind und wie GSMA implementiert wird.

 

 

Inhaltsverzeichnis

  • 1 Anlegen eines „normalen“ Service Accounts
    • 1.1 Problemfall 1: Wir können das Konto nicht selbst anlegen
    • 1.2 Problemfall 2: Server ersetzen und Kennwort ist nicht mehr bekannt
  • 2 Managed Service Accounts in Windows Server 2008R2 / 2012
    • 2.1 Windows Server 2008 – Managed Service Accounts
    • 2.2 Windows Server 2012 – Group Managed Service Accounts
    • 2.3 Voraussetzungen
  • 3 Anwendung von Group Managed Service Accounts

 
Viele Anwendungen auf Windows-Plattformen basieren auf Diensten. Ein großer Teil dieser Dienste benötigt spezielle Berechtigungen auf Ressourcen. Diese Berechtigungen bekommen sie über die zugeordneten Service-Konten. Will man zum Beispiel schreibend auf das Active Directory zugreifen, muss dafür ein Konto im AD angelegt und berechtigt werden.
 

Anlegen eines „normalen“ Service Accounts

Wir legen nun ein Service-Konto an. Dieses bekommt sehr weitreichende Berechtigung im AD und auf allen Maschinen, auf denen der Dienst läuft.
Darüber hinaus bekommt es noch ein sicheres aber natürlich nicht ablaufendes Kennwort.
 

Problemfall 1: Wir können das Konto nicht selbst anlegen

Wenn wir den Service-User nicht selbst anlegen durften, benötigen wir nun noch das Kennwort. Dieses sollte möglichst sicher übermittelt werden. (Zum Beispiel auf einem Notizzettel, der dann im Papierkorb landet oder in einer verschlüsselten Mail)

Das alles ist schon mal ein Alptraum für jeden Sicherheitsbeauftragten.

Denn Sicherheitsbeauftrage predigen in der Regel, dass Kennworte regelmäßig geändert werden müssen und nicht per Mail verschickt werden dürfen.
 

Problemfall 2: Server ersetzen und Kennwort ist nicht mehr bekannt

Ebenso schlimm ist es, wenn ein Server ersetzt werden muss und beim Installieren des Dienstes das Kennwort nicht mehr bekannt ist. Ändert man das Kennwort, muss es aber auch auf allen anderen Servern, auf dem der Dienst läuft, geändert werden.
(Wobei man sich schon glücklich schätzen kann, wenn man überhaupt noch weiß, wo das Konto überall verwendet wird.)

 

Managed Service Accounts in Windows Server 2008R2 / 2012

Windows Server 2008 – Managed Service Accounts

Aus diesem Grund hat Microsoft mit Server 2008R2 die Managed-Service-Accounts eingeführt.
Diese haben sich aber bisher kaum durchgesetzt, da sie nur auf eine Maschine begrenzt waren (Cluster-Services waren damit nicht möglich). Außerdem wurden sie nur von wenigen Anwendungen unterstützt.
 

Windows Server 2012 – Group Managed Service Accounts

Mit Server 2012 wurden daher die „Group Managed Service Accounts“ (GMSA) eingeführt.
Sie sind an Gruppen von Computern gebunden und funktionieren daher auch auf mehreren Servern für denselben Dienst. Ein Cluster-Betrieb ist also auch möglich.

Grundsätzlich zeichnen sich die „Group Managed Service Accounts“ dadurch aus, dass ihr Kennwort automatisch vom System generiert und regelmäßig geändert wird. Auch muss keiner das Kennwort irgendwo manuell eingegeben werden.
 

Voraussetzungen

Mindestens ein Domain-Controller mit Server 2012 oder höher.
Alle Server, auf denen GMSAs genutzt werden sollen, müssen Server 2012 (Windows 8 für Workstations) oder höher sein.

 

Anwendung von Group Managed Service Accounts

Alle Aktionen bezüglich GMS-Accounts werden über Powershell Befehle durchgeführt!
Vor dem ersten Einsatz muss einmalig ein “Root-Key“ erstellt werden.

Add-KDSRootKey –EffectiveImmediately

“EffectiveImmediately” sagt aus, dass der neue Key sofort wirksam wird.

Danach wird der eigentliche GSMA erstellt:

New-ADServiceAccount -name <ServiceAccountName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword <group> -ServicePrincipalNames <SPN1,SPN2,…>

  • Name: Eindeutiger Name des Accounts
  • DNSHostName: FQDN unter dem der Service erreichbar ist
  • PrincipalsAllowedToRetrieveManagedPassword: Computer oder Gruppe von Computern den der Service-Account genutzt werden kann.
  • ServicePrincipalNames: “Service Principal Names” des Dienstes.

Beispiel:

New-ADServiceAccount FsGmsa -DNSHostName adfs1.contoso.com -ServicePrincipalNames http/adfs1.contoso.com
 

Auf jedem Server, auf dem der GSMA genutzt werden soll muss er auch installiert werden:

Install-AdServiceAccount <gMSA>

Überprüfen des GSMA

Test-AdServiceAccount <gMSA>

Das Konto kann wie jedes andere Konto bei einem Dienst eingetragen werden. Zu beachten ist, dass das Kennwort leer bleibt und dem Kontonamen ein $ angehängt wird!

GSMA-mit-$


Für Fragen zu unseren Leistungen stehen wir Ihnen unter Kontakt gern zur Verfügung.

 


Weitere Quellen zum Artikel: Technet

 

Artikel weiterempfehlen:
  • teilen
  • tweeten
  • sharen
  • xingen
  • mailen
Artikel erstellt am: 19.01.2015
Tags: GMSAGroup Managed Service AccountService Accounts
0

1 Comment

Leave your reply.
  • chris
    · Antworten

    2. Februar 2017 at 1:37 AM

    Mir leuchtet nicht ein wozu ich den fqdn benötige.
    Ich gebe einen ein, den ich jedoch nicht im Dns anlege. So weit ich das sehe funktioniert dennoch alles einwandfrei.

    Was man dazu bingt, widerspricht sich. Manche meinen man müsse den fqdn des DCs angeben auf welchem der Kds Root Key erstellt wurde. Andere meinen es soll der Fqdn des services sein für den der Gmsa genutzt wird.
    Gibt es dazu was offizielles von ms?

Leave a Reply

<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>
Cancel Reply

FirstWare IDM-Portal im Test: IT-Administrator 08-2022

 

ADFAQ-FirstAttribute

Wer schreibt ?

Team der FirstAttribute AG

Consultants und Entwickler der FirstAttribute arbeiten seit mehr als 20 Jahren in IAM- und Cloud-Transition-Projekten.
Zusammen verfügen Sie über einen wertvollen Erfahrungsschatz im Bereich Active Directory und Azure AD und teilen diesen auf Active Directory FAQ.

Neueste Artikel

  • 8 Tipps für mehr Sicherheit in Active Directory und Backups von AD
  • Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen
  • Dateiberechtigungen in MS Teams und SharePoint Online verwalten – So funktioniert es
  • AD-Gruppen in Microsoft Teams verwenden – Dynamische Gruppen in der Praxis
  • Verbindung zwischen Microsoft 365 und SharePoint Online zu Azure AD

Unsere IAM-Lösungen

Ihre IAM-Lösung: FirstWare IDM-Portal

 

my-IAM für Cloud Identity Management in Microsoft Teams

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Jetzt AD Tasks vereinfachen und delegieren: FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • https://www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Azure AD Berechtigung Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange-Ordner Exchange-Postfach Exchange Migration Federation FirstWare Get-Mailbox Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP m365 Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • activedirectoryfaq.com sharepoint login - infoslist bei Windows 365 und Azure AD verstehen in Theorie und Praxis
  • Domäne Letzte Anmeldung - ObenGesichert.com bei LastLogon vs. LastLogonTimestamp
  • Teams Code Zur Anmeldung - ObenGesichert.com bei Authentifizierung für MS Teams in hybriden Netzwerken
Login
Impressum
Datenschutzerklärung

© 2023 · Active-Directory-FAQ by firstattribute.com

Prev Next