cj_berlin

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?

Allerdings, und das meine ich ernst, muss mir jemand mal zeigen, WIE er diese Website heutzutage noch benutzt, basiert die Ausstellung von Zertifikaten doch auf ActiveX-Controls...

Klar, jeden Tag, wenn Du die BSI- oder CIS-Härtung anwendest, dann wird der letzte angemeldete Name nicht vorbelegt.

Das ist die ACL, die jedes Objekt von seiner Klasse im Schema mitgegeben bekommt, wenn es erstellt wird. Wenn Du dir ein neues Objekt anschaust und die Berechtigungen unter "Advanced" auflistest, dann gibt es halt Einträge, die nicht vererbt sind. Das sind diese

genau. das ist ja der Sinn von "übernommen" --> es ist dann "ihre eigene" Domain

Manche, die ich so kriege, kommen mit valider DKIM-Signatur.

Moin, RDS-Lizenzierung ist niemals "concurrent" und ist es nie gewesen, daher schrieb ich oben Ansonsten, was @Nobbyaushb und ich auch bereits angemerkt haben - vergiss die zwei gleichzeitigen Sitzungen. Die sind für die Verwaltung des Servers und der darauf installierten Anwendungen, NICHT für die Benutzung. Andererseits, wenn ein Device lizenziert wurde (nein, nicht MAC-Adresse, die RDS-Lizenzierung funktioniert anders), können sich von diesem Device beliebige - und beliebig viele - User anmelden, Admin oder nicht. Ich bin generell kein Fan von VPN, aber ALLES ist besser als RDP ungeschützt ins Internet zu stellen, also per dieser Definition auch VPN

"PAT" ist das, was sein Router als "NAT" anbietet.

Moin, seltsame Formatierung, Ist es ein Copy/Paste aus einem anderen Forum? Dann bitte auf Cross-Post hinweisen. Das Wichtigste vorab: Du willst NICHT Port 3389 per NAT ins Internet stellen. Es sei denn, alle zugreifenden Clients haben feste IPs, und Du erlaubst nur diese auf der Firewall Deines Routers. Aber eigentlich auch dann nicht. Tust Du es dennoch, wird Dein Server nur damit beschäftigt sein, falsche Anmeldungen abzuweisen, bis die erste nicht falsch ist, und dann ist es nicht mehr Dein Server. Ansonsten: Neben RDS-Rolle aktivieren, musst Du dem Server noch den zuständigen RDS-Lizenzserver und den Lizenzierungstyp mitteilen. Der Typ, falls Du kein AD hast, kann nur "per Device" sein, der Lizenzserver kann auf demselben Windows Server aktiviert sein, und dort musst Du die RDS CALs einspielen - so viele, wie es unterschiedliche Devices gibt, von denen aus Deine User zugreifen werden. Aber da gibt es eine Karenzzeit. Dass bereits jetzt immer noch zwei Sessions möglich sind, ist ein Hinweis darauf, dass - vielleicht, nur vielleicht? - Deine "User" alle lokale Admins auf dem Server sind. Das ist natürlich auch nicht zielführend. Die Gruppe der Remotedesktop-Benutzer existiert auch lokal.