NilsK

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

Moin, öh - ich fürchte, mit diesen Hinweisen kann der TO nichts anfangen. Ich wüsste jedenfalls nicht, was dcdiag hier leisten könnte und wozu genau ich was geschrieben haben sollte. @emw leider sind die Angaben etwas spärlich. Es ist auch kaum zu verstehen, wer nun das Problem hat, von wo die Ereignismeldungen stammen und was die Aufgabe des Servers ist. Hier müsstest du bitte noch mal genauer erklären, was Sache ist. Alternativ bliebe nur der Hinweis, dass du die DNS-Einstellungen kontrollieren solltest. Genauer geht es auf der jetzigen Grundlage leider nicht. Gruß, Nils

Moin, Siemens S35i. Das blöde Ding, das nach dem Wählen immer noch mal mit voller Lautstärke piepte. Aber erst nach ein paar Sekunden, damit man es garantiert schon am Ohr hatte. Gruß, Nils ... aber mit WAP, das war die Innovation damals. Hat niemand mehr als zweimal ausprobiert.

Moin, auch wenn es ein Laberthread ist - ein gewisses Niveau sollten wir nicht unterschreiten. Es geht nicht um "zu b***d um zu schauen", sondern darum, dass man gerade als Sehender nicht mit fast geräuschlosen Autos rechnet. Fassen wir uns doch alle mal an die eigene Nase - im Alltag gibt es enorm viel, womit der Geist sich beschäftigt. Natürlich ist man da abgelenkt und natürlich kann es schnell zum Problem werden, wenn man ein Auto nicht bemerkt, mit dem eine Kollision fatale Folgen haben kann. Das hat doch nichts mit "b***d" zu tun. Gerade im Verkehr haben wir zu oft das Phänomen, dass jeder den anderen als unfähig ansieht und sich selbst als den einzigen Hort der Vernunft. Das funktioniert unabhängig vom Verkehrsmittel - ein Autofahrer, der aufs Fahrrad umsteigt, ist dort schnell der einzige, der was vom Radfahren versteht. In Bremen gab es vor Kurzem eine Kampagne für "mal bitte runterkühlen", die hülfe allgemein mal. Gruß, Nils

Moin, <OT>sehr erfreulich, Ella aus meiner Liste hier zu treffen.</OT> Gruß, Nils

Moin, Lassen wir diesen Thread doch bitte Off-Topic. Für die Frage gibt es ja schon einen eigenen. Gruß, Nils

Moin, "Chef, das Jahr 1996 ist am Telefon. Es will seine Administration zurück." Gruß, Nils

Moin, danke für die Rückmeldung. Wenn es um Standardisierung geht, wäre Norberts Vorschlag aber trotzdem einen Blick wert. Gruß, Nils

Moin, vor allem scheint mir das zu kurz gedacht und allgemein noch zu wenig ausgearbeitet. Was willst du mit welchem Ziel trennen? Was willst du erreichen? Was heißt Berücksichtigen kann viel heißen. Was ist da gemeint? Eine Subdomain erschwert die Verwaltung, erhöht aber nicht die Sicherheit. Wer soll das hinterher verwalten? Hat jemand geklärt, ob der Einsatz von M365 überhaupt zulässig ist? Wenn ja, wie ist der Abgleich gedacht - es ist ja kaum anzunehmen, dass für alle Schüler*innen die Einwilligung der Eltern vorliegt? Gruß, Nils

Moin, wenn die Zeitskala stimmt, müssen es wohl MB gewesen sein. Ungefähr zu der Zeit habe ich mir einen Rechner mit 64 MB gekauft, der von meinem Chef als "Rennwagen" bezeichnet wurde. Gruß, Nils

Moin, ach je. Also noch eine weitere Ebene. Die hat mit dem Fehler, den Thomas oben genannt hat, aber anscheinend nix zu tun. Ich seh schon: Meine Behauptung oben war doch etwas kühn. Gruß, Nils

Moin, Hm, dann klingt das, als sei bei dem Vorgang ein Fehler aufgetreten. Die Wahrscheinlichkeit, dass sowas passiert, erhöht sich natürlich, je häufiger man das durchführt. Insofern könnte man schon von "zu häufig Sysprep" sprechen. Worauf ich hinaus will, ist eine häufig falsche Vorstellung davon, was Sysprep eigentlich macht. Das ist nichts, was ein Windows irgendwie abnutzen würde oder so. Solche Vorstellungen gibt es durchaus, ähnlich wie falsche Vorstellungen von der Registry und sogenannten Cleanern. Gruß, Nils

Moin, "Zu oft Sysprep" ist ein Mythos. Wenn eine Software damit nicht klarkommt, dann ist es kein Unterschied, ob Sysprep einmal oder mehrfach gelaufen ist. Sysprep macht ja nix Schädliches, sondern tauscht im Wesentlichen die SID des Systems aus. Gruß, Nils

Moin, das ist ein neues Thema. Mach bitte einen neuen Thread dazu auf. Danke. Gruß, Nils

Moin, Dass ihr einander vertraut, ist prima, aber darum geht es ja gerade nicht. Es geht um Angreifer. Und was man "müsste", hängt entscheidend von den Umständen des einzelnen Unternehmens ab. Das ist das, was ich mit Planung meine. Gruß, Nils

Moin, ist die ESX-Umgebung dieselbe, auf der auch die produktiven Maschinen laufen? Streng genommen wäre auch das eine Vermischung der Sicherheitsbereiche. Es gibt immer mal wieder Bugs im Hypervisor (egal welcher), die einen Übergriff aus der VM auf die Host-Ebene erlauben. Das heißt nicht, dass dieser Aufbau ausscheidet. Das Risiko wäre aber zu bewerten und zu dokumentieren. Gruß, Nils

Moin, Beim Hersteller findest du einiges dazu. Und auch sonst gibt es viel Material. Aber erwarte bitte keine Anleitungen zum direkten Umsetzen. Gruß, Nils

Moin, Vor allem ist Martins Hinweis relevant, dass "Tier 0" eben die Domänen-Admins sind. Da wird nix delegiert, das ist der Level, der alles kann und darf. Genau deswegen separiert man den ja. Alles andere wird dann delegiert. Bitte beachten: das ist jetzt grob vereinfacht. Ich habe aber bei vielen Kunden festgestellt, dass der Tier 0 tatsächlich die größten Verständnisprobleme hervorruft. Gruß, Nils