cj_berlin

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.

Das ist nicht korrekt. In der IPv6-Kommunikation spielt der Router immer eine Rolle.

Moin, machst Du stateless oder stateful DHCPv6? Und ist der Router auch derselben Meinung, sprich, schickt er in seinen RAs den O-Flag oder den M-Flag? Und welche Konfiguration in Bezug auf IPv6 hat der DNS-Server? Und wenn Du sagst, dass "Ping auf die IPv4-Adresse geht", meinst Du ping A.B.C.D oder ping -4 A.B.C.D ? (Und falls stateful, warum eigentlich?)

Erahnen wolh eher, denn die beiden IPCONFIG-Listings sind identisch. EDIT OK, doch nicht ganz. Dennoch: Was Du mit NSLOOKUP versuchst, ist ja nur Reverse Lookup, und auch das nur labherzig, denn Du stellst den Abfragetyp ja nicht auf PTR um. Reverse-Auflösung ist fast nie wirklich notwendig, Ausnahmen bestätigen durch ihre Seltenheit die Regel. Da bin ich bei Jan: Welches Problem versuchst Du zu lösen? Bedenke: NSLOOKUP ist nicht identisch mit Namensauflösung, sonst hieße es NAMERESOLVE.

Nicht mit einem Aufruf. Schleife oder Pipeline halt

Nein, das ist im Computer -Objekt nicht vermerkt. Falls Du allerdings Drucker im AD veröffentlichst, könntest Du von dort die Identität des jeweiligen Servers auslesen.

Moin, kommt darauf an, ob es "Merge Replication" ist oder "Transactional Replication": Replication backward compatibility - SQL Server | Microsoft Learn

Na *dafür* reicht Dir ein selbstsigniertes Zertifikat, wenn alle potentiellen Clients im AD sind und diesen in ihren Root Store per GPO reinbekommen.

DAS ist die wichtigste Frage. Beispiel, wann eine CA pro Site durchaus zu überlegen wäre: es wird 802.1X eingesetzt und die eingesetzten Zertifikate sind relativ kurzlebig WAN-Leitungen zwischen den Sites sind manchmal unterbrochen, und zwar so lange, dass die Downtime des WAN durchaus den Renewal-Zeitraum eines 802.1X-Zertifikats überschreiten kann (ich denke da an Schiffe, Ölbohrplattformen an Land oder im Wasser etc.) Sites sind soweit autark, dass auch ohne WAN irgendeine Art sinnvolles Arbeiten möglich ist. inklusive Authentifizierung. Aber in 99% aller typischen Fälle ist es nicht erforderlich und steigert nur den Verwaltungsaufwand unnötig. Wo man sich sehr wohl Gedanken über Verfügbarkeit und Erreichbarkeit machen sollte, ist die Validierung der Zertifikate, also CDP/OCSP.

Moin, meinst Du, Du willst ein Dual Boot-System mit einer TS bauen? Es ist nicht unmöglich, aber...

Gewiss. Aber Du hast noch kein Szenario. Du hast noch nicht einmal den gewünschten Endzustand formuliert, geschweige denn, dass wir den Ausgangszustand kennen würden. Microsoft beschreibt in Learn/Docs mehrere Migrations-Teilpfade, so beispielsweise auch die Profilmigration, die ich oben zitiert habe. Aber es sind immer einzelne Schritte. Diese richtig zu kombinieren - dafür braucht man eben ein "Szenario". Und nein, es gibt kein "One Size Fits All" best practice. Relativ einig ist sich die globale Community darin, dass ein Hybrid Join viele Probleme aufwirft, aber keinen wirklichen Nutzen bringt. Aber auch das ist nur ein Puzzle-Stück von vielen.

Durch welches Protokoll würdest Du dieses für lokale Accounts ersetzen wollen, wenn Du dir was wünschen könntest?

https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders oder USMT. Am besten, Du holst Dir jemanden an die Seite, der sowas schon mal gemacht hat, zumindest für ein Bainstorming. Du musst den gewünschten Endzustand formulieren und, wenn sich das irgendwie machen lässt, sollte dieser kein Active Directory mehr beinhalten. Aber das geht in einem freien, offenen Forum, wo leute in ihrer Freizeit helfen, einfach nicht.

Der Aufhänger war ja, dass sie für fremde-domain.de keinen Proof of Ownership beibringen können (weil Ownership nicht gegeben ist ).