LmCompatibilityLevel ಒಂದು Windows ನೀತಿ, VPN ಪರಿಹಾರ ಅಲ್ಲ

ಒಬ್ಬರು VPN ಮೂಲಕ ಫೈಲ್ ಹಂಚಿಕೆಗೆ ತಲುಪಲಾಗುತ್ತಿಲ್ಲ, LmCompatibilityLevel ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ NTLM ಸಮಸ್ಯೆಗಳು ಸರಿಯಾಗುತ್ತವೆ ಎಂದು ಓದಿ, ಹಂಚಿದ ಸರ್ವರ್ನಲ್ಲಿ ಅದನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ. ಮರುದಿನ ಬೆಳಿಗ್ಗೆ ಇತರ ಅಪ್ಲಿಕೇಶನ್ಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಮೂಲ ಸಮಸ್ಯೆ ಹಾಗೆಯೇ ಉಳಿಯುತ್ತದೆ. ಈ ಸೆಟ್ಟಿಂಗ್ ಎಂದೂ ಪ್ರತಿ-ಸುರಂಗ ಸ್ವಿಚ್ ಆಗಿರಲಿಲ್ಲ; ಇದು ಈ ವ್ಯವಸ್ಥೆಯು ಯಾವ ದೃಢೀಕರಣ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಯಂತ್ರ ಮಟ್ಟದ ಹೇಳಿಕೆ. ಒಂದು ಲಾಗಿನ್ ಸರಿಪಡಿಸಲು ಅದನ್ನು ಬದಲಾಯಿಸುವುದು ಯಂತ್ರ ಮಾಡುವ ಪ್ರತಿ ಲಾಗಿನ್ನ ನಿಯಮಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ.

ದಾಖಲಾದ ಹಂತಗಳನ್ನು ಓದುವುದು ನೀತಿ ಮೌಲ್ಯವನ್ನು ಮಾಂತ್ರಿಕ ಸಂಖ್ಯೆ ಎಂದು ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ವೇಗವಾದ ದಾರಿ.

ಮೂರು ಹಂತಗಳು, ಮೂರು ವಿಭಿನ್ನ ಭರವಸೆಗಳು

ಹಂತ 1 ಕ್ಲೈಂಟ್ LM ಮತ್ತು NTLM ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಂಧಾನ ಅನುಮತಿಸಿದಾಗ NTLMv2 ಸೆಷನ್ ಭದ್ರತೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಹಂತ 3 ಕ್ಲೈಂಟ್ ಕೇವಲ NTLMv2 ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದು ಸ್ವೀಕರಿಸುವ ಬದಿಯಲ್ಲಿ ಎಲ್ಲಾ ಹಳೆಯ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ನಿರಾಕರಿಸುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ. ಹಂತ 5 ಕ್ಲೈಂಟ್ ಅನ್ನು NTLMv2 ನಲ್ಲಿ ಇರಿಸಿ, ಡೊಮೇನ್ ನಿಯಂತ್ರಕರ ದಾಖಲಿತ LM ಮತ್ತು NTLMv1 ನಿರಾಕರಣೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಮೂರು ಸಂಖ್ಯೆಗಳು, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಆದ್ಯತೆ ಅಲ್ಲ, ನೀತಿ ನಿರ್ಣಯ.

ಆ ವ್ಯತ್ಯಾಸಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪ್ರಕರಣದಿಂದ ಮೌಲ್ಯವನ್ನು ನಕಲಿಸುವುದು ಏಕೆ ನಂಬಲರ್ಹವಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ. ತಪ್ಪಾಗಿ ಸಂರಚಿಸಿದ ಕ್ಲೈಂಟ್ ಅನ್ನು 1 ರಿಂದ ಅನುಮೋದಿತ ಮೂಲರೇಖೆಗೆ ಸರಿಸುವುದು ಸರಿಯಾಗಿರಬಹುದು. ಫೋರಂ ಥ್ರೆಡ್ 3 ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದರಿಂದ ಮಾತ್ರ ಕಠಿಣಗೊಳಿಸಿದ ನಿಯೋಜನೆಯನ್ನು 5 ರಿಂದ 3 ಕ್ಕೆ ಇಳಿಸುವುದು ಯಾರೋ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿದ ಗಡಿಯನ್ನು ಸಡಿಲಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಯಂತ್ರ ಮಾತನಾಡುವ ಪ್ರತಿ ಸೇವೆಗೂ ಅದನ್ನು ಮಾಡುತ್ತದೆ.

ಜಾರಿಯಲ್ಲಿರುವ ನೀತಿಯನ್ನು ಓದಿ, ಒಂದು ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯವನ್ನಲ್ಲ

ಸ್ಥಳೀಯ ಮೌಲ್ಯದ ಮೇಲೆ ಓದಲು-ಮಾತ್ರ ನೋಟ ಸೂಕ್ತ ಆರಂಭಿಕ ಹಂತ: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. ಮೌಲ್ಯ ಇಲ್ಲದಿರುವುದು ಜಾರಿಯಲ್ಲಿರುವ ನೀತಿ ಶೂನ್ಯ ಎಂದು ಅರ್ಥವಲ್ಲ, ಏಕೆಂದರೆ ಡೊಮೇನ್ ಅಥವಾ ಸ್ಥಳೀಯ ಭದ್ರತಾ ನೀತಿ ಅದನ್ನು ಬೇರೆಡೆ ಹೊಂದಿಸಬಹುದು, ಮತ್ತು ಯಂತ್ರದ ಪಾತ್ರ ಆ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

ಏನನ್ನಾದರೂ ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ನಿರ್ವಹಿತ ನೀತಿ, ವ್ಯವಸ್ಥೆಯ ಪಾತ್ರ ಮತ್ತು ನಿಜವಾದ build ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಒಂದೇ ಮೌಲ್ಯವಿರುವ ವರ್ಕ್ಸ್ಟೇಷನ್ ಮತ್ತು ಡೊಮೇನ್ ನಿಯಂತ್ರಕ ಮೇಲಿನ ತುದಿಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ಎರಡು ಯಂತ್ರಗಳನ್ನು ಹೋಲಿಸುವಾಗ ಜನರು ಮರೆಯುವುದು ಅದೇ ಭಾಗವನ್ನು.

ನಿಜವಾಗಿ ಯಾವ ದೃಢೀಕರಣ ವಿಫಲವಾಯಿತು ಎಂಬುದನ್ನು ಗುರುತಿಸಿ

Kerberos ಟಿಕೆಟ್ ಸಮಸ್ಯೆಗಳು, NTLM ನಿರಾಕರಣೆಗಳು ಮತ್ತು VPN ಪ್ರವೇಶ ವೈಫಲ್ಯಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ಸಾಕ್ಷ್ಯ ಬೇಕು. ಗುರಿ ಸೇವೆ, ಖಾತೆ ಮತ್ತು ನಿಖರ ದೋಷವನ್ನು ಒಂದೇ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಒಟ್ಟಿಗೆ ಇರಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಏನನ್ನು ಇಷ್ಟಪಡುತ್ತದೆ ಎಂಬುದನ್ನಲ್ಲ, ಸೇವೆ ಏನನ್ನು ಕೇಳಿತು ಎಂಬುದನ್ನು ನೋಡಿ. ಆ ಒಂದೇ ಟಿಪ್ಪಣಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು ತಿರುವನ್ನು ತಡೆಯುತ್ತದೆ, ಅಂದರೆ ಸರ್ವರ್ ಬದಿಯ ನಿರಾಕರಣೆಗೆ ಉತ್ತರವಾಗಿ ಕ್ಲೈಂಟ್ ಬದಿಯ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸುವುದು.

ಸಾಮಾನ್ಯ ಲಾಗಿನ್ ದೋಷ ಮಾಯವಾಗುವವರೆಗೆ ನೀತಿಯನ್ನು ಪದೇ ಪದೇ ಇಳಿಸುವುದು ರೋಗನಿರ್ಣಯವಲ್ಲ; ಅದು ಸಾಕ್ಷ್ಯವನ್ನು ಮರೆಮಾಡುವ ಬದಲಾವಣೆ. ಅಪ್ಲಿಕೇಶನ್ Kerberos ಬಳಸಿದರೆ, NTLM ಹೊಂದಾಣಿಕೆ ಮಟ್ಟವು ಸಂಬಂಧಿತ ನಿಯಂತ್ರಣವೂ ಅಲ್ಲ, ಮತ್ತು ನೀವು ಗಡಿಯನ್ನು ವ್ಯರ್ಥವಾಗಿ ಸಡಿಲಗೊಳಿಸಿದ್ದೀರಿ.

ಕೆಲವು ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲವನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗದು

Windows 11 24H2 ಮತ್ತು Windows Server 2025 ಇನ್ನು NTLMv1 ನೆಟ್ವರ್ಕ್ ದೃಢೀಕರಣವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಂಡಿಲ್ಲ. build ಇನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಯಾವ ಹೊಂದಾಣಿಕೆ ಸಂಖ್ಯೆಯೂ ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹಳೆಯ ಆವೃತ್ತಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡಿದ ಡೌನ್ಗ್ರೇಡ್ ಹೊಸದರಲ್ಲಿ ಸರಳವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. Microsoft ಆ ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ನೀತಿ ಸೆಟ್ಟಿಂಗ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಕೆಲಸ ಮಾಡಲಾಗದ ಸಲಹೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಸಂಬಂಧಿತ ಆದರೆ ವಿಭಿನ್ನ ನಿರ್ಬಂಧ MSCHAPv2 ಆಧಾರಿತ ಏಕ ಸೈನ್-ಆನ್ ಬಳಸುವ NTLMv1 ನಿಂದ ಪಡೆದ ರುಜುವಾತುಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಇದು ಪಡೆದ ರುಜುವಾತುಗಳ ಪ್ರಶ್ನೆ, ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ನದೇ ಅಲ್ಲ, ಮತ್ತು ಈ ಒಂದು ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯದದೂ ಅಲ್ಲ. ಮೂರನ್ನೂ ಒಂದೇ ವಿಷಯ ಎಂದು ಪರಿಗಣಿಸುವುದು ಸಂಸ್ಥೆಗಳು ಒಂದು ನಿಯಂತ್ರಣವನ್ನು ದುರ್ಬಲಗೊಳಿಸಿ ಇನ್ನೊಂದನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುವ ದಾರಿ.

ಮಾಲೀಕರ ಮೂಲಕ ಅದನ್ನು ಬದಲಾಯಿಸಿ, ನಂತರ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ನಿಜವಾಗಿ ತಿದ್ದುಪಡಿ ಬೇಕಿದ್ದರೆ, ಮೂಲರೇಖೆ ಸುಸಂಗತವಾಗಿರಲು ನೀತಿ ಮಾಲೀಕರ ಮೂಲಕ ಮಾಡಿ, ಮತ್ತು ಏಕೆ ಎಂದು ದಾಖಲಿಸಿ. ನಂತರ ಹೊಸ ಸೆಟ್ಟಿಂಗ್ ಅಡಿಯಲ್ಲಿ ಅಧಿಕೃತ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಷೇಧಿಸಿದ ದೃಢೀಕರಣ ಪ್ರಕರಣವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಹಂಚಿಕೆಯನ್ನು ಸರಿಪಡಿಸಿ ಬೇರೆಡೆ ಹಳೆಯ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ ಮೌನವಾಗಿ ಅವಕಾಶ ನೀಡುವ ಬದಲಾವಣೆ ಯಶಸ್ಸಲ್ಲ. ಕಾರ್ಯನಿರ್ವಹಿಸುವ VPN ಸಂಪರ್ಕ ಪ್ರವೇಶ ಯಶಸ್ವಿಯಾದುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು ಯಂತ್ರದ ದೃಢೀಕರಣ ನೀತಿಯನ್ನು ಮಾನ್ಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ಹಿಂದಿನ ಪ್ರತಿ ಸೇವೆ ಇನ್ನೂ ವಿನ್ಯಾಸಗೊಳಿಸಿದಂತೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಖಂಡಿತವಾಗಿ ತೋರಿಸುವುದಿಲ್ಲ.

ವಿಫಲವಾಗುವ ಸೇವೆ Kerberos ಆಧಾರಿತವಾಗಿದ್ದರೆ, ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನೋಡುವುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸಿ. ಅದು ನಿಜವಾಗಿ ಹೆಚ್ಚು ಉತ್ತಮ ಮಾಡಲಾಗದ ಹಳೆಯ ಸಾಧನವಾಗಿದ್ದರೆ, ಆ ವಿನಾಯಿತಿಯನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ಅದರ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಪರ್ಯಾಯವೆಂದರೆ ಯಾರೂ ಅನುಮೋದಿಸಿದ್ದನ್ನು ನೆನಪಿಲ್ಲದ ಮೌನವಾಗಿ ದುರ್ಬಲಗೊಳಿಸಿದ ಮೂಲರೇಖೆ.