NilsK

Moin, die lokale SID führt nicht zu solchen Problemen. Die einzigen Probleme, die entstehen könnten, lägen in lokalen Berechtigungen. Es wären auch keine Probleme im AD zu erwarten. Was immer es ist, es ist was anderes. Gruß, Nils

Moin, klingt krude ... wenn tatsächlich ein Account dieser Klasse kompromittiert wird, wird ein Angreifer als erstes solche Überwachungsmechanismen abschalten. Das spricht nicht grundsätzlich dagegen, auf Basis der Security-Logs zu überwachen, aber eine Mail scheint mir kein geeignetes Mittel zu sein. Und versprechen würde ich mir davon keinen ernsthaften Sicherheitsgewinn. Vor allem vor dem Hintergrund, dass der typische Angriff auf Konten dieser Art ohne ein Logon-Ereignis bei einem DC auskommt, weil er Cached Credentials verwendet. Von da aus geht es dann z.B. mit Silver Tickets oder Golden Tickets weiter, und von denen bekommt eine Überwachung dann gar nichts mehr mit. Bevor ich also Energie in sowas stecken würde, würde ich auf anderen Ebenen Lücken schließen. Da wird es genügend geben. Gruß, Nils

Moin, abgesehen davon, dass wir hier komplett off-topic sind ... betreiben kann man uralte oder exotische Betriebssysteme auch in Hyper-V. Sie laufen dort halt nicht optimiert und werden nicht supported. Die Frage, warum man das machen wollen würde, können "die anderen" aber auch nicht beantworten. [Windows NT 4. 0 als VM in Hyper-V | faq-o-matic.net] https://www.faq-o-matic.net/2014/11/03/windows-nt-4-0-als-vm-in-hyper-v/ Und die "kleinste" VM, die ich mal in Hyper-V erzeugt hatte: 32 MB RAM keine HDD, zweiter Disk-Controller entfernt keine Netzwerkkarte Betriebssystem: FreeDOS (weil ich kein MS-DOS gefunden hatte) mit Word 5.5, gebootet von virtueller Floppy Lief im Rahmen der Möglichkeiten prima. Gruß, Nils

Moin, *lol* - ja, sowas kann passieren. Hier ein Artikel mit einem Überblick, wann Azure AD welches Attribut heranzieht. https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-userprincipalname Im Detail also durchaus komplex, daher tut man gut daran, vorher ein wenig zu planen. Gruß, Nils

Moin, ich kann jetzt kein Beispiel nennen, aber es gibt Anbieter von Sicherheitssoftware, die genau damit werben, dass man sie auf solchen Uralthobeln installieren kann. Gruß, Nils

Moin, nein, die Funktionsebene hat damit nichts bzw. wenig zu tun. Vielleicht meinst du das Schema - da merkt der Installer, dass er es erst aktualisieren muss. Sofern der ausführende User Schema-Admin ist, geschieht das dann im Hintergrund ohne weitere Aufforderung. Die Trennung, die es früher gab, hat sich als unnötige Vorsichtsmaßnahme erwiesen. Gruß, Nils

Moin, im Prinzip schon. Schritt 2 ist aber nicht mehr nötig, das macht die Installation des AD auf dem 2016 schon selbst. (Ich weiß aus dem Kopf auch nicht, ob es das ADPrep überhaupt noch gibt.) Nur vorsichtshalber: Falls Exchange 2010 in Betrieb ist, zuerst (vor der WS-2016-Installation) dort die aktuellen Updates einspielen. Das Update, das Exchange braucht, ist zwar schon älter, aber ich sehe es zu oft, dass es nicht vorhanden ist ... Gruß, Nils

Moin, der "beste" vielleicht ... aber auch da gibt es mehr Probleme, als man haben möchte. So richtig gar ist leider keine Lösung. Gruß, Nils

Moin, das kannst du von außen nicht steuern. Regedit prüft selbst, ob der User Admin ist. Wenn ja, fordert Regedit per UAC Adminrechte an, weil der User dann auch unter LocalMachine ändern darf, Ist der User aber gar kein Admin, dann startet Regedit ohne Änderungsmöglichkeit in LocalMachine. Ein User ohne Adminrechte müsste Regedit also ausdrücklich als Administrator starten, wenn er per UAC-Abfrage die Möglichkeit haben soll, ein Adminkonto anzugeben. Gruß, Nils

Moin, nein, das will man nicht. Jedenfalls nicht mit Bordmitteln. Das wäre eine hervorragende Möglichkeit, die Probleme unerträglich zu machen. Gruß, Nils

Moin, mag sein, aber ... Roaming Profiles auf Notebooks sind unpraktikabel und produzieren nur Probleme. Ändert das. Gruß, Nils

Moin, ich stelle an der Stelle immer die Frage: Braucht ihr denn überhaupt Roaming Profiles? Bei den meisten Kunden, die sich mit Problemen damit melden, stellt sich heraus, dass die User dort immer am selben Rechner arbeiten. Damit entfällt der Bedarf nach meiner Ansicht komplett. In dem Fall sollte man über Datensicherung nachdenken, aber nicht über servergespeicherte Profile. Gruß, Nils

Moin, heute vor 20 Jahren hat Microsoft seine interne Domäne auf Active Directory migriert. Das dürfte der erste produktive Einsatz der neuen Technik gewesen sein. [Active Directory wird 20: Herzlichen Glückwunsch! - michael wessel Blog] https://blog.michael-wessel.de/2019/04/09/active-directory-wird-20-herzlichen-glckwunsch/ Gruß, Nils

Moin, nein. Gruß, Nils

Moin, Auf einem DC dürfen sich nur Administratoren anmelden. Du musst der Gruppe also noch die interaktive Anmerkung auf den DCs gestatten. Gruß, Nils

Moin, in dem Fall solltest du deinen Filter erweitern können um die User-Eigenschaft. Die setzt sich ihrerseits aus zwei Einträgen zusammen. So in der Art: (&(objectClass=user)(objectCategory=person)(memberOf=CN=Signaturgruppe,OU=Pfad,DC=domain,DC=de)) Sollte es mit "memberOf" und der Verschachtelung doch nicht gehen, müsstest du die Abfrage um den Chain-Operator erweitern: (memberOf:1.2.840.113556.1.4.1941:=CN=Signatugruppe,OU=Pfad,DC=domain,DC=de) Gruß, Nils

Moin, lass uns mal richtig rum anfangen: Was soll am Ende erreicht werden? Gruß, Nils

Moin, wenn es bei der Installation eines der Programme Probleme gibt, dann solltest du die lösen, ggf. gemeinsam mit dessen Hersteller. Ein Betriebssystem-Upgrade hat viele Tücken. Bei einem Client kann das noch gutgehen, selbst da kann es aber problematisch sein. Bei einem Server sind solche Probleme eher zu erwarten, gerade bei einem Terminalserver, auf dem sich ja viel Anwendungssoftware befindet und der vor allem zahlreiche Usersessions ausführt und die zugehörigen Benutzerprofile hat. Daher rate ich nochmals von deinem Vorhaben ab, zumal du ja zwei Upgrades nacheinander machen müsstest. Bei Servern ist generell die Neuinstallation der Königsweg, bei Terminalservern noch mal mehr. Gruß, Nils

Moin, üblicherweise macht man bei Terminalservern keine Upgrades, sondern man richtet sie neu ein und stellt dann die Benutzer um. Gruß, Nils

Moin, ich stimme zu. Den physischen abschalten und dessen Netzwerkports mit Bauschaum ausfüllen. Dann das Computerkonto im AD zurücksetzen und den virtuellen SQL Server erneut aufnehmen. Gruß, Nils

Moin, du musst das Ergebnis hier auch nicht veröffentlichen. Du kannst mit der Auswertung aber prüfen, ob die Subnets vollständig und korrekt zugewiesen sind. Nur so kann dem Client der richtige AD-Standort zugeordnet werden. Wie gesagt, das müsste dann bei allen Domänen passend sein. Zusätzlich müssen in deinem Fall mit den vertrauten Domänen und der Verteilung von Clients und Usern allerdings die Namen der betreffenden Sites in den verschiedenen Domänen bzw. Forests gleich sein, damit die Zuordnung funktioniert - das meinte ich mit den komplexeren Details. [Domain Locator Across a Forest Trust | Ask the Directory Services Team] https://blogs.technet.microsoft.com/askds/2008/09/24/domain-locator-across-a-forest-trust/ Gruß, Nils

Moin, äh - wie Norbert schon andeutet, ist dieser Umstand (zwei Domänen) für die Frage natürlich alles andere als nebensächlich. In deinem Szenario müssten DCs beider Domänen an den Standorten vorhanden sein, an denen sich User anmelden. Und genauso müssten die Subnets auf beiden gepflegt sein. Da die domänenübergreifende Anmeldung noch eine ganze Ecke komplexer sein kann, kann es dabei dann aber durchaus passieren, dass die Anmeldung nicht wie gewünscht verläuft. Das zu analysieren und zu optimieren, wäre dann aber ggf. eine Sache, die man sich im Detail ansehen müsste. Gruß, Nils

Moin, welche Subnets sind denn konkret welchem der Standorte im AD zugewiesen? Du kannst dies mal mit diesem Tool auslesen: [Borg: AD-Standorte dokumentieren | faq-o-matic.net] https://www.faq-o-matic.net/2007/04/28/borg-ad-standorte-dokumentieren/ Jedes Subnet, in dem sich Clients befinden, muss eindeutig einem AD-Standort zugewiesen sein. Nur wenn das stimmt, kann das AD dem Client den passenden Logonserver nennen. Gruß, Nils

Moin, Shared Memory? In Hyper-V? Kann es sein, dass du da was durcheinander bringst? Gruß, Nils

Moin, ja, genau das meine ich. Danke für den Hinweis. Manchmal sollte man mit der Bewertung der Arbeit anderer einfach ein bisschen vorsichtiger sein ... Gruß, Nils