Đăng nhập PIV không thành công trên Windows EAP-TLS? Kiểm tra đường ký

Hiển thị chứng chỉ của thẻ PIV trong mọi hộp thoại Windows và đăng nhập VPN vẫn có thể thất bại, vì khả năng hiển thị và khả năng sử dụng là hai thuộc tính khác nhau. Chứng chỉ là một đối tượng công khai; đăng nhập cần một thao tác khóa riêng do thẻ thực hiện theo các quy tắc truy cập của chính nó. Giữa hai sự thật đó là bốn giai đoạn thất bại theo bốn cách khác nhau: chọn hồ sơ, chọn chứng chỉ, ký cục bộ và xác thực phía máy chủ. Đi qua chúng theo thứ tự biến một lỗi bắt tay chung chung thành câu hỏi cụ thể cho người sở hữu phần tiếp theo.

Bắt đầu với hồ sơ và phương thức EAP

Mở thuộc tính của kết nối và đọc xem hồ sơ thực sự dùng phương thức EAP nào, sau đó đọc xem phương thức được cấu hình chọn chứng chỉ nào. Nhiều triển khai có cả phương thức bên ngoài dựa trên chứng chỉ và phương thức bên trong, và chứng chỉ được cấu hình ở cấp kết nối không tự động là chứng chỉ được trình bày bên trong EAP-TLS. Nếu hồ sơ chọn chứng chỉ theo nhà phát hành hoặc theo bộ lọc chủ thể, bộ lọc đó chọn từ những gì Windows thấy trong kho liên quan, không phải từ những gì thẻ tình cờ chứa. Một bộ lọc không khớp gì sẽ rơi vào một lời nhắc hoặc một lỗi im lặng tùy theo cấu hình hồ sơ, vì vậy nên ghi lại dấu vân tay đã chọn trước bất kỳ thay đổi nào.

Cũng xác định xem kết nối chạy dưới danh nghĩa người dùng đã đăng nhập hay dưới danh nghĩa máy. Riêng sự thật đó quyết định kho chứng chỉ nào nằm trong phạm vi và ngữ cảnh bảo mật nào thực hiện việc ký.

Xác nhận chứng chỉ nào đã được chọn

So sánh dấu vân tay Windows đã chọn với yêu cầu: mục đích xác thực máy khách, một chuỗi kết thúc ở gốc tin cậy, một danh tính được chính sách của máy chủ xác thực ánh xạ, và một thời hạn hiệu lực bao trùm thời điểm thực tế của lần thử. Đây là những kiểm tra riêng biệt và cái cuối cùng bắt được nhiều bất ngờ hơn người ta tưởng, đặc biệt với chứng chỉ được cấp luân phiên và hồ sơ đã lưu trong bộ nhớ đệm vẫn trỏ tới lựa chọn của ngày hôm qua.

Ngữ cảnh người dùng và máy là nửa còn lại của kiểm tra. Chứng chỉ trong kho cá nhân của người dùng không hiển thị với một dịch vụ chạy dưới danh nghĩa máy, và chứng chỉ của máy không được trình bày bởi trao đổi EAP ở chế độ người dùng trừ khi hồ sơ nói như vậy. Nhập lại chứng chỉ vào kho sai tạo ra một chứng chỉ hiển thị và một thông tin đăng nhập vô hình. Đọc đường dẫn kho trong hồ sơ, không phải đường dẫn trong hộp thoại tình cờ mở ra.

Kiểm tra thao tác khóa mà không đoán PIN

Khi lựa chọn đã rõ, câu hỏi là liệu thẻ có thực hiện việc ký. Windows cần một nhà cung cấp thẻ hoặc minidriver được hỗ trợ để tới khóa riêng, và thiết bị áp dụng các quy tắc PIN và hiện diện của riêng nó cho thao tác. Một thẻ được cấu hình yêu cầu chạm cho mỗi lần ký hành xử khác với thẻ lưu bộ nhớ đệm một xác minh cho một phiên, và cả hai đều là cấu hình hợp lệ làm thay đổi thời điểm xuất hiện lời nhắc. Sự khác biệt đó giải thích một lần đăng nhập thành công khi vừa cắm thẻ và thất bại sau khi khôi phục từ trạng thái ngủ, mà không có chứng chỉ nào sai.

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

Lệnh đầu tiên kiểm kê thẻ và báo cáo trạng thái đầu đọc và nhà cung cấp, được ghi trong hướng dẫn gỡ lỗi thẻ thông minh của Microsoft. Lệnh thứ hai liệt kê những gì ngữ cảnh người dùng thực sự thấy. Không lệnh nào chứng minh một xác thực thành công; cả hai đều thu hẹp nơi nó dừng lại.

Đừng đoán PIN. Thẻ áp đặt giới hạn số lần thử, và vài lần thử lạc quan biến một vấn đề quyền thành một thông tin đăng nhập bị khóa cần phục hồi của quản trị viên. Nếu việc ký cục bộ thất bại, hãy ghi lại trạng thái nhà cung cấp và trạng thái thẻ thay vì thử các biến thể. Lặp lại lần thử một lần với cùng hồ sơ, cùng chứng chỉ và một đường dẫn đầu đọc đã biết là tốt, rồi so sánh hai bản ghi; thay đổi nhiều biến cùng lúc tạo ra một câu chuyện chứ không phải kết quả.

Đọc cả hai phía của bắt tay

Một chữ ký hoàn tất vẫn chưa phải là sự cho phép. Máy chủ xác thực phải chấp nhận chuỗi, kiểm tra thu hồi, ánh xạ danh tính theo các quy tắc hiện hành và cho phép yêu cầu; máy khách đến lượt mình phải xác thực chứng chỉ của máy chủ như hồ sơ yêu cầu. Một cảnh báo TLS do máy chủ tạo trông giống hệt trong nhật ký của máy khách với một cảnh báo được tạo cục bộ, vì vậy phía phát ra quan trọng hơn văn bản cảnh báo.

Thu thập các sự kiện Windows và các sự kiện phía máy chủ với dấu thời gian được căn chỉnh, rồi xác định phía nào tạo ra lỗi đầu tiên. RFC 5216 mô tả bước bằng chứng sở hữu trong EAP-TLS, và một cảnh báo bắt tay chung không tự nêu nguyên nhân khóa cục bộ. Việc so sánh dấu thời gian là thứ biến hai nhật ký thành một chuỗi.

Giữ ranh giới thẳng trong báo cáo

Viết báo cáo thành bốn giai đoạn với một kết luận cho mỗi giai đoạn: hồ sơ và ngữ cảnh nào đã chạy, Windows đã chọn chứng chỉ nào, thẻ có ký hay không, và máy chủ đã quyết định gì. Cấu trúc đó làm bước tiếp theo trở nên rõ ràng và ngăn chặn cách sửa phổ biến là tắt xác thực để vượt qua một giai đoạn mà không ai xác định được.

Một chứng chỉ phần mềm như so sánh tạm thời là một thử nghiệm quản trị hợp lệ, nhưng nó thay đổi mô hình thông tin đăng nhập và bảo đảm, nên nó thuộc về một thay đổi được phê duyệt chứ không phải một lối tắt im lặng trong môi trường sản xuất. Kỷ luật tương tự áp dụng cho các lần thử PIN và cho việc cấp lại thông tin đăng nhập trước khi biết giai đoạn thất bại. Một thẻ thay thế thất bại giống hệt là bằng chứng đắt giá rằng vấn đề chưa bao giờ nằm trên thẻ.