festus94
Goto Top

Scheduled Tasks mit MSA ausführen

Hallo zusammen,

ich hoffe, ihr habt ein ruhiges Wochenende. face-smile Ich sitze seit ein paar Tagen vor einem Problem, bei dem ich vermutlich einfach den Wald vor lauter Bäumen nicht sehe.

Ich möchte auf einem Windows Server 2016 einen Scheduled Task im Kontext eines Managed Service Accounts ausführen. Der Task wurde angelegt, und der MSA wurde mit folgenden Kommando eingetragen:

schtasks /change /TN \Test-Task /RU DOMAIN\MSA$ /RP ""  

Das funktioniert soweit auch. Wenn der Task dann allerdings starten möchte, bekomme ich folgenden Fehler (ID 101):

Task Scheduler failed to start "\Test-Task" task for user "DOMAIN\MSA$". Additional Data: Error Value: 2147943785.

Wenn man nun nach dem Fehler 2147943785 sucht, findet man eine Flut an Beiträgen, die darauf hinweisen, dass der Account "Logon as a batch job"-Rechte auf der Maschine benötigt, Diese sind bei mir jedoch vorhanden, und ein kurzer Blick in den Richtlinienergebnissatz zeigt in den User Rights Assignments auch das richtige Ergebnis an.

Wenn ich den MSA durch einen normalen Account mit identischen Rechten ersetze, läuft der Task anstandslos an. Dann habe ich zur Sicherheit noch mal überprüft, ob der MSA korrekt auf dem Server installiert ist. Das Kommando

Test-ADServiceAccount -Identity "MSA$"  

gibt auch direkt ein "True" zurück. Habt ihr eine Idee, was ich übersehen haben könnte? Der Server, auf dem der Task laufen soll/muss, ist ein Domänen-Controller. Gibt es da ggf. Besonderheiten zu berücksichtigen? Meine Kollegen sind sich jedenfalls sicher, genau mit meiner Vorgehensweise schon Tasks mit der Ausführung als MSA angelegt zu haben.

Vielen Dank für eure Hilfe.

Viele Grüße

Festus94

Content-Key: 1277269494

Url: https://administrator.de/contentid/1277269494

Ausgedruckt am: 19.03.2024 um 06:03 Uhr

Mitglied: 143611
143611 18.09.2021 um 17:26:46 Uhr
Goto Top
Moin,

keine Ahnung, wo die Ursache konkret liegt; habt Ihr überprüft, ob der Computeraccount des Rechners, welcher den Task ausführen soll, in der dem gMSA zugeordneten Berechtigungsgruppe ist?

Viel Erfolg!
Mitglied: Festus94
Festus94 18.09.2021 aktualisiert um 18:47:42 Uhr
Goto Top
Hi @143611,

muss ich tatsächlich noch mal prüfen, aber hätte ich den Account dann überhaupt installieren können? Habe ich noch nie ausprobiert.

Ich reiche die Info nach.

Viele Grüße

Edit: Im Attribut "PrincipalsAllowedToRetrieveManagedPassword" des MSAs steht der korrekte Server drin. Auch verstehe ich die Beschreibung von Test-ADServiceAccount so, dass ein Fehler an dieser Stelle zu einem Fehler führen würde.

Trotzdem danke für den Ansatz.
Mitglied: canlot
canlot 18.09.2021 um 21:22:00 Uhr
Goto Top
Hi, überprüfe ob diese 3 Dienste laufen: Keyiso, Netlogon, w32Time.

Hat der Benutzer auch Admin Rechte auf der Kiste, für manche Aufgaben braucht man das.
Mitglied: Festus94
Festus94 18.09.2021 um 21:57:39 Uhr
Goto Top
Hi @canlot,

ja, die laufen. Sonst hätte ich mit dem DC ein ganz anderes Problem.

Admin auf einem DC heißt Domänen-Admin. Das kommt nicht infrage und ist auch nicht Sinn der Sache. Ist aber auch nicht nötig, denn genau dafür ist das Recht "Logon as a Batch Job" ja da.

Viele Grüße
Mitglied: Dani
Lösung Dani 19.09.2021 aktualisiert um 13:01:41 Uhr
Goto Top
Moin,
wenn ich es richtig verstanden habe, hast du auf einem Domain Controller eine Scheduled Task eingerichtet. Dieser soll im Kontext eines (g)MSA eine Aufgabe ausführen, korrekt? Wenn dem so ist, bitte den (g)MSA noch das Recht "logon as a service" zuteilen. Das geschieht in der Regel über die "Default Domain Controllers" Policy im Group Policy Editor.

By the way: Kannst du uns noch sagen, was die Scheduled Task ausführt/tun soll?


Gruß,
Dani
Mitglied: Penny.Cilin
Penny.Cilin 19.09.2021 um 11:33:51 Uhr
Goto Top
Hallo und guten Morgen,

warum hast Du den Managed Service Account als MSA$ angelegt?
Lege zum testen mal den Managed Service Account als MSA1 an. Und NICHT mit $-Zeichen am Ende.

In den folgenden Beispielen unter Examples1 and Examples2 sieht man die Analge der Managed Service Accounts.

Gruss Penny.
Mitglied: Dani
Dani 19.09.2021 um 12:04:34 Uhr
Goto Top
@Penny.Cilin
warum hast Du den Managed Service Account als MSA$ angelegt?
Das $ ist in diesen Fall gewollt/normal. Und zwar fügt Microsoft das Zeichen beim Attribut SamAccountName am Ende hinzu. Kann man ganz einfach mit Get-ADServiceAccount prüfen.


Gruß,
Dani
Mitglied: Festus94
Festus94 19.09.2021 aktualisiert um 13:38:12 Uhr
Goto Top
Hey @Dani,

danke für deine Rückmeldung.

Zitat von @Dani:

Moin,
wenn ich es richtig verstanden habe, hast du auf einem Domain Controller eine Scheduled Task eingerichtet. Dieser soll nicht im Kontext eines (g)MSA eine Aufgabe ausführen, korrekt?

Doch, dieser soll als MSA ausgeführt werden. Ich teste es mal zusätzlich mit Logon as a service, aber das habe ich noch in keinem Beispiel gefunden. Rückmeldung folgt.

Zitat von @Dani:

By the way: Kannst du uns noch sagen, was die Scheduled Task ausführt/tun soll?

Na klar face-smile Es geht um den Task, den das Windows Backup bei der Einrichtung eines Backupplans anlegt. Ich habe testhalber aber auch einen eigenen Task angelegt (alternativ auch per PowerShell statt per GUI) und den MSA draufgesetzt. Der Fehler ist immer derselbe. Mit dem MSA kommt der o. g. Fehler, mit einem normalen Account funktioniert es ohne Probleme. Es liegt also auch nicht an dem konkreten Task.

@Penny.Cilin: Danke dir für deine Antwort. Dani hat es ja schon erklärt. face-smile

Viele Grüße
Mitglied: Festus94
Festus94 20.09.2021 um 08:42:51 Uhr
Goto Top
Guten Morgen zusammen,

die Vergabe der Berechtigung Logon as a service scheint das Problem behoben zu haben. Das wundert mich etwas, denn der Standard-Account, mit dem der Task funktioniert hat, hatte dieses Recht ja auch nicht.

Ich beobachte das noch einen oder zwei Tage und mache den Thread dann zu. Danke noch mal. face-smile

Viele Grüße
Mitglied: Dani
Dani 20.09.2021 um 10:56:24 Uhr
Goto Top
Moin,
Das wundert mich etwas, denn der Standard-Account, mit dem der Task funktioniert hat, hatte dieses Recht ja auch nicht.
was verstehst du unter einem Standard Account?


Gruß,
Dani
Mitglied: Penny.Cilin
Penny.Cilin 20.09.2021 um 12:54:43 Uhr
Goto Top
Zitat von @Dani:

Moin,
Das wundert mich etwas, denn der Standard-Account, mit dem der Task funktioniert hat, hatte dieses Recht ja auch nicht.
was verstehst du unter einem Standard Account?
Er meint bestimmt das normale Benutzerkonto.
@Festus94
die Optionen "Logon as A Batch Job" und "Logon as a Service" haben normale Benutzer nie. Bei beiden Optionen muss immer das Benutzerkonto angegeben werden, welche dies dürfen.


Gruß,
Dani
Gruss penny.
Mitglied: Dani
Dani 20.09.2021 um 12:59:32 Uhr
Goto Top
@Penny.Cilin
Er meint bestimmt das normale Benutzerkonto.
Das dachte ich zuerst auch. Aber es handelt sich um ein Domain Controller. Somit gelten doch andere Voraussetzungen wie bei einem Client. Daher meine Nachfrage.


Gruß,
Dani
Mitglied: Festus94
Festus94 21.09.2021 um 08:10:33 Uhr
Goto Top
Hallo zusammen.

Zitat von @Dani:

was verstehst du unter einem Standard Account?

Mit einem Standard-Account meine ich ein normales Benutzerkonto.

Zitat von @Penny.Cilin:

die Optionen "Logon as A Batch Job" und "Logon as a Service" haben normale Benutzer nie. Bei beiden Optionen muss immer das Benutzerkonto angegeben werden, welche dies dürfen.

Richtig, aber ich habe auch bei dem normalen Account nur Logon as a batch job vergeben. Da hat es gereicht.

Es sieht aber tatsächlich so aus, als würde es nun mit dem MSA laufen, nachdem ich zusätzlich zu Logon as a batch job auch Logon as a service als Berechtigung vergeben habe. Einerseits wundert es mich start, und mich würde der Hintergrund interessieren, andererseits bin ich einfach froh, dass es funktioniert.

Danke für eure Hilfe. face-smile

Viele Grüße

Festus94
Mitglied: Dani
Dani 21.09.2021 um 14:28:26 Uhr
Goto Top
Moin,
Ich teste es mal zusätzlich mit Logon as a service, aber das habe ich noch in keinem Beispiel gefunden
Du hast auch kein Zugriff auf unsere KB. face-wink

Richtig, aber ich habe auch bei dem normalen Account nur Logon as a batch job vergeben. Da hat es gereicht.
wie hast du den normalen Benutzer berechtigt? Denn standardmäßig kann er sich an einem Domoin Controller nicht interaktiv anmelden. Was steht denn zu dem Zeitpunkt in der Richtilinie "Logon as a batch job" drin?


Gruß,
Dani
Mitglied: Festus94
Festus94 21.09.2021 um 19:24:06 Uhr
Goto Top
Hi @Dani,

den normalen Benutzer habe ich exakt so berechtigt wie den MSA. Er war Mitglied in der Gruppe Backup Operators und hatte das recht Logon as a batch job. Mehr nicht, hat geklappt. ¯\_(ツ)_/¯
Mitglied: Dani
Dani 21.09.2021 um 19:27:52 Uhr
Goto Top
Moin,
Er war Mitglied in der Gruppe Backup Operators und hatte das recht Logon as a batch job.
Kann es sein, dass Backup Operators das Recht schon haben? Ich kann leider gerade nicht nachschauen, da ich kein VPN Zugriff habe. Hast du den (g)MSA ebenfalls über die Gruppe oder manuell einzeln berechtigt?


Gruß,
Dani
Mitglied: Festus94
Festus94 22.09.2021 um 12:53:52 Uhr
Goto Top
Hi @Dani,

der MSA war ebenfalls von vornherein Mitglied der Gruppe Backup Operators. Hier dürfte es keinen Unterschied gegeben haben. Bei uns haben die Backup Operators das Recht Logon as a batch job, aber nicht Logon as a service. Ich will aber nicht garantieren, dass da dem Standard entspricht, da hier sehr viel verstellt wurde. face-sad

Viele Grüße
Mitglied: Dani
Dani 24.09.2021 um 12:23:02 Uhr
Goto Top
Moin,
Ich will aber nicht garantieren, dass da dem Standard entspricht, da hier sehr viel verstellt wurde.
entspricht dem Standard. face-smile

Ich hab mit dem technischen Kollegen gesprochen. Der Unterschied zu einem Benutzerkonto liegt darin, dass (g)MSA nicht einem klassischen Benutzerkonto/Vorgang entspricht. Der (g)MSA agiert bei Scheduled Taks als Service Account und benötigt die entsprechenden Rechte auf einem Domain Controller. Das von dir verwendete Benutzerkonto war vermutlich schon interaktiv am Server im Einsatz und damit auch "initialisiert".


Gruß,
Dani
Mitglied: Festus94
Festus94 24.09.2021 um 12:25:28 Uhr
Goto Top
Hi Dani,

nein, das von mir verwendete "normale" Konto war brandneu und hat sich noch nie interaktiv angemeldet. face-smile