cj_berlin

Moin,

wenn man ein ordentliches Imaging-Verfahren hat, würde ich den Nutzen von WinRE generell hinterfragen und das Update einfach ausblenden. 

Wer aber keins hat, wird um das Thema herum skripten müssen oder auf das Update verzichten.

Moin,

die Idee, neue Fileserver mit CNAME- oder sogar A-Records mit dem alten Namen zu maskieren ist zwar verbreitet, aber am Ende landest Du meistens bei DisableStrictNameChecking und öffnest ein paar Anfälligkeiten, die Du nicht unbedingt haben müsstest. Grundsätzlich kriegt man das hin, ich würde es aber erst als Plan Z in Betracht ziehen.

Wenn die Maschinen virtuell sind, kannst Du ja einen neuen Server 2022 als Fileserver mit dem Namen des DC erstellen. Das würde vermutlich die geringste Disruption verursachen, und Du hättest den DC vom Fileserver getrennt.

Ansonsten musst Du die Migration gegenüber den Usern vielleicht einfach ankündigen: "Am Donnerstag, VPN aufbauen, langsam bis 20 zählen, dann gpupdate durchführen und rebooten." Danach sollte doch eigentlich alles funktionieren  , auch wenn Zugriff auf GPOs erst nach dem VPN-Aufbau möglich ist.

Der Einwand von Jan, dass SMB nicht für WAN und erst recht nicht für VPN gemacht ist, ist absolut berechtigt, aber natürlich kann sich nicht jeder einen Terminalserver / eine TS- oder VDI-Farm leisten. Spätestens jedoch. wenn die superkritisiche Excel-Tabelle durch WAN-Unterbrechung zerschossen wird, könnte auch Budget für eine solche Lösung frei werden. Wieviele User sind im Schnitt gleichzeitig per VPN verbunden?

Moin,

ich meine, Du musst DuckDuckGo zu der Policy "Managed Search Engines" hinzufügen, dann hast Du für die Default auch diese Abkürzungen.

Und der Hinweis auf die aktuellen ADMXen ist berechtigt, da gab es durchaus Bugs, auch im Bereich der Suchanbieter.

vor 37 Minuten schrieb NilsK:

allerdings muss man bei Thomas Joos leider meist dazu sagen, dass ihm oft die Sorgfalt fehlt, seine Bücher auch ordentlich zu aktualisieren, wenn es neue Versionen der Produkte gibt.

Daher empfehle ich auch gern das Exchange-Buch vom anderen Thomas (Stensitzki) - da fehlt gar nix.

Allerdings war das Problem hier in diesem Thread ja kein Exchange-, sondern ein Outlook-Problem. Und da gibt es noch weitere, die einem nicht beigebracht werden. Aber dieses konkrete Problem ist schon 15 Jahre alt: https://web.archive.org/web/20141231022743/http://support.microsoft.com/kb/913843

Moin,

checke erst mal in certlm.msc, ob das Zertifikat mit privatem Schlüssel importiert ist. Ist es drin, aber ohne privatem Schlüssel, lösche es, spiele dioe PFX noch einmal korrekt ein und nutze Enable-ExchangeCertificate, um es zu aktivieren. Danach, falls das Cmdlet keine Fehler wirft, iisreset durchführen.

Ist das Zertifikat mit privatem Schlüssel drin, probiere Enable-ExcahnegCertificate nochmal und schau im IIS Manager, welches Zertifikat auf der Frontend-Website (Default Web Site) gebunden ist. BACKEND WEBSITE NICHT ANFASSEN!!!

Ihr habt Zertifikate vergessen - zumindest im öffentlichen Netzverkehr avancieren sie zum neuen DNS...

Ich würde die Frage nach "in Kürze neu aufsetzen" dringend klären, und wenn es auf 3-Monatssicht vorgesehen ist, das mit dem Upgrade sein lassen. Vielleicht kannst Du stattdessen ein paar längst überfällige Härtungsmaßnahmen dort vornehmen und so die Eintrittswahrscheinlichkeit der nicht mehr gepatchten Vulnerabilities verringern...

Der neue Server ist dann ja vermutlich auch 2022 oder zumindest 2019, hast Du länger Ruhe.

Vermutlich UEFI vs. BIOS?

...und vorher das hier noch kurz lesen: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/access-based-enumeration-abe-concepts-part-1-of-2/ba-p/400435

Moin,

hier z.B. von ManageEngine: https://www.manageengine.com/products/active-directory-audit/how-to/how-to-track-changes-in-active-directory-groups.html

Moin,

da Verteilern AD-Gruppen zugrunde liegen, ist es bei aktiviertem Audit Logging im AD möglich, festzustellen, welche Mitglieder wann welcher Gruppe hinzugefügt und welche wann entfernt wurden. Zurückrechnen aus dem aktuellen Stand muss man selbst. 

Bei dynamischen Verteilern ist es leider nicht möglich - es sei denn, man macht sich die Mühe, Änderungen an den Attributen, über welche der Filter definiert ist, aus dem Audit Logging zurückzuverfolgen...

Moin,

funktionieren denn auf den Cliens die Signaturen bei Dateien, die der Connection  Broker selbst signiert (also bei solchen, die Du aus RDWeb herunterlädst)? Und falls ja, was ist an diesen Dateien so falsch, dass Du eigene erzeugen und manuell signieren möchtest?

Moin 

für das Thema "zertifikatsbasierte Authentifizierung mit Microsoft-Produkten" musst Du dich in Windows Hello for Business einlesen.

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...