olc

Hi, ja, das wäre eine Möglichkeit. D.h. diese konkreten Daten in eine eigene Replikationsgruppe übertragen (=anderes Share) und dann nur Nachts o.ä. replizieren lassen. Die Frage ist, "warum" die Daten repliziert werden sollen. Backup Lösung zentral, Datenbearbeitung dezentral? D.h. es wird immer nur in Außenstellen gearbeitet, zentral jedoch gesichert? HIerbei wäre dann zu beachten, daß genau zu der Zeit, in der der Schedule offen ist, auch die Datensicherung im Datacenter erfolgt. Das kann problematisch sein. Außerdem wäre zu klären, ob das Zeitfenster dann auch zuverlässig ausreicht, die Daten ins Datacenter zu übertragen. Was ist das genaue Szenario? Viele Grüße olc

Hi ATV und willkommen an Bo(a)rd, :) zu 1) Das Eventlog zeigt die "Sharing Violations" an, inkl. eigener Event ID. zu 2) Ja. :) zu 3) Das ist nur indirekt möglich, die Dateien werden über einen Staging Bereich ausgetauscht. Wird jedoch nach dem Zusammenfügen die Datei nicht geschrieben, da noch in Benutzung, kann es hier zu Problemen / Kollisionen kommen. Alles in allem: Versuche lieber nicht, die Einschränkung zu "umgehen", damit wirst Du nur Probleme haben. Sprich leg keine Datenbanken o.ä. auf den replizierten Ordnern ab. Damit ersparst Du Dir mittelfristig größere Probleme. ;) Viele Grüße olc

Hi, auch mit Thawte CA Zertifikat ist es das gleiche Vorgehen: How to move a certification authority to another server Viele Grüße olc

Hi David, schau einmal hier hinein: 3 Möglichkeiten, um Anzeigenamen einem Attribut zuzuordnen - Aktives Verzeichnis Blog - Site Home - TechNet Blogs ;) Viele Grüße olc

Ein Neustart schadet natürlich nicht, sofern "alle beteiligten Systeme" neu gestartet werden. Dabei werden auch eventuelle Kerberos Caches gelöscht. In dem Fall reicht jedoch der Neustart des SBS nicht. Ob sich der Aufwand lohnt, mußt Du bzw. Dein Kunde entscheiden. ;)

Hi, nein, ein Reboot ist nicht notwendig. Den SPN vom Admin-Konto entfernen und ein wenig warten, dann sollte es passen. :) Viele Grüße olc

Hi, Du müßtest vermutlich von dem "Admin" Konto den SPN entfernen. Zumindest dann, wenn dieser nicht als Service Account des SQL Server genutzt wird, wovon ich ausgehen würde und es andernfalls keine gute Sache wäre. D.h. Du kannst beispielsweise in ADSIedit.msc auf dem Konto CN=Admin,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=ccl,DC=local" schlicht den "servicePrincipalName" Attributwert "MSSQLSvc/CCLS-001.ccl.local:21257" entfernen. Das sollte das Problem beheben. Sollten sich wider erwarten dann Probleme zeigen, registrierst Du ihn schlichtweg auf dem Konto neu (sprich: Du trägst den entfernten Wert wieder ein): Aber wie gesagt, das würde mich wundern... Deine Kommandos sollten eigentlich auch funktionieren - aber ich hab das gerade nicht getestet, daher die Wegbeschreibung für ADSIedit. Ansonsten: Alles sehr gut recherchiert. :) Viele Grüße olc

Hi, schau einmal hier hinein, das sollte helfen: "Access Denied" error message when you try to access remote resources Viele Grüße olc

Hi, Du legst eine universelle Sicherheitsgruppe an (oder verschachtelst diese mit vorhandenen Rollen, je nach Deinem Gruppenkonzept) und berechtigst diese Gruppe auf die GPO. In diese Gruppe legst Du die Computerkonten TB1 und TB2. Die "Authentifizierten Benutzer" entfernst Du von der Sicherheitsfilterung der GPO. Nach einem Rechnerneustart der beiden Systeme greift die Richtlinie nur noch für diese beiden Systeme bzw. für Mitglieder der Sicherheitsgruppe. Siehe dazu auch: Security filtering using GPMC: Group Policy Viele Grüße olc

Hi, ich bin mir nicht sicher, was Du mit "Eigenschaften-Zertifizierungspfad" meinst. Solltest Du das "geöffnete" Zertifikat meinen und die Zertifikatkette in dieser Ansicht, dann wird die Sperrung dort nicht angezeigt. Versuch es einmal mit einem "certutil -verify -urlfetch Zertifikat.cer" - dort sollte angezeigt werden, daß das Zertifikat zurückgezogen wurde. P.S.: Mir ist nicht ganz klar, warum Du den privaten Schlüssel des RAS Servers auf dem Client importiert hast - aber es klingt für mich nicht korrekt. ;) Viele Grüße olc

Hi, Du hast "Glück" - Dein CRM spricht derzeit kein Kerberos (aufgund des Fehlers), fällt jedoch auf NTLM zurück. Daher siehst Du keine Probleme, obwohl es im Kern eines gibt. Warum verwendest Du anstatt der drei Konten nicht ein Dienstkonto? Im Regelfall ist das die Konfiguration, wenn es um Lastenausgleich o.ä. gibt, so daß mehr als eine Maschine im gleichen Kontext / Dienstbenutzer läuft. Viele Grüße olc

Hi, geht mir genauso. ;) Welches IPSec Zertifikat hast Du denn gesperrt? Das des RAS Servers oder das des Clients? Ich habe es so verstanden, daß das Zertifikat des Clients zurückgezogen wurde. Das wäre ja das gängigste Szenario. Viele Grüße olc

Hi, nein, das ist nicht möglich und auch nicht sinnvoll. In den EFS Infos steht, welcher Benutzer entschlüsseln kann. Daher sollte das auch kein Problem werden. Außerdem hast Du einen Data Recovery Agent, daher ist "irrelevant", wer die Datei verschlüsselt hat. Du kannst sie immer mit dem DRA entschlüsseln. Dafür ist er da. ;) Zum Thema "Feature entdeckt, darum soll es genutzt werden": Das ist aus meiner Sicht kein Anforderungsprofil. ;) Insbesondere, da es sinnvollere / besere Produkte gibt als EFS. Zuallererst sollte also einmal geklärt werden, wovor sich Deine GF da eigentlich schützen möchte, warum sie sich schützen wollen und ob der eingeschlagene Weg ein sinnvoller Weg ist. :) Viele Grüße olc

Hi, der RAS Server ist nicht der Client. ;) Genau dort mußt Du den Cache löschen. BTW: Die Autoenrollment GPO wird nicht den Effekt haben, daß das RAS Server Zertifikat vom Client entfernt wird. Meines Wissens werden nur die eigenen Zertifikate, also etwa Client Zertifikate durch die Einstellung nach einer Revocation entfernt. Aber da mag ich mich irren, hab ich mir schon länger nicht angeschaut. Viele Grüße olc

Off-Topic: Mich beißen nur die Flöhe. :D

Hi, Du mußt den Cache auf dem *Client* löschen, dann sollte es klappen. :) Viele Grüße olc

Hi, schau mal hier: ADPREP "multi-language" ;-) - Aktives Verzeichnis Blog - Site Home - TechNet Blogs [EDIT] Zu lahm. :) [/EDIT] Viele Grüße olc

Hi, Das ist keine Antwort auf die Frage. ;) Die "lokalen" Zertifikate liegen im AppData Verzeichnis. Aber das Thema hat sich aufgrund Deines Nachsatzes, der erst nachträglich eingefügt wurde, erledigt. :) Das ist wie angesprochen "by design" und kein Problem. Wenn es Dir also nur darum geht, daß auf den Servern pro Benutzer eigene Zertifikate erzeugt werden, dann brauchst Du an dieser Stelle nicht weitersuchen. Das ist normal. Siehe dazu auch: ACK. ;) Viele Grüße olc

Hi Philipp, warum möchtest Du EFS nutzen? Meiner Erfahrung nach wird EFS nur sehr eingeschränklt genutzt, ggf. gibt es andere / bessere Lösungen je nach Anwendungszweck. Was ist der Hintergrund der Anforderung? Zu Deiner Frage: Vermutlich melden sich die Benutzer an unterschiedlichen Arbeitsstationen an? Wenn dem so ist und es keine Ordnerumleitung bzw. Roaming Profiles gibt (und kein Credential Roaming eingesetzt wird), fordert der Benutzer auf jeder Maschine / jedem neuen Profil ein neues Zertifikat an. Denn die Zertifikate liegen im Benutzerprofil (AppData). In der Konstellation wäre es also sinnvoll, eine der 3 Optionen zu nutzen (Ordnerumleitung, Roaming Profiles oder Credential Roaming). Alle 3 Optionen erfordern jedoch einigen Planungsaufwand, weshalb das nicht "mal eben" aktiviert werden sollte. Ihr könnt auch das Autoenrollment für EFS Zertifikate (bzw. das jeweilige Template) auf Eurer CA deaktivieren. Jedoch ist das auch nicht zielführend, da es nur die Sympthome behebt, nicht jedoch die Ursache. [EDIT] Zu Deinem Nachtrag: Das ist normal - EFS erzeugt auf dem Dateiserver automatisch ein Zertifikat für den Benutzer und verschlüsselt damit die Daten auf dem Server. DIes ist jedoch transparent für den Benutzer und "by design". [/EDIT] Viele Grüße olc

...wobei ich mich frage, ob mein Beitrag überhaupt gelesen wurde. Das stand nämlich alles schon drin. ;) P.S.: Wenn OCSP korrekt installiert / konfiguriert ist, hätte die Sperrung nach Veröffentlichung der CRL auch schneller funktionieren können / sollen. Vermutlich hat es das, weshalb RAS dann auch nicht mehr "funktionierte". Beschäftigst Du Dich mit RAS oder den PKI Grundlagen? Falls RAS, hat es ggf. Sinn, sich gleichzeitig mit PKI zu beschäftigen. :) Viele Grüße olc

Hi, wie oft wird die CRL bzw. Delta CRL auf der CA veröffentlicht? Erst, wenn die CRL / Delta CRL regular veröffentlicht wurde, werden die Clients die Sperrung mitbekommen. Es hilft Dir im Moment (ohne OCSP) nichts, die CRL vorher zu veröffentlichen. Die Clients schauen erst nach einer CRL, wenn die alte abgelaufen ist. Wenn es sich um Windows Vista+ Clients handelt, könntest Du den Ablauf der "Wartezeit" mittels Script o.ä. verkürzen: How to refresh the CRL cache on Windows Vista - Windows PKI blog - Site Home - TechNet Blogs Viele Grüße olc

Hi, schau einmal hier hinein: Hallo? Hier Basisverzeichnis ... Oh, falsch verbunden ... tüt .. tüt .. tüt - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Viele Grüße olc

Hi, Du kannst ausschließlich Benutzer oder globale Sicherheitsgruppen mit PSOs versehen. OUs gehen nicht. Siehe dazu auch: Viele Grüße olc

Hi Nils, wie gesagt, ich stimme Dir da vollkommen zu. :) Ich wollte zusätzlich jedoch eine Alternative geben, da nicht immer alles so gut läuft, wie man es sich z.B. in Bezug auf die Dokumentation vorstellt... Insbesondere auch, da der Weg anders herum dazu dienen kann, neue Betriebssysteme auf den DCs einzubringen, ohne sie jedoch allen Clients sogleich verfügbar zu machen. Und das schwingt ja auch bei dem Thread mit, ohne daß es vom TO genannt wurde. :) Bezüglich des Netzwerk Monitors: Vollkommen richtig, obwohl man das auch "abfangen" kann. Alternativ dazu geht auch ganz simpel ein PerfMon oder SPA-Mitschnitt. Der zeigt auch die Top-Konsumenten (bzw. ggf. auch alle). Viele Grüße olc

Hi, generell stimme ich Nils zu, wenn es um die Dokumentation geht. Und ich stimme blub auch zu, wenn es um die Möglichkeit geht, bei nicht vorhandener Dokumentation (was häufig das zugrundeliegende Problem ist), dennoch die AD-Konsumenten zu bestimmen. Ein Weg, den ich persönlich sauberer als den der Prioritäten empfinde, ist der folgende (den ich übrigens genau anders herum für Migrationen zu neuen Betriebssystemen auf DCs häufig empfehle): Erzeuge eine neue AD-Site ohne (oder mit nicht verwendetem) IP-Subnetzbereich. Verschiebe den DC in diese neue Site. Dort sollten (automatisch) keine Clients zugewiesen werden, d.h. das Subnetz sollte wirklich nicht verwendet werden. Entferne den DC aus der globalen / generischen AD-DNS _tcp-Zone mittels SRV-mnemonics: How to optimize the location of a domain controller or global catalog that resides outside of a client's site Prüfe die korrekte DNS Registrierung, d.h. SRV-Einträge in der neuen Site des DCs als auch das Entfernen der alten Einträge aus den alten Sites bzw. der globalen _tcp-Zone. Nun dürften keine "regelkonformen" Anfragen mehr per DCLocator an den DC gehen, ausschließlich hart-verdrahtete Systeme "finden" den DC noch. Logging kann entweder mit den von den Kollegen genannten Möglichkeiten erfolgen oder aber schlichtweg mittels Netzwerk Monitor, der den "inbound" Verkehr überwacht. Wichtig ist hier ein längerer Zeitraum der Überwachung, was aber zu Problemen bei der Datenauswertung führen kann. Zuguterletzt schaltest Du den DC testweise aus, ohne ihn zu demoten. Hier zeigt sich dann am deutlichsten und schnellsten, ob es Probleme gibt. Das ist allerdings die letzte Maßnahme. Viele Grüße olc