Rotwilderer

Nachdem ich das angeforderte Zertifikat von der root CA expoortiert und bei der ausstellenden CA von Hand installiert habe, hat es funktioniert. Wundert mich nur, dass das nirgends so beschrieben ist.

Hallo zusammen, ich habe eine Root CA und eine Ausstellenden Zertfizierungsstelle, beide laufen unter Windows 2008 R2. Da das Zertifikat der ausstellenden CA bald abläuft, will ich dieses erneuern. Ein entsprechende Anforderung habe ich and die Root CA nach dieser Anleitung gestellt: https://technet.microsoft.com/de-de/library/cc962077.aspx An der root CA kommt die Anforderung auch an und ich kann das Zertifikat ausstellen, allerdings erhält die anfordernde CA das neue Zertifikat nicht. Ich habe die Anforderung auch mal offline mit einer req-Datei gestellt - gleiches Ergebnis. Der Zertifikatsdienst wurde auch vorher beendet, Server habe ich auch mal neu gestartet. Muss ich das ausgestellte Zertifikat noch irgendwie manuelle importieren oder was hab ich sonst falsch gemacht?

Hallo zusammen, seit ein paar Tagen erhalte ich auf einem unserer RODC Server folgende Fehlermeldungen: Protokollname: Directory Service Quelle: Microsoft-Windows-ActiveDirectory_DomainService Datum: 17.08.2016 16:38:54 Ereignis-ID: 2904 Aufgabenkategorie:Konsistenzprüfung Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: ANONYMOUS-ANMELDUNG Computer: Server.domäne.local Beschreibung: Dieses Ereignis dokumentiert zusätzliche REPAIR PROCEDURES zum Auflösen des NTDS KCC-Ereignisses 1311 für einen schreibgeschützten Active Directory- Domänencontroller. Lokale Website: CN=Erkrath,CN=Sites,CN=Configuration,DC=drahtundschutz,DC=local Benutzeraktion: Die Benutzeraktion zum Auflösen des NTDS KCC-Ereignisses 1311 für einen schreibgeschützten Active Directory-Domänencontroller ist mit dem Aktionsplan für einen (vollständig) schreibbaren Active Directory-Domänencontroller identisch, jedoch mit den folgenden Zusatzanforderungen: 1. Wenn das NTDS KCC-Ereignis 1789 direkt neben den NTDS KCC-Ereignissen 1311 und NTDS KCC 2904 protokolliert wird, verwenden Sie das Snap-In "Active Directory-Standorte und -Dienste" mit Fokus auf einem schreibbaren Active Directory-Domänencontroller, um diese Website einem entsprechenden Websitelink hinzuzufügen, und führen Sie dann die Schritte 4 und 5 aus. 2. Das Ereignis 1311 kann zahlreiche Ursachen besitzen. Führen Sie den Aktionsplan im Link "Onlinehilfe des Ereignisprotokolls" eines benachbarten Ereignisses vom Typ 1311 aus. Weitere Informationen finden Sie möglicherweise unter http://support.microsoft.com, oder rufen Sie den MSKB-Artikel "http://support.microsoft.com/default.aspx?scid=kb;EN-US;307593" auf. 3. Alle Korrekturen zur Auflösung des Ereignisses 1311 müssen auf einem Active Directory-Domänencontroller vorgenommen werden, auf dem eine schreibbare Kopie der Active Directory-Partition oder der zu ändernden Gruppenrichtlinie gehostet wird. 4. Wenn der schreibgeschützte Active Directory-Domänencontroller, von dem das Ereignis 2904/1311 protokolliert wird, über keinen gültigen "repsFrom"- Active Directory-Quelldomänencontroller verfügt, führen Sie den folgenden Befehl aus, andernfalls setzen Sie den Vorgang mit Schritt 5 fort: [Hinweis: Für diesen Schritt sind Anmeldeinformationen als Organisationsadministrator erforderlich.] repadmin /add <DN der aktualisierten Active Directory- Partition> <Name des schreibgeschützten Active Directory- Domänencontrollers> <vollqualifizierter Computername des schreibbaren Active Directory-Domänencontrollers> /readonly /selsecrets 5. Lösen Sie die Replizierung vom schreibbaren, in den vorherigen Schritten aktualisierten Active Directory-Domänencontroller auf den schreibgeschützten Active Directory-Domänencontroller mit dem folgenden Befehl aus: [Hinweis: Für diesen Schritt sind Anmeldeinformationen als Organisationsadministrator erforderlich.] repadmin /replicate <Name des schreibgeschützten Active Directory-Domänencontrollers> <Name des schreibbaren Active Directory-Domänencontrollers> <DN der aktualisierten Active Directory-Partition> OR Sie können auch die Benutzeroberfläche von Active Directory-Standorte und -Dienste verwenden, indem Sie die folgenden Schritte ausführen: - Klicken Sie auf die Website mit diesem schreibgeschützten Active Directory-Domänencontroller. - Klicken Sie auf die Konfiguration der Replikation vom/zum ausgewählten Active Directory-Domänencontroller. Protokollname: Directory Service Quelle: Microsoft-Windows-ActiveDirectory_DomainService Datum: 17.08.2016 16:38:54 Ereignis-ID: 1311 Aufgabenkategorie:Konsistenzprüfung Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: ANONYMOUS-ANMELDUNG Computer: server.domäne.local Beschreibung: Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition festgestellt. Verzeichnispartition: CN=Configuration,DC=domäne,DC=local Es gibt für die Konsistenzprüfung nicht genügend Standortskonnektivitätsinformationen, um eine umfassende Gesamtstruktur-Replikationstopologie zu erstellen. Zudem besteht die Möglichkeit, dass mindestens ein Verzeichnisserver mit dieser Verzeichnispartition nicht in der Lage war, die Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an nicht zugreifbaren Verzeichnisservern. Benutzeraktion Führen Sie einen der folgenden Schritte aus: - Veröffentlichen Sie genügend Informationen über Standortkonnektivität, sodass die Konsistenzprüfung eine Route ermitteln kann, durch die die Verzeichnispartition diesen Standort erreichen kann. Diese Option wird empfohlen. - Fügen Sie von einem Verzeichnisdienst mit derselben Verzeichnispartition auf einem anderen Standort ein Verbindungsobjekt zu einem Verzeichnisdienst mit der Verzeichnispartition an diesem Standort hinzu. Wenn keine dieser beiden Aufgaben den Problemzustand behebt, überprüfen Sie die bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht zugreifbaren Verzeichnisserver identifizieren. Des Weitern wird der Standortübergreifende Messagindienst nicht automatisch gestartet, dies funktioniert nur manuell. Zu meiner Umgebung: Alle Server laufen unter W 2008 R2, Domäne 2008 R2 Ich habe 3 Schreibbare DCs am Hautpstandort und an 3 Niederlassungen jeweils 1 RODC. Die Replikaton schien auf dem betroffenen RODC aber einwandfrei zu laufen, auch das AD Replication Stauts tool hat keine Fehler erkannt. Ich habe, wie in den Fehlermeldungen vorgeschlagen, ein repadmin /add Befehl abgesetzt, ich erhalte aber die Meldung: DsBindWithCred mit rodc.domäne.lokal ist fehlgeschlagen mit Status 1 722 (0x6ba): Der RPC-Server ist nicht verfügbar. Der Fehler tritt seit dem letzten Microsoft Update auf, nachdem der Server neu gestartet wurde. Auf den anderen RODCs wurden die selben Updates gefahren, dort funktioniert aber alles.

Hallo, ich versuche in meiner Testumgebung unter Windows 2012 R2 eine Domäne mit der Powershell aufzusetzen, die Domänendienste wurden bereits erfolgreich installiert. Jetzt habe ich versucht, die Umgebung mit folgendem Befehl zu testen: Test-ADDSForestInstallation -DomainName "corp.contoso.com" -NoRebootOnCompletion Nach Bestätigung mit Enter erscheint folgende Eingabeaufforderung: SafeModeAdministratorPassword: Wenn ich nun ein von mir gewähltes Passwort eingebe, erscheint nach Drücken der Enter-Taste folgende Fehlermeldung: Test-ADDSForestInstallation : Es wurde kein Positionsparameter gefunden, der das Argument "SafeModeAdministratorPassword bestätigen" akzeptiert. In Zeile:1 Zeichen:1 + Test-ADDSForestInstallation -DomainName "corp.contoso.com" -NoRebootOnCompletion + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Test-ADDSForestInstallation], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.DirectoryServices.Deployment.PowerShell.Commands.T estADDSForestInstallationCommand Ich habe auch schon mehrere Passwörter probiert und ja, natürlich auch mal neu gestartet und die Powershell mit Adminrechten gestartet, aber es funktioniert nicht. Normalerweise müsste doch nach der Eingabe des Passworts eine Bestätigung angefordert werden.

So, ich habe das Problem gelöst: Es lag an der Kryptographie, ich habe den falschen Algrorythmus ausgewählt. Standardmäßig wird bei der Erstellung der Zertfikatsvorlage immer der RSA Algorythmus eingestellt, es wird aber für EFS eine ECC Kryptographie gefordert: https://technet.microsoft.com/de-de/library/dd630631%28v=ws.10%29.aspx Drauf gekommen bin ich über folgenden Beitrag: http://www.journeyofthegeek.com/?p=137 Am Ende dieses Artikels stand der entscheidene Hinweis.

Ich meinte natürlich EFs Recovery Agent. Habe ich woh in der Aufregung durcheinander gebracht. :) Wie dem auch sei, ich habe mir die von dir geposteten Artikel druchgelesen. Dort ist beschrieben, dass der erste Dom-Admin der die Domäne erstellt hat, das EFS-RA Zertifikat automatisch erstellt bekommt. Da ich die Domäne von meinem Vorgänger geerbt habe kann ich nicht mit gewissheit sagen, welcher User das ist. Ich habe auf jeden Fall bei allen in frage kommenden Accounts die Zertifikatsspeicher auf dem ersten DC durchsucht, habe aber kein Zertifikat gefunden. Funktioniert das ganze denn noch wenn ich diesen Schlüssel bzw. das Zertifikat nicht mehr habe? Ich habe das entsprechende EFS-RA Zertifikat angefordert und exportiert, es dann inder Gruppenrichtlinie direkt importiert. Es wird der Account mit dem Zertifikat auf angezeigt. Ich erhalte beim Verschlüsseln aber immer noch die Meldung: Falscher Parameter!

Ja, einen Key Recovery Agent habe ich aus der Vorlage "Key Recovery Agent" erstellt, d.h. der Dom-Admin hat das Zertifikat angefordert und ich habe diesen User in der Gruppenrichtlinie unter Computerkonfiguration => Richtlinien => Windows Einstellungen => Sicherheitseinstellungen => Richlinien für öffentliche Schlüssel => "Verschlüsselndes Dateisystem" "Datenwiederherstellungs Agent hinzufügen" hinzugefügt und das entsprechende Zertifikat ausgewählt. (Siehe Oben). Wenn der selbe User allerdings verucht unter dem gleichen Pfad die Option "Datenwiederherstellungs Agent erstellen" anwähle, dann bekommte ich di oben genannte Fehlermeldung. Wo liegt denn eingentlich der Unterschied zwischen erstellen und hinzufügen?

Ich habe jetzt noch mal ein bisschen selbst rumprobiert und mit ist aufgefallen, dass die Schlüssel für die angeforderten Zertifikate nicht archiviert werden, obwohl ich die Schlüsselarchvierung aktiviert habe (KRA eingerichtet, Zertfikat wird als "Gültig" angezeigt). In den Vorlagen habe ich ebenfalls die Haken "Privaten Schlüssel für die Verschlüsselung archivieren" und "Erweiterten symmetrischen Algorythmus zum senden des Schlüssels an die Zertifierungsstelle verwenden" gesetzt. In der Ansicht "Ausgestellte Zertifikate" erscheint bei den aus den oben genannten Vorlagen erstellten Zertifikaten in der Spalte "Archivierter Schlüssel" kein Eintrag. Vielleicht ist das auch die Ursache, warum die Verschlüsselung nicht funktioniert. Weiß hier jemand woran das liegen kann?

Hat denn keiner dazu eine Idee?

Hallo zusammen, ich habe eine W2K8 R2 Domäne und möchte darüber die EFS Verschlüsselung einrichten. Folgendes habe ich durchgeführt: Zertifizierungsstelle ist eingerichtet KRA Zertifikat wurde ausgestellt und vom Dom-Admin angefordert EFS-Zertifkat (Verschlüsselndes Dateisystem) wurde mit folgenden Parametern ausgestellt: Vorlage für windows Server 2008 Enterprise Zertifikat in Active Directory veröffentlichen Autoenrollment für authentfizierte Benutzer unter "Sicherheit" angehakt Zertifikat für Schlüsselweiderherstellung mit den gleichen Einstellungen (Außer Berechtigungen, die habe ich nur für die Domänen-Admins gesetzt) Datei-Wiederherstellung-Agent hinzugefügt Gruppenrichtlinie in der Root der Domäne für EFS konfiguriert und das zuor ausgestellt Zertifikat für die EFS-Verschlüsselung angegben Wenn ich nun an einem Client versuche einen Ordner/Datei zu verschlüsseln, erscheint folgende Fehlermeldung: Beim Übernehmen der Attribute für die Datei ist ein Fehler aufgetreten: Dateipfad/Name Falscher Parameter. Das EFS-Zertifikat wird aber vom Client abgerufen, es erscheint auch im Zertifikatsspeicher. Ich habe den Verdacht, dass es am Wiederherstellungs-Agenten liegt. Wenn ich unter "Verschlüsseltes Dateisystem" einen Weiderherstellungs-Agenten erstelle, wird dieser mit dem Standard EFS-Wiederherstellungs-Agent Zertifikat angelegt. Lösche ich dieses, kann der Wiederherstellungsagent nicht erstellt werden, es kommt die Fehlermeldung: Es kann kein Datenwiederherstellungs-Agent erstellt werden. Die angeforderte Zertfikatvorlage wird von dieser Zertifizierungsstelle nicht unterstützt. Wenn ich einen Datenwiederherstellungs-Agent hinzufüge, klappt dies wunderbar mit dem zufor erstellten und angefordertem Zertifikat. Mit stellt sich dann außerdem die Frage, was der Unterschied zwischen einem Wiederherstellungs-Agent hizufügen und erstellen ist?

Ich habe den Fehler selbst gefunden: In der Gruppenrichtlinie war nicht das richtige Zertifikat hinterlegt, dadurch hat sich der Client ein selbstsigniertes Zertifikat ausgestellt.

Hallo zusammen, ich würde in usnerem Unternehmen gerne auf verschiedenen Lapots über EFS Dateien verschlüsseln, die von verschiedenen Domänen-Administratoren wiederhergestellt bzw. entschlüsselt werden können sollen. Wir haben eine Windows 2008R2 Domäne mit Windows 7 Clients. Folgendes habe ich bisher eingerichtet: Eine austellende Zertifizierungsstelle, die die Zertifiakte ausstellt, ist eingerichtet. Zertifikate für die EFS-Wiederherstellung wurden erstellt und von dem jeweiligen Administrator angefordert. Es wurde auf oberster Domänenebene eine Gruppenrichtlinie eingerichtet, in welcher unter "Richtlinien für öffentliche Schlüssel" => "Verschlüsselndes Dateisystem" die Administatoren als Wiederherstellungs-Agenten hinzugefügt wurden. Wenn auf einem Client nun eine Datei verschlüsselt wird, könne die oben genannt hinterlegten Administratoren die Dateien trotzdem nicht entschlüsseln? Was habe ich vergessen oder könnte ich übersehen haben?

Danke für die Antworten. Ich habe es schon befürchtet, dass es keine technische Lösung gibt. Es ist leider vereinzelt vorgekommen, dass einige (wenige) Benutzer das Notebook aus der Domäne genommen haben, angeblich ist es dann schneller :confused: . Der User dein Feind... :D Mit ist bekannt, dass dies möglich ist. Allderings sind gerade die älteren Programme, die über verschiedene Schnittstellen mit Anlagen kummunizieren, ohne Adminrechte recht "zickig".

Hallo zusammen, wir haben in unserer Firma mehrere Notebooks von Aussendienst Mitarbeitern, die aus verschiedenen Gründen lokale Adminrechte benötigen. Leider haben die Benutzer auch damit das Recht, den Computer aus der Domäne zu entfernen. Wie kann man das deaktivieren bzw. die Benutzerrechte so ändern, dass nur Domänen-Admins die Computer aus der Domäne entfernen können?

Man kann es kaum glauben, aber ich habe die Installation doch noch auf dem RODC hinbekommen! Für die Installation des SQL muss im AD folgende Gruppe erstellt und auf den RODC repliziert werden: SQLServer2005SQLBrowserUser$Servername Für die Installation des WSUS müssen folgende Gruppen erstellt und repliziert werden: WSUS-Administratoren WSUS-Berichterstatter Diese beiden Gruppen scheinen aber nur für Windows 2008 R2 zu gelten, under 2012 R2 heißen diese: WSUS Administrators WSUS Reporters Vielen Dank an Daniel für den Hinweis mit den SQL-Sicherheitsgruppen und an Alle, die sich mit eingebracht haben.