NilsK

Moin, ob man Elemente im PDF einzeln bearbeiten, exportieren usw. kann, hängt davon ab, wie das PDF erzeugt wurde. Wenn es keine einzelnen Elemente erzeugt, kann man eben keine nutzen. Gruß, Nils

Moin, es gibt keinen technischen Zwang, das DNS ins AD zu integrieren. Es ist aber sehr zu empfehlen. In dem Fall läuft DNS dann nur auf den DCs. Man kriegt alles Nötige auch mit separaten DNS-Servern hin, es ist dann aber aufwändiger (und ggf. weniger sicher). Und Vorteile gibt es keine. Wenn man ein separates DNS benötigt, sollte man dafür ein übergreifendes Design erzeugen. Gruß, Nils

Moin, aha. Das bringt etwas, wenn auch nicht viel Licht in die Sache. Allgemein vorweg: Ich halte es für sinnvoll, wenn ihr euer Vorhaben von jemandem begleiten lasst, der die Mechanismen des AD kennt. Sonst lauft ihr ziemlich wahrscheinlich in eine ungünstige Richtung. Auch wäre es wahrscheinlich sinnvoll, wenn ihr euch noch ausführlicher mit den Security-Grundlagen von Windows und AD befasst, da ist vieles anders als in der *x-Welt. Zu deiner Frage: Wenn ihr personalisierte Admin-Accounts haben wollt, reicht die Mitgliedschaft in den betreffenden Gruppen aus. Es gibt keine "versteckten" Attribute oder sowas. Einzige Ausnahme ist der vordefinierte Administrator (das ist der mit der RID -500), für den ein paar "hardcodierte" Ausnahmen gelten, damit er auch im Notfall noch Zugriff hat, Diesen Account verwendet man genau aus diesem Grund auch nicht für die tägliche Arbeit, sondern nur für Notfälle. Diese Ausnahmen sind aber nicht misszuverstehen als "Gott-Modus" - es gibt nichts, was der -500-Administrator kann, was man nicht mit anderen Admin-Accounts auch erreichen könnte, wenn diese die nötigen Berechtigungen haben. Genau an der Stelle fängt dann die Planung an. Windows selbst nutzt weder UID noch GID. Wenn es dort also Unterschiede bei euren Objekten gibt, dann habt ihr die selbst mit eurer Datenübertragung hergestellt. Für Windows und das AD sind diese Unterschiede aber ohne Belang. Gruß, Nils

Moin, "gidnumber" deutet auf eine Linux-/Unix-Integration hin. Vielleicht kann @marhal mal genauer beschreiben, was eigentlich die Anforderung und die Umgebung ist. Gruß, Nils

Moin, ich orakel mal: Der TO hat ein AD mit einem oder mehreren DCs unter Windows Server 2016 Diese DCs haben nicht die DNS-Rolle installiert Er hat einen separaten Server, auf dem die DNS-Rolle installiert ist, der aber kein DC ist. Auf diesem DNS-Server gibt es eine oder mehrere DNS-Zonen. Er hat diesen DNS-Server in die Domäne aufgenommen Nun fragt er, ob DNS dadurch automatisch ins AD integriert ist Falls diese Vermutungen zutreffen, ist die Antwort: Nein. Kann aber auch ganz anders sein. In diesem Fall möge @decehakan bitte genau beschreiben, was er wissen möchte. Gruß, Nils

Moin, im Zweifel baut man ein Frontend und lässt den Kram über die PowerShell erledigen. Da würde ich mal mit meinem Entwicklungsleiter sprechen - aber wie gesagt, versprechen kann ich nix. "Alles was das alte kann" ist mir zu generisch, ich will nicht erst forschen müssen. Biitte beschreiben, was für Funktionen ihr konkret braucht - gern auch schon unterteilt in "must have" und "nice to have". Gruß, Nils

Moin, man könnte da ja mal was bauen ... ich kann nichts versprechen, aber das wäre vielleicht ein interessantes Übungsprojekt. Was sollte so ein Web-Interface denn können? Gruß, Nils

Moin, was heißt "sind integriert"? Was heißt das? Wohin "gehen" die? Ich halte das nicht für zielführend. Gruß, Nils

Moin, mir fiele dazu ein: Der Anmeldeversuch kommt von außen. Vielleicht also ein Mobilgerät mit falscher/zwischengespeicherter Anmeldung. Oder was auch immer bei euch über das Gateway geht. Falls es, wie du schilderst, nur um wenige Konten geht, spricht das gegen einen Angriffsversuch, da wäre eher zu erwarten, dass zahlreiche Konten durchprobiert werden. Gruß, Nils

Moin, genau wie Rolf bleibe ich dabei, dass Gruppen hier sinnvoller sind. Eine solche Informationsfülle, wie du sie in AD-Attributen ablegen willst, ist in der Praxis kaum beherrschbar und sehr schlecht zu verwalten (wie du ja merkst). Zudem gibt es im Standardschema bereits das Attribut "location" bei Computerobjekten, also würde ich mir gut überlegen, ob ich wirklich das AD-Schema für sowas erweitere. Gruß, Nils

Moin, alle DCs in einer AD-Domäne sind gleichberechtigt. Dass der "zweite" DC die Ereignisse zur Sperrung anzeigt, liegt einfach daran, dass er "zufällig" (vereinfacht gesagt) die Anmeldeversuche bearbeitet hat. Solche Ereignisse finden immer nur auf einem der DCs statt und werden nur dort protokolliert. Einen ursächlichen Zusammenhang zwischen dem konkreten DC und der Sperrung gibt es nicht. Wenn der protokollierende DC feststellen kann, von welchem Endgerät der Anmeldeversuch kommt, sollte sich dies in den Ereignisdetails finden. Je nach Netzwerkaufbau kann es durchaus aufwändig sein, die Ursache genau herauszufinden. Es ist aber kaum anzunehmen, dass etwas anderes dahintersteckt. Natürlich kann es sich auch um automatisierte Angriffsversuche handeln, aber auch das wäre eher untypisch. Fast immer ist es was "Simples". Nebenbei bemerkt, sollten alle DCs natürlich auch gleichartig konfiguriert sein, sprich, der zweite sollte auch DNS ausführen und in der Konfiguration aller Clients als DNS-Server mit angegeben sein. Sonst gibt es keine Ausfallsicherheit. Gruß, Nils

Moin, erstens gibt es keinen "Backup-DC", wie Norbert schon richtig sagt. Zweitens: Was heißt "von welchem wohl die ganze Sperrung auszugehen scheint"? Und was genau heißt Wieso "im Prinzip"? Gibt es also noch mehr als die zwei? Gibt es neben der "Hauptdomäne" noch weitere? Kontensperrungen resultieren aus falschen Anmeldungen. In praktisch allen Fällen liegt das daran, dass irgendwo was läuft, was ein falsches Kennwort gespeichert hat: Dienste, Tasks, Mobilgeräte ... Gruß, Nils

Moin, Für einmalige Vorgänge ist csvde oft prima. Als Teil wiederholter Prozesse ist es u.a. deshalb schwierig, weil es die Felder in nicht vorhersehbarer Reihenfolge ausgibt. Man muss dann jedes Mal neu schauen, an welcher Stelle das gewünschte Attribut steht. Aber zu den genaueren Anforderungen will der TO ja leider nichts sagen. Daher bleibt auch nur meine Vermutung, dass es mit Gruppen viel einfacher ginge. (Falls ich das noch nicht erwähnte.) Gruß, Nils

Moin, gern. Aber schau dir auch das Tool an, das Norbert empfiehlt. Könnte durchaus noch besser sein. Und für's nächste Mal: Gib bitte immer gleich an, was du genau vorhast. Dann kann man dir besser helfen. Der Weg mit den Attributen scheint mir unnötig komplex. Gruß, Nils

Moin, menno. Ich probier jetzt trotzdem weiter, ob ADModify noch funktioniert. EDIT: ... was hiermit nachgewiesen ist. Mit dem obigen Verfahren kann man ADModify.net lauffähig herunterladen und ausführen. Auf neueren Windows-Versionen muss man ggf. noch die .NET-3.x-Features aktivieren. Dann geht's. Gruß, Nils

Moin, ich hab grad noch mal rumprobiert. Der Download, den man bei Microsoft findet, enthält doch die ausführbare Version. Die scheint auch zu funktionieren (zumindest startet sie unter Windows 10). Lade dir das Archiv herunter: https://archive.codeplex.com/?p=admodify Entpacke es in einen Ordner. Im Ordner "Releases" enthält der Unterordner "1" die letzte Version. Beide Dateien, die dort liegen, benennst du um, sodass sie ".zip" als Extension tragen. Den Unterschied zwischen beiden Fassungen kann ich auf die Schnelle nicht ausmachen. Starten kann man beide. EDIT: Die Fassung in dem Zip, das mit 035... anfängt, scheint aktueller zu sein. Also eins der Zips entpacken, dort kannst du dann die Admodify.exe starten. Das Tool ist sehr leistungsfähig, du kannst dort ein Set an Objekten mit einem LDAP-Filter auswählen, die gewünschten Änderungen per GUI vornehmen und es dann loslaufen lassen. Jede Änderung landet in einer Undo-Datei, sodass man sie auch wieder rückgängig machen kann. Anleitungen zu dem Tool findest du noch zahlreich im Web, z.B. hier: [Massenänderungen mit ADModify | faq-o-matic.net] https://www.faq-o-matic.net/2005/10/01/massenaenderungen-mit-admodify/ Ganz abgesehen davon, dürften aber normale Gruppen für dein Vorhaben viel leichter zu handhaben sein als selbstgebaute Attribute ... Gruß, Nils

Moin, musst du vielleicht auch ... wie ich gerade feststelle, gibt es das Tool wohl nicht mehr zum Download. Es gibt nur noch den Quellcode, das müsste man dann selbst kompilieren. Gruß, Nils

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