SPN Rechte
Siehe dazu auch Kerberos:mit SQL Server
Der Eintrag des Service Prinzipal Name erfolgt meist automatisch. So addiert Windows seinen "HOST"-Eintrag im SPN alleine und wenn Sie einen IIS installieren, dann habe ich zumindest noch nie von Hand einen SPN auf den Computernamen addieren müssen. Anders sieht es aus, wenn Sie einen Servicenamen zwischen mehreren Computern nutzen und daher ein Dienstkonto oder virtuelles Computerkonto anlegen. Hier müssen Sie als Administrator in der Regel neben den entsprechenden Einstellungen auf der Applikation auch den SPN im Active Directory pflegen.
Nicht alle Programme melden Fehler bei der Pflege "ihres SPN" wie z.B. für SQL auf Kerberos:mit SQL Server beschrieben. Hier landen solche Problem im Eventlog, wenngleich es "nur" eine "Information"-Meldung ist.
Probleme beim Eintragen eines Computerbezogenen SPNs sind meist durch einen fehlenden ACL-Eintrag auf dem Computer-Objekt begründet. Normalweise sollte folgender Eintrag vorhanden sein.
Dies sind die Standardeinstellungen, die ich bei meinen VMs gefunden habe. Per Default hat das Computerkonto selbst (Dargestellt durch den Security Identifier "SELF") unter anderem die Rechte, den DNS-Hostnamen und vor allem den ServicePrincipalName zu schreiben.
If you need to allow delegated administrators to configure
service principal names (SPNs), you must ensure that their User accounts have
the Validated write to service principle name permission.
Quelle: Setspn
https://technet.microsoft.com/en-us/library/cc731241(v=ws.11).aspx
Sollte dies nicht der Fall sein, können Sie dies hier per GUI (AD Users und Computer) oder per Kommandozeile ändern.
dsacls CN=servername,CN=computers,DC=msxfaq,DC=net /G SELF:RPWP;servicePrincipalName
Per PowerShell ist es mit Get-ACL und Set-ACL etwas aufwändiger aber durchaus möglich. Ich habe hier erst mal ein Skriptbeispiel um die Rechte auf allen Computer-Objekten zu prüfen und zu berichten.
Get-ADComputer -Filter { name -like "*"} ` | foreach { [string]$dn="AD:\"+$_.distinguishedname $selfacl = (get-acl $dn).access ` | where { ` ( ($_.IdentityReference -eq "NT AUTHORITY\SELF") ` -and ($_.IsInherited -eq $false) ` -and ($_.ObjectType -eq "f3a64788-5306-11d1-a9c5-0000f80367c1") ` ) ` } if (!$selfacl) { write-host "$dn SPN-ACL Missing" -foregroundcolor red } else { write-host "$dn SPN-ACL OK" -foregroundcolor green } }
Damit erhalten sie einen schnelle Überblick, welche Computer gerade nicht ihren SPN selbst aktualisieren können.
Weitere Links
- Kerberos:mit SQL Server
- Viewing the ACL for an Object
https://technet.microsoft.com/de-de/library/dd378932(v=ws.10).aspx - Use PowerShell to Explore Active
Directory Security
https://blogs.technet.microsoft.com/heyscriptingguy/2012/03/12/use-powershell-to-explore-active-directory-security/ - Active Directory OU Permissions Report:
Free PowerShell Script Download
https://blogs.technet.microsoft.com/ashleymcglone/2013/03/25/active-directory-ou-permissions-report-free-powershell-script-download/ - Active Directory Technical
Specifications (MS-ADTS)
3.1.1.2.3 Attributes http://msdn.microsoft.com/en-us/library/cc223202.aspx
3.1.1.2.3.3 Property Set http://msdn.microsoft.com/en-us/library/cc223204.aspx
5.1.3.2.1 Control Access Rights http://msdn.microsoft.com/en-us/library/cc223512.aspx
5.1.3.2.2 Validated Writes https://msdn.microsoft.com/en-us/library/cc223513.aspx
Validated-SPN hat die GUID "f3a64788-5306-11d1-a9c5-0000f80367c1" - Get-ACL
https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.security/get-acl