testperson 1.758 Geschrieben 27. Februar 2024 Melden Geschrieben 27. Februar 2024 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 Zitieren
NorbertFe 2.155 Geschrieben 27. Februar 2024 Melden Geschrieben 27. Februar 2024 Install-ADServiceAccount geht das unter 2019/2022 überhaupt noch? ich bekam da eigentlich immer Fehler. Unter 2016 war das noch notwendig. Zitieren
testperson 1.758 Geschrieben 27. Februar 2024 Autor Melden Geschrieben 27. Februar 2024 Ich habe es zumindest gerade auf einem Windows Server 2019 ausgeführt (mit Vollzugriff für den ausführenden User auf das sMSA Objekt). Zitieren
NorbertFe 2.155 Geschrieben 27. Februar 2024 Melden Geschrieben 27. Februar 2024 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) Zitieren
NorbertFe 2.155 Geschrieben 27. Februar 2024 Melden Geschrieben 27. Februar 2024 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 ;) Zitieren
testperson 1.758 Geschrieben 27. Februar 2024 Autor Melden Geschrieben 27. Februar 2024 (bearbeitet) 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 2024 von testperson 1 Zitieren
daabm 1.384 Geschrieben 27. Februar 2024 Melden Geschrieben 27. Februar 2024 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... 2 Zitieren
testperson 1.758 Geschrieben 27. Februar 2024 Autor Melden Geschrieben 27. Februar 2024 Im Moment gibt es da für mich wichtigere "Baustellen". Ich würde dich aber glatt im Hinterkopf behalten. ;) Zitieren
v-rtc 92 Geschrieben 28. Februar 2024 Melden Geschrieben 28. Februar 2024 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 ;) Zitieren
daabm 1.384 Geschrieben 28. Februar 2024 Melden Geschrieben 28. Februar 2024 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. 1 Zitieren
testperson 1.758 Geschrieben 1. März 2024 Autor Melden Geschrieben 1. März 2024 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. Zitieren
MurdocX 965 Geschrieben 2. März 2024 Melden Geschrieben 2. März 2024 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 Zitieren
testperson 1.758 Geschrieben 3. März 2024 Autor Melden Geschrieben 3. März 2024 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". 2 Zitieren
testperson 1.758 Geschrieben 3. März 2024 Autor Melden Geschrieben 3. März 2024 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. ;) 1 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.