cj_berlin

...da sollte man sich im Nachhinein aber schon fragen, warum ein Tier 0-System etwas "nachladen" darf

Nein, weil ein Angreifer die Lücke ausnutzen könnte, indem er einem User scheinbar harmlosen Code unterschiebt, der ein anfälliges Gerät anspricht. Klar, weniger wahrscheinlich und ungleich komplexer als ein direkter Angriff aus dem Internet, aber "sicher"? Nein.

Schau mal *in* die Registry, nicht nur auf die Rechte dort. Oder lege den Task im Legacy-Modus mit AT an, dann helfen Dir Rechte im Dateisystem.

Damit motivierst Du natürlich andere, Dir zu helfen Vielleicht beschreibst Du mal, wie es auf anderen Plattformen geht, dass man einen Normaluser befähigt, einen Task mit Root-Rechten zu starten, denn nichts anderes versuchst Du hier. Und Spoiler: Mit Windows geht's.

Moin, ein User ohne Adminrechte hat per Default nicht die Berechtigung, einen Scheduled Task zu starten, den er nicht selbst erstellt hat. Da musst Du nachhelfen (Permissions in C:\Windows\Tasks für AT-Tasks, Fummeln in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\ für moderne Tasks).

Die RDS-Lizenzierung ist Named User/Named Device. Da wird so schnell nichts freigegeben

Moin, was @NilsK gesagt hat, plus noch: Das ganze hört sich zwar nicht nach einer Umgebung mit mehreren Scopes an, aber falls der DHCP Server doch nicht im selben VLANs wie die Clients steht, müssen natürlich noch IP Helper und/oder DHCP Relays angepasst werden.

Für mobile Mitarbeiter haben die meisten Anbieter von "sicheren Mail-Apps" diese Funktionalität am Start. Wenn aber "beliebiger Zugriff" gemeint ist, wird es schwierig.

Nein, das ist ein Feature von Azure AD in Deinem Tenant.

Moin, ad 1. ein Client-Zertifikat ad 2. Nein. Ihr könnt dafür aber die Firmenhandies in Intune enrollen und Conditional Access benutzen, um nur Geräte im Status "company owned" zuzulassen.

Moin, das geht mit "einfachen Bordmitteln" tatsächlich nicht und ist auch vom Hersteller nicht vorgesehen. Der Use Case ist aber keineswegs exotisch. Und, wie vermutet, ist für diesen Use Case Exchange nicht die Plattform der Wahl, aber das will ja keiner hören. Eine sehr bekannte Handelskette hat jahrzehntelang deutschlandweit so gearbeitet (ein Postfach pro Filiale, alle Mitarbeiter haben Zugriff). Bis Outlook (und Exchange) 2010 ging es noch mit PRF-Dateien, die man per Skript pimpen konnte. Mit Outlook (und Exchange) 2016 haben sie dann festgestellt, dass man Outlook 2016 zwar dazu vergewaltigen kann, aber irgendwann Autodiscover greift und alle möglichen Artefakte anfangen. Wie sie das gelöst haben, weiß ich nicht mehr.

Die "Idee, die Microsoft da hat" ist doch einfach die exakte Antwort auf Horizon View: on-prem HCI (vSphere + vSAN) ist in der Lizenz enthalten, und die Lizenz selbst ist eine Mietlizenz pro User. Tatsächlich sind wir uns ja alle einig, dass man heute lieber FSLogix verwenden sollte - obwohl der Vorteil, alles mit einer Konsole managen zu können, ohne auf GPO zurück zu fallen, nicht von der Hand zu weisen ist. Mal sehen, ob es für FSLogix irgendwann eine WAC-Erweiterung gibt, die unter der Haube in die LocalGPO schreibt. Oder halt sogar in GPO. Das müsste sich eigentlich recht leicht programmieren lassen. Als erstes bräuchte man aber eine logische Abbildung einer RDS-Bereitstellung im WAC, und das ist vermutlich als Extension nicht zu realisieren

Moin, AVD und RDS kannst Du aber in Bezug auf den Lifecycle nicht wirklich vergleichen. Den Link für on-prem wirst Du vermutlich die nächsten 3 Jahre nicht finden, denn Server 2022 ist produktiv, Funktionalität ist enthalten und somit für 10 Jahre garantiert. Hier: https://docs.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server-2022 Bei AVD hingegen kann MSFT jeden Tag den Versions-Counter erhöhen, ist ja "as a service".

Moin, FSLogix basiert tatsächlich auf demselben Prinzip wie die UPD, erlaubt aber, neben einer besseren Performance, noch gleichzeitigen Zugriff aus mehreren Sessions auf den gleichen Profildatenträger App Masking - Ausblenden von bestimmten Dateien und Ordnern abhängig von z.B. Gruppenmitgliedschaft Optimierung der Suche spezielle Optimierung für Office (Office Container) Koexistenz mehrerer Java-Versionen auf dem gleichen Session Host

OK, also ist der Jumphost ist ein RDS-Session Host, Connection Broker und RDWeb in einem? Im IIS, dort wo die zertifikatsbasierte Authentifizierung konfiguriert ist, kann man Regeln definieren, die auf alle möglichen Eigenschaften des Zertifikats abzielen, so auch auf den Issuer. Das geht aber IIRC nur mit "IIS Client Certificate Mapping", nicht mit "AD Client Certificate Mapping". Vermutlich ist es nichts, was Du unter Zeitdruck und ohne entsprechendes Know-How angehen solltest. Kannst Du nicht einfach alle User, die in Frage kommen, in eine Gruppe packen und die Session Collection bzw. die Remote App auf diese Gruppe beschränken? Du kannst ja aus der CA1 die Liste der User exportieren, die ein Client-Zertifikat bekommen haben...

bei der Anmeldung woran? Bei der Windows-Anmeldung am Jumphost, Browser-Anmeldung am RDWeb, an Facebook? Auch wenn es schwer vorstellbar ist: Wir kennen Dein System nicht. Wenn es um ein Zertifikat im Browser geht, kann der User, meine ich, ein beliebiges Zertifikat für die Authentifizierung auswählen, das sich samt Private Key in seinem privaten Store befindet und die EKU "Client Authentication" besitzt, egal, ob der Rechner, wo er gerade angemeldet ist, dem Aussteller vertraut oder nicht. Es ist am Webserver, nur bestimmte Aussteller oder gar nur bestimmte Zertifikate (User) zu akzeptieren.

Hah! Du hast ja Glück, dass Du nicht bei Meister See Jay PowerShell lernen musst. Miyagi-san und seine Autowäsche ist Kindergarten dagegen

Du verrätst immer noch nicht, warum es aus Deiner Sicht schlimm wäre, wenn der Jumphost der CA2 vertraut. Erkläre doch bitte, wie genau das User-Zertifikat in die Anmledung a. am Jumphost und b. am RDWeb involviert ist.

Moin, ich verstehe den Zusammenhang zwischen Server- und Benutzerzertifikaten zwar nicht ganz, aber es gibt einige Verfahren, wo das Vertrauen in ein Leaf-Zertifikat explizit erklärt werden kann: Code Signing und S/MIME zum Beispiel. TLS gehört allerdings nicht dazu, hier muss der Zertifikatskette vertraut werden. Hast Du Bedenken, dass, wenn Du das Vertrauen in CA2 erklärst, sich User mit CA2-Zertifikaten werden am Jumphost anmelden können? Dafür gibt es Policies, die die Anmeldung regeln, unabhängig davon, ob sie per Smartcard oder per Username/Password erfolgt. Außerdem - sofern es wirklich um Smartcards geht, Du verrätst ja nicht soviel - ist das generelle Vertrauen in die Zertifikatskette nicht ausreichend, die Root CA muss im NTAuth-Store eingetragen sein.

Was ist aus "lernen durch Schmerz" geworden?

https://devguru.com/content/technologies/wsh/wshshell-run.html Da ist auch die genaue Erklärung drin

Zweiteres. Eine Site mit einem Exchange-Server aber ohne schreibbaren DC ist nicht supported und ich meine, Exchange wird sich in solch einer Site auch nicht installieren lassen. AD-Replikation ist kein zeitkritischer Vorgang, der AD-Zugriff seitens Exchange schon. Auch kann da durchaus Traffic entstehen, den Du nicht im VPN haben willst. Jedenfalls nicht im 16M-VPN.

Naja, wenn die Benutzer am Hauptstandort wirklich körperlich sitzen, dann haben sie ja bis zum Exchange vermutlich Gigabit. Das solltest Du nicht verschenken, indem Du den Exchange von ihnen weg schiebst, denn wie @NorbertFe schrieb, dann haben sie nur 16M zum Exchange für alle. Wenn die Benutzer nach Hause geschickt werden, würde Exchange im Cloud-RZ mehr Sinn machen. Andererseits, wenn sie im Cached Mode arbeiten können oder OWA nutzen, ist es gar nicht so schlimm. Du könntest Dir daher überlegen, den Exchange *nur* im Cloud-RZ bereitzustellen und Cached Mode zur Normalität zu erklären, wie bei O365 halt. Davon profitieren sowohl die mobilen User (der nächste Lockdown kommt bestimmt) als auch Deine anstehende O365-Migration (die kommt bei der Anzahl User auch bestimmt). Irgendeinen Tod muss man halt sterben. Aber wenn Du Exchange im Cloud-RZ platzierst, muss da zwingend auch ein Domain Controller hin.

Moin, wieviele Exchange-User sitzen dauerhaft jeweils am Standort mit 16M am Standort mit 100M außerhalb der Standorte? Nicht zwangsläufig - kommt darauf an, wo der User sitzt (#WFH lässt grüßen)...

GPRESULT und https://techcommunity.microsoft.com/t5/microsoft-security-baselines/new-tool-policy-analyzer/ba-p/701049