-
Gesamte Inhalte
17.625 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von NilsK
-
-
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
-
1
-
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
-
1
-
-
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
-
1
-
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
-
2
-
-
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
-
1
-
-
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
-
1
-
-
Moin,
ZitatIPv4-Adresse . . . . . . . . . . : 10.0.0.1(Dupliziert)
der Server hat gemerkt, dass diese IP-Adresse bereits im Netzwerk verwendet wird und nutzt sie daher nicht.
Gruß, Nils
-
1
-
-
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:
EDIT: exchangekoala, du müsstest den Thread, den du zitierst, auch bitte ganz lesen.
Gruß, Nils
-
1
-
-
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,
ZitatWMI-Abfrage auf die SID und LocalAccount="True"
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,
vor 39 Minuten schrieb mwiederkehr:Und im schlimmsten aller Fälle ist der Host in kurzer Zeit neu installiert.
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
-
1
-
1
-
-
Moin,
mir gehts gut, danke. Mit SCCM hab ich nix tu tun, kann da also leider auch keine Tipps geben.
Gruß, Nils
-
Moin,
<OT>
vor einer Stunde schrieb Sunny61:Ich wei*ss*
genau betrachtet: ich weiß.
</OT>
Gruß, Nils
-
1
-
-
Moin,
laut Eingangspost sprechen wir von acht (!) Nutzern. Da finde ich die Betrachtungen, die hier angestellt werden, größtenteils völlig überzogen. Ich rate dazu, einen kompetenten Berater hinzuzuziehen, der Kosten und Nutzen in einen sinnvollen Zusammenhang stellt, indem er die richtigen Fragen stellt und Erfahrung mit so einem Kundenumfeld einbringt.
Gruß, Nils
-
2
-
-
Moin,
Nein, das ist ganz sicher nicht der Grund.
Und auch wenn der Chef was gegen Cloud hat - bei dem, was hier diskutiert wird, würde ich noch mal die Frage nach dem Aufwand stellen.
Gruß, Nils
-
Moin,
genau. Hat Dukel ja oben angegeben.
Gruß, Nils
Installation Exchange 2019 schlägt fehl
in MS Exchange Forum
Geschrieben
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