von Neulich im Test Lab: Es kamen keine Benutzer-Zertifikate mehr auf den Mobile Devices an. Ein Klassiker, den ich in den vergangenen Jahren schon in vielen verschiedenen Umgebungen erleben durfte. Früher hauptsächlich zur Authentifizierung beim Zugriff auf Exchange genutzt, können Zertifikate inzwischen direkt (d.h. ohne ADFS) beim Zugriff auf Azure AD genutzt werden. Dadurch erhalten Benutzer eine sichere (phishing-resistente) Alternative zu Username+password – ein bequemer Schritt in die Richtung „passwordless“ oder zumindest in eine Passwort-ärmere Zukunft. Entsprechend attraktiv ist es, Zertifikate auf verwalteten Endgeräten bereitzustellen. Im konkreten Fall geht es um iPhones, das Verfahren ist aber nahezu identisch für andere Plattformen.
Die Ausgangslage ist eigentlich immer dieselbe:
Viele Zertifikate sind da, nur die wichtigen nicht. Die Zahl der „Device Identity Certificates“ ist zu niedrig, es gibt 1-2 Stück und wenn man näher hinschaut, sind dies nicht die spannenden, die von der eigenen CA kommen. Das Problem tritt bei allen neu ausgerollten Geräten auf. Ebenso betroffen sind Geräte, die ihr Zertifikat erneuern möchten.
Wenn hingegen alles in Ordnung ist, sieht es wie folgt aus, es gibt mindesten 3 Device Identity Certificates:
Und mindestens eines davon kommt von der eigenen CA und ist für den User (oder das Device) ausgestellt.
Bye bye NDESPlugin.log
Es gibt sehr gute und umfangreiche Troubleshooting Infos zum Thema. Z.B. hier und hier – und das sind nur 2 von hunderten von hilfreichen Artikeln. Dummerweise beziehen sich viele der enthaltenen Tipps auf eine seit Juli 2021 abgekündigte Version des Intune Certificate Connectors, die unter dem Namen „Microsoft Intune Connector“ bekannt war. Den entsprechenden Hinweis dazu findet man z.B. hier, in den meisten anderen Artikeln bleibt dies aber (noch) unerwähnt.
Mit dem runderneuerten „Certificate Connector for Microsoft Intune“, auch bekannt als „Microsoft Intune Certificate Connector“ hat sich… Moment, denkt hier noch jemand bei dieser kreativen Namensgebung an…
„Verzieh dich!
Judäische Volksfront, Quatsch!
Wir sind die Volksfront von Judäa!„
DAS LEBEN DES BRIAN
Herrlich…:-D. Nun gut, beim neuen Connector hat sich aber tatsächlich eine Menge geändert:
Wo früher noch etliche Komponenten miteinander interagierten und jede einzelne ihren Status protokollierte, gibt es nun mehr oder weniger eine Black Box. Zugegeben: Die alte Lösung war schon eine Zumutung und erinnerte ein wenig an ein kompliziertes Uhrwerk. Wenn alles lief, war es interessant, dabei zuzusehen, wie 1000 Rädchen ineinandergriffen und am Ende ein Zertifikat herauskam. Aber der Weg dorthin war steinig und wehe, es gab irgendwo Änderungen. All die wirklich guten Artikel zum Troubleshooting gibt es ja gerade deshalb, weil so viele Kunden Probleme damit hatten. Die Zeit war reif für Tabula rasa. Es gibt nun kein separates NDES Plugin mehr, keinen Certificate Registration Point, etc. und entsprechend keine jeweiligen Log-Dateien.
EventLog
Stattdessen werden nun Einträge im EventLog produziert. Wenn alles gut läuft, sieht man für jedes Zertifikats-Deployment 4 Einträge im EventLog des NDES-Servers mit IDs aus dem 4000er Bereich:
Ansonsten gibt es viel Grundrauschen mit Events aus dem 5000er Bereich und das war es im Normalfall auch schon. Mein Problem war dort aber leider nicht zu finden. Es gab nur das Grundrauschen, sonst passierte hier rein gar nichts.
Schnelltest
Soweit, so schlecht. Eine meiner ersten Aktionen ist normalerweise 1 – 2 URLs zu prüfen, weil es am schnellsten geht:
- https://<externerDNS-Name>/certsrv/mscep?operation=GetCACaps&message=MyDeviceID
Diese URL liefert eine kurze Liste von Parametern. Hierüber tut der Server seine unterstützten „Fähigkeiten“ (-> Capabilities, kurz Caps) kund. Das sieht dann z.B. so aus:
- https://<externerDNS-Name>/certsrv/mscep?operation=GetCACert&message=MyDeviceID
Durch diese URL wird das CA-Zertifikat sowie die beiden RA-Zertifikate des NDES-Servers heruntergeladen. Übrigens kann man die heruntergeladene Datei umbenennen, um hineinzuschauen. Einfach die Endung .p7b anhängen, dann sieht es nach einem Doppelklick z.B. so aus:
Da die beiden URLs klaglos funktionierten, ging es nun ans Heraussieben der noch relevanten Aktionen aus den „alten“ Troubleshooting-Artikeln.
Failed requests
Schnell erledigt ist ein kurzer Blick auf die CA. Dort erscheinen unter Umständen Einträge unter „Failed requests“, wenn der Antragsprozess denn soweit kommt. In meinem Fall leider nichts.
Diagnose-Skript
Teilweise relevant und ein guter Startpunkt ist ein von Microsoft zur Verfügung gestelltes Skript, das sich in der Vergangenheit zur Diagnose bewährt hat. Da es auf den alten Connector ausgelegt ist, produziert es einige irreführende Fehlermeldungen, liefert dennoch aber viele nützliche Informationen.
In meinem konkreten Fall ergab sich jedoch kein relevanter Ansatzpunkt, alles lt. Skript OK bzw. erwartete Fehler.
Unter anderem prüft das Skript, ob das relevante Certificate Template in der Registry des NDES Servers eingetragen ist – das hatte ich schon vorher abgehakt:
Weiter im Text…
Publishing
Wie bei vielen Kunden auch ist in meinem Fall der NDES Server über Azure Application Proxy veröffentlicht. Die Konfiguration ist sehr simpel: Interne URL, externe URL, Pre-Auth auf Passthrough, fertig. Passt alles, nichts zu bemängeln.
Und die AAP Connectors waren auch „alive“.
Dass das Publishing prinzipiell funktioniert, hatten eigentlich auch schon die 2 URLs am Anfang und das o.g. Skript bestätigt.
IIS-Log
Beim IIS-Log dann endlich eine heiße Spur:
Sobald ein device versuchte, Zertifikate zu beantragen, erschienen im IIS Log des NDES Servers „GetCACert“ und „GetCACaps“ Anfragen, die zunächst mit Status code 301 und dann mit 200 quittiert wurden. Dann aber folgte jeweils ein 405 bei „PKIOperation“. Neue Ereignisse tröpfeln übrigens immer mit etwas Verzögerung ins IIS Log – es liegen ca. 30 bis 60 Sekunden dazwischen.
Hier nochmal etwas übersichtlicher via httplogbrowser:
Was heißt das?
Zunächst können die Geräte offenbar den Server erreichen und dort ihre Anfragen loswerden. Das ist schon mal gar nicht schlecht. Das Publishing via Azure Application Proxy scheint also wie gesagt schon mal prinzipiell zu funktionieren.
In diesem Artikel findet man eine ganze Menge an Informationen zu Ursachen für Status code 500 – diese „Server-Fehler“ sind recht häufig, aber hier nicht relevant.
Ein Test der URL via Skript lief auch problemlos. Hierdurch wird insbesondere geprüft, ob große URL-Längen sauber durchgehen bzw. verarbeitet werden, was im Fehlerfall eher einen 404 Status Code nach sich zöge.
405 was?!?
Was aber bedeutet Status Code 405? Er gehört wie alle 4xx zur Kategorie „Client-Fehler“. Das ist allerdings nur die recht einseitige Sicht des Servers, der den Fehler protokolliert. Z.B. kann dies eine nicht zu den Erwartungen des Servers passende Anfrage sein – die deswegen nicht passt, weil der Server falsch konfiguriert ist. Insofern darf man die Kategorisierung nicht unbedingt wörtlich nehmen. Hier gibt es eine schöne Auflistung.
Dieser 405 Error wird bei „operation=PKIOperation“ geworfen und es heißt „Method not allowed“.
Wie man hier im Appendix nachlesen kann, wird bei dieser „operation“ der eigentliche Zertifikatsantrag (CSR) eingereicht und dabei geht offenbar etwas schief.
So lag die Vermutung nahe, dass etwas mit den Anfragen der Clients nicht in Ordnung war. Und zwar als Resultat der Konfiguration in Intune, die letztlich hierfür ausschlaggebend ist.
Und damit zurück zu Intune/Endpoint Manager und den dort definierten Configuration Profiles für SCEP.
Intune und Certificate Template
Prinzipiell sah hier alles gut aus. Es gab ein „Trusted certificate“-Profil mit dem Zertifikat der Root CA und ein „SCEP certificate“-Profil, das dieses CA Zertifikat referenzierte. Ansonsten war nichts auffälliges zu entdecken, die Konfiguration war so, wie man es von einem User-Zertifikat erwarten darf und passte auch zum Certificate template.
Ebenso war der Computeraccount des NDES Servers korrekt eingetragen bzw. dies passte zur Konfiguration des Intune Connectors, wo ich mich für diese Variante entschieden hatte.
Ansonsten passte auch alles: Beim Template ist V2 gewählt:
Für iOS devices war noch erforderlich, dass eine etwas versteckte Option nicht gewählt ist. War erledigt, alles OK.
Da mir langsam die Ideen ausgingen, war ich kurz davor, einen Support Case bei Microsoft zu eröffnen. Da ich den Aufwand scheute und die Erfahrungen in letzter Zeit eher unbefriedigend waren, versuchte ich es mit einem neuen SCEP Profile mit exakt denselben Parametern. Schnell noch beim alten Profil die Zuweisung entfernt… iPhone aktualisiert… TADA!
Das neue Profil funktionierte sofort, Zertifikate angekommen.
In meiner Freude hatte ich das vermaledeite alte Profil dann recht bald gelöscht und allen Benutzern das neue zugewiesen. Und mich durch das Löschen beinahe der Möglichkeit beraubt, die tatsächliche Ursache zu finden. Denn es musste doch einen Unterschied gegeben haben, alles andere wäre Hokuspokus.
Zum Glück gibt es in Intune die oft übersehenen Audit Logs – dort werden alle Aktionen sehr detailliert protokolliert. U.a. auch mein Löschvorgang. In den „Modified properties“ sind alle Parameter versammelt.
Für das neu erstellte Profil war natürlich ebenfalls ein Eintrag vorhanden. Was lag da näher als die Parameter der beiden zu vergleichen? Mit Notepad++ mit aktiviertem „Compare“ Plug-In ein Kinderspiel.
Hier sieht man u.a., wie alt dieses Profil schon war, 2017 ist schon eine Weile her. Viel spannender ist allerdings die unvollständige SCEP Server URL ganz unten: In der alten Konfiguration fehlt am Ende „/mscep.dll“. Sollte es das gewesen sein?
Nachdem ich mutwillig beim neuen Profil diesen Teil wieder entfernt hatte, bestätigte sich: Der Fehler ist wieder da! Kleine Ursache, große Wirkung.
Aber es ergeben sich Folgefragen:
- Fehlte „/mscep.dll“ in diesem alten Profil immer schon?
- Und wenn ja, warum hat es jemals funktioniert?
- War der alte „Microsoft Intune Connector“ vielleicht „gnädiger“ in Sachen Pfad?
- Hat die Connector-Software in der Hinsicht überhaupt Einfluss?
- Oder bin ich einfach nur irgendwann mit der Maus verrutscht?
- Wirklich? Das muss schon mehr als 1 Jahr her sein, da in den Audit Logs nichts davon zu sehen ist – und in der Zwischenzeit hat das Ganze definitiv noch funktioniert. Also unwahrscheinlich…
Ich fürchte, wir werden es nie erfahren… 😉
Fazit
Der Fehler steckt im Detail, man muss schon genau hinschauen.
Zugegebenermaßen war dies eine ziemlich ungewöhnliche Ausgangslage und die Lösung ist dementsprechend – so etwas sollte in einer produktiven Umgebung eigentlich nicht vorkommen.
Wenn es aber an die Fehlersuche geht, sind die durchzuführenden Schritte unabhängig davon meist sehr ähnlich.
Insofern: Danke fürs Lesen, hope it helps! 🙂
