NilsK

Moin, Entschuldige, dass das so rüberkam. Ich wollte nichts mit "d**f" andeuten. Das war zu flapsig. Da hast du völlig Recht. Was ich meinte, ist der Punkt, dass es keine einfache Lösung gibt und du dir das sicher schon gedacht hast. Gruß, Nils

Moin, In Azure halt noch weniger günstig. Wenn jemand schon gesagt hat, dass ein Golf ihm zu teuer ist, kann man ihm ja noch einen Cayenne vorschlagen. Gruß, Nils

Moin, auf einer Kabarett-Bühne würde man jetzt sagen: "Merkste selber, ne?" Wenn es eine einfache und günstige Lösung gäbe, dann hättest du sie bereits. Es gibt aber keine. Es wird teuer, und es wird aufwändig. Das wird der Kunde akzeptieren müssen. Anderenfalls geht es nur so weiter wie jetzt, und das scheint ja nicht ausreichend zu sein. Für das, was wir hier von dem Szenario bislang wissen, dürfte einzig eine zentrale Datenhaltung mit ggf. dezentralem Zugriff in Frage kommen. Eine Synchronisation "möglichst in Echtzeit" (was vermutlich meint: ohne Verögerung; "Echtzeit" ist eigentlich was anderes) dürfte schon an den Datenmengen scheitern, die bei CAD zusammenkommen. CAD "per Citrix" wird nicht günstig, ist aber machbar. Gruß, Nils

Moin, Ich tute in dasselbe Horn. Hier nicht mehr selbst basteln, sondern sich kompetent beraten lassen und ein tragfähiges Konzept bauen. Das ist nicht kompliziert und nicht teuer, aber wenn man sich nicht genügend auskennt, kriegt man es nicht hin. Auch nicht mit Support aus einem Forum. Gruß, Nils

Moin, Die Frage ist aber noch offen, ob du überhaupt ein AD brauchen würdest. Um genauer zu antworten, fehlen uns Informationen, was denn die Anforderungen sind. Gruß, Nils

Moin, das war genau der Hintergrund meiner Frage. Sind wir uns ja mal einig. Gruß, Nils

Moin, Was soll denn der Server machen? Nur "Netzlaufwerke" anbieten, also als Dateiserver arbeiten? Oder noch was anderes? Gruß, Nils

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