NilsK

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

Moin, Computerkennwörter laufen nicht einfach ab. Wenn der Wechsel eines Computerkennworts ansteht, dann ist es der Client, der dies auslöst und durchführt, nicht der DC. Ist also ein Client lange Zeit ohne direkten Kontakt zur Domäne, dann steht er nicht plötzlich vor einem abgelaufenen Konto. Ich zitiere den guten Fabian, von dem ich schon zu lange nichts mehr gehört habe: [Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Microsoft Docs] https://docs.microsoft.com/de-de/archive/blogs/deds/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht EDIT: exchangekoala, du müsstest den Thread, den du zitierst, auch bitte ganz lesen. Gruß, Nils

Moin, könntest du bitte erst mal das Problem erklären, um das es eigentlich geht? Du hast hier bislang nur die Probleme eines Lösungswegs beschrieben. Gruß, Nils

Moin, genau diese Sorte Abfrage war früher (als ich in anderem Zusammenhang damit arbeitete) immer sehr langsam bzw. hat eine Verzögerung im zweistelligen Sekundenbereich verursacht. Ist das jetzt besser bzw. tritt das in dem Anwendungsfall nicht auf? Gruß, Nils

Moin, zumal es in der Praxis ausgesprochen wahrscheinlich ist, dass man eine andere Hardware als Ersatz hat. Dann bringt einem das Host-Restore nicht viel außer mehr Aufwand. Gruß, Nils

Moin, mir gehts gut, danke. Mit SCCM hab ich nix tu tun, kann da also leider auch keine Tipps geben. Gruß, Nils