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?

vor 8 Minuten schrieb cj_berlin:

...aber bist Du auch lokaler Admin auf der Zielmaschine? Kannst Du mal den obigen Invoke-Copmmand, aber mit dem folgenden Scriptblock laufen lassen:
 

$currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
$currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

Wenn $false zurückkommt, weißt Du auch schon bescheid

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?

Am 17.4.2025 um 13:26 schrieb Dukel:

Versuche einmal:

Invoke-WUjob

 

In deinem Fall:

 

$script = { Get-WindowsUpdate -Install -AcceptAll -IgnoreReboot -KBArticleID KB5002588 }
Invoke-WUjob -ComputerName Server-FQDN -Script $Script -RunNow

 

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

vor 11 Minuten schrieb Sunny61:

Ausführen als Administrator dürfte der Unterschied zwischen Lokal und Remote sein. Alternativ mit PSEXEC probieren.

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

vor 7 Minuten schrieb Damian:

So ist es.

 

@Scharping-FVB Schreibe ein Mail mit deinem Anliegen an: boardadmin@mcseboard.de

 

Hab das Thema auch ins OT verschoben, ist ja kein Windows-Problem.

 

VG

Damian

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.

vor 3 Minuten schrieb NorbertFe:

Sollte dafür nicht die recipient Administrators Gruppe ausreichen?

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

Am 20.3.2025 um 10:01 schrieb Dukel:

Im Serverraum gibt es keine freien LAN Dosen um eine Verbindung zum AD zu bekommen?

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 :-(

Am 20.3.2025 um 10:01 schrieb Dukel:

Im Serverraum gibt es keine freien LAN Dosen um eine Verbindung zum AD zu bekommen?

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.

vor 3 Minuten schrieb Dukel:

 

Macht es doch ;) Du kannst die Credentials nicht ohne Verbindung ins Netz ausprobieren.

 

Entweder keine Protected Users oder Lokale Administratoren (LAPS) nutzen.

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!

vor 3 Minuten schrieb NorbertFe:

Hängt halt vom Anforderungsprofil ab. Und bevor ich sowas pauschal umsetze, schaue ich mir evtl. eben erstmal die Konsequenzen an, die diese Konfiguration mit sich bringt.

Wir haben einiges ausprobiert, aber diese lokale Anmeldung dabei übersehen.

Bisher hatte Protected Users keine negativen Auswirkungen gehabt.

vor 7 Minuten schrieb NorbertFe:

Wer kommt denn auf die Idee 😆 

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?

vor 27 Minuten schrieb testperson:

Hi,

 

 

falls der Domain User mit lokalen Adminrechten in der Gruppe der "Protected Users" ist, dann ist das so.

 

Gruß

Jan

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

Am 17.3.2025 um 13:18 schrieb NorbertFe:

Nein ist es nicht. Aber der User sollte sich schon neu anmelden, damit die Gruppenmitgliedschaft zieht. ;)

Oha, das ist wohl das Problem, tut mir leid, ich war da zu schnell...

Klappt natürlich, so wie du es sagst

vor 50 Minuten schrieb Squire:

pack die User in eine Verteilergruppe (Typ Sicherheit) und berechtige die Gruppe. Blende die Gruppe dann in der Adressliste aus.

Die Anwender können/müssen dann die Shared Mailbox selbst hinzufügen

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

vor 18 Minuten schrieb testperson:

Hi,

 

bei FullAccess benötigst du das Kennwort nicht, da der zugreifende User ja halt FullAccess hat.  Generell sollte bei Gruppenpostfächer niemand das Kennwort kennen/brauchen und der Account dahinter ist doch deaktiviert.

 

Gruß

Jan

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

vor 12 Minuten schrieb Nobbyaushb:

Nein, nicht innerhalb der Mailbox!

Über den Plus Button als weitere Mailbox einrichten 

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.

vor 11 Minuten schrieb Nobbyaushb:

Automapping macht eh immer Probleme 

Abschalten und manuell einbinden ist die einzige Lösung 

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

vor 24 Minuten schrieb NorbertFe:

Was kein Wunder wäre, wenn du tatsächlich den Offline Modus meinst. ;) Ich vermute aber, du meinst den Cache-Mode (ja, das ist tatsächlich ein Unterschied).

 

Die Automapped Mailboxes einfach NICHT in den den Cachemode integrieren, sondern per Policy verhindern.

 

Bye

Norbert

 

ok, werde ich ausprobieren, danke