Welche Berechtigungen zum installieren eines Managed Service Account delegieren?

[testperson 1.707]

Hi,

 

gibt es irgendwo eine Übersicht für die möglichst minimalen Rechte, die der User auf den MSA delegiert haben muss, um diesen installieren zu können? Laut (Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting | Microsoft Learn)

Zitat

Note:  Besides being a local administrator on the computer, the account installing the MSA needs to have permissions to modify the MSA in AD. If a domain admin this "just works"; otherwise, you would need to delegate modify permissions to the service account's AD object. 

 

soll es "Modify" sein. Mit den Rechten "Read" / "Write" funktioniert es jedenfalls nicht. Sobald ich "Full Access" delegiere gehts. ;) Hat jemand zufällig einen Link oder eine Übersicht zu den minimalen Rechten?

 

Vielen Dank und Gruß

Jan

 

[NorbertFe 2.061]

Install-ADServiceAccount geht das unter 2019/2022 überhaupt noch? ich bekam da eigentlich immer Fehler. Unter 2016 war das noch notwendig.

[testperson 1.707]

Ich habe es zumindest gerade auf einem Windows Server 2019 ausgeführt (mit Vollzugriff für den ausführenden User auf das sMSA Objekt).

[NorbertFe 2.061]

müßte ich echt mal nachschauen. ich hab das neulich für den AADC konfiguriert und ein install-MSA gabs da gar nicht mehr als befehl oder es gab irgendeinen Fehler (ich schau nachher mal)

[NorbertFe 2.061]

vor 4 Stunden schrieb testperson:

soll es "Modify" sein. Mit den Rechten "Read" / "Write" funktioniert es jedenfalls nicht. Sobald ich "Full Access" delegiere gehts. ;) Hat jemand zufällig einen Link oder eine Übersicht zu den minimalen Rechten?

Im Worst Case mal das auditing anschalten und schauen, woran es scheitert ;)

[testperson 1.707]

vor 18 Minuten schrieb NorbertFe:

Im Worst Case mal das auditing anschalten und schauen, woran es scheitert ;)

Da muss jetzt aber erstmal noch ne Menge - zumindest vermutlich für 30 Tage - Wasser den Rhein runter fließen bis der Worst Case mich "motiviert". Es gibt im Moment genug andere Schauplätze..

 

Fürs Erste habe ich Vollzugriff erteilt, Install-ADServiceAccount und Vollzugriff entfernt. ;)

bearbeitet 27. Februar von testperson

[daabm 1.366]

Wenns wichtig ist frag ich rum - wir haben das wohl im DefaultSD von gMSA angepaßt, weiß nur nicht was genau weil ich nicht dran beteiligt war...

[testperson 1.707]

Im Moment gibt es da für mich wichtigere "Baustellen". Ich würde dich aber glatt im Hinterkopf behalten. ;)

[v-rtc 88]

vor 13 Stunden schrieb daabm:

Wenns wichtig ist frag ich rum - wir haben das wohl im DefaultSD von gMSA angepaßt, weiß nur nicht was genau weil ich nicht dran beteiligt war...

Frag gerne mal nach, würde andere auch interessieren ;)

[daabm 1.366]

Hab rumgefragt - niemand erinnert sich daran. Kann auch sein, daß sich das zwischen MSA und gMSA unterscheidet, wir nutzen nur noch gMSA. Und das funktioniert auch ohne Schreibrechte auf dem AD-Account. Im Zweifel würde ich die SACL aktivieren und nachschauen, was da geblockt wird.

[testperson 1.707]

Am 27.2.2024 um 14:55 schrieb NorbertFe:

Im Worst Case mal das auditing anschalten und schauen, woran es scheitert ;)

Hätte ich mich doch nur dafür entschieden, anstatt heute den Tag damit zu verbringen Dinge über TGGAU (Token-Groups-Global-and-Universal) und die "Windows Authorization Access Group" zu lernen... Bzw. welche Auswirkungen es auf die Live Migration hat, wenn man die "Authenticated Users" aus der "Pre-Windows 2000 Compatible Access" Gruppe entfernt.

[MurdocX 953]

Am 1.3.2024 um 16:33 schrieb testperson:

Bzw. welche Auswirkungen es auf die Live Migration hat, wenn man die "Authenticated Users" aus der "Pre-Windows 2000 Compatible Access" Gruppe entfernt.

Jetzt bin ich neugierig geworden. Ist zwar etwas am Thema vorbei, aber du als TO hasts ja in die Runde geschmissen   

[testperson 1.707]

Die Shared Nothing Livemigration von einem Managementserver / -client funktioniert nicht mehr:

Move-VM : Virtual machine migration operation failed at migration source.
Failed to establish a connection with host ... : No credentials are available in the security package (0x8009030E)
...

(Komplette Fehlermeldung findet sich hier: Why Hyper-V Live Migrations Fail with 0x8009030E - Microsoft Community Hub)

 

In der Umgebung gibt es mehrere Hyper-V Hosts, die nicht im Cluster sind. Wie das mit der "normalen" Livemigration im Cluster aussieht, teste ich "die Tage".

[testperson 1.707]

Was mich hier generell daran verwirrt:

• Hyper-V so grob aus 2008
• Pre-Windows 2000 Compatible Access

Aber auch damit werde ich leben können. ;)