NilsK

Moin, Ja, und eigentlich ging es nur um einen Hinweis, damit man sich hinterher nicht über seltsame Ergebnisse wundert. Rein technisch spricht nichts dagegen. Nur um das noch mal zu betonen. Gruß, Nils

Moin, Ich habe das bei verschiedenen Applikationen gesehen, die mit IdM-Hintergrund die Namens- und Adressdaten des AD auswerten und verwenden. Wenn die aus den USA kommen, nehmen die das Initial mit in den Namen einer Person auf, weil das dort üblich ist. Hier ist das völlig unüblich (und im ADUC-GUI auch noch falsch übersetzt), daher wundert man sich dann oft, was dabei rauskommt. Gruß, Nils

Moin, Die Frage ist ja auch, ob es vor dem Hintergrund, den Evgenij meint, einen Unterschied macht, ob man nach 120 oder nach 365 Tagen das Kennwort ändert. Soweit ich es verstehe, müsste man das dann schon in wesentlich geringeren Abständen tun, eher unterhalb von 24 Stunden. Also braucht man zusätzliche Sicherungen, denn das ist ja nicht praktikabel. Es zeigt eher, dass das ganze Kennwort-Ding M*st ist. Eine Lösung habe ich nicht dafür, aber der NTLM-Einwand zielt auf eine andere Ebene als das hier diskutiere Thema. Gruß, Nils

Moin, Ich möchte bei der Gelegenheit aber darauf hinweisen, dass man zwar durchaus "brachliegende" AD-Felder umnutzen kann, dabei aber Nebenwirkungen auftreten können. Das Feld "Initials" gehört zu denen, die hier und da von Anwendungen ausgewertet werden, daher würde ich da nicht "irgendwas" reinschreiben. Gruß, Nils

Moin, Bei solchen Performance-Fragen muss man auch schauen, ob es um sehr dicht gepackte Enterprise-Umgebungen geht - da können sich solche Effekte so summieren, dass man vielleicht Auswirkungen bemerkt - oder um eine "typische" mittelständische Umgebung, wo man normalerweise überdimensionierte Systeme hat (oder man hat altes Zeug, das ohnehin schon aus Löchern pfeift, aber dann kommt es auch nicht mehr darauf an). Es ist jedenfalls, wie du selbst schon sagst, unwahrscheinlich, dass das eine Einschränkung darstellt. Und wenn, dann wäre das kein Grund, auf die Sicherheit zu verzichten. Gruß, Nils

Moin, Haben denn deine Nachforschungen etwas ergeben? Wir müssen ja nicht nach einem Mauseloch suchen, wenn es die Maus gar nicht gibt. Vermutlich sollte man da noch etwas abwarten wegen der Feiertage. Wenn es etwas Naheliegendes gäbe, wäre es erfahrungsgemäß hier schon genannt worden. Gruß, Nils

Moin, Ah, sehr gut. Danke für die Rückmeldung! Gruß, Nils

Moin, Keine Ahnung, aber du schriebst von Sekunden, und das sollte man per Timing doch hinkriegen. Muss ich ja aber auch nicht lösen. Gruß, Nils

Moin, Ja, schon, aber der Witz bei den Quest-Tools ist ja gerade, dass sie das leisten, was man von den Bordmitteln erwartet, aber nicht bekommt. Da wundert es mich dann immer wieder, dass sie selbst solche Lücken lassen. Zumal es für Quest, wenn ich es richtig verstanden habe, recht einfach sein müsste, das Problem zu umschiffen. Das Timing verändern oder mit ein paar Zeilen Code den richtigen DC ausfindig machen, dürfte ja so schwer nicht sein. Gruß, Nils

Moin, Klingt plausibel. Also, eigentlich klingt das total beh*mmert, aber wenn man schon seit fast 25 Jahren Automatisierung von AD-Prozessen beobachtet, dann ist es eben plausibel. Nebenbei willst du uns aber sagen, dass das Quest-Tool diese Probleme nicht selbst behandelt, ja? Auch das würde ich in Verbindung mit dem Hersteller nicht zum ersten Mal hören. Was hatten wir vor 15 Jahren für einen Aufwand, hinter den Lücken im Migrator herzuscripten. (Aber das nur am Rande.) Danke für den Einblick. Gruß, Nils

Moin, Ich gehe davon aus, dass das nicht der Punkt ist, auf den ein Auditor sehr viel Zeit verwenden würde. Da gibt es für ihn anderswo mehr zu holen. Interessanter Punkt aber auf jeden Fall. Und guter Hinweis, dass die Angaben dort auch nicht eindeutig sind. Gruß, Nils

Moin, Hmm, so habe ich das noch nie gehört. Klingt fast wie eine Frage für den @lizenzdoc. Gruß, Nils

Moin, Dann bitte hier. Gruß, Nils

Moin, mangels eigenem Bedarf habe ich leider keine Lösung dafür. Aber vielleicht wäre ein zentralisiertes Log-Management eine bessere Lösung für euch? Das muss nicht automatisch riesige Summen kosten, ich habe sowas mal mit freien Tools für einen Kunden gebaut. Kommt halt auf die Anforderungen an. Gruß, Nils

Moin, generell schon, nur ist ein RODC eben aus gutem Grund eingeschränkt. Das ist ja das Prinzip eines RODC. Und deshalb fragte Evgenij, ob ihr denn wirklich einen solchen braucht. Dass ein RODC per se für mehr Sicherheit sorge, ist ein Missverständnis. Das tut er nur in einem sehr engen Feld von Anwendungsfällen (also genau genommen nur in einem). Was genau meinst du denn eigentlich mit: ? Gruß, Nils

Moin, direkt kann ich deine Frage nicht beantworten, aber: die Mitgliedschaft in der Gruppe "Event Log Readers" reicht nicht aus? Gruß, Nils

Moin, Interessant. Gruß, Nils

Moin, na, das liest man aber auch nur noch selten. Gruß, Nils

Moin, Beides lässt sich verbinden. Richte allen Usern Mailboxen in Exchange ein. Stelle dann das Mail-Routing um und verbinde die User. So ist der Empfang durchgehend möglich. Dann exportierte die alten Mailboxen und importiere sie in Exchange. Wahrscheinlich wird das sehr schnell gehen. Und wenn nicht, informierst du eben die User, die erst etwas später an der Reihe sind, dass es einen Tag länger braucht, bis sie ihre historischen Inhalte sehen. Gruß, Nils

Moin, Die Anzahl der Anwender und deren geografische Verteilung spricht für mich ebenfalls nicht gegen, sondern für eine Remote-Lösung. Genau wie Evgenij kenne ich Beispiele, in denen auch CAD über eine Citrix-Verbindung gut funktioniert hat - die richtige Ausstattung vorausgesetzt. Alles, was mit Replikation oder Datenbanken "im Internet" zu tun hat, will man nicht, weil es einem schneller auf die Füße fällt, als man "WTF?!" sagen kann. Gruß, Nils PS. ja, ein reiner "Finde-ich-auch"-Post, schien mir hier aber angebracht.

Moin, First things first - ich würde "etwas aus den Lot" erst mal bei den naheliegenden Dingen suchen. Updates, die nicht abgeschlossen sind. Virenscanner mit falscher Konfiguration. Kaputte Treiber. Software, die sich nicht benimmt. In der beschrieben Situation wird sich sicher im Event Log und im Process Monitor was finden. Es geht mir ja nicht darum, deine Erfahrung in Zweifel zu ziehen oder dich bloßzustellen - aber in kleinen und mittleren Umgebungen sind es typischerweise nun mal sehr "irdische" Probleme, mit denen man zu tun hat. Der Verdacht, dass "das AD" zu viel Last verursache, lässt sich so gut wie nie erhärten. Gruß, Nils

Moin, Ja, ich wusste auch, dass Martin sich nicht zurückhalten kann. Und dass wir ihn (bzw. alle anderen Lesenden dieses Threads) dann darauf hinweisen müssen, dass seine AD-Umgebung mit weitem Abstand ein Ausreißer ist. Martin weiß so gut wie wir, dass jemand, dessen Umgebung so groß ist, die hier diskutierten Fragen gar nicht stellen würde, weil er über Personal und Prozesse verfügt, die das unnötig machen. Anderen hier ist das möglicherweise nicht bewusst, daher weisen wir gern erneut darauf hin. Und natürlich weiß Martin auch, dass ein DC mit 16 GB auch in so einer großen Umgebung nicht derart langsam sein würde wie beschrieben, sodass der Kern meiner Aussage eben doch zutrifft. Auch hier sei das aber für alle anderen noch mal erwähnt. Gruß, Nils

Moin, Ein DC braucht weder viel RAM noch viel CPU. Wenn das also was lahm ist, dann ist das ein deutliches Zeichen, dass irgendwas aus dem Lot ist. Gruß, Nils

Moin, Evtl. falsche Einträge im DNS-Cache auf dem Server oder im Resolver-Cache auf dem Client. Außerdem machen, wenn ich es richtig verstanden habe, mache Browser die DNS-Auflösung selbst, da könnte es also auch falsche Daten im Cache geben. Gruß, Nils

Moin, dann würde ich darüber nachdenken, ihn abzuschaffen und durch Cloud-Dienste zu ersetzen. Gruß, Nils