AD Managed Service Accounts - logon failure (error 1069)

[Korakal]

Hoi,

Voor ons bedrijf ben ik afgelopen week begonnen met het inrichten van Managed Service Accounts in Active Directory. Wij hebben een relatief kleine omgeving, met een aantal servers (meestal Windows Server 2019, somige 2016) en één domain controller. Voor een aantal applicaties moeten rechten worden toegekend en is het niet voldoende om deze als Local System te draaien. Tot nu toe gebruikten we daarvoor users die een labeltje 'service user' hadden, maar verder niet afweken van reguliere users.

We hebben niet eerder MSA gebruikt en ik heb nog géén werkende situatie voor elkaar kunnen krijgen. In de keuze MSA/gMSA hebben we voor de eerste accounts voor MSA gekozen, omdat het services betreffen die beperkt zullen zijn tot één server.

Ik heb de volgende stappen uitgevoerd met Powershell (uiteraard na het definiëren van de betreffende variabelen en maken van de KdsRootKey):

Tegen de DC:

code:

New-ADServiceAccount -Name $MSAAccountName -Enabled $true -Description "Managed Service Account for $Server - $functionshort ($function, $description)" -DisplayName "MSA $Server - $functionshort" -RestrictToSingleComputer

Tegen de server waarop het MSA account moet gaan draaien:

code:

Install-windowsfeature RSAT-AD-Powershell
Install-ADServiceAccount -Identity $MSAAccountName

Het resultaat lijkt goed:

code:

Test-ADServiceAccount -Identity $MSAAccountName

geeft True

en

code:

Get-ADServiceAccount MSA.SVW36-Strt$

RunspaceId        : 87c83d89-0d64-4b14-93f1-XXXXX
DistinguishedName : CN=MSA.SVW36-Strt,CN=Managed Service Accounts,DC=XXXXX,DC=local
Enabled           : True
Name              : MSA.SVW36-Strt
ObjectClass       : msDS-ManagedServiceAccount
ObjectGUID        : 18056437-6ea8-491a-923e-XXXXX
SamAccountName    : MSA.SVW36-Strt$
SID               : S-1-5-21-2065692108-2897296754-XXXXX
UserPrincipalName :

Wanneer ik op de betreffende server de service logon properties instel, krijg ik ook netjes te zien:

code:

The account XXXXX\MSA.SVW36-Strt$ has been granted the Log On As A Service right.

Zodra ik echter de service start zie ik:

code:

Could not start the <service name> service on Local Computer.
Error 1069: The service did not start due to a logon failure.

Een tweetal suggesties die ik al online had gevonden:
- Ik kan via de group policy editor zien dat het MSA account is opgenomen bij Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > User Rights Assignment > Log on as a service. De accounts zijn (als extra check) niet vermeld bij Deny log on as a service (die is helemaal leeg).
- Het MSA account is enabled (zie codeblock met Get-ADServiceAccount)

Ik mis vermoedelijk nog een stap, maar ik kan niet vinden wat ik nog méér zou moeten doen. Het helpt mij overigens niet dat heel veel info die ik vind over de gMSA accounts gaat...

Iemand het briljante idee voor mij?

[ProjectB00man]

Wat ik zo kan vinden bij Microsoft is het volgende.
als ik dat vergelijk met wat je al gedaan hebt dan mis je deze stap

Associate the new MSA with a target computer in Active Directory:

Add-ADComputerServiceAccount -Identity <the target computer that needs an MSA> -ServiceAccount <the new MSA you created in step 3>

https://techcommunity.mic...ementing-best/ba-p/397009

hopelijk is dat de oplossing

[Korakal]

Thanks voor de tip; het lijkt echter dat het hiermee alleen maar een stap terug gaat:

code:

Server name: SVW36TOPOLOGY
MSA account name: MSA.SVW36-Strt
----
Cannot install service account. Error Message: 'Hiermee wordt aangegeven dat een bepaalde beveiligings-id waarschijnlijk niet is benoemd als de eigenaar van een object.'.
    + CategoryInfo          : WriteError: (MSA.SVW36-Strt:String) [Install-ADServiceAccount], ADException
    + FullyQualifiedErrorId : InstallADServiceAccount:PerformOperation:InstallServiceAcccountFailure,Microsoft.ActiveDirectory.Management.Commands.InstallADServiceAccount
    + PSComputerName        : <domaincontroller>

Test-ADServiceAccount -Identity $MSAAccountName
geeft nu False

[Korakal]

Hmmmm ik heb inmiddels wel iets anders interessants ontdekt:
https://petri.com/managed-service-accounts-2

code:

Get-ADServiceAccount -Identity MSA.SVW36-Strt$ | Select HostComputers

HostComputers
-------------

Is leeg...

Dan lijkt het erop dat je dus met Add-ADComputerServiceAccount daar resultaat zou moeten krijgen:

code:

Add-ADComputerServiceAccount -Identity SVW36TOPOLOGY -ServiceAccount MSA.SVW36-Strt$ -PassThru


RunspaceId        : 87c83d89-0d64-4b14-93f1-xxxxx
DistinguishedName : CN=SVW36TOPOLOGY,OU=OnzeLocatie,OU=Servers,OU=XXXXXDomainComputers,DC=XXXXX,DC=local
DNSHostName       : SVW36TOPOLOGY.XXXXXX.local
Enabled           : True
Name              : SVW36TOPOLOGY
ObjectClass       : computer
ObjectGUID        : 1da7c239-f611-4166-bf65-933450xxxx
SamAccountName    : SVW36TOPOLOGY$
SID               : S-1-5-21-2065692108-2897296754-294639xxxx
UserPrincipalName :

Ook daarna blijft de bovenste query (Select HostComputers) leeg - dus het lijkt alsof ik de toewijziging niet kan/mag doen...

[Question Mark]

Korakal schreef op maandag 19 oktober 2020 @ 11:18:
Thanks voor de tip; het lijkt echter dat het hiermee alleen maar een stap terug gaat:

Powershell wel via "Run as administrator" gestart?

Wat zie je op het managed serviceaccount object in ADUC? (wel even advanced features enablen). Wie is owner van het object?

[ Voor 20% gewijzigd door Question Mark op 19-10-2020 14:12 ]

[Korakal]

Yep, anders kreeg je die gelijk wel om je oren

OK, ik ben een stap verder - door een iets andere aanpak kan ik nu de boel met een omweg aan de praat krijgen. Het blijkt dat er in de remote-sessie op de target server op de een of andere manier niet hetzelfde gebeurt als wanneer je dat echt lokaal doet (of ik doe met remoting iets niet goed, dat kan natuurlijk ook ).

De stappen zijn nu als volgt:

code:

New-ADServiceAccount -Name $MSAAccountName -Enabled $true -Description "Managed Service Account for $Server - $functionshort ($function, $description)" -DisplayName "MSA $Server - $functionshort" -RestrictToSingleComputer

En in een scriptblock met invoke-command:

code:

if((Get-WindowsFeature RSAT-AD-Powershell).Installstate -eq "Installed") {
                                    # RSAT-AD-Powershell is Installed
                                } else {
                                    Install-windowsfeature RSAT-AD-Powershell
                                }

Install-ADServiceAccount -Identity $MSAAccountName 

Test-ADServiceAccount -Identity $MSAAccountName

Wanneer ik dat laatste deel uitvoer door te RDP'en naar de target server en daar in een PS sessie uitvoer, dan werkt het wél en kan ik de service met het MSA account starten.

edit:

Meer mensen met hetzelfde issue blijkbaar, ik zie bijv https://www.reddit.com/r/...t_unable_to_use_remoting/

De Add-ADComputerServiceAccount blijkt in ieder geval niet nodig om het werkend te krijgen!

[ Voor 5% gewijzigd door Korakal op 19-10-2020 15:04 ]

[Question Mark]

Korakal schreef op maandag 19 oktober 2020 @ 14:35:
Het blijkt dat er in de remote-sessie op de target server op de een of andere manier niet hetzelfde gebeurt als wanneer je dat echt lokaal doet (of ik doe met remoting iets niet goed, dat kan natuurlijk ook ).

Dubbel-hoppen in Powershell geeft uitdagingen met het doorgeven van "Admin" zijn.

Making the second hop in PowerShell Remoting

[Korakal]

Ha thanks, that helps!