NilsK

Moin, in solchen Fällen kann es tatsächlich ein Ausweg zu sein, die Authentifizierung über ein separates System zu steuern. Obacht aber, dann darf natürlich auch die SAML-Komponente nicht auf einem Windows-Server laufen ... Und: Eine der eingangs genannten Anforderungen war Einfachheit. In dem jetzt diskutierten Konstrukt hätte man aber mindestens zwei Authentisierungsquellen. Einfach wird das dann nicht mehr sein. Und da kommt dann eine Kostenbetrachtung ins Spiel, zumindest rate ich entschieden dazu. Gruß, Nils

Moin DocData, äh - merkste selber, ne? Gruß, Nils

Moin, Office 365 oder OneDrive sind keine Alternative? Damit könntest du einfach immer auf die aktuelle Fassung zugreifen, unabhängig vom Gerät. Gerade für MS-Office-Dateien ist das eine komfortable Lösung, wenn einsetzbar. Gruß, Nils

Moin, Äpfel und Birnen. Für die genannten Zwecke ist eine RAM-Disk schon sinnvoll. Gruß, Nils

Moin, das ganze Konstrukt ist unsinnig. Auch eine technische Lösung, wie sie dir vorschwebt, wird nicht mehr Verlässlichkeit bringen, denn wie du schon richtig sagst: Wenn ihr jemandem Adminrechte gebt, kann er seine Spuren verwischen, wenn er es drauf anlegt. Wenn ihr also bei dem "Notfall-Admin"-Verfahren bleibt, werdet ihr mit einer Unschärfe leben müssen. Das Problem liegt nicht in der Umsetzung, sondern in dem Verfahren selbst. Gruß, Nils

Moin, ich empfehle noch mal nachdrücklich, jemanden hinzuzuholen, der sich damit auskennt. Das Vorhaben ist umfangreicher, als du denkst. Und man kann durchaus so viel falsch machen, dass man sehr viel Arbeit hat, die Anwender am Arbeiten hindert oder Datenverluste und Sicherheitsprobleme erzeugt. Gruß, Nils

Moin, dann wäre es schön, wenn du künftig auf solche Umstände hinweist. Ist ja schon ein Unterschied, ob das produktiv-kritisch ist oder nicht. Wie Norbert auch schon andeutete (der eine, bestätigt vom anderen ), werden "Altlasten" oft überbewertet. So magisch ist das AD nun auch wieder nicht, dass man es nicht aufgeräumt oder repariert bekäme. Ein AD, das nicht ordentlich läuft, lässt sich so gut wie immer korrigieren. Das ist am Ende eine Frage des Aufwands. Um hier aber am richtigen Ende anzusetzen: Was genau heißt "Teststatus"? Ist das eine produktive Umgebung oder nicht? Wäre es evtl. effizienter, das AD neu einzurichten, weil es ohnehin nicht ernsthaft verwendet wird? Oder müsste man sich darauf konzentrieren, das Vorhandene geradezubiegen? Falls Letzteres, gehe ich stark davon aus, dass die Installation eines zweiten DCs in der Domäne die Stabilität des ADs herstellen würde. Dann könnte man den "alten" DC in Ruhe reparieren oder ersetzen. Es klingt für mich bis hierhin so, als läge auf der Maschine ein lokales Problem vor. Um das richtig einzuschätzen, könnte aber kompetente Unterstützung hilfreich sein, wie Norbert (der andere) auch vorschlägt. Gruß, Nils

Moin, der DC ist ja auch nicht überlastet. Einen überlasteten DC habe ich in 20 Jahren noch nie gesehen, auch nicht in Großunternehmen. Da ist was anderes im Busch. Einen weiteren DC empfehlen wir nicht wegen Leistungsgrenzen, sondern wegen der Redundanz. Wie du ja merkst, hängt ein Windows-Netzwerk von Active Directory ab, da ist es sehr hinderlich, wenn dieses nur auf einem Server läuft und dieser nicht richtig funktioniert. Die Ausgabe von dcdiag gibt leider nichts her. Im Eventlog müsste sich was finden lassen. Das Verhalten ist jedenfalls nicht normal. Gruß, Nils

Moin, ich gehe sogar noch weiter und sage: Der TO sollte über einen zweiten DC nachdenken. Ernsthaft: Bei 77 Usern ist ein DC viel zu wenig. Sobald es zweistellig wird, ist ein einzelner DC zu wenig. Warum, das siehst du ja jetzt. Die Logs, in denen sich sicher was findet, sind das System Log, das Application Log und unterhalb von "Dienst- und Anwendungsprotokolle" die Verzeichnisdienste (je nach Sprache auch "Directory Service"). Parallel kannst du in einem CMD-Fenster mit Adminrechten noch mal dies ausführen und uns sagen, welche Fehler dort gemeldet werden: dcdiag > C:\Pfad\dcdiag.txt Gruß, Nils

Moin, wie groß ist das Netzwerk? Wie du jetzt gerade siehst, kann ein einzelner DC zu wenig sein. Die Problemlage sollte sicher Spuren im Eventlog hinterlassen. Was sagt das denn dazu? Gruß, Nils

Moin, doch, es gibt solche Tools. Sind aber teuer, sehr teuer. Wir haben uns vor Jahren mal LinkFixer von LinkTek angesehen, es aber nie eingesetzt, weil die Kunden es nicht bezahlen wollten und es dann ganz magisch auch ohne ging. Gruß, Nils

Moin, auch diese Eigenschaft löst aber das Problem nicht, dass eine verschobene Datei (selbes Volume) ihren Zeitstempel behält. Es lässt sich an solchen Daten nun mal nicht zweifelsfrei ablesen, wann eine Datei in einem Ordner aufgetaucht ist. Gruß. Nils

Moin, https://en.wikipedia.org/wiki/List_of_RAM_drive_software Die Starwind-Software kenne ich nicht persönlich, aber zumindest ist der Hersteller seriös und leistungsfähig. Erfordert allerdings eine Registrierung. Gruß, Nils

Moin, die ActiveSync-Einbindung als solche lässt nicht zu, dass ein Admin der Firma an die privaten Daten des Telefons herankommt. Je nachdem, wie gut oder wie fehlerhaft die Einbindung auf dem Gerät softwareseitig gemacht ist, kann es aber passieren, dass ein RemoteWipe auch seine privaten Daten löscht. Sollte zwar heute eigentlich nicht mehr so sein, ist aber alles schon dagewesen. Gruß, Nils

Moin, hier bist du an einer Stelle, die sich mit einfachen Mitteln kaum sinnvoll lösen lässt. Man könnte jetzt darüber sinnieren, dass es einen Unterschied gibt, ob eine Datei an das Ziel kopiert wurde oder ob sie dorthin verschoben wurde (was hier vermutlich die Ursache ist). Danach wird man aber wahrscheinlich den nächsten Punkt finden. Die Mechanismen des "rohen" Dateisystems sind oft ungeeignet, um darauf Workflows von geschäftlicher Bedeutung abzubilden. Vielleicht ist hier ein grundsätzlich anderes Vorgehen empfehlenswert. Gruß, Nils

Moin, können wir bitte sachlich bleiben? Danke. Gruß, Nils

Moin, Das mit dem DHCP ist ... so mittelzuverlässig. Gruß, Nils

Moin, ein Skript, das das Konto und den DNS-Record löscht? Gruß, Nils

Moin, nein, wenn der Rechner nicht online ist, geschieht gar nichts. Einfach aus dem Grund, dass es der Client ist, der das Kennwort neu setzt. Ginge ja auch kaum anders. [Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Aktives Verzeichnis Blog] https://blogs.technet.microsoft.com/deds/2009/01/20/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht/ Gruß, Nils PS. ... ach ja, Fabian ... der war auch schon lange nicht mehr hier.

Moin, wobei sich der Prozess ja leicht so erweitern ließe, dass beim Löschen des Computerkontos auch der DNS-Eintrag ausdrücklich gelöscht wird. Intuitiv erschiene mir das logischer und sinnvoller als ein Workaround mit dem Wiederverwenden des Kontos. Die Client-Installation hat ja auch lokal eine andere Identität (lokaler SID). Am Ende akademisch, wie du schon sagst. Wichtig ist, dass man seine Prozesse im Griff hat. Gruß, Nils

Moin, ich verstehe ehrlich gesagt den Grund der Frage nicht, weil mir das Ziel der Vorgänge unklar ist. Warum würde man in dem Szenario überhaupt das Computerkonto weiterverwenden? Es geht doch um Clients? In wie vielen Gruppen werden die schon Mitglied sein? Und "ziehen" muss der Client die GPOs sowieso, er wurde ja neu installiert. Gruß, Nils

Moin, wenn du die Domäne löschst, werden auch deren Informationen aus dem Global Catalog entfernt. Dann dürfte der Spuk ein Ende haben. Gruß, Nils

Moin, wozu das Ganze? Brauchst du die CA als solche oder nur Zertifikate? Falls es um die CA geht, dann mach es lieber richtig und installiere eine Windows-Root-CA und eine Windows-Sub-CA. Das ist am besten dokumentiert und du kannst sicher sein, dass das Nötige im CSR und den Zertifikaten steht. Falls du nur Zertifikate brauchst, dann nimm selbstsignierte oder bau dir was Kleines mit OpenSSL oder so. Gruß, Nils

Moin, Weg damit. Die Root aufzuräumen, wird geringer Aufwand sein. Gruß, Nils

Moin, auf die Schnelle habe ich leider keine Lösung für das CRL-Problem. Aber ein wichtiger Hinweis: Für dein Szenario ist das Sperren des Zertifikats i.d.R. nicht der richtige Weg bzw. das reicht nicht aus. Da eine Sperrliste immer eine Laufzeit hat, wird das Sperren eines Zertifikats immer eine längere Verzögerung bedeuten. Möchtest du einen Zertifikatsinhaber schnell aussperren (was hier ja das Szenario zu sein scheint), musst du das primär auf anderem Wege tun, also meist das Zugangskonto selbst sperren. Nur so sorgst du für eine schnelle Wirkung. Zu der Fehlermeldung gibt es eine Reihe von Fundstellen im Web, geh die mal durch. Manchmal sind es simple Dinge wie ein falscher Authentifizierungsmodus auf dem Webserver. Gruß, Nils