olc

Hi Dosihris, willkommen an Board, :) zum Thema AD LDS: AD LDS ist der "LDAP Kern" von Active Directory, ohne die dabei vorausgesetzten Dienste wie DNS, Kerberos etc. D.h. zum Beispiel reine LDAP Auth. / basic authentication geht damit. Zur Frage NAV: Das weiß ich nicht, da ich die Grundlagen für NAV nicht kenne. Wenn nur ein simple oder secure LDAP bind notwendig ist oder auch eine lokale Benutzerverwlatung für dich kein Problem darstellt, dann könnte es funktionieren. Gibt es dazu keine Dokumentation von NAV / Dynamics? Viele Grüße olc

Hi, der Config NC ist kein "untergeordneter Container" - es ist ein eigener NC. Daher funktioniert das in der Form nicht. Ich habe den Hintergrund für das Vorhaben nicht so richtig verstanden - was genau willst Du erreichen? Viele Grüße olc

Hi, DU mußt bei einer LDAP Suche immer den NC angeben, der durchsucht werden soll - das ist Teil der LDAP Spezifikationen. Da der Domänen NC in AD Umgebungen der Standard-NC ist, der bei keiner Angabe eines NCs durchsucht wird, ist das Verhalten normal. Wieso gibst Du nicht einfach den NC an, der durchsucht werden soll? Das wäre der richtige Weg und ich sehe da gerade keinerlei Nachteile. Viele Grüße olc

Hi, also Punkt 3 der oben genannten Möglichkeiten. Danke für die Rückmeldung und Gruß olc

Hi Tom, aus Sicherheitssicht ist es keine optimale Konfiguration, einen DHCP Server auf einem DC zu betreiben. Wenn es also andere Systeme gibt, auf denen Du den DHCP Server laufen lassen kannst, würde ich persönlich das empfehlen. Wenn das nicht möglich ist, schau zumindest einmal in den folgenden KB, der einen Workaround zeigt: Event ID 1056 Is Logged After Installing DHCP Viele Grüße olc

Hi, in der Fehlermeldung sind ja mehrere potentielle Problemquellen angegeben, etwa: - falsche Berechtigungen auf dem Template (Computer oder User hat keine "read" und "enroll" Berechtigungen) - die CA ist keine Enterprise CA und daher nicht über das IIS Interface zu erreichen - das Zertifikat der Root CA bzw. die Zertifikate der Zertifikatkette sind nicht auf dem IIS installiert. Prüf erst einmal die drei Punkte, danach schauen wir weiter. ;) Viele Grüße olc

Hi, doch, die Rolle kann auch auf einem Workgroup Server hinzugefügt werden. Es muß also etwas auf dem System nicht stimmen, wenn Du die CA nicht auswählen kannst. Viele Grüße olc

Hi, eine eigene Zertifizierungsstelle installiert man nicht "mal eben nebenbei". Von daher würde ich von der Idee stark abraten, Dir eine eigene CA zu installieren. Generell kannst Du das jedoch aber auch tun, als sogenannte Stand-Alone CA. Dann muß das Webenrollment oder "offline Requests" für die Beantragung von Zertifikaten genutzt werden. Das ist aufwändiger als eine "AD integrierte" Enterprise CA zu betreiben. Viele Grüße olc

Hi, hast Du Dir den Link bzw. die "Enroll on behalf of" Option angeschaut? Das sollte das Thema sein, welches Du suchst. :) Viele Grüße olc

Hi, das Update steht nicht für Windows 2000 zur Verfügung. Daher kannst Du das Webenrollment nicht von 2008 auf 2000 nutzen. Die Alternative ist ein Enrollment mittels MMC auf dem 2008er oder ein Upgrade der Windows 2000 CA. BTW: ziemlich genau 14 Tagen läuft der (extended) Support für Windows 2000 aus. Allerhöchste Zeit sich um neue Systeme zu kümmern. Viele Grüße olc

Hi, wie oben schon angesprochen könntest Du für alle Fälle noch einmal ein -repairstore durchführen. Aber vermutlich wurde das Zertifikat bei Erstellung oder Import als "nicht exportierbar" markiert - dann gibt es keine "offizielle" Möglichkeit. Viele Grüße olc

Hi, wie genau hast Du den Restore durchgeführt? Im Grunde hast Du die Antwort auf Deine Frage oben schon bekommen oder was genau ist unklar? :) Viele Grüße olc

Hi, natürlich - die Möglichkeit hast Du auch. "Enroll on behalf of" ist das Stichwort dazu: http://technet.microsoft.com/en-us/magazine/2007.08.securitywatch.aspx Das hat dann aber nichts mehr mit einem Autoenrollment zu tun. ;) Viele Grüße olc

Hi, wenn der Benutzer das Zertifikat vor der WLAN Anmeldung benötigt, muß er sich mindestens ein Mal (oder sein Rechner, wenn es auf Computerbasis läuft) mit Netzwerkverbindung angemeldet haben. Zur Not also mit LAN-Kabel. Viele Grüße olc

Hi, der Port wird in der HTTP URL hinter einem Doppelpunkt angegeben. D.h. es gibt keinen gesonderten Punkt dafür. Die Form wäre also "http://crl.domain.tld:8080/CertEnroll/...". Viele Grüße olc

Hi oLLi!, willkommen an Board, :) für bestehende Zertifikate kannst Du die URL nicht mehr anpassen, lediglich für neu ausgestellte. Die Optin dafür findest Du in den Eigenschaften der CA (Rechtsklick auf den Namen der CA in der CA MMC) oder direkt in der Registry unter "HKLM\System\CurrentControlSet\Services\CertSrv\Configuration\Name der CA". Ich persönlich würde den MMC Weg empfehlen, da Dir die GUI Hilfestellung zum Format der Einträge gibt. Viele Grüße olc

Hi, ein paar Absätze und Satzzeichen mehr erhöhen die Lesbarkeit ungemein. ;) D.h. Du hast eine neue Policy erzeugt und darin die Autoenrollment Einstellungen definiert? Die Default Domain Policy unter Windows Server 2003 hat einen Anzeigefehler, was die Standardeinstellungen des Autoenrollments betrifft - daher die Nachfrage. Welche der Optionen hast Du in der Autoenrollment Policy aktiviert? Bestenfalls beide Haken setzen (+ "Enabled" natürlich). Ob die Autoenrollment Einstellungen greifen, siehst Du auf einem Client unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment" --> "AEFlags". Der Wert sollte bei gesetzten Optionen vorhanden und größer "0" sein (ich denke "7" oder "9"). Fehler im Ereignisprotokoll "Application" der Clients? Viele Grüße olc

Hi, habt Ihr beim Export den privaten Schlüssel ebenfalls gelöscht (also im entsprechenden Dialog den Haken gesetzt) Falls ja (und ihr habt das Zertifikat inkl. des privaten Schlüssels nicht gesichert), dann habt ihr schlechte Karten. Falls ihr nur das Zertifikat gelöscht habt, dann importiert das *.cer wieder und repariert die Zuordnung mittels "certutil -repairstore MY "SERIENNUMMER DES ZERTIFIKATS". Viele Grüße olc

Hi Andi, grundsätzlich kannst Du eine Sicherung wiederherstellen, wenn es "unterstützte" Backupmechanismen sind, also etwa Systemstate-Backup mittels VSS. Dann brennt da nichts an in Bezug auf Konflikte etc. Schlecht würde es nur werden, wenn Du eine Sicherungsart nutzt, die DFSR nicht supportet. Dann kann es im schlimmsten Fall zu Problemen kommen - aber selbst hier bringt DFSR einige Schutzmechanismen mit. Gut, daß es nun wieder funktioniert. :) Viele Grüße olc

Hi cypress73, willkommen an Board, welcher Gruppe hast Du Autoenroll Berechtigungen gegeben - Benutzer- oder Computergruppen? Für Computer Autoenrollment wäre letzteres notwendig. Wurde das Autoenrollment per GPO im Computerteil der Policy aktiviert, greift die Policy überhaupt auf dem Client? Was steht im Eventlogs des Clients, was im Eventlog (oder Failed Requests) der CA? Viele Grüße olc

Hi, die Frage ist, warum es überhaupt zu dem DB-Fehler gekommen ist. AV-Scanner nicht mit den richtigen Ausschlüssen konfiguriert? Wenn der betreffende Server nicht der "Master" für Dich ist (also wenn es nicht der Server ist, dessen Daten "autorativ" sein sollen, könntest Du Dich in den SYSTEM Kontext heben, die DB löschen und den DFSR Dienst neu starten. Dann wird eine Initialreplikation angestoßen und der Server ist "Slave", also Non-Primary. Die geänderten Daten werden also auf diesem System dann durch die anderen Partner "überschrieben" werden. Wenn der Server Dein "Master" ist, dann solltest Du das eher nicht so durchführen, da es sonst zu Datenverlusten kommen kann. In den System-Kontext kommst Du beispielsweise mit PsExec: psexec.exe \\localhost -s cmd . Viele Grüße olc

Hi Rinus, wurde nur das Zertifikat gelöscht oder auch der private Schlüssel? Wie genau ist der Löschvorgang erfolgt? Falls "nur" das Zertifikat weg ist: Habt Ihr das Zertifikat selbst noch irgendwo herumliegen? Zum Beispiel auf irgend einem Client? Ggf. könnte man dann das Zertifikat wieder mit dem privaten Schlüssel verbinden (certutil -repairstore). Wenn Ihr beides nicht mehr habt sieht es schlecht aus mit einer "Wiederherstellung". Viele Grüße olc

Hi, was genau heißt "es gibt Probleme"? Steht in der GPO Beschreibung nicht eher etwas von "Vista aufwärts"? Viele Grüße olc

Hi Martin, das hatte ich verstanden ;) - die Frage ist, warum Du den Remote Share Zugriff verhindern möchtest? Was ist der Sinn dahinter - technisch Probleme zu lösen, die eigentlich an den Prozessen / der internen Kommunikation liegen? Ist der Fileserver gleichzeitig Terminal Server? Über welche Größenordnung sprechen wir hier - eine solche Rollenmischung ist oftmals nicht optimal. Viele Grüße olc

Hi, Du greifst auf das Share nicht im System / Computerkontenkontext zu - daher kann das ist der Form nicht klappen. Der Benutzer authentifiziert sich beim Zugriff auf das Share, nicht der Computer. Was genau möchtest Du damit erreichen bzw. was ist der Hintergrund für dieses Vorhaben? Vielleicht läßt sich das ja auch anders lösen. Viele Grüße olc