NilsK

Moin, auch im Bereich der IT-Security solltest du die Anforderungen definieren, bevor du Maßnahmen evaluierst oder umsetzt. Vieles von dem, was du anführst, kann man durchaus machen (abgesehen von dem lokalen User). Kommt halt drauf an, warum man das macht und wie es in ein Gesamtkonzept eingebunden ist. Dass man zuhause "direkt im Internet sei", ist in aller Regel schon lang nicht mehr so. Auch Heimrouter haben einen okayen Firewallschutz, dazu kommt das, was Windows mitbringt. Wir sind nicht mehr im Jahr 2000. Und gegen moderne Bedrohungen für Clients hilft eine Unternehmensfirewall oft auch nicht viel, weil sowas eben heute völlig anders funktioniert. Am Ende eine Sache der Abwägung - man kann Maßnahmen aus meiner Sicht nicht bewerten, ohne das Szenario zu kennen. Gruß, Nils

Moin, vom Prinzip her relativ einfach: Du willst ja gar nicht wissen, ob die Tests bestanden sind, sondern nur die Fehler finden. Du könntest also nach den Zeichenketten suchen, mit denen in der Textdatei ein Fehler angezeigt wird (in Notepad suche ich immer nach "nicht" bzw. nach "failed", je nach Sprache). Edit: ja, Jan, du warst schneller. Wobei ich "passed" für uninteressant halte. ;) Noch ein Edit: Du kannst es auch noch einfacher haben und dcdiag gleich nur die Fehler ausgeben lassen ... Ist allerdings die Frage, ob das für eine automatisierte Auswertung ein sinnvoller Weg ist. Das AD gibt in aller Regel ganz gut über die Eventlogs Bescheid, wenn was nicht passt. Für ein Alerting ist das meist viel praktischer. Gruß, Nils

Moin, "von - bis". Ein lokaler User statt eines Domänenusers löst jedenfalls kein einziges Problem, schafft dafür aber viele neue. Warum würdest du das erwägen? Ein Notebook ist ein Mobilrechner, der ist ja dafür da, dass man ihn an verschiedenen Stellen betreibt, also auch in verschiedenen Netzwerken. "Einfangen" kann man sich beim "Rumsurfen" überall was. Moderne Malware kann im gesicherten Firmen-LAN genauso zuschlagen wie im Heim-WLAN. Die Risiken unterscheiden sich heute nicht mehr wesentlich. Wichtig ist, dass die wichtigen Assets eben auch gut geschützt sind. Da bin ich aber nicht der erste, der darauf hinweist. Ein "VPN-Zwang" wird das Risiko typischerweise nicht verringern, sondern erhöhen. Über ein VPN ist der Client an das Unternehmensnetzwerk angeschlossen, als wäre er direkt in der Firma. Hätte er sich also "was eingefangen", dann wäre es direkt im Firmennetz. "VPN" ist keine Sicherheitsmaßnahme, sondern nur ein Werkzeug für ganz bestimmte, eingegrenzte Szenarien. Um jetzt nicht ganz ohne Vorschlag dazustehen: Manche Firmen nutzen Notebooks im Home Office nur als "dumme Terminals", die Anwender greifen also per RDP/Citrix/... auf die Applikationen zu, die im Unternehmen laufen. Das ist schon vom Grundprinzip her i.d.R. deutlich "sicherer" als ein direkter Durchgriff. In dieser Allgemeinheit hat das jetzt das Potenzial, ein ausufernder Mega-Thread zu werden, der nichts Neues enthält. Wie wäre es, wenn du dich erst mal allgemein informierst und dann mit konkreten Fragen kommst? Gruß, Nils

Moin, Wenn du es nicht willst, dann lass es halt. Aber wenn du uns fragst, sagen wir eben unsere Meinung. Gruß, Nils

Moin, man könnte bzw. sollte in der Situation auch prüfen, ob eine Migration überhaupt sinnvoll ist oder ob man die bestehende CA auslaufen lässt und durch eine neue ersetzt. Je nachdem, wie "gut" das derzeitige Konstrukt entworfen, eingerichtet und gepflegt ist, kann der Neuaufbau durchaus sinnvoller sein. Das hängt allerdings von einer Reihe von Faktoren ab, die man in einem Forum nicht behandeln will. Wenn es tatsächlich nur um eine Migration "von Server zu Server" geht, ist das eigentlich ein simpler Vorgang, der bei Microsoft auch gut dokumentiert ist. Gruß, Nils

Moin, müssen wir am Ende technisch nicht diskutieren, ich weise nur aus organisatorischer Sicht auf meinen Kenntnisstand hin. Soweit ich weiß, ist es immer noch so, dass im Supportfall Microsoft als eine der ersten Maßnahmen anfordern würde, das Teaming abzuschalten. Und da das AD hervorragende Methoden für die Ausfallsicherheit hat, braucht man da ja die "generischen" Mittel gar nicht erst einzusetzen. Gruß, Nils

Moin, für Domänencontroller ist Teaming nicht empfohlen. Soweit ich weiß, gibt es sogar Supportausschlüsse, wenn es kein reines Failover-Teaming ist. Jedenfalls rät man allgemein davon auf DCs ab, weil man dort die Ausfallsicherheit eher über Server-Redundanz herstellt (also "mehr" DCs). Gruß, Nils

Moin, bestenfalls als Workaround. Aber eigentlich: das ist gar nicht gut. Selbst wenn du es zum Laufen bekommst (ich hab es lange nicht mehr probiert, kann durchaus sein, dass das nicht mehr oder nicht ohne Weiteres geht), verschiebst du das Problem ja nur in die Zukunft. In drei Jahren kommt der nächste Name dazu, dann noch einer ... das ist nicht nur organisatorisch ein Alptraum. Gruß, Nils

Moin, Ich wage zu bezweifeln, dass man mit solchen Mitteln was Stabiles hinbekommt. Weder Differencing Disks noch rsync sind für so ein Szenario gedacht. Gruß, Nils

Moin, Anscheinend aber nicht zu vergleichen mit dem Kram vom letzten Jahr. Gruß, Nils

Moin, sagen wir es mal so: Ich bin kein ausgewiesener Security-Spezialist, wurde aber im letzten Jahr zu mehreren Major-Incidents gerufen, bei denen es um eine vollständige Domänenübernahme ging. Darunter eine Uni und ein Glücksspielanbieter, nicht nur kleine Butzen. in *allen* Fällen war das Einfallstor bei schlecht gesicherten RDP-Servern gefunden worden. Gruß, Nils

Moin, möglicherweise bist du in einem Developer-Board besser mit deiner Frage aufgehoben. Hier sind hauptsächlich "Admins" unterwegs. Es gibt zwar auch Devs hier und Leute, die sich mit Softwareentwicklung auskennen, aber es ist eben kein Dev-Board. Gruß, Nils

Moin, keine Ahnung. Funktioniert es denn? Das wäre beim Scripting das entscheidende Kriterium. Wenn du das selbst zusammengebastelt hast, was willst du dann jetzt von uns dazu wissen? Gruß, Nils

Moin, doch. ADUC macht das, wenn man einen Homepfad bei einem neuen User einträgt, der erreichbar ist. Dort sind die ACLs dann aber vorgegeben, vermutlich hart codiert in ADUC. Gruß, Nils

Moin, habe ich es richtig verstanden, dass die Domäne "intern" heißt, also einen einteiligen DNS-Namen hat? Dann müsstest du doch öfter mal über Probleme dieser Art stolpern, oder? So eine Konfiguration ist zwar supported, aber nur "gerade noch so eben" ("commercially reasonable"). Die Empfehlung lautet, von einer solchen Konfiguration in eine korrekt benannte Umgebung zu migrieren. Es ist bekannt, dass es viele Produkte und Komponenten gibt, die mit einer Single-Label-Domäne nicht klarkommen. Das dürfte ja auch hier der Fall sein (ADAC nutzt eine andere Schnittstelle als ADUC). [Microsoft support for Single Label Domains - Windows Server | Microsoft Docs] https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/single-label-domains-support-policy Edit: Vielleicht habe ich den Screenshot auch falsch interpretiert. Du hast selbst ja "intern.xxxx.de" genannt, das wäre korrekt. In dem Fall bitte dies hier ignorieren. Gruß, Nils

Moin, man muss den Dienst SQL Server vor einem Neustart nicht separat beenden. Und wenn man es täte, würde dasselbe geschehen. Das sog. "Recovery" führt der SQL Server beim Start immer aus, weil er ja nicht weiß, ob der letzte Neustart koordiniert erfolgt ist oder nicht. Ich habe das hier ausführlich beschrieben: https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Es hätte also sehr wahrscheinlich ausgereicht, wenn du noch etwas gewartet hättest. Gruß, Nils

Moin, O weia. Ich rate entschieden davon ab, das so nachzubauen. Gruß, Nils

Moin, aber das sind doch zwei Paar Schuhe. Ich habe beantwortet, wie du vorgehen kannst, um die einmalige erste Kopie der Daten im neuen System einzurichten. Deine Frage zielt auf das Einrichten neuer Homes, darum ging es mir gar nicht. Was du beschreibst, ist im Prinzip durchaus möglich, aber das ist eben ein ganz anderes Thema. Und der Hinweis, dass man Userhomes nicht einzeln freigeben sollte, ist auch berechtigt, aber ebenso themenfern. Gruß, Nils

Moin, ja, so eine Problemlage tritt immer wieder auf. Man wird sich in solchen Fällen dann auch ansehen müssen, was denn wirklich passiert. Oft stellt man dabei fest, dass man sich in falscher Sicherheit wiegt, nur weil Zertifikate im Spiel sind. So ist es bei vielen Anwendungen so, dass zwar die "Erstanmeldung" ein Client-Zertifikat erfordert, der eigentliche Zugriff aber auf Basis eines Tokens geschieht, dass nach der Anmeldung ausgestellt wird. Solange dieses Token gültig ist, prüft niemand mehr das Zertifikat. Da kann man es dann sperren, so viel man will. So ist das z.B. bei den allermeisten Cloud-Services, die eine Zertifikatsanmeldung erlauben. Die Anbieter (z.B. Microsoft) dokumentieren das auch, man muss aber danach suchen. Auch die Möglichkeit, mit OCSP schneller auf Sperrungen zu reagieren (danke @cj_berlin für die Ergänzung), ändert daran nichts. Zudem ist bei OCSP immer zu berücksichtigen, dass der Client auf die Idee kommen muss, überhaupt nachzufragen, was dann in seinem Ermessen liegt. Und noch dazu wird für OCSP oft eine herkömmliche CRL als Fallback angeboten - ist OCSP also nicht erreichbar, nützt dessen Geschwindigkeitsvorteil auch wieder nix. Es bleibt also dabei: Wenn ein Zugriff schnell entzogen werden muss, muss man eine zertifikatsbasierte Zugriffssteuerung auf jeden Fall durch weitere Mechanismen ergänzen. Edit: Da in deinem Anwendungsfall auch noch eine andere Ebene durchscheint, auch dazu noch eine Anmerkung. Du sagst, dass ihr reagieren wollt, wenn jemand seine Smartcard verliert, aber nicht das Unternehmen verlässt. Hier wollt ihr euch absichern, dass nicht jemand anderes mit der gefundenen/gestohlenen Smartcard sich anmeldet. Hier wäre der korrekte Weg (neben dem Erfordernis, dass zu einer Smartcard auch ein zweiter Faktor wie eine PIN gehören sollte), das vorhandene, ggf. gesperrte Zertifikat von dem Useraccount zu trennen. Der legitime Benutzer braucht dann ja ohnehin eine neue Smartcard, also ein neues Zertifikat mit neuem Private Key. Auch hier würde dir eine schnellere Durchsetzung der Zertifikatssperrung nichts nutzen - diese kann ja erst erfolgen, wenn der Verlust bekannt ist, und sie muss manuell erfolgen. Da gehört es dann zum Prozess, das nicht mehr vertrauenswürdige Zertifikat vom Useraccount zu trennen. Auch dies hilft allerdings nur für Neuanmeldungen, nicht für bestehende Sitzungen. Letztere allerdings gehören auch nicht zu dem Szenario "Smartcard verloren". Wie sich hieraus ergibt, können Smartcards immer nur ein Baustein sein, aber keine ausreichende Lösung für ... irgendwas. Gruß, Nils PS: dies sind Details, die mich dazu bringen, PKI insgesamt als "krank" zu betrachten.

Moin, Das Sperren eines Zertifikats ist keine sofort wirksame Sache. Der Client wird erst dann eine neue CRL anfordern, wenn die alte abgelaufen ist. Solange nutzt er die letzte, die er im Cache hat, sie ist ja noch gültig. Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. Für zeitkritische Fälle braucht man also immer noch zusätzliche Mechanismen, muss also etwa den User sperren. Gruß, Nils

Moin, Dass ich das noch erleben darf! Gruß, Nils

Moin, in der aktuellen c't oder der Ausgabe davor war ein Artikel dazu. Da standen auch Verhaltenshinweise. Ob es materiell was bringt, da wäre ich zwar skeptisch, aber vielleicht ist es einen Blick wert. Gruß, Nils

Moin, wie wäre es mit: Die Daten ans Ziel kopieren danach (!) per Skript die Berechtigungen so setzen, wie sie sein sollen Dann scheiterst du nicht an Unwägbarkeiten, die durchaus auch mit dem Tool zusammenhängen können, das du zum Kopieren verwendest. Für den zweiten Schritt würde ich dann SetACL von Helge Klein nehmen. Gruß, Nils

Moin, prima, dann hätten wir ja schon bald die Hälfte der konkreten Angaben, nach denen wir gefragt haben. Nun bitte noch die Angaben des Clients und zu den konkreten Fehlermeldungen sowie dazu, was genau gemacht wird und was passiert. Gruß, Nils

Moin, hm, so könnte das etwas schwierig werden. Es kann gut sein, dass es nix Großes ist, aber bei der Art der Angaben dazu ist es vielleicht schneller, wenn du dir jemanden vor Ort kommen lässt. Soll kein Vorwurf sein, sondern ist ernst gemeint. "Der Server" ist der Domänencontroller? Was heißt dies genau: Was tun die Anwender, was passiert genau, welche Meldungen erscheinen an den PCs? Wie ist die DNS-Konfiguration der Clients, wie die "des Servers"? (jeweils ein ipconfig /all würde uns mehr sagen, bitte als Text bzw. Code hier posten) Gruß, Nils