olc

Hi Haggard, Ziel-Betriebssystem, auf dem der Task angelegt werden soll, ist...? :) Viele Grüße olc

Hi Haggard, kannst Du es einmal ohne das "/HOURS 8" versuchen? Viele Grüße olc

Hi Frank, ok, danke für die Rückmeldung. Das hat Sinn und ist gut zu wissen. :) Viele Grüße olc

Hi Nando, Sofern Du eine "Enterprise" CA installiert hast (also nennen wir es einmal "AD integriert" - davon gehe ich aus, sonst wäre kein Autoenrollment möglich), mußt Du die Vorlage "duplizieren", damit Du die Werte verändern kannst. Siehe dazu auch: Designing and Implementing a PKI: Part III Certificate Templates - Ask the Directory Services Team - Site Home - TechNet Blogs Da es sich um einen Windows Server 2008 R2 handelt, muß die SKU (also die OS Version) nicht mehr "Enterprise" sein, das war nur bis 2008 der Fall, um Templates duplizieren zu können. Na ja, der Weisheit letzter Schluß ist das auch nicht - im Normalfall *möchtest* Du ja, daß die Zertifikate auch nach Ablauf o.ä. erneuert werden. Wie gesagt, das ganze ist ein Prozessthema: Wie gehst Du / der Kunde mit zurückgerufenen Zertifikaten bzw. deren Maschinen um? Da liegt die Frage, nicht in der Ausstellung neuer Zertifikate. Autsch, daran sollte man nicht "herumtesten". :) Genau, ein Dienst pro Server. Die CA auf einem DC zu installieren hat neben generellen SIcherheitserwägungen, Rollentrennung usw. auch darum keinen Sinn, weil es Probleme macht, sobald Du z.B. den DC demoten mußt, die CA jedoch weiterlaufen soll. Das ist so einfach nämlich nicht möglich und schränkt Deine Troubleshooting Vatianten deutlich ein. Es gibt noch 1.000 andere Gründe dafür, das anders zu lösen. Die Punkte oben sind nur kurz angerissen. Ok. :) Viele Grüße olc

Hi Nando, willkommen an Bo(a)rd, :) zu Frage 1: WIe lang ist denn die Zertifikatlaufzeit? Beträgt diese nur einen Tag? Was hast Du im Template festgelegt? Handelt es sich immer um dieselben Clients oder sind alle betroffen? Setzt Du ggf. die Maschine mittels Imaging / Snapshot o.ä. täglich auf einen Status X zurück? zu Frage 2: Der Screenshot der "Registrierungsrichtlinienkonfiguration" gibt Dir die Erklärung: Du hast die Option gewählt, daß abgelaufene und gesperrte Zertifikate entfernt werden. In diesem Moment "weiß" der Client nicht mehr, daß er schon ein entsprechendes Zertifikat ausgestellt hatte und wird es neu beantragen. Genau das ist auch korrekt so - denn wenn ein Client als nicht mehr vertrauenswürdig eingestuft wird (revokiation eines Zertifikats), dann wirst Du ihn im Normalfall ja auch aus der AD entfernen o.ä., wodurch er keine neuen Zertifikate mehr bekommen wird. Das Autoenrollment macht an dieser Stelle alles richtig, es ist ein Prozessthema, kein rein technisches Thema. :) P.S.: Ich gehe davon aus, daß wir über eine Testumgebung sprechen? Falls nicht, wären da so einige "nicht best practices" anzusprechen in Bezug auf die Anordnung der Dienste auf dem DC... ;) P.P.S.: Wenn die Abnahme Morgen um 16:00 Uhr ist, dann bist Du sehr spät dran mit der Fertigstellung der Arbeit. Denke daran, daß wir das hier alle in unserer Freizeit machen - wenn Du ein SLA benötigst, solltest Du einen Dienstleister bezahlen. ;) Viele Grüße olc

Hi, wie ich schon schrieb ;), sind einige Dinge schlichtweg nicht mehr unter WIndows 7 verfügbar. Das Update für die 2003er CA rüstet zwar die Grundfunktionalität nach, jedoch nicht jedwede Funktionalität. Ich weiß nicht, ob die Archivierung ebenso darunter fällt, ich würde es anhand Deiner Angaben jedoch vermuten. Versuch einmal den Zugriff vom W7 Client auf die CA mittels MMC anstatt der Webseite. Funktioniert es damit? Viele Grüße olc

Hi Marcus, genau, es wird an einigen Stellen im Container der "logische" Name verwendet (etwa AIA), an anderen jedoch der Hostname der CA, der ggf. den logischen Namen als Subcontainer enthält (etwa in der CDP). Und genau da liegt die Aufgabenstellung: Da alte Zertifikate zum Beispiel in der CDP auf den alten Hostnamen zeigen, unterhalb des Containers erst der logische Name der CA auftaucht, müssen neue CRLs auch dort hin verteilt werden. Landen die CRLs nur auf dem Container des neuen Hostnamens, hast Du ein Problem - die alten Zertifikate würden irgendwann den Abruf einer veralteten CRL nach sich ziehen. Du kannst also entscheiden, ob Du in der Konfiguration weiterhin nur auf den alten Hostnamen CDP die CRLs veröffentlichst, ob Du den alten und neuen Hostnamen versorgst oder ob Du nur im neuen Hostnamen Container veröffentlichst und die Veröffentlichung im alten Container "manuell" oder gescripted erledigst. Du mußt es nur machen... ;) Schau Dir einmal die Strukturen unterhalb von "CN=Public Key Services,CN=Services,CN=Configuration,DC=deine_domäne,DC=tld" an, dann wirst Du das besser nachvollziehen können. :) Viele Grüße olc

Hi, Es wird im AD nichts geändert - das ist ja genau der Punkt. Wenn im Config-NC der alte Name der CA als Container vorhanden war, bleibt das auch weiterhin so. Denn dort müssen ja die CRLs oder neue AIA usw. weiterhin veröffentlicht werden, schließlich hast Du Zertifikate im Umlauf, die darauf verweisen. Ja, daher müssen die alten Verteilungspunkte weiterhin aktiv sein und mit aktuellen "Daten" versorgt werden. Ja, den logischen Namen der CA, nicht den Hostnamen, den Du ja geändert hast. Nein, das konkret nicht. Wenn Du jedoch in den CDPs der Zertifikate zum Beispiel eine HTTP URL angegeben hast, die auf den alten Hostnamen der CA verweist, hast Du ein Problem, welches Du beheben mußt. Kein guter Test, zwei Clients sind hier sinnvoller. :) Wie gesagt, die Webseite ist "tot", Du solltest auf die MMC umstellen. Viele Grüße olc

Gern, freut mich daß es nun funktioniert. :) Viele Grüße olc

Hi, so wie ich das sehe, ist Deine Klammersetzung bzw. Operatorensetzung nicht ganz korrekt. Die Verkettung von UND bzw. ODER ist hier entscheidend. Schau einmal, ob es so funktioniert: (&(objectclass=user)(objectcategory=person)(|(memberOf=CN=Group,OU=OU,OU=ÜberOU,DC=Teil1,DC=Teil2,DC=Teil3)(memberOf=CN=Group,OU=OU,OU=Über,DC=Teil1,DC=Teil2,DC=Teil3)));sAMAccountName;telephoneNumber Übrigens ist es immer interessant zu lesen, a) mit welchem Stück Software Du die Abfrage durchführst und b) was "funktioniert nicht" für einen Fehlercode / Fehlermeldung zeigt. ;) So wäre es einfacher Hinweise zu geben. :) Viele Grüße olc

Hi, im Kern mußt Du alles prüfen, wo der alte CA Hostname auftaucht. So etwa die CDP, AIA (also etwa HTTP Links, wenn Du sie nicht generalisiert hast) usw. Nur die Umbenennung und Anpassung des Dienstes reicht also im Kern - je nach Deiner Konfiguration und Struktur - nicht aus. Auf die alten CDP Container (AD als auch andere Lokationen) muß das neue Computerkonto Schreibberechtigungen haben, denn wenn dort die CRLs veröffentlicht werden sollen, tut dies ja nun die neue Maschine. Und Du *mußt* die CRLs auch auf die Verteilungspunkte der alten Maschine veröffentlichen, denn dort zeigen ja die von der alten CA ausgestellten Zertifikate hin. Es sei denn, Du hast von Anfang an alle URLs nicht auf den logischen Maschinennamen gebunden, was ich jedoch anhand Deiner Angaben von oben ausschließe. Bezüglich des Enrollments: Wie genau greifst Du denn auf die Webseite zu? Sind beide Clients vom gleichen OS? ALso W7 / W7 oder versuchst Du es von unterschiedlichen OS? Ist der angemeldete Benutzer derselbe usw.? Da es Änderungen in den Webseiten für das Enrollment gab, ist dies wichtig. Ab Vista / W7 ist es empfehlenswert, nicht mehr die Webenrollment Seiten zu nutzen, sondern die MMC. Einige Funktionen sind per Webenrollment schlichtweg nicht mehr verfügbar. Viele Grüße olc

Hi, ok - anders gefragt: GIbt es wie auf dem Urspungssystem zum Beispiel eine Platte C: mit X GB, eine Platte D: mit X GB, die gleich dem Originalsystem sind (Laufwerke als auch bestenfalls ungefährt die Größen). Viele Grüße olc

Hi, wie genau sollen wir DIr mit solchen Beschreibungen weiter helfen? ;) Das bedeutet, wir reden hier ganz offensichtlich nicht von einem SSL Problem. Eine gute Fehlerbeschreibung gäbe uns die Möglichkeit, das zu prüfen. Mit "geht nicht" kann man nichts anfangen. Aha, und der Verwendungszweck heißt genau wie? "Mach LDAP über SSL mit ldp.exe" habe ich bisher nicht gefunden als Schalter zum Erzeugen eines Zertifikats... ;) Du verstehst scheinbar nicht, was ich frage: Bitte gib eine genaue Beschreibung, wie Du vorgegangen bist. Hast Du ein PFX installiert oder nur das *cer importiert. Letzteres *kann nicht* funktionieren, um LDAP/S zu aktivieren. Wo genau hast Du es importiert - in welchen Speicher usw. Ja, wenn man es richtig macht. Von welchem MS Dokument sprichst Du? Nein, außer der "soft-skill Richtlinie", daß man sich ein wenig bemühen muß zu verstehen, was man dort tut. Bitte entschuldige meine deutlichen Worte - aber so geht das nicht. Wenn Du möchtest, daß wir Dir helfen, mußt Du ein wenig genauer werden. Viele Grüße olc

Wieso nicht bemerkt - es hat uns schlichtweg nicht weiter interessiert. :D :p Nein, im Ernst: Tolle Sache, danke für die Zeit, das Geld und die Arbeit, die Du / Ihr ins Board investierst / investiert. :) Viele Grüße olc

Hi, was ist denn der "certificate purpose" des von Dir ausgestellten Zertifikats? Beschreibe noch einmal ganz genau, wie Du vorgegangen bist. Also wie wurde das Zertifikat erstellt, welche Optionen wurden im Zertifikat definiert, wurde der private Schlüssel ebenfalls importiert, gibt es Fehler im Eventlog, wie greifst Du auf den LDAP Server zu (DNS Name, NetBIOS Name, was auch immer) usw. Viele Grüße olc

...ist denn das Disk Layout das selbe wie auf der anderen VM? Viele Grüße olc

Hi, die Antwort lautet: "Ja". ;) SACL und dann siehst Du die ACL Einträge, in denen Du Dich bzw. die entsprechende Admin Gruppe wieder hinzufügst. Es kann nichts kaputt gehen, bevor Du "Ok" klickst. Wenn Du nicht weißt, was Du genau tust, klicke lieber auf "Abbrechen" und schalte einen Dienstleister ein. ;) Viele Grüße olc

Hi, wie gesagt, ich empfehle den LDP Weg zu gehen - schau es DIr bitte noch einmal an. Das ist nicht schwer/tragisch. :) Default schema permissions (die Du dann ggf. nach Deinen Wünschen anpassen mußt) kannst Du recht einfach mit dsacls zurück setzen: C:\> dsacls.exe "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,[b][color="Red"]DC=deine-domain,DC=tld[/color][/b]" /S /T Danach dann noch einmal mittels GPMC in die Policy hinein klicken, es kommt dann ein Dialog, daß die SYSVOL Berechtigungen gerade gezogen werden müssen. Das dann bestätigen und es sollte wieder in Ordnung sein. Viele Grüße olc

Hi, warum nutzt Du die LDP Suche und gehst nicht direkt zu "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=deine-domain,DC=tld"? Dann kannst Du auf das Policy Objekt selbst rechts klicken und wie im Thread oben beschrieben die Sicherheit zurück setzen. Ansonsten kann man auch mit ADSIEdit.msc den "Default Security Desriptor" vom Schema auf das Objekt publizieren, aber das ist eigentlich nicht notwendig. Viele Grüße olc

Hi Exxodos, willkommen an Bo(a)rd, :) schau einmal hier hinein: http://www.mcseboard.de/windows-server-forum-78/gpmc-gpo-zugriff-verweigert-alle-154782.html Viele Grüße olc

Hi, durch veränderte Enrollment-DLLs hat sich einiges von XP zu W7 verändert, siehe dazu auch: AD CS: Web Enrollment Ggf. könntest Du Dir für "nicht-Domänenclients" die AD CS Web Services anschauen: What's New in Active Directory Certificate Services (AD CS) in Windows Server 2008 R2 Viele Grüße olc

Hi, Du hast alle Antworten oben schon bekommen. ;) Viele Grüße olc

Hi, bare metal restore auf unterschiedliche Hardware ist seitens MS nicht supported, da es die von Dir beschriebenen Probleme geben kann. Siehe dazu auch (Tabelle unter "Possible recovery scenarios"): How to move a Windows installation to different hardware Du kannst zwar versuchen, es irgendwie hinzufrickeln, aber es wird keine Garantie geben, daß es klappt. Der Weg dorthin ist im KB ebenso beschrieben. Viele Grüße olc

Hi, Warum antwortest Du dann? Wenn Du die Zeit investiert hättest, hättest Du gesehen, daß das Thema oben schon vom TO besprochen wurde. Viele Grüße olc

...siehe dazu auch meine Anmerkungen zum Vorgehen oben. ;) Ok, es sollte alles relevante gesagt sein. :) Viele Grüße olc