Windows ನಲ್ಲಿ EAP-TLS ಜೊತೆ PIV ಲಾಗಿನ್ ವಿಫಲವಾಗಿದೆಯೇ? ಸಹಿ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಪ್ರತಿ Windows ಸಂವಾದದಲ್ಲಿ PIV ಕಾರ್ಡ್ನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತೋರಿಸಿದರೂ VPN ಲಾಗಿನ್ ವಿಫಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ಗೋಚರತೆ ಮತ್ತು ಬಳಕೆಯೋಗ್ಯತೆ ಬೇರೆ ಗುಣಲಕ್ಷಣಗಳು. ಪ್ರಮಾಣಪತ್ರವು ಸಾರ್ವಜನಿಕ ವಸ್ತು; ಲಾಗಿನ್ಗೆ ಕಾರ್ಡ್ ತನ್ನದೇ ಪ್ರವೇಶ ನಿಯಮಗಳ ಅಡಿಯಲ್ಲಿ ನಿರ್ವಹಿಸುವ ಖಾಸಗಿ ಕೀಲಿ ಕಾರ್ಯಾಚರಣೆ ಬೇಕು. ಈ ಎರಡು ಸತ್ಯಗಳ ನಡುವೆ ನಾಲ್ಕು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುವ ನಾಲ್ಕು ಹಂತಗಳಿವೆ: ಪ್ರೊಫೈಲ್ ಆಯ್ಕೆ, ಪ್ರಮಾಣಪತ್ರ ಆಯ್ಕೆ, ಸ್ಥಳೀಯ ಸಹಿ ಮತ್ತು ಸರ್ವರ್ ಬದಿಯ ಮಾನ್ಯತೆ. ಅವನ್ನು ಕ್ರಮವಾಗಿ ಕ್ರಮಿಸುವುದು ಸಾಮಾನ್ಯ ಹ್ಯಾಂಡ್ಶೇಕ್ ದೋಷವನ್ನು ಮುಂದಿನ ಭಾಗದ ಮಾಲೀಕರಿಗೆ ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಪ್ರೊಫೈಲ್ ಮತ್ತು EAP ವಿಧಾನದಿಂದ ಆರಂಭಿಸಿ

ಸಂಪರ್ಕದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ತೆರೆದು ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿ ಯಾವ EAP ವಿಧಾನವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಓದಿ, ನಂತರ ವಿಧಾನ ಯಾವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ಓದಿ. ಅನೇಕ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರ ಆಧಾರಿತ ಹೊರ ವಿಧಾನ ಮತ್ತು ಒಳ ವಿಧಾನ ಎರಡೂ ಇರುತ್ತವೆ, ಮತ್ತು ಸಂಪರ್ಕ ಮಟ್ಟದಲ್ಲಿ ಸಂರಚಿಸಿದ ಪ್ರಮಾಣಪತ್ರವು EAP-TLS ಒಳಗೆ ಪ್ರಸ್ತುತಪಡಿಸುವ ಪ್ರಮಾಣಪತ್ರವೇ ಆಗಿರುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡುವವರ ಅಥವಾ ವಿಷಯ ಫಿಲ್ಟರ್ ಮೂಲಕ ಆಯ್ಕೆ ಮಾಡಿದರೆ, ಆ ಫಿಲ್ಟರ್ ಸಂಬಂಧಿತ ಸ್ಟೋರ್ನಲ್ಲಿ Windows ನೋಡಬಲ್ಲದರಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಕಾರ್ಡ್ನಲ್ಲಿ ಆಕಸ್ಮಿಕವಾಗಿ ಇರುವುದರಿಂದ ಅಲ್ಲ. ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ಫಿಲ್ಟರ್ ಪ್ರೊಫೈಲ್ನ ಸಂರಚನೆಯನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರಾಂಪ್ಟ್ ಅಥವಾ ಮೌನ ವೈಫಲ್ಯಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಆಯ್ಕೆಯಾದ ಥಂಬ್ಪ್ರಿಂಟ್ ದಾಖಲಿಸುವುದು ಯೋಗ್ಯ.

ಸಂಪರ್ಕವು ಸೈನ್-ಇನ್ ಆದ ಬಳಕೆದಾರರಾಗಿ ಅಥವಾ ಯಂತ್ರವಾಗಿ ಚಲಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನೂ ನಿರ್ಧರಿಸಿ. ಆ ಒಂದು ಸತ್ಯ ಯಾವ ಪ್ರಮಾಣಪತ್ರ ಸ್ಟೋರ್ಗಳು ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ ಮತ್ತು ಯಾವ ಭದ್ರತಾ ಸಂದರ್ಭ ಸಹಿ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಯಾವ ಪ್ರಮಾಣಪತ್ರ ಆಯ್ಕೆಯಾಯಿತು ಎಂದು ದೃಢೀಕರಿಸಿ

Windows ಆಯ್ಕೆ ಮಾಡಿದ ಥಂಬ್ಪ್ರಿಂಟ್ ಅನ್ನು ಅಗತ್ಯದೊಂದಿಗೆ ಹೋಲಿಸಿ: ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣಕ್ಕಾಗಿ ಬಳಕೆ, ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಸರಪಳಿ, ದೃಢೀಕರಣ ಸರ್ವರ್ನ ನೀತಿ ನಕ್ಷೆ ಮಾಡುವ ಗುರುತು, ಮತ್ತು ಪ್ರಯತ್ನದ ನಿಜವಾದ ಕ್ಷಣವನ್ನು ಆವರಿಸುವ ಮಾನ್ಯತಾ ಅವಧಿ. ಇವು ಪ್ರತ್ಯೇಕ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಕೊನೆಯದು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಆಶ್ಚರ್ಯಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ನಿರಂತರವಾಗಿ ನೀಡಲಾಗುವ ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು ಇನ್ನೂ ನಿನ್ನೆಯ ಆಯ್ಕೆಯನ್ನು ತೋರಿಸುವ ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ಗಳೊಂದಿಗೆ.

ಬಳಕೆದಾರ ಮತ್ತು ಯಂತ್ರ ಸಂದರ್ಭ ಪರಿಶೀಲನೆಯ ಇನ್ನೊಂದು ಅರ್ಧ. ಬಳಕೆದಾರರ ವೈಯಕ್ತಿಕ ಸ್ಟೋರ್ನಲ್ಲಿರುವ ಪ್ರಮಾಣಪತ್ರ ಯಂತ್ರವಾಗಿ ಚಲಿಸುವ ಸೇವೆಗೆ ಅಗೋಚರ, ಮತ್ತು ಯಂತ್ರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರೊಫೈಲ್ ಹೇಳದ ಹೊರತು ಬಳಕೆದಾರ ಮೋಡ್ EAP ವಿನಿಮಯ ಪ್ರಸ್ತುತಪಡಿಸುವುದಿಲ್ಲ. ತಪ್ಪು ಸ್ಟೋರ್ಗೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮರು ಆಮದು ಮಾಡಿದರೆ ಗೋಚರ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಅಗೋಚರ ಲಾಗಿನ್ ರುಜುವಾತು ಉಂಟಾಗುತ್ತದೆ. ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ಸ್ಟೋರ್ ಮಾರ್ಗವನ್ನು ಓದಿ, ಆಕಸ್ಮಿಕವಾಗಿ ತೆರೆದ ಸಂವಾದದ್ದಲ್ಲ.

PIN ಊಹಿಸದೆ ಕೀಲಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ

ಆಯ್ಕೆ ನಿರ್ಧಾರವಾದ ನಂತರ ಪ್ರಶ್ನೆ ಎಂದರೆ ಕಾರ್ಡ್ ಸಹಿ ಮಾಡುತ್ತದೆಯೇ. ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ತಲುಪಲು Windows ಗೆ ಬೆಂಬಲಿತ ಕಾರ್ಡ್ ಒದಗಿಸುವವರು ಅಥವಾ ಮಿನಿಡ್ರೈವರ್ ಬೇಕು, ಮತ್ತು ಸಾಧನವು ತನ್ನದೇ PIN ಮತ್ತು ಉಪಸ್ಥಿತಿ ನಿಯಮಗಳನ್ನು ಕಾರ್ಯಾಚರಣೆಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಪ್ರತಿ ಸಹಿಗೂ ಸ್ಪರ್ಶ ಕೇಳುವ ಕಾರ್ಡ್, ಅಧಿವೇಶನಕ್ಕೆ ಪರಿಶೀಲನೆಯನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವ ಕಾರ್ಡ್ಗಿಂತ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಪ್ರಾಂಪ್ಟ್ ಯಾವಾಗ ಕಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವ ಕಾನೂನುಬದ್ಧ ಸಂರಚನೆಗಳು. ಆ ವ್ಯತ್ಯಾಸವೇ ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರ ತಪ್ಪಿಲ್ಲದೆ ಹೊಸ ಸೇರಿಸುವಿಕೆಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಮರುಪ್ರಾರಂಭದ ನಂತರ ವಿಫಲವಾಗುವ ಲಾಗಿನ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

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

ಮೊದಲ ಆಜ್ಞೆ ಕಾರ್ಡ್ನ ಪಟ್ಟಿ ಮಾಡಿ ಓದುಗ ಮತ್ತು ಒದಗಿಸುವವರ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು Microsoft ನ ಸ್ಮಾರ್ಟ್-ಕಾರ್ಡ್ ಡೀಬಗ್ ಮಾಡುವ ಮಾರ್ಗದರ್ಶನದಲ್ಲಿ ದಾಖಲಾಗಿದೆ. ಎರಡನೆಯದು ಬಳಕೆದಾರ ಸಂದರ್ಭ ನಿಜವಾಗಿ ಏನನ್ನು ನೋಡಬಲ್ಲದು ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಯಾವುದೂ ಯಶಸ್ವಿ ದೃಢೀಕರಣವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ; ಎರಡೂ ಎಲ್ಲಿಗೆ ನಿಂತಿತು ಎಂಬುದನ್ನು ಸಂಕುಚಿಸುತ್ತವೆ.

PIN ಊಹಿಸಬೇಡಿ. ಕಾರ್ಡ್ಗಳು ಮರುಪ್ರಯತ್ನ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ಆಶಾವಾದಿ ಪ್ರಯತ್ನಗಳು ಅನುಮತಿ ಸಮಸ್ಯೆಯನ್ನು ಆಡಳಿತಾತ್ಮಕ ಮರುಪ್ರಾಪ್ತಿ ಬೇಕಾಗುವ ನಿರ್ಬಂಧಿತ ರುಜುವಾತಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ. ಸ್ಥಳೀಯ ಸಹಿ ವಿಫಲವಾದರೆ, ರೂಪಾಂತರಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವ ಬದಲು ಒದಗಿಸುವವರ ಸ್ಥಿತಿ ಮತ್ತು ಕಾರ್ಡ್ನ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ. ಅದೇ ಪ್ರೊಫೈಲ್, ಅದೇ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ತಿಳಿದಿರುವ ಉತ್ತಮ ಓದುಗ ಮಾರ್ಗದೊಂದಿಗೆ ಪ್ರಯತ್ನವನ್ನು ಒಮ್ಮೆ ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಎರಡು ದಾಖಲೆಗಳನ್ನು ಹೋಲಿಸಿ; ಒಟ್ಟಿಗೆ ಹಲವು ಚರಗಳನ್ನು ಬದಲಿಸುವುದು ಫಲಿತಾಂಶವಲ್ಲ, ಕಥೆ ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಹ್ಯಾಂಡ್ಶೇಕ್ನ ಎರಡೂ ಬದಿಗಳನ್ನು ಓದಿ

ಪೂರ್ಣಗೊಂಡ ಸಹಿ ಇನ್ನೂ ಪ್ರವೇಶವಲ್ಲ. ದೃಢೀಕರಣ ಸರ್ವರ್ ಸರಪಳಿಯನ್ನು ಸ್ವೀಕರಿಸಿ, ರದ್ದತಿ ಪರಿಶೀಲಿಸಿ, ತನ್ನ ಪ್ರಸ್ತುತ ನಿಯಮಗಳ ಅಡಿಯಲ್ಲಿ ಗುರುತನ್ನು ನಕ್ಷೆ ಮಾಡಿ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಅಧಿಕೃತಗೊಳಿಸಬೇಕು; ಕ್ಲೈಂಟ್ ತನ್ನ ಬದಿಯಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಬೇಡುವಂತೆ ಸರ್ವರ್ನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮಾನ್ಯಗೊಳಿಸಬೇಕು. ಸರ್ವರ್ ಉತ್ಪಾದಿಸುವ TLS ಎಚ್ಚರಿಕೆ ಕ್ಲೈಂಟ್ ಲಾಗ್ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪಾದಿಸಿದಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ ಎಚ್ಚರಿಕೆಯ ಪಠ್ಯಕ್ಕಿಂತ ಅದನ್ನು ಹೊರಡಿಸುವ ಬದಿಯೇ ಮುಖ್ಯ.

Windows ಘಟನೆಗಳು ಮತ್ತು ಸರ್ವರ್ ಬದಿಯ ಘಟನೆಗಳನ್ನು ಹೊಂದಿಸಿದ ಸಮಯಮುದ್ರೆಗಳೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಿ, ನಂತರ ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಯಾವ ಬದಿ ಉಂಟುಮಾಡಿತು ಎಂದು ಗುರುತಿಸಿ. RFC 5216 EAP-TLS ನಲ್ಲಿ ಸ್ವಾಧೀನದ ಸಾಕ್ಷ್ಯದ ಹಂತವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಹ್ಯಾಂಡ್ಶೇಕ್ ಎಚ್ಚರಿಕೆ ತಾನಾಗಿಯೇ ಸ್ಥಳೀಯ ಕೀಲಿ ಕಾರಣವನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ. ಎರಡು ಲಾಗ್ಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರಿವರ್ತಿಸುವುದು ಸಮಯಮುದ್ರೆಗಳ ಹೋಲಿಕೆಯೇ.

ವರದಿಯಲ್ಲಿ ಗಡಿಗಳನ್ನು ನೇರವಾಗಿ ಇರಿಸಿ

ವರದಿಯನ್ನು ನಾಲ್ಕು ಹಂತಗಳಾಗಿ ಬರೆಯಿರಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಒಂದು ತೀರ್ಪು: ಯಾವ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಸಂದರ್ಭ ಚಲಿಸಿತು, Windows ಯಾವ ಪ್ರಮಾಣಪತ್ರ ಆಯ್ಕೆ ಮಾಡಿತು, ಕಾರ್ಡ್ ಸಹಿ ಮಾಡಿತೇ ಮತ್ತು ಸರ್ವರ್ ಏನು ನಿರ್ಧರಿಸಿತು. ಆ ರಚನೆ ಮುಂದಿನ ಹೆಜ್ಜೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಯಾರೂ ಗುರುತಿಸದ ಹಂತವನ್ನು ದಾಟಲು ಮಾನ್ಯತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಸಾಮಾನ್ಯ ದುರಸ್ತಿಯನ್ನು ತಡೆಯುತ್ತದೆ.

ತಾತ್ಕಾಲಿಕ ಹೋಲಿಕೆಯಾಗಿ ಸಾಫ್ಟ್ವೇರ್ ಪ್ರಮಾಣಪತ್ರ ಕಾನೂನುಬದ್ಧ ನಿರ್ವಾಹಕ ಪರೀಕ್ಷೆ, ಆದರೆ ಅದು ರುಜುವಾತು ಮತ್ತು ಭರವಸೆಯ ಮಾದರಿಯನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಸ್ಥಾನ ಅನುಮೋದಿತ ಬದಲಾವಣೆಯಲ್ಲಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮೌನ ಪರ್ಯಾಯದಲ್ಲಿ ಅಲ್ಲ. ಅದೇ ಶಿಸ್ತು PIN ಪ್ರಯತ್ನಗಳಿಗೆ ಮತ್ತು ವಿಫಲವಾಗುವ ಹಂತ ತಿಳಿಯುವ ಮೊದಲು ರುಜುವಾತುಗಳನ್ನು ಮರುನೀಡುವುದಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಅದೇ ರೀತಿ ವಿಫಲವಾಗುವ ಬದಲಿ ಕಾರ್ಡ್ ಸಮಸ್ಯೆ ಎಂದೂ ಕಾರ್ಡ್ನಲ್ಲಿರಲಿಲ್ಲ ಎಂಬ ದುಬಾರಿ ಸಾಕ್ಷ್ಯ.