none
Autoenrollment für XP Clients RRS feed

  • Allgemeine Diskussion

  • Hallo

    ich hab mir eine 2 stufige CA auf Basis von 2012 aufgebaut. DC's sind auf 2003 aber schon auf Schema 2012 erweitert.

    Nun habe ich Autenrollment eingerichtet und dies erfolgreich getestet allerdings nur mit windows 7.

    Jetzt habe ich einen XP Client auf dem ich mich mit dem gleichen User angemeldet habe der unter Windows 7 erfolgreich automatisch Zertifikate beziehen kann.

    Mit dem XP Client bekomm ich aber keine Zertifikate. Wenn ich vom XP CLient ein certutil -ping versuche bekomme ich

    Server konnte nicht erreicht werden: Ein Fehler im Sicherheitspaket ist aufgetreten. 0x80070721 (WIN:1825)

    Der Client bekommt alsp grundsätzlich keine Verbindung zur CA und kann dann natürlich kein Zertifikat beziehen.

    Folgendes habe ich ausprobiert: http://social.technet.microsoft.com/Forums/en-US/6711baa0-bff5-402d-8baf-a57e2d3ec876/problem-with-autoenrollment-of-a-windows-2003-server-to-a-windows-2008-ca-server

    Ich habe auf meiner CA die entsprechenden Gruppen hinzugefügt und weiß ehrlich gesagt nicht wo ich sonst noch schauen könnte außer in den DCOM Einstellungen.

    Netzwerkseitig funktioniert alles. Ein normaler ping geht durch.

    Eine sache die ich noch in verdacht hatte war

    https://social.technet.microsoft.com/wiki/contents/articles/6289.certification-authority-authentication-level-incompatible-with-windows-xp.aspx

    aber ich habe dies deaktivert und es zeigt keinen effekt.

    Mittwoch, 16. Oktober 2013 16:21

Alle Antworten

  • Evtl. ist es nicht das Autoenrollment, sondern die SChlüssellänge. XP kann keine Root Zertifikate mit mehr als 2048 Bit importieren. 

    Tschö
    Mark Heitbrink - MVP Windows Server - Group Policy
    Homepage: www.gruppenrichtlinien.de - deutsch
    GPO Tool: www.reg2xml.com - Registry Export File Converter

    Donnerstag, 17. Oktober 2013 14:01
  • Ich hab Root Cert und Sub Cert mit genau 2048 Bit. Auch alle ausgestellten Zertifikate

    Hab extra Sha1 verwendet da das nur unterstützt wird.

    Hab auch in der CAPolicy AlternateSignatureAlgorithm auf 0 gesetzt da ich gelesen hatte das das sonst nicht klappt.

    Donnerstag, 17. Oktober 2013 14:51
  • Mach bitte sowohl auf dem betroffenen Client als auch gleichzeitig auf der zugehörigen Issuing CA einen Network-Trace und analysiere die Pakete nach Fehler.

    Dazu wäre parallel das CAPI2-Logging (s. http://blogs.technet.com/b/pki/archive/2006/12/16/the-easy-way-of-crl-troubleshooting-in-windows-vista.aspx) ebenso auf Client und Server zu aktivieren und auszuwerten.

    Bei beiden Network-Traces solltest Du vorher (als Admin mit "elevated privileges") folgendes ausführen und sämtliche, nicht benötigte - soweit möglich - Applikationen und Dienste beenden, um einen sauberen Trace zu bekommen:

    klist purge
    REM "klist -li 0x3e7 purge" works only on Windows Vista and higher
    klist -li 0x3e7 purge
    ipconfig /flushdns
    NBTStat -R
    dfsutil /pktflush
    dfsutil /spcflush

    Weitere Hintergrundinformationen:

    Troubleshooting PKI Problems on Windows
    http://technet.microsoft.com/en-us/library/cc749296.aspx

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Donnerstag, 17. Oktober 2013 16:46
  • Ich habe den Tracert gemacht und konnte nur einen Kerberos KRB_AP_ERR_MODIFIED im Log sehen womit ich nicht viel anfangen konnte.

    Hab auch noch parallel nen Case aufgemacht und sind dan über einen Hotfix für XP Kerberos der dann den Fehler im Tracert auch im Event Log erscheinen läßt, auf ein Windows Server 2012 Hotfix bezüglich dieses Fehlers gekommen den ich noch ausprobieren muss.

    Ich hoffe das dieser das Problem schon alleine behebt.


    • Bearbeitet Kerm_IT Donnerstag, 24. Oktober 2013 18:34
    Donnerstag, 24. Oktober 2013 18:33