cj_berlin

Moin, wenn wir schon im Klugscheißer-Modus sind, besteht kein Widerspruch zwischen dem Begriff "Reverse Lookup-Zone" für die Zone und "DNS Reverse Pointer" für einen Eintrag in dieser Zone es heißt nicht "AD-Controller" und hat es auch nie, der korrekte Begriff ist "Domain Controller" es gibt kein "static DHCP", sondern lediglich "DHCP-Reservierungen" der Link, der vorgeblich auf den früheren Post verweisen sollte, führt ins Leere. Zur Sache jedoch: Wenn Du eine Konfiguration mit Netzwechsel LAN/WLAN (oder auch LAN1/LAN2) und stets aktuellen A- und PTR-Einträgen haben willst, muss der DHCP-Server für die DNS-Einträge zuständig sein, und zwar von Anfang an, praktisch noch vor dem Domänen-Beitritt. Sonst wird der Eintrag ggfls. nie aktualisiert (weil Rechte fehlen) und irgendwann per Scavenging bereinigt. Hier ist der epische, bis heute gültige Post von Ace Fekay (inzwischen nur noch in der Wayback Machine): https://web.archive.org/web/20110505054918/https://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

Das verrät Dir der Hersteller https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-FBECACED-E9E2-4DE5-A4D2-3587D90D2420.html

Ansonsten gibt es genügend Firmen, die sowohl vor als auch nach einem Vorfall helfen können - durch Konfigurationsanalyse, Prozessanpassungen, Tools. Ich hoffe, Du erwartest nicht wirklich, dass diese Art Beratungsleistung in einem kostenlosen offenen Forum erbracht werden kann. Von der Komplexität des Vorhabens mal abgesehen, Du brauchst für so etwas einen "trusted advisor", einen Sparring-Partner, und nicht einen Haufen Wissender und Halbwissender, die hier in ihrer Freizeit unterwegs sind.

Moin, sorry, wenn ich nicht den gesamten Roman gelesen habe und die Antwort da bereits enthalten war, aber eine solche Aktion ist bei vSphere in mindestens drei Logs enthalten, und in mindestens einem davon steht auch, wer sie ausgelöst hat, und mit etwas mehr analytischem Geschick kann man sogar eruieren, von welcher Quell-Adresse und mit welchem Client die dazugehörige Verbindung hergestellt worden ist...

Moin, ob's zu Problemen führt, kommt darauf an, ob - und wo - der Name benutzt wird Wenn Die Domain (und speziell der betroffene User) mit O365 synchronisiert ist, ist dann erst mal das OneDrive weg, kommt aber irgendwann wieder. Eventuell. Für reinen Windows-Betrieb ist es wurscht. Ob irgendeine Applikationen bei der ersten Anmeldung den UPN speichert und ihn dann erwartet, können wir nicht wissen. Tatsächlich sogar an der GUID, wie ich unlängst lernen durfte

Moin, meistens ist so etwas darauf zurückzuführen, dass die virtuelle Netzwerkkarte darunter sich soweit geändert hat, dass sie als neu erkannt wurde. Ist denn die gesamte Konfiguration (wie Du im Text schreibst) oder nur der Default Gateway (wie Du im Betreff schreibst) verloren gegangen?

Moin, das Standardwerk von Thomas Stensitzki umfasst 851 Seiten; Du wirst es uns nachsehen müssen, dass wir es hier nicht referieren. Wichtige Stichworte sind: Autodiscover DNS Resource Records Virtual Directories SAN-Zertifikate Das Standardwerk im Web ist MSXFAQ von Frank Carius, für TLDR-Admins wäre das Web eines anderen Frank wohl eher geeignet. Wenn Du konkrete Fragen hast, wird Dir hier gern geholfen

Das ist korrekt und wäre *vor der Maßnahme* auch mein Rat gewesen. Nun ist der Server aber schon gelaufen, und neben der aktualisierten Config im AD sind möglicherweise auch schon neue Elemente in den Datenbanken. Das Wiedereinschalten der Hyper-V-VM wird also möglicherweise auch nicht nur Regenbogen und Einhörner produzieren.

Schaut mal, ob der Converter die NICs ordentlich bereinigt hat (Stichwort devmgr_show_nonpresent_devices)

Da sage ich nur, iexpress,exe - der Klassiker seit Windows NT (gefühlt)

Moin, wenn Dein Postfach auf einem lokalen Exchange liegt, ist es das erwartete Verhalten.

Moin, das *ist* die Out-Of-The-Box-Konfiguration für Domain Member

Könnte es sein, dass die Verbindung über FQDN einfach per Kerberos abgesichert ist, und die Zertifikate keine Rolle spielen?

Sagt die Meldung beim Aufruf über IP, dass der Name nicht stimmt?

reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f würde für diesen Effekt sorgen

Ich kenne das mit Prinzipalen aus einem anderen Forest, die dort deaktiviert wurden, danach wieder aktiviert, seit der Aktivierung jedoch keine Verbindungen zu dem betrachteten Forest aufgenommen hatten. Aber auch nur vereinzelt.

Moin, entscheidend ist ja nicht, ob das Device AD-Mitglied ist oder nicht, sondern ob die User sich dort mit dem AD- oder mit dem Azure AD-Konto anmelden. Wenn das AD-Konto verwendet wird, ist das Kennwort immer eine Option. Vermutlich könnte man sie irgendwie tottreten, aber vermutlich wäre der Preis dafür auch der Verlust einer möglichen lokalen Anmeldung im Troubleshooting-Fall.

...aber nur mit dem Client/Agent, der auf jede Maschine drauf müsste, zumindest innerhalb eines IP-Segments. Zwei in unterschiedliche Zonen gesteckte NICs in einer Maschine sind das Gegenteil von Netztrennung, das ist Netzbrückung. Jeder Pentester kriegt bei sowas gleich feuchte Augen. Ich würde hier die Windows-Firewall ins Gespräch bringen wollen, und zwar ausgehend von der Annahme, dass die schützenswerten Dinge ein recht modernes Windows-OS haben und die Firewall somit gut funktioniert, also besser als auf XP Dann beschränkst Du mit Policies, wer MIT dieser Maschine kommunizieren darf und auf welchen Protokollen, also nur Inbound Rules. Damit ist es egal, ob in einem Segment oder über Segmentgrenzen hinweg.

Das musst Du aber nur Inboud setzen, nicht Outbound

Execution Policy ist *kein* Sicherheitsfeature. Es ist nur ein Anti-Schludrigkeitsfeature.

https://www.itxperience.net/en/recreating-the-public-folder-hierarchy-active-directory-with-adsiedit/ oder so - dies nicht als Anleitung, nur als Pointer...

Dann: gutes verifiziertes Backup ADSIEdit Beten

Dann lege mal eine neue PFMailbox an (die dann eine sekundäre Hierarchie kriegt) und sage Get-Mailbox -PublicFolder | Update-PublicFolderMailbox -InvokeSynchronizer

Moin, hast Du die öffentlichen Ordner von Exchange 2010 denn migriert?

Den Gateway-Eintrag gibt es aber nur in DHCPv4, nicht in DHCPv6. Daher sind die RAs auch so wichtig.