Jump to content

Scharping-FVB

Members
  • Gesamte Inhalte

    118
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Scharping-FVB

  1. 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?
  2. Das klappt leider noch weniger, da gibt es keine Rückmeldung. Die Updates werden nicht installiert.
  3. Die ISE, in der ich die Remote-PS aufbaue ist Admin-elevated, auf einem Server, an dem ich als Domain Admin angemeldet bin.
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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 :-(
  11. 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.
  12. 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!
  13. Wir haben einiges ausprobiert, aber diese lokale Anmeldung dabei übersehen. Bisher hatte Protected Users keine negativen Auswirkungen gehabt.
  14. 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?
  15. Dann ist das der Grund, danke für den Hinweis!
  16. 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
  17. Oha, das ist wohl das Problem, tut mir leid, ich war da zu schnell... Klappt natürlich, so wie du es sagst
  18. Dann ist aber wieder das Kennwort notwendig, beim Start von Outlook poppt ein Anmeldefenster für das Gruppenpostfach auf...
  19. Gelöscht, weil noch nicht alles ausprobiert
  20. 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
  21. 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.
  22. 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
  23. Liebes Forum, wir haben vermehrt das Problem, dass Outlook 2016 (Offline Modus) das Postfach nicht aktualisiert. E-Mails können versendet werden, es werden jedoch keine neuen angezeigt. Insbesondere bei automatisch eingebundenen Vollzugriff-Postfächer tritt dies auf, aber gelegentlich auch bei Hauptpostfächern. Outlook zeigt "Verbunden mit..." und "Alle Ordner sind auf dem neuesten Stand" an. Ein neues Outlook Profil behebt da Problem erst einmal, meist tritt es nach einigen Tagen erneut auf. Im OWA ist erwartungsgemäß alles vorhanden und wird auch aktualisiert. Was kann ich hier machen, um das Problem mit der Aktualisierung einzugrenzen und zu beheben? Viele Grüße Davorin
  24. Liebes Forum, ich habe versucht RCG für einen Server und einen Client einzurichten. Für den Client habe ich diese GPO eingestellt: System/Credentials Delegation Policy Setting Restrict delegation of credentials to remote servers: Enabled Use the following restricted mode: Require Remote Credential Guard Für den Server: System/Credentials Delegation Policy Setting Remote host allows delegation of non-exportable credentials: Enabled Der zu testende AD-User ist Mitglied einer AD-Gruppe, die wiederum Mitglied der lokalen Gruppe "Remote Desktop Users" ist. Wenn ich mich mit einem AD-User anmelde, dann erhalte ich: "the requested session access is denied". Ist der AD-User Mitglied der lokalen Gruppe der Administratoren, funktioniert die Anmeldung. Im ersteren Fall kommt im Event Log, "successfully", obwohl die Anmeldung abgewiesen wird: An account was successfully logged on. Subject: Security ID: SYSTEM Account Name: SERVER$ Account Domain: YYY Logon ID: 0x3E7 Logon Information: Logon Type: 10 Restricted Admin Mode: No Virtual Account: No Elevated Token: No Impersonation Level: Impersonation New Logon: Security ID: YYY\xxxx Account Name: xxxx Account Domain: YYY Im zweiten Fall, als lokaler Admin kommt dieses Ereignis: An account was successfully logged on. Subject: Security ID: SYSTEM Account Name: SERVER$ Account Domain: YYY Logon ID: 0x3E7 Logon Information: Logon Type: 10 Restricted Admin Mode: No Virtual Account: No Elevated Token: No Impersonation Level: Impersonation New Logon: Security ID: YYY\addom-XXXX Account Name: addom-XXXX Account Domain: YYY Logon ID: 0x140036 Linked Logon ID: 0x13FFEE Network Account Name: - Network Account Domain: - Logon GUID: {00000000-0000-0000-0000-000000000000} Process Information: Process ID: 0x8b8 Process Name: C:\Windows\System32\svchost.exe Network Information: Workstation Name: SERVER Source Network Address: 10.x.x.x Source Port: 0 Detailed Authentication Information: Logon Process: User32 Authentication Package: Negotiate Transited Services: - Package Name (NTLM only): - Was kann ich tun, um RCG für Domänen-Administratoren zu erzwingen? Viele Grüße Davorin
  25. OK, das funktioniert generell. Doch ich habe dann ein anderes Problem mit Remote Credential Guard, für das ich einen neuen Thread eröffne.
×
×
  • Neu erstellen...