NilsK

Moin, möglicherweise gibt es eins, aber die Beschreibung deiner Anforderung macht es nicht leicht, eines zu suchen. Daher musst du das dann wohl selbst tun. Vielleicht funktioniert das alte ADModify.NET noch: https://www.msxfaq.de/tools/mswin/admodifynet.htm Gruß, Nils

Moin, du sprichst von neuen Attributen, die du im AD-Schema definiert hast? Die kannst du z.B. per PowerShell befüllen wie jedes andere Attribut auch, indem du bei dem betreffenden Set-AD*-Cmdlet den Parameter -Replace angibst. https://devblogs.microsoft.com/scripting/powertip-set-custom-attributes-in-active-directory/ (in deinem Fall wäre es Set-ADComputer) Oder, wenn es per Batch gehen soll, nimmst du AdMod: https://joeware.org/freetools/tools/admod/index.htm Gruß, Nils

Moin, alles Gute, junger Mann! Gruß, Nils

Moin, für Standalone-Systeme wäre mir da nix bekannt. Öffne den lokalen Gruppenrichtlinien-Editor (gpedit.msc) und klick dich durch ... Vielleicht hilfreich: https://www.gruppenrichtlinien.de/de/artikel/gpeditmsc-multi-lokale-richtlinien-standalone-ohne-server-ohne-ad/ https://www.gruppenrichtlinien.de/de/artikel/domaenenrichtlinien-an-standalone-workgroup-client-nondomain-joined-uebergeben/ Gruß, Nils

Moin, rsop ist für Domänen-GPOs gedacht. Für lokale Richtlinien ist es daher nicht das richtige Tool. Gruß, Nils

Moin, was sagt denn net accounts in einem CMD-Fenster? Gruß, Nils

Moin, ja, das weiß ich natürlich. Ich wollte nur rumgeeken. Gruß, Nils

Moin, aber selbstverständlich. Zu der Zeit ging das mit Viren überhaupt erst los, und es gab noch kaum Gegenmittel. Daher können solche Rechner von uralter Schadsoftware befallen werden. Das wollen Kunden, die sowas einsetzen, nur nicht hören. Gruß, Nils

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