Scharping-FVB

Enter-PSSession klappt, Test-WSMan auch. In beiden Domänen. Ich habe auch mal "Protected Users" ausgeschlossen, hat nicht geholfen. Auch ein Versuch, mich mit einem Domain Admin Konto an einem Tier0 Server anzumelden funktioniert nicht. Immerhin etwas "Neues": Wenn ich mich mit einem Domain Admin am WAC anmelde, bekomme ich diese Meldung, beim Versuch mich an einem Tier1 Server anzumelden: Connecting to remote server XYZ.DOMAIN.de failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x8009030e occurred while using Kerberos authentication: A specified logon session does not exist. It may already have been terminated. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. Das ergibt Sinn, da Tier0-Admins sich nicht an einem Tier1-Server anmelden dürfen. Also wird eine Anmeldung versucht und die Credentials korrekt weitergegeben. An einem Tier0-Server kann ich mich aber trotzdem nicht anmelden, da kommt diese Meldung: Zum Ausführen des einmaligen Anmeldens mit dem Windows-Konto muss unter Umständen die eingeschränkte Kerberos-Delegierung eingerichtet werden. The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". Die Installation in der zweiten Domäne bleibt ohne weitere Verbindung zum AD oder Internet, obwohl ich im selben Browser, in dem WAC geöffnet ist, sehr wohl surfen kann, kann das WAC jedoch keinen Katalog der Extensions laden. Noch andere Ideen?

Liebes Forum, ich habe in zwei Domänen das WAC-Gateway auf jeweils 2019 installiert. In der einen Domäne kann ich mich zwar anmelden und auch alles einstellen und sogar alle AD-Server hinzufügen, aber ich kann mich auf keinen der Server verbinden. Weder mit dem AD-Account, der am Gateway im Browser angemeldet ist und auf allen Servern lokaler Administrator ist, noch mit irgendeinem anderen Administrator Account, welches ich dann pro Server manuell eingebe. In der anderen Domäne (gleiche Installationsdatei), kann ich noch nicht einmal das AD nach Servern durchsuchen, auch einzelne Server werden nicht hinzugefügt, auch nicht über den FQDN. In beiden Domänen ist die Windows Firewall aus und die Server sind alle im selben Subnetz. Der Virenschutz (Cortex XDR) hat keine Meldung von sich gegeben. Ich habe bisher nichts dazu finden können, was irgendwie geholfen hat. Hat jemand eine Idee, was bei mir los ist? Viele Grüße Davorin

Nach langer Zeit habe ich es noch einmal getestet. Auf dem remote Server ist UAC auf "aus" (unterste Einstellung), der verwendete admin-User ist lokaler Admin auf allen Servern. Ich habe ausprobiert: Invoke-Command -ComputerName REMOTE-SERVER -Credential $Creds -ScriptBlock { Install-WindowsUpdate -AcceptAll -AutoReboot } In einer PS-Session: Install-WindowsUpdate -KBArticleID KB5025229 -AcceptAll -AutoReboot Ich bekomme bei beiden "Access Denied". Direkt am Server ausgeführt funktioniert es. Ich bin doch nicht der einzige, der Windows Updates über remote Powershell installiert, oder?

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!

Liebes Forum, wenn ich ohne Domain, zu Hause, mich an meinem Win10 Notebook als ein lokaler Administrator (Domain User) anmelden möchte, scheitert dies, aufgrund der fehlenden Domäne. Mit meinem eigenen, normalen User klappt es. Der adloc-User war bereits in der Domäne angemeldet, die Credentials sollten also zwischen gespeichert sein, so wie die meines normalen Users. Oder werden die Creds eines lokalen Admins (Domain User) nicht zwischengespeichert? Wie kann ich erreichen, dass sich auch ein loakler Admin (Domain User) ohne Verbindung zur Domäne anmelden kann? Viele Grüße Davorin

Oha, das ist wohl das Problem, tut mir leid, ich war da zu schnell... Klappt natürlich, so wie du es sagst

Dann ist aber wieder das Kennwort notwendig, beim Start von Outlook poppt ein Anmeldefenster für das Gruppenpostfach auf...

Gelöscht, weil noch nicht alles ausprobiert

Oha, wieder etwas gelernt, das klappt ja tatsächlich nun muss ich nur noch jeden FullAccess "austauschen" gegen FullAccess -Automapping:$false Sollte ja irgendwie per PowerShell Skript machbar sein, alle Postfächer daraufhin zu prüfen und das dann zu entfernen und neu hinzuzufügen Danke an euch alle

Das ist b***d, denn dann brauche ich das komplexe Kennwort für die Gruppenpostfächer :-( Und das können wir dann nicht mehr einfach so ändern.

Du meinst so? b***d, dass ich für alle Postfächer mit "Vollzugriff" nun manuell per Powershell /automapping:false einstellen muss :-/ Oder mühselig einzelne Berechtigungen einrichten muss. Ich probiere das erstmal für besonders hartnäckige Problemfälle aus. Danke ok, werde ich ausprobieren, danke