ಒಂದು ತಿಂಗಳ ಆಫ್‌ಲೈನ್ ನಂತರ ಡೊಮೇನ್ ಟ್ರಸ್ಟ್ ವಿಫಲವೇ? ಮೊದಲು ಪರಿಶೀಲಿಸಿ
ಸದಸ್ಯ ವರ್ಕ್‌ಸ್ಟೇಷನ್ ಯಂತ್ರ-ಪಾಸ್‌ವರ್ಡ್ ಮಧ್ಯಂತರವನ್ನು ಮೀರಿ ಆಫ್‌ಲೈನ್ ಆಗಿದ್ದರೂ ಟ್ರಸ್ಟ್ ಕಳೆದುಕೊಳ್ಳದಿರಬಹುದು. ಖಾತೆಯನ್ನು ಮರುಹೊಂದಿಸುವ ಮೊದಲು ಸುರಕ್ಷಿತ ಚಾನಲ್ ಸಾಬೀತುಪಡಿಸಿ.
ಒಂದು ಲ್ಯಾಪ್‌ಟಾಪ್ ಆರು ವಾರ VPN ನಿಂದ ಹೊರಗಿದ್ದು ಹಿಂತಿರುಗುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರು ಡೊಮೇನ್ ಖಾತೆಯಿಂದ ಲಾಗಿನ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ದೋಷವು ಟ್ರಸ್ಟ್ ಸಂಬಂಧವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಯಾರೋ ಕಂಪ್ಯೂಟರ್ ಖಾತೆಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತಾರೆ, ಅಥವಾ ಬಳಕೆದಾರರನ್ನು ಪೂರ್ಣ ಟನೆಲಿಂಗ್‌ಗೆ ಒತ್ತಾಯಿಸುತ್ತಾರೆ, ಮತ್ತು ಸಮಸ್ಯೆ ಮಾಯವಾದಂತೆ ಕಾಣುತ್ತದೆ. ಎರಡೂ ಕ್ರಿಯೆಗಳು ಏನು ಮುರಿದಿತ್ತು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸಲಿಲ್ಲ. Windows ಸದಸ್ಯವು ಸಾಮಾನ್ಯ ಯಂತ್ರ-ಪಾಸ್‌ವರ್ಡ್ ಮಧ್ಯಂತರವನ್ನು ಬಹಳ ಮೀರಿ ಆಫ್‌ಲೈನ್ ಆಗಿರಬಹುದು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟ್ರಸ್ಟ್ ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೊದಲ ಕೆಲಸ ತಲುಪುವಿಕೆಯ ವೈಫಲ್ಯವನ್ನು ನಿಜವಾದ ಸೀಕ್ರೆಟ್ ಅಸಂಗತಿಯಿಂದ ಬೇರ್ಪಡಿಸುವುದು.
ದೋಷವು ಟ್ರಸ್ಟ್‌ನಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಮೂರು ಸ್ಥಿತಿಗಳು ಹೋಲುತ್ತವೆ
ಬಳಕೆದಾರರು ಸಂಗ್ರಹಿಸಿದ ಡೊಮೇನ್ ಮಾಹಿತಿಯೊಂದಿಗೆ ಸೈನ್ ಇನ್ ಮಾಡಬಹುದು, ವರ್ಕ್‌ಸ್ಟೇಷನ್ ಡೊಮೇನ್ ನಿಯಂತ್ರಕವನ್ನು ಹುಡುಕಲಾಗದಿರಬಹುದು, ಅಥವಾ ಸದಸ್ಯ ಮತ್ತು ಡೊಮೇನ್ ಯಂತ್ರ ಖಾತೆಯ ಬಗ್ಗೆ ನಿಜವಾಗಿಯೂ ಒಪ್ಪದಿರಬಹುದು. ಕಟ್ಟುನಿಟ್ಟಾದ ಅರ್ಥದಲ್ಲಿ ಮುರಿದ ಟ್ರಸ್ಟ್ ಸಂಬಂಧ ಮೂರನೆಯದು ಮಾತ್ರ.
AD ಪ್ರತಿಕೃತಿಯ ಆರೋಗ್ಯವು ನಾಲ್ಕನೇ ಅವಲೋಕನ, ಮತ್ತು ಅದು ಈ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ. ಅದು ಡೊಮೇನ್ ನಿಯಂತ್ರಕರ ನಡುವಿನ ಒಪ್ಪಂದವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಆರೋಗ್ಯಕರ ಪ್ರತಿಕೃತಿ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಈ ಯಂತ್ರದ ಸ್ಥಳೀಯ ಸೀಕ್ರೆಟ್ ಅದರ ಕಂಪ್ಯೂಟರ್ ಖಾತೆಗೆ ಹೊಂದುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಪರಿಚಿತ 30 ದಿನದ ಡೀಫಾಲ್ಟ್ ಒಂದು ಬದಲಾವಣೆ ನೀತಿ, ಆಫ್‌ಲೈನ್ ಮುಕ್ತಾಯದ ಗಡುವಲ್ಲ. Microsoft ನ ಯಂತ್ರ-ಖಾತೆ ಪಾಸ್‌ವರ್ಡ್ ವಿವರಣೆ ಸಂಯೋಜಿತ ಬದಲಾವಣೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಸ್ಥೆಯು ಬೇರೆ ಮಧ್ಯಂತರವನ್ನು ಸಂರಚಿಸಬಹುದು.
VPN ಐಕಾನ್ ಸುರಕ್ಷಿತ ಚಾನಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ
ಯಾವುದೇ ಪರೀಕ್ಷೆ ಅರ್ಥಪೂರ್ಣವಾಗುವ ಮೊದಲು ಸಂಪರ್ಕವು ಡೊಮೇನ್ ಸೇವೆಗಳನ್ನು ತಲುಪಲು ಸಾಕಷ್ಟು ಉತ್ತಮವಾಗಿರಬೇಕು. ಅಂದರೆ ಉದ್ದೇಶಿಸಿದ ಡೊಮೇನ್ DNS ರಿಸಾಲ್ವರ್, ಹುಡುಕಬಹುದಾದ ನಿಯಂತ್ರಕ, ತಲುಪಬಹುದಾದ ದೃಢೀಕರಣ ಸೇವೆಗಳು ಮತ್ತು Kerberos ಗೆ ಸಾಕಷ್ಟು ಹತ್ತಿರದ ಗಡಿಯಾರ.
ಪೂರ್ಣ ಟನೆಲಿಂಗ್ ಇಲ್ಲಿ ಸಂಪೂರ್ಣ ಮಾನ್ಯ ವಿನ್ಯಾಸವಾಗಿರಬಹುದು. ವಿಭಜಿತ ಟನೆಲಿಂಗ್‌ಗೆ ಬದಲಾಗುವುದು ಆರೋಗ್ಯಕರ ಡೊಮೇನ್ ಸಂಬಂಧದ ಪೂರ್ವಾಪೇಕ್ಷೆಯಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಹಾಗೆ ಪರಿಗಣಿಸುವುದು ರೋಗನಿರ್ಣಯವನ್ನು ವಾಸ್ತುಶಿಲ್ಪ ಬದಲಾವಣೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ವರ್ಕ್‌ಸ್ಟೇಷನ್ ನಿಜವಾಗಿ ಯಾವ ನಿಯಂತ್ರಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಆ ಹೆಸರನ್ನು ದೋಷದೊಂದಿಗೆ ಇರಿಸಿ.
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -VerboseDNS ಸರ್ವರ್, ಪರಿಹರಿಸಿದ ನಿಯಂತ್ರಕ ಮತ್ತು ದೋಷದ ನಿಖರ ಪಠ್ಯವನ್ನು ದಾಖಲಿಸಿ. ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ವರದಿ ಮಾಡುವ VPN ಕ್ಲೈಂಟ್ ಸುರಂಗವಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಡೊಮೇನ್ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದಲ್ಲ. Kerberos ಪೋರ್ಟ್‌ನಲ್ಲಿ ಉತ್ತರಿಸಿ ಡೈರೆಕ್ಟರಿ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಉತ್ತರಿಸದ ನಿಯಂತ್ರಕ ಫೈರ್‌ವಾಲ್ ಕಂಡುಹಿಡಿಯುವಿಕೆ, ಟ್ರಸ್ಟ್ ಕಂಡುಹಿಡಿಯುವಿಕೆ ಅಲ್ಲ.
ಸರಿಪಡಿಸುವ ಮೊದಲು ಸದಸ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಿ
ಅಧಿಕೃತ Windows ಡೊಮೇನ್ ಸದಸ್ಯದಲ್ಲಿ, Test-ComputerSecureChannel -Verbose ಯಂತ್ರ ಮತ್ತು ಡೊಮೇನ್ ನಡುವಿನ ಚಾನಲ್‌ನ ಓದು-ಮಾತ್ರ ಪರಿಶೀಲನೆಯಾಗಿದೆ. ನೀವು ತನಿಖೆ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರದ ಸಂದರ್ಭದಲ್ಲಿ ಅದನ್ನು ಚಲಾಯಿಸಿ, ಡೊಮೇನ್ ನಿಯಂತ್ರಕದಿಂದಲ್ಲ, ಏಕೆಂದರೆ ಅದರ ಪಾತ್ರ ಮತ್ತು ಮರುಪ್ರಾಪ್ತಿ ನಿಯಮಗಳು ಬೇರೆ. ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಎಂಬ ಪದದ ಬದಲು ಔಟ್‌ಪುಟ್ ಮತ್ತು ನಿರ್ಗಮನ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ. ಆ ಬಿಲ್ಡ್‌ನಲ್ಲಿ cmdlet ಇಲ್ಲದಿದ್ದರೆ, ಮಾಡ್ಯೂಲ್ ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆ.
ಫಲಿತಾಂಶಕ್ಕೆ ಇನ್ನೂ ಸಂದರ್ಭ ಬೇಕು. ಯಂತ್ರವು ಆಯ್ಕೆಮಾಡಿದ ನಿಯಂತ್ರಕವನ್ನು ತಲುಪಲು ಅಥವಾ ಅಲ್ಲಿ ದೃಢೀಕರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ವಿಫಲ ಪರೀಕ್ಷೆ ಆಫ್‌ಲೈನ್ ಪಾಸ್‌ವರ್ಡ್ ಮುಗಿದಿದೆ ಎಂಬ ಸ್ವತಂತ್ರ ಪುರಾವೆಯಲ್ಲ. ನಿಜವಾದ ದೋಷ ಮತ್ತು ಬಳಸಿದ ನಿಯಂತ್ರಕವನ್ನು ಇರಿಸಿ, ಮಾರ್ಗ ತಿಳಿದು ಉತ್ತಮವಾದ ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ.
ಘಟನೆಯ ಸುತ್ತ ಸದಸ್ಯ ಮತ್ತು ಸಂಬಂಧಿತ ನಿಯಂತ್ರಕದಲ್ಲಿ Netlogon ಘಟನೆಗಳನ್ನು ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ. ಯಂತ್ರದ ಹೆಸರು, ಮೂಲ ವಿಳಾಸ, ಸಮಯ ಮತ್ತು ಖಾತೆ ಬದಲಾವಣೆಯ ಯಾವುದೇ ಪುರಾವೆಯನ್ನು ಸಂರಕ್ಷಿಸಿ. ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ಯಶಸ್ವಿ ಲಾಗಿನ್, ಅಥವಾ ಆರೋಗ್ಯಕರ ನಿಯಂತ್ರಕ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್, ಈ ಯಂತ್ರದ ವಿನಿಮಯಕ್ಕೆ ಬದಲಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನೀವು ಸಾಬೀತುಪಡಿಸಿದ ಸಂಬಂಧವನ್ನು ಮಾತ್ರ ಸರಿಪಡಿಸಿ
ಸಂಪರ್ಕ ಸ್ಥಿರವಾದ ನಂತರ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಸೂಕ್ತ ಎಂದು ನಿರ್ವಾಹಕರು ದೃಢೀಕರಿಸಿದ ನಂತರ, ಅಧಿಕೃತ ರುಜುವಾತುಗಳೊಂದಿಗೆ cmdlet ನ -Repair ಮೋಡ್ ಸದಸ್ಯ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗೆ ಬೆಂಬಲಿತ ಒಂದು ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಅದು ಸಂಬಂಧವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಇನ್ನೊಂದು ಓದು-ಮಾತ್ರ ಪರೀಕ್ಷೆಯಲ್ಲ.
ಬದಲಾವಣೆಗೆ ಮೊದಲು ಅನುಮೋದಿತ ಸ್ಥಳೀಯ ಮರುಪ್ರಾಪ್ತಿ ಖಾತೆ ಮತ್ತು ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ಲಭ್ಯವಾಗಿಸಿ. ಡೊಮೇನ್ ನಿಯಂತ್ರಕರಿಗೆ ಬೇರೆ ಮರುಪ್ರಾಪ್ತಿ ಪಾತ್ರವಿದೆ ಮತ್ತು ಈ ವಿಧಾನ ಅವರನ್ನು ಸಾಮಾನ್ಯ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗಳಂತೆ ಪರಿಗಣಿಸಬಾರದು. ಹಲವು ಮರುಹೊಂದಿಸುವ ಸಾಧನಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ ಅವುಗಳಲ್ಲಿ ಒಂದು ಸರಿ ಎಂದು ಆಶಿಸುವ ಬದಲು ಸಂಸ್ಥೆಯ ಮರುಪ್ರಾಪ್ತಿ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಬಳಸಿ.
ಸರಿಪಡಿಸಿದ ನಂತರ ಹೊಸ ಸುರಕ್ಷಿತ-ಚಾನಲ್ ಪರೀಕ್ಷೆ ಮತ್ತು ಮೂಲ ಡೊಮೇನ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯನ್ನು ಸಂರಕ್ಷಿಸಿ, ಮತ್ತು ತೆಗೆದು-ಮತ್ತೆ ಸೇರಿಸುವುದನ್ನು ಮೊದಲ ವಿವರಿಸದ ಕ್ರಿಯೆಯಾಗಿಸಬೇಡಿ.
ವೈಫಲ್ಯ ಮರಳಿ ಬಂದಾಗ ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು
ವೈಫಲ್ಯ ಮರಳಿ ಬಂದರೆ, ಅದೇ ಖಾತೆಯನ್ನು ಮತ್ತೆ ಮರುಹೊಂದಿಸುವ ಬದಲು ರೋಲ್‌ಬ್ಯಾಕ್, ನಕಲಿ ಗುರುತು ಮತ್ತು ಖಾತೆ ಬದಲಾವಣೆಗಳ ಸಮಯವನ್ನು ನೋಡಿ. ಮರುಸ್ಥಾಪಿಸಿದ ಇಮೇಜ್, ಸ್ನ್ಯಾಪ್‌ಶಾಟ್, ಕ್ಲೋನ್ ಮಾಡಿದ ಯಂತ್ರ ಗುರುತು, ಅಥವಾ ಬೇರೆಡೆ ಮಾಡಿದ ಕಂಪ್ಯೂಟರ್-ಖಾತೆ ಮರುಹೊಂದಿಕೆ—ಎಲ್ಲವೂ ತನಿಖೆಗೆ ಅರ್ಹ.
ತಾತ್ಕಾಲಿಕವಾಗಿ ಯಶಸ್ವಿ ಮರುಹೊಂದಿಕೆ ಉಪಯುಕ್ತ ಮರುಪ್ರಾಪ್ತಿ ಪುರಾವೆ, ಆದರೆ ಮಧ್ಯದಲ್ಲಿ ನಿಲ್ಲುವ VPN ಮೂಲ ಅಸಂಗತಿಗೆ ಕಾರಣವಾಯಿತು ಎಂಬ ಪುರಾವೆಯಲ್ಲ. ಕಾರಣವನ್ನು ನಿಜವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಮುಂದಿನ ಸಂಭವ ತಿಳಿಸುತ್ತದೆ.
ನಿಯಂತ್ರಕ, DNS ಸರ್ವರ್ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ. ಆ ದಾಖಲೆಯೇ ನಿಜವಾದ ಟ್ರಸ್ಟ್ ವೈಫಲ್ಯವನ್ನು ಡೊಮೇನ್ ಹುಡುಕಲಾಗದ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.