19
Scheduled Tasks mit MSA ausführen
Hallo zusammen,
ich hoffe, ihr habt ein ruhiges Wochenende.
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:
Das funktioniert soweit auch. Wenn der Task dann allerdings starten möchte, bekomme ich folgenden Fehler (ID 101):
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
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
ich hoffe, ihr habt ein ruhiges Wochenende.
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1277269494
Url: https://administrator.de/contentid/1277269494
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
19 Kommentare
Neuester Kommentar
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!
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!
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.
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.
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.
Hat der Benutzer auch Admin Rechte auf der Kiste, für manche Aufgaben braucht man das.
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
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
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
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
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.
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.
@Penny.Cilin
Gruß,
Dani
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
Hey @Dani,
danke für deine Rückmeldung.
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.
Na klar 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.
Viele Grüße
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?
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.
Na klar
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.
Viele Grüße
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.
Viele Grüße
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.
Viele Grüße
Moin,
Gruß,
Dani
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
Zitat von @Dani:
Moin,
Er meint bestimmt das normale Benutzerkonto.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?@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
@Penny.Cilin
Gruß,
Dani
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
Hallo zusammen.
Mit einem Standard-Account meine ich ein normales Benutzerkonto.
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.
Viele Grüße
Festus94
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.
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.
Viele Grüße
Festus94
Moin,
Gruß,
Dani
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. 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
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. ¯\_(ツ)_/¯
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. ¯\_(ツ)_/¯
Moin,
Gruß,
Dani
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
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.
Viele Grüße
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.
Viele Grüße
Moin,
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
Ich will aber nicht garantieren, dass da dem Standard entspricht, da hier sehr viel verstellt wurde.
entspricht dem Standard. 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
Hi Dani,
nein, das von mir verwendete "normale" Konto war brandneu und hat sich noch nie interaktiv angemeldet.
nein, das von mir verwendete "normale" Konto war brandneu und hat sich noch nie interaktiv angemeldet.
