olc

Hi, prüfe im Fehlerfall einmal die Ausgabe von "DFSUTIL /PKTINFO" auf dem betroffenen Client. Der "ACTIVE" Knoten, auf den also in dem Moment zugegriffen wird, hat wahrscheinlich eine andere Konfiguration als die funktionierenden Systeme. Viele Grüße olc

Hi, prüf einmal die selben Daten wie: https://www.mcseboard.de/windows-forum-allgemein-83/boot-anmeldeprozess-ausgeben-164033.html Viele Grüße olc

...und vor allen Dingen: Nachdem Du die internen Systeme neu installiert hast (das OS), woher bekommst Du dann die Programminstallationen für die Software auf den Rechnern? Du verwendest hoffentlich keine Installationssoftware, die Du von einem befallenen System kopiert hast? Kommt es auch zu Problemen, wenn kein Internetzugriff, sondern nur LAN Zugriff auf den Systemen genutzt wird? Ganz ehrlich: Es mutet etwas sehr merkwürdig an, was Du da schreibst. Viele Grüße olc

Hi DrMabuse und willkommen an Board, :) wenn Du ein wenig "tiefer" hineinschauen möchtest, schau Dir einmal das GpSvc Logging (Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista ganz unten) an und den XPerf bzw. XBootMgr. Viele Grüße olc

Hi Sascha, dann gehe in die Registrierung (mit Admin Rechten) --> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Schedule und stelle dort das DWORD "Start" auf Hex "2". Danach Reboot der Maschine. Viele Grüße olc

Hi, das ist "normal" - es gibt einige Dienste, die Du nicht neu starten kannst oder ähnliches. Dazu zählt auch der Scheduler, da er einige für die Funktionalität von Windows Vista / 2008 aufwärts wichtige Komponenten anspricht. Bei anderen Diensten gibt es unter Umständen andere gewichtige Gründe, warum diese nicht gestartet, gestoppt etc. werden können. Was möchtest Du denn genau erreichen - vielleicht sucht Du mit Deinem Ansatz "an der falschen Stelle"? Viele Grüße olc

Hi, nein, Du kannst die Laufzeit verlängern. Dazu mußt Du jedoch bei einer Root CA die Datei "Policy.inf" bemühen und folgende Zeilen einfügen: [certsrv_server] renewalkeylength=2048 RenewalValidityPeriodUnits=10 RenewalValidityPeriod=years Ggf. sind die Werte anzupassen. Danach kannst Du ein neues Cert mit 10 Jahren Laufzeit ausstellen. Zu der Migration: Du kannst eine CA wie im Link oben beschrieben "einfach" umziehen - dann entfällt ein Parallelbetrieb. Das wäre meines Erachtens auch die bessere Variante, um Wildwuchs mit 2 CAs zu vermeiden. Die Laufzeit des Root CA Zertifikats ist ja nun kein Hindernis mehr. ;) Viele Grüße olc

Hi Lothar, nein, nachträglich kannst Du die Laufzeit eines Zertifikats nicht verändern - Du mußt also ggf. ein neues Zertifikat für die Root CA mit längerer Laufzeit ausstellen. Danach können neue SmartCard Zertifikate etc. auch eine längere Laufzeit haben, da sie mit dem neuen Root Cert / Issuing Cert signiert werden. Es laufen dann eine Zeit "X" die beiden Root Zertifikate (alt und neu) parallel auf derselben CA. 2 CAs parallel betreiben kannst Du natürlich, nur vermute ich, daß das nicht das bringt, was Du Dir wünscht. Auch wenn Du "nochmal" schreibst, daß Du CAs parallel betreiben möchtest, ist mir auch nach Deinem dritten Post nicht klar, was Du damit bezwecken möchtest. :wink2: Viele Grüße olc

Hi, wenn Dir das alles bekannt ist, mußt Du Deine Fragen präziser formulieren. Zahni hat Dir mit dem Hinweis auf den CSV Export schon eine Möglichkeit genannt. Viele Grüße olc

Hi, doch, Du kannst die CA einfach migrieren. Ich verstehe wie gesagt die Fragestellung nicht zu 100% - vielleicht beschreibst Du noch einmal, was Du konkret erreichen möchtest. Wenn es Dir ausschließlich um einen "Umzug" der CA geht, dann hilft Dir vielleicht das weiter: How to move a certification authority to another server bzw. das: Active Directory Certificate Services Migration Guide Viele Grüße olc

Hi, Du hast meine Fragen oben nicht beantwortet und nur ein Event angegeben, nicht alle relevanten. Es gibt wie angesprochen unterschiedliche Methoden, sich zu authentifizieren. Je nach Anmeldemethode sperrt ein DC ein Benutzerkonto oder eben nicht. Ich beziehe mich auf die normale OWA Webseitenauthentifizierung. Wie genau melden sich die Benutzer also an? Wie genau lauten die relevanten Events / Event-Texte? Das eine Event hilft hier nicht weiter. Und ebenfalls noch einmal der Hinweis, daß 7 ungültige Anmeldeversuche bis zu einer Sperrung meines Erachtens zu wenig sind. Viele Grüße olc

Hi tqsystem und willkommen an Board, :) leider verstehe ich Dein Anliegen nicht so richtig - wo genau liegt das Problem auf welcher CA? Schau einmal hier hinein, vielleicht hilft es Dir einen Schritt weiter: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 . Viele Grüße olc

Hi numx, warum so beleidigend? Du kannst in den Eigenschaften der Datensammlung angeben, wie oft ein Report gezogen werden soll (es wird dafür AFAIK ein eigener geplanter Task erstellt). Oder Du startest die Datensammlung mittels manuell mit einem geplanten Task. Der Report wird dann automatisch erzeugt, wenn Du dies in den Optionen der Datensammlung mit angegeben hast - standardmäßig sollte das eigentlich der Fall sein. Welche Counter Du wählst, definierst Du ebenfalls selbst beim Erstellen der Datensammlung. Viele Grüße olc

Hi, wie gesagt, eine Webanmeldung über OWA (Webinterface) dürfte meines Wissens das Problem nicht verursachen. Anders sieht es aus, wenn mittels NTLM die Authentifizierung stattfindet - wie genau greifen die Bneutzer auf OWA zu bzw. wie werden sie authentifiziert? Poste einmal die konkreten Lockout Events (alle für einen Lockout), dort steht der Authentication Type mit drin. 7 ungültige Anmeldeversuche sind meines Erachtens zu niedrig. Ich würde es mit mindestens 10 - 20 Versuchen noch einmal probieren. Schau außerdem einmal auf den IIS Teil des folgenden Technet Artikels: Troubleshooting Account Lockout --> vielleicht spielt der IIS Token Cache hier auch eine Rolle. Viele Grüße olc

Hi, vielleicht waren die Benutzer ja einmal Mitglied einer geschützten Gruppe? Das Flag der Vererbung wird nach dem Entfernen der Gruppenmitgliedschaft nicht neu gesetzt. Ansonsten hat Nils schon alles relevante gesagt. :) Viele Grüße olc

Hi, am besten nicht alle Probleme in einen Thread packen, das wird zu unübersichtlich. Ich sehe den Screenshot nicht, aber zu den GPO Einstellungen gibt es diverse Technet Seiten, die das erklären. ;) Kurzform: AFAIR mußt Du, wenn Du Zertifikattemplates neu ausrollen möchtest (Reenroll al certificate holders), diese Option setzen. Viele Grüße olc

Hi, zu 2) Das Autoenrollment muß nicht auf dem Template aktiv sein, sondern per Gruppenrichtlinie aktiviert sein. Hatte ich oben schon geschrieben. ;) zu 3) Wenn der Client nicht in der Domäne ist, kann kein Kerberos verwendet werden. Von daher solltest Du ggf. das Webenrollment verwenden anstatt die MMC. Ich vermute W7 nutzt die AD CS HTTPS Gateway Zugriffe, jedoch ist das nur eine Vermutung, weil Deine Umgebung unbekannt ist. Viele Grüße olc

Hi, zu 2) Nein, sie müssen nicht im AD veröffentlicht sein. Der Client hat eine ausstehende ("pending") Zertifikatanfrage, daher schaut er während des Autoenrollments nach, ob es "Neuigkeiten" gibt. Dazu muß aber wie gesagt das Autoenrollment aktiviert sein (bestenfalls mit beiden Haken in den GPO Optionen "update pending..." etc.). zu 3) Ich habe Dich schon richtig verstanden. ;) Vielleicht läuft Kerberos auf den XP Clients nicht richtig, vielleicht gibt es Unterschiede in den Sicherheitseinstellungen der Templates etc. Ein schneller Test kann sein zu prüfen, ob Du Benutzerzertifikate ausrollen kannst und nur die Maschinentemplates nicht. Das grenzt einen solchen Fehler schon mal ein. Ist mit den aktuellen Informationen schwer zu sagen, was nicht paßt - check erst einmal die Unterschiede zum Vista / W7 Client und dann kann man weiter schauen. :) Viele Grüße olc

Hi, dann prüfe noch einmal, ob die anderen Benutzer auch wirklich die GPP bekommen oder ob es Probleme bei der Übernahme der GPO / GPP gibt. Hierzu kannst Du den GPMC Group Policy Result Report für die GPO und ggf. das GPP Logging and Tracing verwenden. Zu beiden Stichworten geben Suchmaschinen eine Menge Material aus. ;) Viele Grüße olc

Hi, solche Fragen stellte man im Normalfall, bevor man die PKI "hochzieht". ;) Oder handelt es sich hier um eine Testumgebung? zu 1) Ja, entweder per "Roaming Profiles" oder mittels "Credential Roaming". Beides sollte gut geplant und nicht "nebenbei" eingeführt werden. zu 2) Wenn Autoenrollment auf den Clients aktiviert ist (für gibt es Benutzer- als auch Computergruppenrichtlinien), dann passiert das automatisch. zu 3) Handelt es sich bei den Templates um Vorlagen, die Du mit der Option "Windows Server 2008" Templates versehen hast (beim Kopieren / Erstellen)? Falls ja, dann sind dieser nur ab Vista + höher verfügbar und XP kann diese Templates nicht ausrollen. Oder es fehlen schlichtweg die Berechtigungen auf das Template für XP Clients / Administratoren. Viele Grüße olc

Hi, d.h. die Gruppenrichtlinie ist auf der OU für die Windows 7 Clients verlinkt? Der Link ist auch aktiv und die Computereinstellungen nicht deaktiviert? Wie ist die Sicherheitsfilterung für die GPO eingestellt? Poste doch einmal ein GPRESULT /Z von einem betroffenen Client, nachdem Du eventuell problematische Daten entfernt hast. Viele Grüße olc

Hi, der built-in Admin wird im abgesicherten Modus "aktiviert" bzw. kannst Du Dich mit dem Account dann anmelden. Dafür ist diese Funktionalität gedacht. ;) Viele Grüße olc

Hi, na ja, wenn es die Dimension vom Conf***er hätte, wären wahrscheinlich mehr / alle Accounts betroffen. Aber klar, einen Blick in die Richtung ist sicher nicht verkehrt. Nebenbei die Frage: Nach wie vielen ungültigen Anmeldeversuchen werden die Accounts in der Umgebung gesperrt, d.h. was ist von Euch konfiguriert worden? Wenn es nur 3 oder 5 ungültige Anmeldeversuche sind, brauchen wir hier gar nicht großartig herum zu suchen. Dann solltest Du erst einmal mindestens 10 Anmeldeversuche einstellen und prüfen, ob das Problem dann immer noch auftritt. Viele Grüße olc

Hi, starte den Windows 7 Client einmal neu, dann sollten die Computereinstellungen auch angewendet werden. Alternativ als Admin "gpupdate" ausführen. Viele Grüße olc

Hi, OWA Anmeldungen sperren keine Konten, da es sich um einen nicht umfassten Anmeldetyp für Kontensperrungen handelt. Du mußt auf Deinen DCs gegenprüfen, von welchem Client die Sperrung ausging. Am besten Du fängst auf dem PDCe an, von dort bekommst Du den Hinweis, auf welchem DC die Sperrung stattgefunden hat (ggf. auch auf ihm selbst) und von dort bekommst Du den Client. Viele Grüße olc