NilsK

Moin, das ist ein typischer Fall für: Bitte zurück an den Tisch und die Anforderungen wirklich im Detail herausarbeiten. So, wie es formuliert ist, ist die Aufgabe nicht lösbar. Mit "im Detail" meine ich: kein Unternehmen hat nur hochkritische Anwendungen. Der Fileserver, auf dem die IT ihre ISOs ablegt, muss nicht hochverfügbar sein. Was also ist wirklich kritisch? Und was heißt überhaupt kritisch? Das ist in keinem Unternehmen der Punkt "jetzt wird es unbequem", sondern es ist der Punkt "jetzt tritt ein Schaden ein, der das Unternehmen gefährdet". Viele überrascht es dabei, dass man z.B. für das Mailsystem fast immer feststellt, dass auch ein Ausfall von mehreren Stunden kein "echtes" Problem ist ... Gruß, Nils

Moin, es ist technisch auch nicht notwendig, den neuen DC vorher in die Domäne zu bringen. In dem Szenario mit getrennten Standorten/Netzen kann es aber helfen, dass man "vorher" schon sieht, ob es Probleme bei der Kommunikation mit der Domäne gibt (was hier ja der Fall zu sein scheint). Gruß, Nils

Moin, falls die "organisatorischen Gründe" auf die Struktur des Unternehmens zurückzuführen sind (und nicht auf die technischen Erfordernisse der IT-Administration), dann solltet ihr dies zum Anlass nehmen, nicht die Namen zu ändern, sondern gleich die ganze Struktur umzubauen. Das AD soll nicht das Organigramm abbilden, sondern es soll die IT-Administration unterstützen. Eine Struktur, die diesem Prinzip folgt, wird man so gut wie nie aus organisatorischen Gründen ändern müssen. Zu deiner eigentlichen Frage: Du könntest mit der Technik, die in folgendem Artikel am Anfang genannt wird, versuchen, die tatsächlichen Abfragen zu identifizieren, die an das AD gestellt werden. Ob das funktioniert, weiß ich nicht, aber es sieht aus, als wäre es einen Versuch wert. https://blogs.technet.microsoft.com/askpfeplat/2012/11/11/mcm-active-directory-indexing-for-the-masses/ Gruß, Nils

Moin, keine Ahnung - aber es ist zur Zeit einigermaßen aussichtslos, eine Webcam kaufen zu wollen. Wenn zufällig mal welche lieferbar sind, wirst du keine Auswahl haben, sondern musst nehmen, was kommt. "USB-Port oben am Monitor" klingt nebenbei auch nicht nach einem üblichen Ausstattungsmerkmal. Gruß, Nils

Moin, nein, das willst du nicht. USB-Platten sind nicht zuverlässig genug, um solche Konstrukte zu bauen. Ein Stripeset wäre da noch schlimmer als ein übergreifendes Volume, denn da hast du auf jeden Fall 100% Datenverlust, wenn nur eine der beiden Patten kaputt geht. Verabschiede dich bei Servern allgemein von USB-Platten für relevante Zwecke. Bei einem Server ist USB maximal zum Ad-hoc-Transport von Daten geeignet, auf die es weniger ankommt. Dein Konzept klingt auch etwas krude - erst USB, dann LTO? Gruß, Nils

Moin, Sperrkonflikte? Gruß, Nils

Moin, Warum sollte man das tun? Gruß, Nils

Moin, nein, er sagt doch, dass er das auf seiner Sophos eingerichtet hat. Die scheint das Routing zwischen den Segmenten zu machen. @kosta88 ich vermute das Problem eher bei PXE. Ich kann mir gut vorstellen, dass das in Kombination mit DHCP Relay nicht geht oder Probleme bereitet. Das ist ja ohnehin oft eine etwas haklige Technik. Gruß, Nils

Moin, und ansonsten ist das natürlich eine Frage, die du mit eurer Administration klären solltest. Oder bist du der Admin? Gruß, Nils

Moin, nimm es mir nicht übel, aber was du erzählst, erzeugt den Eindruck einer vergurkten Umgebung. Wäre ich du, ich setzte jetzt erst mal ein Projekt auf, um die geradezuziehen. Gruß, Nils

Moin, schön, dass es nun geklappt hat. Ich will ja jetzt nicht unken, aber wenn es eine Produktionsumgebung ist und man jetzt im Zuge der Problemsuche ganz viel "hier" und "dort" verstellt hat und es jetzt durch eine nicht näher bekannte Einstellung dann doch ging - dann spricht das nicht dafür, dass die Umgebung wirklich noch vertrauenswürdig ist. Dem wäre dann noch mal nachzugehen. Gruß, Nils

Moin, in dem anderen Thread, den ich nur überflogen habe, ist die Rede von "strengen GPOs". Je nachdem, was dort "streng" gesetzt wurde, kann man das Exchange-Setup damit natürlich schon arg behindern. Und es ist auch nicht gesagt, dass das Deaktivieren der GPOs daran ad hoc was ändert. Alles Weitere kann man jetzt leider nur glaskugeln. Ist das eine Produktionsumgebung? Gruß, Nils

Moin, ach ja, die langen Pfade ... bevor du dich da in etwas verrennst, was mehr Probleme erzeugt als löst: "Windows" kann schon seit frühen NT-Zeiten Pfade mit mehr als 260 Zeichen. Es dürften über 32.000 sein. Ein paar alte APIs können das aber nicht. Die schränken die maximale Pfadlänge auf 260 ein, wenn sie in Anwendungen genutzt werden. Irgendwelche Tricks, um "das Limit zu erhöhen", funktionieren nur, wenn im Hintergrund die Applikation, die man verwendet, damit klarkommt. Hat man Applikationen, die das nicht können, dann hat man sich selbst eine Falle gestellt. Die Pfade sind länger, funktionieren aber nur mit "manchen" Applikationen. Das Problem verschärft sich, wenn noch andere Systeme mit ihren API-Beschränkungen ins Spiel kommen. Etwa SharePoint und OneDrive. Gruß, Nils

Moin, naja, dann ... baut euch eine Authentisierungsfunktion, die auf Open ID Connect beruht. Oder eine mit SAML, die dann die Drittsoftware über OAuth anspricht. Gruß, Nils

Moin, korrekt, das Sperren und Entsperren geht nur "im Paket" über das Attribut userAccountControl. Das bedeutet, dass auch andere Kontenattribute gesetzt werden können. Das Verschieben erfordert Löschrechte in der Quell-OU und Schreibrechte in der Ziel-OU. Wichtig: Um sowas zu entwickeln, braucht man ein separates (!) AD, in dem man testen kann, ohne die Produktion zu beeinträchtigen. Und man macht sowas nicht per GUI, sondern per Skript. Ich zitiere mich mal selbst dazu: Gruß, Nils

Moin, am saubersten baust du das, indem du eine Gruppe (domänenlokal) dafür anlegst identifizierst, in welchen OUs die Konten liegen, um die es geht der Gruppe im AD genau die Berechtigungen auf die OU bzw. OUs gibst, die sie zur Bearbeitung braucht das Task-Konto (das nur für diese Aufgabe verwendet werden sollte) in die Gruppe aufnimmst den Task NICHT direkt auf einem DC erzeugst, sondern auf einem separaten Management-Rechner den Ordner, in dem das Skript liegt, per Berechtigung so absicherst, dass das Task-Konto das Skript lesen kann und nur berechtigte Admins es ändern können per GPO verhinderst, dass das Task-Konto sich irgendwo anders anmelden kann Gruß, Nils

Moin, typischerweise wirst du sowas nicht hinbekommen, ohne beide Seiten - also beide Applikationshersteller - ins Boot zu holen. Vielleicht gibt es da schon Schnittstellen, die du nutzen kannst. Vielleicht müsste da aber auch erst was implementiert werden. Keine der modernen Auth*-Techniken bekommst du von außen nachträglich angekorkt, wenn das in den Applikationen nicht vorgesehen ist. Ein Applikationshersteller sollte dich dabei unterstützen können, jedenfalls so weit, dass ein kundiger Dritter dir dabei helfen kann. Es kann nicht deine Aufgabe als Kunde sein, das alles selbst zu entwickeln. Wer hat denn die bisherige Authentisierung des "Extranets" gebaut und auf welcher Technik beruht das? Gruß, Nils

Moin, OAuth ist, wie du schon richtig sagst, ein Protokoll zur Autorisierung, nicht zur Authentifizierung. Es dient also dazu, bereits "angemeldeten" Identitäten den Zugriff auf zusätzliche Ressourcen zu gewähren: Ein Facebook-User könnte so seine eigenen Tweets nach Facebook übernehmen. Die Session, die Norbert meint, ist diese: [Woher kennt mich die Cloud? Die Folien | faq-o-matic.net] https://www.faq-o-matic.net/2017/11/29/woher-kennt-mich-die-cloud-die-folien/ Tatsächlich wird OAuth bisweilen auch zur Authentifizierung verwendet, man kann das so hinbiegen (ich habe mich mit dem Teil selbst noch nicht beschäftigt). Die Hüter des Standards raten selbst aber davon ab: [End User Authentication with OAuth 2.0 — OAuth] https://oauth.net/articles/authentication/ Die Empfehlung lautet in solchen Fällen daher, auf OpenID Connect zu setzen. Aus Erfahrung rate ich dir, dazu intensiv mit deinem Anbieter zu sprechen. Ich erlebe es allzu oft, dass ein Applikationsanbieter kaum Kenntnisse von der Technik hat und dadurch am Ende ziemlichen Murks implementiert ... Gruß, Nils

Moin, wow, ich bin begeistert, was ihr so alles aus meiner Metapher rausholt. Ein Aspekt sei hier noch erwähnt: Die vier Züge haben nur dann einen Vorteil, wenn es auch vier "Netzwerk-Streams" gibt. Das ist auf einem VM-Host zwar oft, aber eben auch nicht immer gegeben. Wenn eine VM genau eine Netzwerkverbindung zu einem anderen Rechner hat, dann wird diese auch durch noch so viele zusätzliche Karten in einem Team nicht schneller. Gruß, Nils

Moin, hm, hab ich irgendwie vorgeschlagen, oder? Naja, gut, dass es jetzt geht. Und danke für die Rückmeldung. Gruß, Nils

Moin, also, ich würde mit csvde.exe die relevanten Userdaten in eine CSV-Datei exportieren und die dann mit Excel auswerten. Gruß, Nils

Moin, es lässt sich aus der Ferne kaum einschätzen, was da quer hängt. Da der Netzwerkstack bei Installation von Hyper-V kräftig durchgerüttelt wird, ist es vermutlich am sinnvollsten, den Host einmal sauber neu zu installieren und große Sorgfalt auf das Einrichten der Netzwerkeinstellung zu legen. Da macht man gerade als Anfänger oft was verkehrt, weil die Sache leider etwas unübersichtlich ist. Gruß, Nils

Moin, der Server hat gemerkt, dass diese IP-Adresse bereits im Netzwerk verwendet wird und nutzt sie daher nicht. Gruß, Nils

Moin, ein RODC würde in dem Szenario doch gar keinen Sicherheitsvorteil ergeben. Die User melden sich, wie du sagst, per VPN an. Das VPN ist also deine Sicherheitsgrenze. Ab da sind die User im Netzwerk. Ob sie also auf einen RODC oder einen echten DC zugreifen, macht keinen Unterschied. Danach greifen sie ja ohnehin vermutlich auf "alle" Ressourcen zu. RODCs wurden ursprünglich für genau einen Zweck entworfen: kleine Niederlassungen, die physisch nicht ausreichend gesichert sind, aber einen lokalen DC haben sollen. Der RODC steht dann also physisch in dieser Niederlassung. Wenn dort der DC gestohlen wird, soll nicht gleich das ganze Unternehmen kompromittiert sein. Außerhalb dieses einen Szenarios gibt es - nach meiner Ansicht - keinen sinnvollen Einsatzzweck für einen RODC. Verschiedentlich wird ein RODC für andere Zwecke in Konzepten genannt, aber wenn man sich das genauer ansieht, passt es eigentlich nie. Es gibt keinen Sicherheitsvorteil, es werden praxisferne Annahmen getroffen oder jemand hat das einfach nicht verstanden. Kein Angriff beabsichtigt, nur die Darstellung der Dinge aus meiner Sicht. Gruß, Nils

Moin, ich halte einen RODC fast nie für sinnvoll. Genau betrachtet, habe ich noch nicht ein einziges Mal ein Szenario beschrieben bekommen, in dem ich einen RODC für passend gehalten hätte. Warum würdest du denn meinen, sowas zu brauchen? Gruß, Nils