Die Dokumentation enthält das Beispiel:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Dieser Parameter ist erforderlich. Was genau ist der Zweck von a DNSHostNameund wie soll ich entscheiden, worauf es eingestellt werden soll?
Antworten:
Nachdem ich eine Weile mit diesen Konten gearbeitet hatte, fand ich den Grund heraus:
Sie sind eine Teilmenge oder möglicherweise eine Ableitung der Maschinentypkonten. Daher erben sie diese Eigenschaft von ihnen, und da sie für den Maschinentyp erforderlich ist, ist sie auch für gMSA erforderlich.
Sie können überprüfen, ob beide Typen in ihren Attributmengen genau übereinstimmen. Außerdem geben sie in der gesamten TechNet- Dokumentation einen einfachen eindeutigen Wert für dieses Attribut an gmsa-name.contoso.com, genau wie dies bei einem Computerkonto der Fall ist.
Ich bin mir nicht sicher, warum sie es nicht automatisch generiert haben und erspare uns das Fragen und das Tippen.
Der DNSHostName sollte der Name Ihres Dienstes sein. Im Falle eines Clusters wäre dies der Name Ihrer virtuellen Instanz.
Der DNSHostName bezieht sich auf die automatische SPN-Registrierung des Kontos. In Active Directory haben Computer und GMSAs die Berechtigung "Validiertes Schreiben in ServicePrincipalName zulassen". Dies bedeutet, dass ein Computer nur SPNs registrieren kann, die den Namen von sich selbst enthalten. Beispiel: Ein Computer mit dem Namen Webserver1 (DNS: Webserver1.mydomain.net) kann http: /Webserver1.mydomain.net: 443 automatisch registrieren, http: /Webserver55.mydomain.net: 443 jedoch nicht
Der DNSHostName eines GMSA sollte also angeben, welche SPNs Sie für einen Dienst registrieren möchten.
In einem SQL-Cluster hätten Sie zwei Hosts: Host1 und Host2. Ein Clustername: Clu1 und eine virtuelle SQL-Instanz: SQL1 Wenn Sie den SQL1-Dienst mithilfe eines GMSA ausführen möchten, erstellen Sie ihn folgendermaßen.
$comp1 = get-adcomputer Host1
$comp2 = get-adcomputer Host2
New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2
(Sie können auch eine Gruppe verwenden, anstatt den Hosts direkt Rechte zuzuweisen.)
Beim Start des SQL-Dienstes werden automatisch zwei SPNs registriert: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433
Wenn Sie etwas anderes in den DNSHostName eingeben (zum Beispiel gmsa01.mydomain.net), wird der Dienst weiterhin gestartet, es können jedoch keine SPNs registriert werden (und es wird auf die NTLM-Authentifizierung zurückgegriffen).
Wenn Ihnen die Kerberos-Authentifizierung (und die SPNs) egal sind oder Sie SPNs für Ihren Dienst manuell registrieren möchten, können Sie den DNSHost-Namen nach Belieben einfügen. Die GMSA wird weiterhin funktionieren.
Ich würde nicht empfehlen, Ihren DomainController wie oben erwähnt in den DNS-Namen einzufügen (es sei denn, Sie planen die Verwendung des GMSA, um einen Dienst auf einem Domain-Controller auszuführen).
Ich bin kein Experte. Es gibt jedoch so wenige Informationen zu diesem Thema, dass ich es für sinnvoll hielt, das zu posten, was ich weiß
Der Trainer eines 70-411- Kurses, an dem ich teilgenommen habe, verwendete den FQDN eines Domänencontrollers als Wert für den DNSHostNameParameter, als er das New-ADServiceAccountCmdlet demonstrierte . Soweit ich weiß, DNSHostNamewird dem Cmdlet nur mitgeteilt, auf welchem Domänencontroller das Konto erstellt werden soll. Ich denke nicht, dass es wichtig ist, welchen DC Sie verwenden, diese GMSAs scheinen sich sowieso sofort zu replizieren. Ich habe DNSHostNameauf einen meiner DCs gezeigt und es scheint so weit zu funktionieren.
Es wäre mir wirklich lieber, wenn es konkrete Unterlagen dazu gäbe. Die zutreffende TechNet-Befehlsreferenz ist nur tautologischer Unsinn für den DNSHostNameParameter.
Wenn Sie den Parameter -RestrictToSingleComputer hinzufügen, ist dies nicht mehr erforderlich. Natürlich sollten Sie diese Option lesen, bevor Sie sie verwenden.
Mögen:
New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer
Ich habe sehr lange nach einer Antwort gesucht und endlich eine gefunden, die sich für mich richtig anhört.
-DNSHostName sollte der vollqualifizierte Domänenname des Domänencontrollers sein, der den KDS-Hauptschlüssel enthält - msKds-ProvRootKey.
Höchstwahrscheinlich haben Sie diese bereits erstellt - sehen Sie sich den Container für den Gruppenschlüsselverteilungsdienst in der Konfigurationspartition Ihrer AD-Gesamtstruktur an.
Und wahrscheinlich könnten Sie jeden DC in dieser Gesamtstruktur verwenden, solange Sie deren Namen in -PrincipalsAllowedToRetrieveManagedPassword festlegen
Alles oben Genannte stellt den "neuen" gMSA dar. Wenn Sie also stattdessen den alten MSA verwenden möchten, vergessen Sie einfach diesen -DNSHostName, da er dann nicht erforderlich ist, und verwenden Sie einfach -RestrictToSingleComputer, um ein Konto auf einem Server zu sperren.
Ich hoffe, das hilft.
Zitiert die Antwort von Proed am 17. Januar 2018 im Warum benötigt ein gMSA einen DNS-Hostnamen? (Danke an @Daniel für das frühere Zitieren).
Ich würde empfehlen, das
dNSHostNameso einzustellen, wie es für das AD-Computer-Objekt eingestellt ist (sAMAccountName+ und Ihr Domain-Suffix)
… weil:
msDS-GroupManagedServiceAccounterbt von AD-Computer(im Sinne des AD-Schemas) und muss daher angegeben werdenSchauen Sie sich diesen Link an: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
Der DNSHostName ist der vollständig qualifizierte Domänenname Ihres Dienstkontonamens.
New-ADServiceAccount-name -DNSHostName