cj_berlin

Moin, ad 1. das kannst Du alles in den Conditional Access Policies einstellen. Normalerweise muss man sich nicht ständig neu authentifizieren, wenn man nicht ständig die IP wechselt. ad 2. Hier musst Du bitte beschreiben, was Du erreichen willst.

Moin, nur um ein Paar Missverständnisse aufzuräumen: das explizite Laden des Exchange-SnapIns in eine neutrale PowerShell-Sitzung war noch nie supported (die offizielle Sprachregelung ist: "nur auf Anweisung des Microsoft-Supportpersonals") JEDE Exchange Management Tools-Sitzung ist eine Remoting-Sitzung, selbst wenn es nur einen Exchange-Server gibt und die PowerShell lokal auf diesem gestartet wurde Die ISE oder Shell "als Admin" ausführen, spielt nur lokal auf einem Exchange-Server eine Rolle, und zwar nur dann, wenn die darunterliegende Remoting-Sitzung dann auch zu diesem Server erfolgt Die von @testperson beshriebene Vorgehensweise ist eigentlich die "einzig wahre", allerdings muss man darauf vorbereitet sein, dass einige Komfort-Funktionen verloren gehen. Fragt man beispielsweise Größen oder Quotas ab, so wird der Wert "X GB (aaa,bbb,ccc Bytes)" als String geliefert, und der Aufruf $db.IssueWarningQuota.Value.ToGB() wird nicht funktionieren, da diese Funktion nicht von Exchange per Remoting mitgegeben wird, sondern Teil des Snap-Ins ist. Aber es ist viel darüber geschrieben worden, wie man damit umgeht.

Moin, schau mal, was Get-Mailbox ohne Parameter Dir liefert. Solltest Du nur die eigene Mailbox des Admin-Users (sofern er überhaupt eine Mailbox hat) zurück bekommen, dann ist mit der Deaktivierung von RC4 bzw. NTLM wohl auch die Gruppenzuordnung zu den Exchange-Rollengruppen gestört. So richtig mag sich mir das im Moment aber noch nicht erschließen...

Laut Deinem OP hast Du die offiziellen Roots entfernt, so dass die Liste leer war, und das ist gegen RFC. Vom Ersetzen der offiziellen Roots durch eigene war nie die Rede. Ich habe das gemacht und der BPA ist ruhig, laut Wireshark wird auch nicht versucht, die offiziellen Roots zu kontaktieren, wenn der BPA-Scan läuft.

Vermutlich weil der DC sie nicht erreichen kann. Trage Deine eigenen externen Forwarder als Root ein und lösche die offiziellen, dann sollte Ruhe sein - solange Deine Forwarder die Root-Zone auflösen können.

Moin, wenn die Clients in der Domäne sind, die User mit ihren AD-Accounts angemeldet sind und das VPN ihnen die "Line of Sight" zum Domain Controller bietet, so könnten sie ihr Passwort ja am Client ändern, nachdem sie die VPN-Verbindung aufgebaut haben. Tatsächlich müssten sie das sogar das erste Mal, wenn sie den Rechner nach der Mittagspause entsperren Aber da sind sie ja schon nach dem Frühstück bei RDP gegen die Wand gelaufen und der Haken ist wieder raus. Nimm den Haken raus und schreib ein Skript, das jedem, der sich angemeldet, sein Passwort jedoch nicht geändert hat, zweimal am Tag eine Mail mit Anleitung schickt.

Solche "Gateways" haben viele Behörden und große Unternehmen. Beispiel: https://www.opswat.com/products/metadefender/kiosk

Moin, um das Offensichtliche auszuschließen: ist das Zertifikat, das an den Listener gebunden ist, von einer Kette ausgestellt, die sich am Client in Trusted Roots wiederfindet?

Hmm. Du hast am Server das Forwarding aktiviert, damit ist er ein Router oder zumindest denkt er das. Da bin ich mir gerade nicht so sicher, ob er dann aus den RAs von anderen Routern sich die grundlegenden Einstellungen wie IP-Adresse, Gateway usw. holen wird. Das Problem mit den dualen Adressräumen ist, dass Du letztendlich nicht beeinflussen kannst, über welchen von ihnen die Systeme intern miteinander kommunizieren werden - im Zweifel suchen sie sich einen aus. Das rächt sich an der Datacenter-Firewall, das rächt sich an der Windows-Firewall, vor allem, wenn die Adressen dann auch noch dynamisch sind.

Ha! Ich hatte mal einen Freund, in dessen Aufgabengebiet die Betreuung einer RDS-Farm fiel (Server 2003, da gab es noch keine RDS-Farmen im technischen Sinne) bei der die Clients auf einer Forschungsstation in der Antarktis standen und nur per Satellit angebunden waren. Wie wäre es mit 5-10 Sekunden Latenz?

Achtung, möglicherweise redet ihr gerade aneinander vorbei. @mzaplata was meinst Du in Deinem OP mit "Geräte"? USB-Geräte ("Autoplay soll für den roten USB-Stick gelten, aber nicht für den blauen") oder tatsächlich Clients (wie @Pipeline es verstanden hat)?

Und ja, Deine Beobachtung, dass sich die meisten Admins nur oberflächlich, sofern überhaupt, mit IPv6 beschäftigt haben, ist absolut zutreffend. Denn: Wenn man nicht gerade in Ausbildung ist oder bei einem ISP/TelKo arbeitet, hält sich die Notwendigkeit, das zu beherrschen, extrem in Grenzen. Wir sind hier in einem Microsoft-lastigen Forum, und sowohl bei Microsoft-Produkten als auch bei vielen auf Microsoft-Technologie basierenden 3rd Party-Applikationen gilt die Maxime "IPv6 wird unterstützt, solange IPv4 korrekt konfiguriert ist und das v4-Routing und -DNS auch funktioniert" Wenn ich jetzt, wo der Abend schon weit fortgeschritten ist, darüber nachdenke, welches Produkt oder Feature IPv6 zwingend braucht, fällt mir eigentlich nur DirectAccess ein. Selbst Systeme wie HPE Synergy, wo die ganze interne Verdrahtung über IPv6 läuft, operieren nach außen wunderbar über IPv4. Und Admins haben halt gerade ganz andere Baustellen, wo IPv6 nicht helfen kann...

Moin, die Frage ist aber doch, wozu soll diese Dopplung gut sein? Wie dem auch sei, poste mal die Ausgabe von netsh interface ipv6 show interface "<Name der Netzwerkkarte>" vom Server.

Wenn Autodisvover gestört ist, kannst Du kein Out of Office einschalten und meistens auch nicht auf fremde Postfächer zugreifen.

Das wäre auch meine Frage, vor allem da Du scheinbar möchtest, dass beide Konfigurationen - vom Router und vom DHCP Server - überall ankommen (bis auf den DHCP Server selbst natürlich). Meinem Verständnis nach müsstest Du dem Server eine statische IPv6-Adresse verpassen und nur den Standardgateway über RA abholen.

Moin, kannst Du mal checken, ob sie a. die typischen Autodiscover-Artefakte hat (z.B. Abwesenheit einrichten usw.) b. einen frisch angelegten Kontaktordner in ihrem eigenen Postfach als Adressbuch einrichten kann?

Ja. In jedem Forum, in dem ich bisher tätig war, fand sich früher oder später die eine Person, die mir vorwarf, ich würde nur wegen Ego oder wegen Punkten antworten. Meistens sind das Mitglieder, die selbst noch nie irgendwas hilfreiches beigesteuert haben. Du bist also diese Person in diesem Forum. Haken dran. Das ist das alltägliche Risiko, mit dem man als Community-Contributor halt leben muss. Ich orientiere mich da aber lieber an den random Leuten, die mich an der Ostsee am Strand ansprechen und sich für einen Beitrag bedanken, der ihnen vor drei Jahren aus der Patche geholfen hat

Moin, was ist denn der Sinn der Übung? Welche Konstellation willst Du im Endeffekt erreichen?

das hat auch niemand vorgeschlagen Hmmm. Dass jemand "Netzwerker" im Forum-Namen stehen hat und nicht weiß, dass man "eine Netzwerkkarte, die zu einem bestimmten Netzsegment verbunden ist" umgangssprachlich "ein Bein" nennt (kommt, wie immer, aus dem Englischen - "one-legged vs. two-legged appliance design") konnte man ja nun wirklich nicht ahnen, tut mir leid.

Moin, sorry, aber wer hat von "real" im Sinne von "Hardware" gesprochen? Der NAT-Switch von Hyper-V hat keine Reverse-NAT-Funktion, Punkt. Außerdem ist er nur auf Client-Betriebssystemen supported. Eine VM mit einer kostenfreien Firewall-Distribution ist eine schnelle, ressourcenschonende und kostenfreie Lösung, die dazu auch noch mit mehreren Hosts verwendbar oder von einem Host auf einen anderen portierbar wäre: Externen vSwitch mit LAN2 als Uplink Privaten vSwitch für die VMs pfSense-VM mit einem Bein je vSwitch NAT in der pfSense-VM einrichten (outbound NAT ist ab Werk da, wenn Du das externe Interface als WAN kennzeichnest) Glücklich sein. EDIT: Abgesehen davon, dass es in "real" keinen "NAT-Switch" gibt

Moin, einfach nicht mit dem eingebauten NAT-Switch arbeiten, sondern eine Router-VM mit zwei Beinen bereitstellen. Ich nehme dafür seit vielen Jahren pfSense, aber es gibt auch andere Distributionen. Auf diesem Router kannst Du dann NAT inbound machen, nicht nur outbound.

Moin, Du kannst ja mal mit KLIST schauen, ob Du über das VPN Kerberos-Tickets bekommst.

Moin, welche Fehlermeldung bekommen denn die User, die sich nicht anmelden können? Es sieht ja bald so aus, als würde nur NTLM zu eurem RDS funktionieren, aber nur dann, wenn man es dazu zwingt. Frage: Habt ihr noch Rechner, wo ihr das "Erneuern der Vertrauensstellung" noch nicht durchgeführt habt, das aber noch probieren würdet, weil es da diese Probleme gibt? Könntet ihr, bevor ihr das macht, dort einen User anmelden, der dort noch nie angemeldet war (am besten einen neuen Testuser anlegen) und schauen, ob das klappt? Und, nicht weniger wichtig, wie genau habt ihr die Migration der DCs durchgeführt?

Dann geh auf einen Server, wo Du *weisst*, dass das Cert dort installiert ist (gerne per obigem Code-Snippet, aber ohne den Thumbprint und den Backslash davor), und hol Dir den Thumbprint

Die Lösung steht oben.