olc

Hi, merkwürdig ist durchaus, warum dort eine Authentifizierung im Maschinenkontext (also etwa SYSTEM) erfolgt und das auch noch über NTLM. Das kann bis 2008 R2 in der Form nicht funktionieren. Geh einmal in den System Kontext eines betroffenen Clients, etwa mittels "PsExec\\localhost -s cmd" und führe ein "klist purge" aus. Danach zieht Du einen Netzwerktrace auf dem Client, während Du den Fehler in Outlook reproduzierst (also eine Anmeldung durchführst). Dann filterst Du den Netzwerktrace nach Kerberos Paketen und schaust, ob wirklich keine Principal Name Fehler auftreten. Falls doch, kannst Du den problematischen SPN gleich im Trace ablesen... Viele Grüße olc

Hi und willkommen an Board, :) eine kurze Websuche dazu brachte folgendes: Numerous "Event ID 1216" Events in Directory Services Event Log Habt Ihr an den "Diagnostics" Werten etwas geändert? P.S.: Der gesamte Eventtext inkl. Event ID hilft meist, ein Problem innerhalb eines Forums besser einzugrenzen. ;) Viele Grüße olc

Hi, es gibt diverse Tools, mit denen Du das regeln könntest - kleine oder ausgewachsene, kostenfreie oder kostenpflichtige. Was hältst Du von "Eventtriggers.exe" + "Blat.exe": faq-o-matic.net Auf Windows-Ereignisse reagieren Viele Grüße olc

Hi Sabine, schau einmal hier hinein: Windows 7 and SmartCard removal behaviour… no system lock? | Sebastian Rohr Viele Grüße olc

Hi Tobias und willkommen an Board, :) hast Du den Zugriff getestet? Wenn es funktioniert, wäre die Frage "unnötig". Wenn es nicht funktioniert, wäre eine Fehlermeldung interessant. Grundsätzlich kann das mit Deinen Angaben oben schon hinkommen, aber das ist jetzt eher so "Glaskugel schauen"... ;) Viele Grüße olc

Hi, also wenn ich mir den Prozess oben anschaue, dann deutet es in dem von Dir geposteten Fall auf die "Suche" hin: "ExSearch.exe" Wenn die Suche unter System Rechten läuft, könnte das ein Hinweis auf das Problem sein. Deaktiviere einmal den MSSearch Dienst und prüfe, ob der Fehler auch weiterhin noch auftritt. Viele Grüße olc

Hi, bezüglich Root CA: Nein, der Responder kann vollkommen unabhängig von der CA laufen. So kann man auch einen OCSP Responder nachträglich aufbauen, obwohl die URL nicht in den schon ausgestellten Zertifikaten vorhanden ist (per GPO). Stichwort CertEnroll: Das mit der Webregistrierung hatte ich oben schon geschrieben. Hättest Dir also ein wenig Zeit sparen können. ;) Viele Grüße olc

Hi, grundsätzlich kann auch die Root CA per OCSP die Sperrungen verteilen. Die Frage ist meist, ob das "sinnvoll" ist, insbesondere, wenn es sich um eine Offline CA gibt. Ich meine mich auch zu erinnern, daß man per OCSP Instanz auch mehrere CA CRLs "bedienen" kann - ist aber schon länger her, daß ich mich damit beschäftigt habe. Somit könntest Du beide CAs bzw. Sperrlisten mit einem OCSP Array bedienen. Viele Grüße olc

Off-Topic: Jaaaaa, endlich: Sonst muß ich doch immer 50 Cent pro Post zahlen. 1,- € bei falscher Antwort. :D Ihr etwa nicht? ;)

Off-Topic: Also noch einmal gefragt: Was habe ich gewonnen? :D

Hi, Du mußt das Zertifikat derjenigen CA angeben, für die OCSP die Sperrlisten Informationen bereitstellen soll. In Deinem Fall wäre das die Issuing CA, theoretisch könnte es aber natürlich auch die Root CA sein. Du bist also für Dein Szenario mit der Issuing CA richtig vorgegangen. Ich kenne das Buch nicht. Aber wenn es so ist, wie Du es beschreibst, dann fehlt da tatsächlich dieser Teil. "certutil -vroot" sollte das bei Bedarf auch erledigen. Im Normalfall wird das Verzeichnis jedoch bei der Installation der Webregistrierungsstelle automatisch angelegt. Ich kann also nicht sagen, was bei Dir schief gelaufen ist. :) Viele Grüße olc

Hi, ich komme bei Deinen steten Änderungen nicht mehr mit, von daher habe ich keine Antwort auf Deine Fragen. :wink2: Bezüglich des HTTP Fehlers würde ich davon ausgehen, daß das IssuingCA(1) Zertifikat schlichtweg von Dir / der CA nicht an der HTTP Lokation veröffentlicht wurde. Viele Grüße olc

...und Du hast bei Deiner Antwort noch ein kleines "findet den Fehler" Spielchen eingebaut. :p Ich habe den Fehler gefunden: Du meintest "oder einen Windows Server 2008 Member Server verwenden" anstatt :) Was habe ich gewonnen? :D Viele Grüße olc

Hi toasti, trotz der Anzeige von PKIView kann OCSP korrekt funktionieren. Check das lieber einmal mit "certutil -url" bzw. "certutil -urlfetch -verify Dein_Zertifikat.cer". Siehe dazu auch OCSP Responder - Error in pkiview.msc Oder ändere den Typen des Eintrags auf "32", falls Du eine "34" eingetragen hast (solltest Du es per Registry Änderung und nicht per GUI durchgeführt haben): http://www.winserverkb.com/Uwe/Forum.aspx/windows-cryptography/2242/Problem-with-OCSP AIAs enthalten die Informationen zu Root- und Issuing CAs bzw. deren Zertifikate. Viele Grüße olc

Hi, ich meinte das icacls.exe Script. Wie angesprochen kannst Du die PowerShell recht einfach nutzen. Siehe den oben genannten Link. Dann sind das nur 3 Minuten Arbeit. Viele Grüße olc

Hi, wie genau sieht denn Deine derzeitige Kommandozeile aus, mit der es nicht klappt? Ansonsten könnte die PowerShell eine Alternative sein: http://blogs.msdn.com/johan/archive/2008/10/01/powershell-editing-permissions-on-a-file-or-folder.aspx Viele Grüße olc

N'Abend Nils, ja - mir sind Fälle bekannt, bei denen es bei der Replikation nach dem Schema Upgrade Probleme gab. Und ja - in den allermeisten Fällen hätte man die Probleme vermeiden können, indem man die Replikation bzw. Funktionsfähigkeit der DCs vorher sauber geprüft hätte. Ich bin also ganz bei Dir - nur leider zeigt sich in der Praxis recht häufig, daß eben diese Tests nicht korrekt durchgeführt werden. Du wirst das immer sauber tun (und andere sicher auch), das passiert jedoch leider nicht immer umfassend. Es kann jedoch auch Probleme geben, die sich nicht so einfach vorher ausschließen lassen - ich habe zum Beispiel schon Lingering Objects im Configuration NC nach dem Schema Upgrade gesehen, die vorher nicht "aufgefallen sind", bis dann Änderungen am Configuration NC durch das Schema Upgrade durchgeführt wurden. Die wären kurze Zeit später auch zwangsläufig aufgefallen, aber manchmal ist das Timing halt einfach schlecht... :wink2: Außerdem schließt sich oftmals direkt das Domainprep an, was dann eine ganze Reihe weiterer Probleme mit sich ziehen kann. Ich bin kein Mensch, der auf Panikmache steht. Ein Schema Upgrade wird meist problemlos laufen, wenn es sauber durchgeführt wird. Aber Vorsichtsmaßnahmen schaden nicht. :) Viele Grüße olc

Hi, am besten nutzt Du nicht "xcacls.exe", sondern Icacls - xcacls hat in einigen Konstellationen Probleme beim Ändern der ACLs, so daß es zu einer Beschädigung der ACL-Strukturen kommen kann. ICACLS kann ebenso Gruppenmitgliedschaften ändern. Viele Grüße olc

Hi, der von Dir gepostete Blog sagt dazu: "based on what PGP/GPG front end plugin you use". Bei PGP einen Kontakt an die Strippe zu bekommen ist sicher nicht verkehrt. Ich habe einen solchen Mix in der Praxis noch nicht gesehen, daher auch keine Idee. Sorry. Viele Grüße olc

Hi Wisi, setz einmal testweise die Gruppenrichtlinie "Always wait for the network [...] auf den betroffenen Clients. Siehe dazu auch: Aktives Verzeichnis Blog : Hallo? Hier Basisverzeichnis ... Oh, falsch verbunden ... tüt .. tüt .. tüt Viele Grüße olc

Hi Martin, die Richtlinie "Lokal anmelden zulassen" nur für Admins/Operatoren ist in Ordnung, solange es dabei um den SBS geht. Der Client hat da natürlich Probleme mit... In welcher Gruppenrichtlinie hast Du diese EInstellung denn genau gefunden - in der Default Domain Policy oder direkt im RSOP des Clients? Was heißt, Du kannst es nicht ändern? Wie genau bist Du vorgegangen? Viele Grüße olc

Hi, ja, ich will auf einen Freitag Abend nur stänkern: :p Weil man bei deaktivierter Replikation des Schema Masters nicht prüfen kann, ob das Upgrade auch korrekt repliziert wird. Daher würde ich persönlich immer mindestens einen zweiten DC mit in die abgetrennte Site bzw. das abgetrennte VLAN mit hinein nehmen, um damit die Replikation zu prüfen. Auch auf die Gefahr von volleren Eventlogs hin. ;) BTW: Das Flag kann auch mit einem repadmin [...] /force überschrieben werden. ...außer einem "repadmin /syncall /e /force", wenn man den DC / die DCs "nur" in eine andere Site verschiebt. :D Ok, bin schon weg. ;) Viele Grüße olc

Hi, ja, da bist Du auf dem Holzweg. ;) Bei RMS geht es nicht nur um Verschlüsselung o.ä. - es geht auch darum, Berechtigungen für die Dokumente zu vergeben. Somit ist die Struktur eine andere, als bei reiner Verschlüsselung. Diese ist nur ein mögliches Merkmal von RMS. Viele Grüße olc

Hi, vermutlich sind die ACLs der betroffenen Ordner / Dateien strukturell nicht in Ordnung / beschädigt. Wenn das die Software verursachen sollte, dann sollte der Hersteller schnellstmöglich das Problem nachvollziehen und beheben. Weißt Du, wie die Berechtigungen gesetzt werden? Es gab auch einige Fehler in CACLS und XCACLS, die zur Beschädigung von NTFS ACLs führen konnten - daher existiert derzeit die Empfehlung von MS, icacls.exe zu verwenden, wenn Änderungen an den ACLs durchgeführt werden sollen. Wenn die Applikation jedoch mit eigenem Code ggf. MS APIs anspricht, dann muß der Hersteller ran. Viele Grüße olc

Moin, nein - Du lagst absolut richtig. Ich habe das "mehrere" Roaming Profiles überlesen. :wink2: Viele Grüße olc