Mrz 16 2009

Windows 2003 Domänencontrolller – Certificate AutoEnrollment schlägt fehl

Category: Arbeit,Technik,Windows Server — trekkie22 @ 5:33 pm

Und wieder mal hat es mich eingeholt. Wir haben eine neue Domäne in Betrieb genommen und prompt schlug wieder das Rechte-Problem beim Autoenrollment zu.

Event Type: Error
Event Source: AutoEnrollment
Event Category: None
Event ID: 13
Date:  16.03.2009
Time:  15:44:04
User:  N/A
Computer: <Servername>
Description:
Automatic certificate enrollment for local system failed to enroll for one Domain Controller certificate (0x80070005).  Access is denied.

Hintergrund: Der Domänencontroller hat seit Windows Server 2003 Servicepack 1 keine Rechte mehr, ein Zertifikat anzufordern. Die Rechteverwaltung der Zertifikatsdienste wurde mit Servicepack 1 verändert, es gibt jetzt eine neue Gruppe „CERTSVC_DCOM_ACCESS“, in der die Rechte für den DCOM-Access verwaltet werden.

Wenn man die Zertifizierungsstelle nun in die Stammdomäne installiert, wird die Gruppe angelegt und die Rechte für die Stammdomäne werden erteilt (Domänencomputer und Domänenbenutzer). Schon hier fehlen die Domänencontroller – will also ein DC ein Zertifikat anfordern, hat er Pech gehabt. In meinen Augen eine blödsinnige Konfiguration, da gerade die DCs doch eigentlich am dringendsten die Zertifikate brauchen.

Noch schöner wird es, wenn man Child-Domänen anlegt – die tauchen in der Gruppe nämlich per Default erstmal gar nicht auf, man muß sie manuell hinzufügen, ansonsten hat man in der kompletten Domäne auf jedem Rechner das Problem, daß das AutoEnrollment fehlschlägt. Konkret wären aus der betroffenen Domäne die Gruppen „Domänenbenutzer“, „Domänencomputer“ und „Domänencontroller“ hinzuzufügen.

Das AutoEnrollment kann man mit certutil -pulse auf der Kommandozeile manuell anstoßen, das Eventlog gibt dann umgehend Auskunft, ob es funktioniert hat.

Dazu gibt es natürlich auch einen Knowledgebase-Artikel: http://support.microsoft.com/kb/903220/en-us

Jan 29 2009

Exchange Domainprep

Category: Arbeit,Technik — trekkie22 @ 11:00 am

Gestern habe ich eine neue Domain im Active Directory in der Firma angelegt, um ein bischen besser mit einigen Berechtigungen jonglieren zu können. Prinzipiell ja kein Problem, DNS-Zone anlegen, auf dem ESX-Server schnell einen neuen Server deployen, dcpromo, domainprep für die Exchange-Umgebung, fertig.

Ja Pustekuchen. Die Domain an sich hat funktioniert, nur Exchange mochte nicht.

Ich konnte zwar eine Mailbox anlegen und auch die Eigenschaften bearbeiten, aber der RUS hatte immer ein kleines, aber unpraktisches Problem: Beim Erstellen der Mailadressen fiel er jedesmal auf die Schnauze – zu wenig Rechte. Äußert sich in einem Eventlog-Eintrag:

Ereignistyp: Fehler
Ereignisquelle: MSExchangeAL
Ereigniskategorie: LDAP-Operationen
Ereigniskennung: 8270
Datum:  28.01.2009
Zeit:  23:02:51
Benutzer:  Nicht zutreffend
Computer: <Computername>
Beschreibung:
LDAP gab beim Importieren der Transaktion
dn: <SID=Hier steht die SID>
changetype: Modify
member:add:<GUID=Folgt GUID des betroffenen Objekts>
–
den Fehler [32] Insufficient Rights zurück. DC=XXX,DC=YYY,DC=ZZZ

Davon gibts dann vier Stück mit leicht unterschiedlichem Inhalt, aber immer der selben Ursache und den selben Fehlercodes. Ich habe den Domainprep mindestens zwanzig mal mit verschiedensten Usern laufen lassen und jeden Hinweis aus der Microsoft-KB ausprobiert, den ich dazu finden konnte. Ohne Erfolg.

Die Lösung war am Ende allerdings ganz einfach – ich hatte durch Zufall in einem Forum beim suchen in einem Nebensatz den Hinweis gefunden, daß man einen DomainPrep nicht nur mit dem Setup von der Exchange-CD starten kann, sondern auch mit der update.exe aus dem Servicepack 2.

Nachdem ich das dann einmal ausgeführt hatte (pfad_zur_update.exe\update.exe /domainprep), stimmten plötzlich auch die Berechtigungen. Der Hinweis von Windows 2003 SP2, daß es mit dem „originalen“ Exchange-Setup Kompatibilitätsprobleme gibt, ist hier also wohl wirklich ernst zu nehmen. Der Domainprep scheint so jedenfalls nicht zuverlässig zu funktionieren.