Scharping-FVB

Wenn ich dies laufen lasse: Invoke-Command -ComputerName "fs1.abc.xyz.de" -ScriptBlock { $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) } kommt "True" zurück. Mein Administrator ist in "Protected Users", vielleicht ist da auch das Problem. Wobei, wenn ich den da raus nehme, macht das auch keinen Unterschied. Kann Remote Credential Guard da rein grätschen?

Das klappt leider noch weniger, da gibt es keine Rückmeldung. Die Updates werden nicht installiert.

Die ISE, in der ich die Remote-PS aufbaue ist Admin-elevated, auf einem Server, an dem ich als Domain Admin angemeldet bin.

Liebes Forum, ich möchte Windows Updates Remote installieren. Über die Befehle: Invoke-Command -ComputerName SERVER-FQDN -Credential $Credentials -ScriptBlock { Import-Module PSWindowsUpdate Get-WindowsUpdate -Install -AcceptAll -IgnoreReboot -KBArticleID KB5002588 } bekomme ich einen Fehler: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) + CategoryInfo : NotSpecified: (:) [Get-WindowsUpdate], UnauthorizedAccessException + FullyQualifiedErrorId : System.UnauthorizedAccessException,PSWindowsUpdate.GetWindowsUpdate Ich verwende als Credentials Domänen Admin Daten. Verwende ich die falschen Befehle oder woran kann es noch liegen? Lokal funktioniert es mit Import-Module PSWindowsUpdate Get-WindowsUpdate -Install -AcceptAll -IgnoreReboot -KBArticleID KB5002588 Daran kann es also eigentlich nicht liegen, es muss etwas mit Remote Powershell zu tun haben. Ein Enter-PSSession funktioniert, ich kann dann mit Get-WUList die Update-Liste abrufen (klappt auch mit Invoke-Command). Irgendwo dazwischen klappt es nicht mit dem Installieren. Hilfe :-( Viele Grüße Davorin

Danke, ich habe eine Mail geschrieben. Ich war mir nicht sicher, ob dies nicht vielleicht doch eine technische Frage ist und habe daher nicht Off-Topic gewählt. Danke für die Klarstellung

Liebes Forum, weiß jemand, wie ich meinen Benutzernamen wechseln kann? Ich werde bald den Arbeitgeber wechseln und dann ist mein Namenszusatz "FVB" nicht mehr gültig. Ich würde ungerne ein komplett neues Profil anlegen, sondern lieber meinen Namen neutral umbenennen. Viele Grüße Davorin

Hui, man muss halt mehrere KI durch probieren (und mit einem ausführlichen Prompt neu anfangen). Claude hat die Lösung gefunden, das Send-As-Recht über eine Management Role zu delegieren. Sein Ansatz: Ermittlung der vorhandenen Rollen mit Add-ADPermission: Das Script überprüft jede Rolle einzeln, ob sie das Add-ADPermission-Cmdlet enthält Erstellung einer neuen Management-Rolle: Basierend auf einer geeigneten Parent-Rolle (vorzugsweise "Organization Management") Die neue Rolle "Custom-SendAs-Management" erhält automatisch alle Cmdlets der Parent-Rolle Zuweisung der neuen Rolle: Die neue Rolle wird der Administrationsrolle "1_Administration-Mailboxes" zugewiesen Das Script versucht sowohl die Zuweisung mit SecurityGroup als auch mit RoleGroup Damit hat es funktioniert, nun sieht die AD-Gruppe in der EAC den Eintrag Send-As". Die Lösung soll für "Nachkommende" zur Verfügung stehen, das PS-Skript habe ich als TXT angehängt. Die ADS-Gruppe "Recipient Management" kann, laut der Description: "Members of this management role group have rights to create, manage, and remove Exchange recipient objects in the Exchange organization." Klingt für mich erst mal nicht so, wie Verwalten des Send-AS Rechts. Aber ich habe eher wenig Ahnung, was sich MS unter diesen Rechten vorstellt. Zudem war die AD-Gruppe bereits Mitglied. Set-delegation-send-as.txt

Also, detaillierter und konkreter: Nach dem Least Priviledge Rechte soll die AD-Gruppe das Recht haben, Mailboxen zu verwalten. Dazu gehört anlegen, bearbeiten, löschen, Rechte vergeben (Send-As, Send-on-behalf, fullAccess). Bis auf die Delegation des Send-As Rechts hat alles funktioniert. Nun möchte ich noch das Verwalten des Send-As Rechts an die AD-Gruppe delegieren. Ob über die Exchange Management Role oder über AD-Permissions ist mir gleich, ich dokumentiere das ja, so ist das nachvollziehbar.

Liebes Forum, ich möchte für eine AD-Gruppe das Recht vergeben für alle on prem Exchange 2019 Mailboxen das Senden-Als-Recht verwalten zu können. Die Gruppe soll also verwalten, wer Senden-Als-Rechte für Mailboxen bekommt. Ich habe es schon über eine Admin Role versucht und für die Management Role, die der Admin Role zugewiesen wurde, die Rechte versucht zu vergeben (Copilot hat das so vorgeschlagen): Set-ManagementRoleEntry "Custom-Mailbox-Change\Add-MailboxPermission" -Parameters "Identity", "User", "AccessRights" In der EAC wird für Mitglieder der AD-Gruppe, die Mitglied der Admin Role ist, unter Mailboxes in den Eigenschaften einer Mailbox bei Mailbox delegation kein Send-As sichtbar, das fehlt völlig. Hab ihr eine Idee? Viele Grüße Davorin

Wenn der Netzwerker die Anforderung hat, sich lokal ohne Netzwerk anmelden zu wollen, dann ist das erst einmal so seine Arbeitsweise. Sicherlich würde er dort, wo er kann, sich ans Netzwerk anschließen. Wofür er die lokale Anmeldung ohne Domäne braucht, weiß ich nicht. Vielleicht wenn er in einem anderen VLAN ohne Routing zur Domäne unterwegs ist zur Router- oder Firewallkonfiguration. Und gerade eben, beim Patchday hat es mich erwischt: Server fährt nach dem Neustart hoch und hat das Netzwerk nicht erkannt. Keine Domäne, keine Anmeldung... VM also neu starten und Daumen drücken, dass das reicht - hat gereicht. Bei Blechservern große ka**e, da muss dann LAPS her. Mit nicht 2025 und dessen lesbaren Kennwörtern, eine Qual :-(

Wenn der Netzwerker die Anforderung hat, sich lokal ohne Netzwerk anmelden zu wollen, dann ist das erst einmal so seine Arbeitsweise. Sicherlich würde er dort, wo er kann, sich ans Netzwerk anschließen. Wofür er die lokale Anmeldung ohne Domäne braucht, weiß ich nicht. Vielleicht wenn er in einem anderen VLAN ohne Routing zur Domäne unterwegs ist zur Router- oder Firewallkonfiguration.

LAPS verwenden wir bereits. Ist halt sehr aufwändig, wenn unser Netzwerker im Serverraum mit seinem Laptop sich lokal als Admin anmelden will. Dann muss er erst das LAPS-Kennwort aufschreiben und dann fehlerbehaftet eintippen. Aber klar, wer das eine Will, muss das andere Mögen!

Wir haben einiges ausprobiert, aber diese lokale Anmeldung dabei übersehen. Bisher hatte Protected Users keine negativen Auswirkungen gehabt.

Ist das eine blöde Idee? Protected Users schützt doch die Credentials. Und vor dem Hintergrund des BSI Empfehlung, Kennwörter nicht mehr regelmäßig zu ändern, sollte vor Pash-the-Hash geschützt werden. Oder gibt es da andere, begründete Empfehlungen?

Dann ist das der Grund, danke für den Hinweis!