cj_berlin

Sorry, die unausgesprochene Message meines letzten Posts sollte sein: Hol Dir Hilfe, nicht so sehr bei der Installation von Terminalservern wie bei der Folgeabschätzung dieser Schritte.

Moin, Möglich? absolut. Du kannst in einer AD-Domäne so viele voneinander unabhängige Terminalserver-Umgebungen betreiben wie Du möchtest. Aus technischen Gründen sollte es nicht mehr als drei RDS-Lizenzserver geben, die Per-User-CALs ausstellen, aber auch dafür gibt es Workarounds. Sinnvoll? aus verwaltungstechnischer Sicht ja. Den Security-Aspekt des ganzen muss die Firma/Organisation jedoch vorher bewerten. Schüler werden Mist bauen, absichtlich oder unabsichtlich. Willst Du den Mist in Deinem AD zulassen, muss jemand Vorkehrungen dafür treffen, dass er nicht die Produktions-Umgebung wegreißt. Ich erinnere gerne daran, dass auch der Bundestag damals über die Schulungsumgebung gehackt wurde, auch wenn die verwendete Technologie auf der ganzen Strecke eine ganz andere war als bei euch.

OK, also sind's ZWEI VPNs: eins beim ERP-Hoster und eins von euch. Wie groß ist die Umgebung? Vielleicht würde so ein Cloud-VPN eure Probleme für vertretbares Geld lösen oder zumindest auf den Cloud-Provider verlagern. Euer WAN würde dann einen VPN-Tunnel - über welche WAN-Leitung auch immer - zum Cloud-VPN unterhalten, und den Traffic zum ERP-Hoster darüber routen. Selbiges könnte man auch für OpenVPN betreiben. Ist zwar Tunnel im Tunnel, aber je nachdem, welche Dienste darüber gehen und wie dick die physischen Uplinks sind, mag es funktionieren.. Mit dem DNS Round Robin hast Du es genau richtig verstanden. Es gibt keinen allgemeingültigen Standard, wie die Client-Anwendung damit umzugehen hat, daher hilft nur ein Gespräch mit den Leuten, die sie im konkreten Fall betreiben.

Moin, gibt es zwischen "VPN" und "ERP Hoster" einen Zusammenhang, oder sind es einfach die zwei Systeme, die vom WAN-Failover betroffen sind? Der Inbound-Teil (VPN) könnte vielleicht einfach ein sekundäres Profil verwenden, das versucht wird, falls das primäre Profil sich nicht verbinden kann. Oder Round Robin, und einige Connections gehen über die Backup-Leitung rein (stört das?). Für den Outbound-Teil (ERP Hoster) - entweder sie können FQDN abbilden, das mehrere IP-Adressen zurückgibt (Round Robin), oder man schaltet einen VPN-Gateway in der Cloud dazwischen, und dessen IP ist dann für den ERP Hoster für die Zulassung maßgeblich.

WDS und MDT sind aber zwei Paar Schuhe

Moin, wenn man das dynamisch (in Bezug auf die Adressen) haben möchte: Die "normalen" PowerShell-Cmdlets für Firewall-Regeln unterstützen durchaus auch das Bearbeiten des Regelwerks in einer GPO: https://learn.microsoft.com/en-us/powershell/module/netsecurity/new-netfirewallrule?view=windowsserver2025-ps#-policystore

Warum aktiviert ihr auf dem Test-PC nicht einfach Logging statt gleich zu blockieren? Dann siehst Du auch gleich, was angesprochen wird und auf NTLM zurückfällt.

Nicht Task-Manager. Hyper-V Manager.

HPE iLO hat das auch zum Teil, ich meine, das wird sogar als ein "USB-Netwerkadapter" erkannt. Muss man in iLO deaktivieren.

Laut OP ist die Zone da

Moin, ist auf dem DC, den Du scanst, folgendes als DNS-Server eingetragen und in dieser Reihenfolge (und ja, ich weiß, dass die Reihenfolge in der Praxis keine Rolle mehr spielt): - IP-Adresse eines anderen DCs in derselben Domain, falls vorhanden - IP-Adresse des Netzwerkadapters - 127.0.0,1 ? Falls nein, korrigieren und nochmal laufen lassen. Ansonsten, wenn DCDIAG keine DNS-Fehler wirft und die Zone aufgelöst wird, ist es möglicherweise eine Unschärfe im BPA. Aber kein reproduzierbarer Bug - in meinem Lab wird dieses Finding nicht reportet.

daran, dass der DC keine gültige IPv4-Adresse hat, sondern nur APIPA, und weil Windows generell IPv6 bevorzugt, falls es dieses für die konkrete Verbindung nutzen kann und das Verhalten per Registry nicht abgestellt wurde. Und wenn er doch eine gültige v4-Adresse hat, musst Du schauen, wo die APIPA-Adresse herkommt, und das beseitigen.

Weil der User in der Regel nicht auf die App und die kleine Karte schaut, sondern einfach die Nummer eingibt. Und wenn man genug Login-Versuche von unterschiedlichen Adressen gleichzeitig abschließt, wird der User mit Wahrscheinlichkeit >0 die richtige Zahl in den falschen Prompt tippen. Händisch nicht machbar, automatisiert - warum nicht? Kostet ja fast nichts.

...aber was sagen die NTLM-Logs dazu?

Sind sie in der Group Policy hinterlegt oder in den User-Objekten? Und werden sie wirklich nicht ausgeführt oder ist "nur" das erwartete Ergebnis nicht da? Kannst ihnen ja meinen Talk auf der BSides Berlin 2023 empfehlen

Moin, mein erster Ansatz wäre zu gucken, ob nicht bereits Hornet sowas anbietet. Ist es nicht der Fall, kannst Du in jedem Postfach die entsprechende Regel hinterlegen und auch in regelmäßigen Abständen überprüfen, ob sie noch aktiv ist (Du kannst den User nicht daran hindern, im eigenen Postfach an Regeln herumzubasteln). Wenn natürlich jemand eine Gruppe mit vielen Empfängern anschreibt, wird es häßlich

Der TO hat nirgends gesagt, dass die Netzwerke, aus denen "übers Internet zugegriffen" wird, von ihm kontrolliert werden. Wenn die Quell-IP in Wirklichkeit ein NAT-Router ist, kann sich dahinter eine ganze koreanische Keyboard-Farm verbergen, getarnt als Kühlschrank, Fernseher, Glühbirnen, Wärmepumpe und was sonst nicht alles. Ich wüßte nicht, in welchem Szenario ich KEINE Bauchschmerzen bei sowas hätte. In Theorie hast Du zwar ein Stück weit recht, aber in der Praxis ist das Risiko einfach zu groß. Das einzige, was mir zu dieser späten Stunde einfällt, sind zwei Unternehmensstandorte JEWEILS mit NAC, aber nicht miteinander vernetzt.

Klar ist es interessant

Ob *Du* kannst, kann ich Dir nicht sagen, aber technisch spricht nichts dagegen. Sind die CALs User CALs oder Device CALs? Haben die Schüler jetzt schon Konten im AD, die sie für irgendwas anderes verwenden? Falls "Device" und "nein, noch nicht", würde ich den neuen Terminalserver einfach als Workgroup-Maschine bereitstellen und die Verbindung auf dem IGEL so einrichten, dass man auf die Windows-Anmeldemaske geschickt wird. Damit erreichst Du die (im Rahmen der von Dir beschriebenen Umgebung) bestmögliche Abgrenzung zwischen Schülern und dem Rest. Und in Anbetracht des geplanten Umzugs würde ich den Lizenzserver für die neue Umgebung auf diesem Server installieren und nicht den vom Domain Controller verwenden.

Ich find's prima, dass Du es prima findest. Mir läuft es kalt den Rücken herunter. Ein Terminalserver braucht kein DHCP. Auch keine weitere Domäne, und schon gar keine wie bisher, wo die User lokal auf dem Domain Controller laufen. IGEL Thin Clients sind normalerweise nicht AD-Mitglied, daher dürfte es egal sein, in welcher Domäne welcher Terminalserver steht. Wie viele Lehrer und wie viele Schüler sollen auf diese neue Umgebung zugreifen, und von welchen Endgeräten sollen die Schüler das tun?

Das steht im Client-Log, Event 8001, Feld "Target Name". Vielleicht

Moin, "state switchover interval" (SSI) ist die "elastizität des Clusters". Wenn Deine Lease-Time nicht in Sekunden bemessen wird und Du den aktiven Knoten einfach nur mal rebooten möchtest, muss es doch noch lange keinen Failover auslösen. Dieser Wert zeigt, wie lange der Knoten wartet bis er annimmt, dass der andere so schnell nicht wieder kommen wird. "Max Client Lead Time" (MCLT) ist die maximal mögliche Verlängerung eines Lease, der durch den anderen Knoten vergeben wurde und die Dauer des Leases, die vom passiven Knoten ausgeteilt werden, wenn der aktive "down" ist und das SSI noch nicht abgelaufen ist. Die Kombination beider Werte ergibt das Verhalten, wenn der aktive Knoten ausfällt: Nach SSI beginnt der ehemals passive Knoten, Anfragen zu beantworten, und nach MCLT ist er dann nicht nur aktiv, sondern auch der Owner aller Leases. Aus Ops-Sicht mag ich Aktiv-Passiv-Cluster jeder Art nicht, *besonders* in KMUs, denn man findet nie Zeit, Failover regelmäßig zu testen, und dann eines Tages knallt's.

Ja, das geht. Du musst das Löschrecht auf "Files Only" beschränken, und das "Create Files" recht auf "Subfolders Only". Und natürlich die Vererbung der darüber hinausgehenden Rechte wegnehmen. Alternativ kannst Du die vererbten Rechte in Ruhe lassen und einen expliziten Deny auf "Delete" für diese Gruppe, in diesem Fall beschränkt auf "Subfolders Only", am "Eingang Logistik" verhängen. Ob David damit uneingeschränkt klar kommt, hätte ich Dir vor 20 Jahren aus dem Kopf sagen können, aber jetzt nicht mehr...

Wegen NTLM im normalen Registrierungsprozess mit certmgr.msc? Ich würde das NTLM-Logging auf beiden Seiten hochdrehen und schauen, was da aufgerufen wird, evtl. fehlt doch ein SPN...

Also zwei Server, die jeweils mehr als 50% brauchen, das erinnert schon fast an den Bundeshaushalt Habt ihr im LB-Betrieb eine sehr ungleiche Verteilung? Dann vielleicht mit den Netzwerkern sprechen, damit sie sich die Helper nochmal angucken? Ich habe es mal erlebt, von "selbstbau-HA" mit Server 2003R2 auf echtes HA mit Server 2012R2 migriert und nie Leases am zweiten Server gesehen. Stellt sich heraus, der Helper für Server 2 hatte einen Delay switch-seitig. Doch selbst wenn der Pool am ersten Knoten mal erschöpft ist: was glaubst Du, was dann passiert?