Logowanie PIV nie działa w Windows EAP-TLS? Sprawdź ścieżkę podpisywania

Pokaż certyfikat karty PIV w każdym oknie dialogowym Windows, a logowanie VPN nadal może się nie udać, ponieważ widoczność i użyteczność to różne właściwości. Certyfikat jest obiektem publicznym; logowanie wymaga operacji kluczem prywatnym wykonanej przez kartę zgodnie z jej własnymi regułami dostępu. Między tymi dwoma faktami leżą cztery etapy, które zawodzą na cztery różne sposoby: wybór profilu, wybór certyfikatu, podpisywanie lokalne i walidacja po stronie serwera. Przejście ich po kolei zamienia ogólny błąd uzgadniania w konkretne pytanie do osoby odpowiedzialnej za następny element.

Zacznij od profilu i metody EAP

Otwórz właściwości połączenia i odczytaj, której metody EAP faktycznie używa profil, a następnie odczytaj, który certyfikat metoda jest skonfigurowana wybrać. Wiele wdrożeń ma zarówno zewnętrzną metodę opartą na certyfikacie, jak i metodę wewnętrzną, a certyfikat skonfigurowany na poziomie połączenia nie jest automatycznie tym, który jest prezentowany wewnątrz EAP-TLS. Jeśli profil wybiera certyfikat według wystawcy lub filtra podmiotu, ten filtr wybiera spośród tego, co Windows widzi w odpowiednim magazynie, a nie spośród tego, co karta przypadkowo zawiera. Filtr, który niczego nie dopasowuje, przechodzi na monit lub na ciche niepowodzenie w zależności od konfiguracji profilu, dlatego wybrany odcisk palca warto zapisać przed jakąkolwiek zmianą.

Ustal też, czy połączenie działa jako zalogowany użytkownik, czy jako maszyna. Ten jeden fakt decyduje o tym, które magazyny certyfikatów są w zakresie i który kontekst zabezpieczeń wykonuje podpis.

Potwierdź, który certyfikat został wybrany

Porównaj odcisk palca wybrany przez Windows z wymaganiem: przeznaczenie do uwierzytelniania klienta, łańcuch kończący się w zaufanym głównym, tożsamość mapowaną przez zasady serwera uwierzytelniania oraz okres ważności obejmujący rzeczywisty moment próby. To osobne kontrole i ostatnia z nich wychwytuje więcej niespodzianek, niż ludzie oczekują, zwłaszcza w przypadku certyfikatów wydawanych w trybie kroczącym i buforowanych profili, które nadal wskazują na wczorajszy wybór.

Kontekst użytkownika i maszyny to druga połowa kontroli. Certyfikat w osobistym magazynie użytkownika jest niewidoczny dla usługi działającej jako maszyna, a certyfikat maszyny nie jest prezentowany przez wymianę EAP w trybie użytkownika, chyba że profil tak stanowi. Ponowne zaimportowanie certyfikatu do niewłaściwego magazynu daje widoczny certyfikat i niewidoczne poświadczenie logowania. Czytaj ścieżkę magazynu w profilu, a nie tę w oknie, które przypadkowo się otworzyło.

Przetestuj operację klucza bez zgadywania PIN-u

Gdy wybór jest ustalony, pytanie brzmi, czy karta wykona podpis. Windows potrzebuje obsługiwanego dostawcy karty lub minidrivera, aby dotrzeć do klucza prywatnego, a urządzenie stosuje do operacji własne reguły PIN i obecności. Karta skonfigurowana tak, by wymagać dotknięcia dla każdego podpisu, zachowuje się inaczej niż karta, która buforuje weryfikację na czas sesji, i obie są legalnymi konfiguracjami, które zmieniają moment pojawienia się monitu. Ta różnica wyjaśnia logowanie, które udaje się po świeżym włożeniu, a zawodzi po wznowieniu, bez żadnego błędnego certyfikatu.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

Pierwsze polecenie inwentaryzuje kartę i raportuje stan czytnika oraz dostawcy, co opisano w wskazówkach Microsoftu dotyczących debugowania kart inteligentnych. Drugie wymienia to, co kontekst użytkownika faktycznie widzi. Żadne z nich nie dowodzi udanego uwierzytelnienia; oba zawężają miejsce, w którym się zatrzymało.

Nie zgaduj kodu PIN. Karty egzekwują limity ponownych prób, a kilka optymistycznych prób zamienia problem uprawnień w zablokowane poświadczenie wymagające odzyskania przez administratora. Jeśli lokalny podpis zawodzi, zapisz stan dostawcy i stan karty zamiast wypróbowywać warianty. Powtórz próbę raz z tym samym profilem, tym samym certyfikatem i znaną dobrą ścieżką czytnika, a następnie porównaj oba zapisy; zmiana kilku zmiennych naraz daje historię, a nie wynik.

Odczytaj obie strony uzgadniania

Ukończony podpis nadal nie jest wpuszczeniem. Serwer uwierzytelniania musi zaakceptować łańcuch, sprawdzić odwołanie, zmapować tożsamość według swoich bieżących reguł i autoryzować żądanie; klient z kolei musi zweryfikować certyfikat serwera tak, jak wymaga tego profil. Alert TLS wygenerowany przez serwer wygląda w dzienniku klienta identycznie jak ten wygenerowany lokalnie, dlatego strona emitująca ma większe znaczenie niż treść alertu.

Zbierz zdarzenia Windows i zdarzenia po stronie serwera z wyrównanymi znacznikami czasu, a następnie ustal, która strona wytworzyła pierwszy błąd. RFC 5216 opisuje krok dowodu posiadania w EAP-TLS, a ogólny alert uzgadniania sam nie wskazuje lokalnej przyczyny klucza. Porównanie znaczników czasu jest tym, co zamienia dwa dzienniki w sekwencję.

Utrzymaj granice prosto w raporcie

Napisz raport jako cztery etapy, każdy z jednym werdyktem: który profil i kontekst działał, który certyfikat wybrał Windows, czy karta podpisała i co zdecydował serwer. Ta struktura czyni następny krok oczywistym i zapobiega częstej naprawie polegającej na wyłączeniu walidacji, aby przejść etap, którego nikt nie zidentyfikował.

Certyfikat programowy jako tymczasowe porównanie jest uzasadnionym testem administratora, ale zmienia model poświadczeń i zapewnienia, więc należy do zatwierdzonej zmiany, a nie do cichego obejścia produkcyjnego. Ta sama dyscyplina dotyczy prób PIN i ponownego wydawania poświadczeń, zanim znany jest zawodzący etap. Karta zastępcza, która zawodzi identycznie, jest kosztownym dowodem, że problem nigdy nie leżał na karcie.