Die Windows-Benutzeroberfläche hat die EAP-TLS-Authentifizierung traditionell als "Smartcard oder anderes Zertifikat" bezeichnet. Vielleicht suchen Sie das also.
Dieser Teil Ihrer Frage macht jedoch keinen Sinn für mich:
Vor Windows 8.x haben wir EAP-TLS als äußeres Authentifizierungsprotokoll verwendet, um diese Anforderung zu erfüllen, und das innere Authentifizierungsprotokoll verwendet, um den Benutzernamen / das Kennwort gegen unser AD zu überprüfen.
… Weil EAP-TLS meines Wissens kein "inneres" Authentifizierungsprotokoll vorsieht. Ich frage mich also, ob Sie möglicherweise EAP-TLS als Ihren einzigen 802.1X-EAP-Typ verwendet haben und die Authentifizierung des Benutzernamens / Kennworts, an die Sie sich erinnern, nicht Teil von 802.1X war, sondern möglicherweise nach Ihrer Authentifizierung bei Ihrer AD-Domäne waren bereits vollständig 802.1X-authentifiziert und verfügten über eine Netzwerkverbindung.
Soweit ich weiß, bauen nur PEAP und TTLS einen "äußeren" sicheren Tunnel über die Dummy-Authentifizierung auf und verwenden diesen Tunnel dann, um eine "innere" Authentifizierungstransaktion sicher zu transportieren. Und selbst PEAP und TTLS für die äußere Authentifizierung machen nur TLS, aber soweit ich mich erinnere, verwenden Sie es nur, um den Authentifikator (AP- oder AAA-Server) zu überprüfen und den verschlüsselten Tunnel einzurichten. Ich kann mich nicht erinnern, dass es jemals eine Möglichkeit gab, ein Client-Zertifikat für die TLS-Authentifizierung außerhalb von PEAP oder TTLS anzugeben.
Sowohl PEAP als auch TTLS erlauben technisch EAP-TLS als inneren Authentifizierungsmechanismus, obwohl viele frühe TTLS-Implementierungen EAP nicht zuließen. Sie erlaubten nur die EAP-PPP-Authentifizierungsmethoden: PAP, CHAP, MS-CHAP, MS-CHAP-V2. Es könnte sein, dass der native Windows 8.1 802.1X-Supplicant einer davon ist. Ebenso unterstützen einige PEAP-Implementierungen EAP-MS-CHAP-V2 und EAP-GTC als innere Authentifizierungstypen und möglicherweise andere Authentifizierungstypen wie EAP-TLS als innere Authentifizierungstypen nicht. Microsofts nativer Windows 802.1X-Supplicant hat EAP-TLS jedoch immer als den internen Authentifizierungstyp für PEAP unterstützt, sie haben es traditionell nur als "Chipkarte oder anderes Zertifikat" bezeichnet.
Es ist für mich keine Überraschung, wenn ein Implementierer bei der Implementierung dieses Protokolls optionale Teile einer Protokollspezifikation überspringt. Bei fast jedem RFC, den ich je gelesen habe, gab es Teile, die ich noch nie gesehen habe. Daher überrascht es nicht, dass der von Windows entwickelte 802.1X-Supplicant von Microsoft keine Möglichkeit bietet, ein Client-TLS-Zertifikat in der äußeren Authentifizierung von TTLS anzubieten. Wenn Sie die TTLS-Spezifikation durchlesen, werden Sie feststellen, dass TTLS in diesem Fall die innere Authentifizierung überspringt, sodass es im Grunde nur EAP-TLS ist. Microsoft hat wahrscheinlich gedacht, dass, da sie bereits EAP-TLS unterstützten, der EAP-TTLS-Modus, der in etwa derselbe ist wie EAP-TLS, gestört wird.