VPN ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ SQL Server Windows ದೃಢೀಕರಣವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ
VPN ಲಾಗಿನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, SQL Server Windows ದೃಢೀಕರಣವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ: ಟನೆಲ್ ಖಾತೆಯನ್ನು ಕ್ಲೈಂಟ್ ಟೋಕನ್‌ೊಂದಿಗೆ ಹೋಲಿಸಿ, ನಂತರ ಸರ್ವರ್‌ನಲ್ಲಿ auth_scheme ಓದಿ.
ಟನೆಲ್‌ಗಳು ಏಳುತ್ತವೆ, ಸರ್ವರ್‌ಗಳು ping ಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಲಾಗಿನ್ ಇನ್ನೂ ದೃಢೀಕರಣ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ VPN ಕೊಂಡಿಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಮುರಿದಿದೆ ಎಂದು ಅರ್ಥವಾಗುವುದು ಅಪರೂಪ, ಏಕೆಂದರೆ ತಲುಪಬಹುದಾದ ಶ್ರೋತೃ ಮತ್ತು ಸ್ವೀಕರಿಸಿದ ಲಾಗಿನ್ ಎರಡು ಬೇರೆ ಫಲಿತಾಂಶಗಳು. ಗೇಟ್ವೇಯನ್ನು ತೃಪ್ತಿಪಡಿಸಿದ ಗುರುತು ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್ ನೀಡುವ ಗುರುತೇ ಆಗಿರಬೇಕೆಂದಿಲ್ಲ. ಯಾವ ಖಾತೆ ಬಂದಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದೇ ಇಡೀ ಕೆಲಸ.
ಲಕ್ಷಣ: ತಲುಪಬಹುದಾದ ಸರ್ವರ್, ನಿರಾಕರಿಸಿದ ಲಾಗಿನ್
ಟೈಮ್‌ಔಟ್ ಪ್ಯಾಕೆಟ್ ಯಾವ ಶ್ರೋತೃವನ್ನೂ ತಲುಪಲಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ದೃಢೀಕರಣ ದೋಷ ಶ್ರೋತೃ ಉತ್ತರಿಸಿ ರುಜುವಾತನ್ನು ನಿರಾಕರಿಸಿತು ಎಂದು ಹೇಳುತ್ತದೆ. ಈ ಎರಡು ಸಂದೇಶಗಳು ನಿಮ್ಮನ್ನು ಬೇರೆ ಬೇರೆ ತಂಡಗಳಿಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಎಂದೂ ಸಮಸ್ಯೆಯಾಗದ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳ ಮೇಲೆ ಒಂದು ದಿನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ದೋಷ ಲಾಗಿನ್ ವೈಫಲ್ಯವಾದಾಗ, ಪೋರ್ಟ್‌ಗಳನ್ನು ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಉಳಿದ ಪ್ರಶ್ನೆ ಎಂದರೆ ಕ್ಲೈಂಟ್ ಯಾವ Windows ಗುರುತನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿತು, ಸರ್ವರ್ ಆ ಗುರುತನ್ನು ಸ್ವೀಕರಿಸಿತೇ, ಮತ್ತು ಅದು ಅನುಮತಿ ಇರುವ ಡೇಟಾಬೇಸ್ ಬಳಕೆದಾರನಾಗಿ ಪರಿಹರಿಸಲ್ಪಟ್ಟಿತೇ.
ಎರಡು ಗುರುತುಗಳು, ಒಂದು ಟನೆಲ್
VPN ಖಾತೆ ಗೇಟ್‌ವೇಯಲ್ಲಿ ದೃಢೀಕರಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಅಲ್ಲೇ ಮುಗಿಯುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್ ಪ್ರತ್ಯೇಕವಾಗಿ Windows ಟೋಕನ್ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ, ಅದನ್ನು ಚಲಾಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಅಥವಾ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಕೇಳಿದರೆ SQL ಲಾಗಿನ್ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇಯ ಸ್ಥಳೀಯ VPN ಬಳಕೆದಾರರಿಗೆ SQL Server ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ, ಮತ್ತು ಟನೆಲ್ ಅಂತಹ ಸಂಬಂಧವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
ವೈಯಕ್ತಿಕ ಯಂತ್ರವನ್ನು VPN ಗೆ ಸಂಪರ್ಕಿಸುವುದು ಅದನ್ನು ಡೊಮೇನ್‌ಗೂ ಸೇರಿಸುವುದಿಲ್ಲ. ಸ್ಥಳೀಯ ಖಾತೆಯನ್ನು ಮರುಹೆಸರಿಸಿ ಅದರ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಡೊಮೇನ್ ಬಳಕೆದಾರರೊಂದಿಗೆ ಹೊಂದಿಸುವುದು ನೋಂದಣಿ ಕಾರ್ಯವಿಧಾನವಲ್ಲ, ಮತ್ತು ಅದು ಡೊಮೇನ್ ನಿಯಂತ್ರಕ ಆ ಬಳಕೆದಾರನಾಗಿ ಸ್ವೀಕರಿಸದ ಟೋಕನ್ ಉತ್ಪಾದಿಸುತ್ತದೆ.
ಕೆಲವು ಸ್ಥಳೀಯ Windows ದೂರಸ್ಥ ಪ್ರವೇಶ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಪ್ರೊಫೈಲ್ ಹಾಗೆ ಸಂರಚಿಸಲ್ಪಟ್ಟಿದ್ದರೆ ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ VPN ರುಜುವಾತನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಆ ವರ್ತನೆ ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಮತ್ತು ಪ್ರೊಫೈಲ್‌ಗೆ ಸೇರಿದ್ದು, ಸಾಮಾನ್ಯವಾಗಿ VPN ಸಂಪರ್ಕಗಳಿಗಲ್ಲ, ಆದ್ದರಿಂದ ಊಹಿಸುವ ಬದಲು ಬಳಕೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್‌ಗೆ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ.
ಕ್ಲೈಂಟ್ ಕೇಳಿದ ಮೋಡ್ ಓದಿ
ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಕ್ಲೈಂಟ್ ಯಾವ ದೃಢೀಕರಣ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಂಯೋಜಿತ ಭದ್ರತೆ Windows ಟೋಕನ್ ಬಳಸುತ್ತದೆ; ಬಳಕೆದಾರ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಜೋಡಿ SQL ಲಾಗಿನ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಇವು ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಮೋಡ್‌ಗಳು, ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಕ್ಕೆ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.
Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;Windows ಲಾಗಿನ್ ವಿಫಲವಾದ್ದರಿಂದ SQL ಲಾಗಿನ್‌ಗೆ ಬದಲಾಗುವುದು ಗುರುತಿನ ಪ್ರಶ್ನೆಯನ್ನು ಮರೆಮಾಡುವ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಹೊಸ ಲಾಗಿನ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ರಚಿಸುವುದು ಹೇಗಾದರೂ ಬೇಕಾಗುತ್ತದೆ. ನಿಯೋಜನೆಗೆ Windows ದೃಢೀಕರಣ ಬೇಕಾದರೆ, ಮೋಡ್ ಅನ್ನು ಉಳಿಸಿ ಗುರುತಿನ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ. SQL ಲಾಗಿನ್‌ಗೂ ತನ್ನದೇ ಅನುಮತಿಗಳು ಬೇಕು, ಆದ್ದರಿಂದ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ ನಿರ್ವಹಣೆಗೆ ಎರಡನೇ ಖಾತೆಯನ್ನು ಖರೀದಿಸುತ್ತದೆ.
ಯಾವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕಿಸುತ್ತಿದೆ ಎಂಬುದನ್ನೂ ದೃಢೀಕರಿಸಿ. ಸಿಸ್ಟಮ್ ಖಾತೆಯಾಗಿ ಚಲಿಸುವ ಸೇವೆ, ನಿಗದಿತ ಕಾರ್ಯ ಮತ್ತು ಸಂವಾದಾತ್ಮಕ ಪ್ರಶ್ನೆ ವಿಂಡೋ ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಮೂರು ಬೇರೆ ಟೋಕನ್‌ಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು, ಮತ್ತು ಕೊನೆಯದು ಮಾತ್ರ ಬಳಕೆದಾರ whoami ಚಲಾಯಿಸಿದಾಗ ಕಾಣುವುದರೊಂದಿಗೆ ಹೊಂದುತ್ತದೆ.
ಸರ್ವರ್ನಿಂದ ಅದು ನಿಜವಾಗಿ ಏನನ್ನು ನೋಡಿತು ಎಂದು ಕೇಳಿ
ಸರ್ವರ್ ಯಾವ ಲಾಗಿನ್ ಅನ್ನು ಪರಿಹರಿಸಿತು ಮತ್ತು ಸಂಪರ್ಕ ಹೇಗೆ ದೃಢೀಕರಣಗೊಂಡಿತು ಎಂಬುದನ್ನು ಹೇಳಬಲ್ಲದು. ತನಿಖೆಯಲ್ಲಿರುವ ಅಧಿವೇಶನದ ಒಳಗೇ ಪ್ರಶ್ನೆಯನ್ನು ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ನಿರ್ವಾಹಕರ ಪ್ರತ್ಯೇಕ ಯಶಸ್ವಿ ಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತಿರುವ ಕ್ಲೈಂಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
SELECT ORIGINAL_LOGIN() AS original_login,
SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;ಮೊದಲ ಸಾಲು ಅಧಿವೇಶನ ತೆರೆದ ಲಾಗಿನ್ ಅನ್ನು ಈಗ ಜಾರಿಯಲ್ಲಿರುವ ಭದ್ರತಾ ಸಂದರ್ಭದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಸೋಗಿನ ಅಡಿಯಲ್ಲಿ ಇವೆರಡೂ ಭಿನ್ನ. ಎರಡನೆಯದು ದೃಢೀಕರಣ ಯೋಜನೆಗೆ ಹೆಸರು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ KERBEROS, NTLM ಮತ್ತು SQL ಊಹೆಗಳ ಬದಲು ಗೋಚರ ಸತ್ಯಗಳಾಗುತ್ತವೆ. ನೀವು Kerberos ನಿರೀಕ್ಷಿಸಿದಲ್ಲಿ NTLM ವರದಿ ಮಾಡುವ ಸಂಪರ್ಕ ಪಾಸ್‌ವರ್ಡ್ ಸಮಸ್ಯೆಯಲ್ಲ, ಹೆಸರು-ಪರಿಹಾರ ಅಥವಾ SPN ಸಮಸ್ಯೆ.
ದೋಷ ಸಂಖ್ಯೆ ಅದನ್ನು ಇನ್ನಷ್ಟು ಕಿರಿದಾಗಿಸುತ್ತದೆ. ಸ್ಥಿತಿ 5 ಸಾಮಾನ್ಯವಾಗಿ ಲಾಗಿನ್ ಹೆಸರು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲ್ಪಡಲಿಲ್ಲ ಎಂದು ಅರ್ಥ, ಸ್ಥಿತಿ 8 ಸಾಮಾನ್ಯವಾಗಿ ಪಾಸ್‌ವರ್ಡ್ ಹೊಂದಲಿಲ್ಲ ಎಂದು ಅರ್ಥ, ಮತ್ತು ಸ್ಥಿತಿ 11 ರುಜುವಾತು ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿತು ಆದರೆ ಸರ್ವರ್ ಪ್ರವೇಶ ವಿಫಲವಾಯಿತು ಎಂದು ಅರ್ಥ. ನಿರ್ವಾಹಕರನ್ನು ಇಡೀ ಸಂದೇಶದ ಬದಲು ಸ್ಥಿತಿಯನ್ನು ಕೇಳಿ, ಏಕೆಂದರೆ ಸಂದೇಶ ಒಂದೇ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ.
| What you observe | What it suggests |
|---|---|
| Timeout, no listener | Route, firewall or wrong port |
| Login failed, state 5 | Name not resolved in the domain |
| Login failed, state 11 | Authenticated but no server access |
| Connected as NTLM | Target name or SPN mismatch |
ಗುರುತು ಬಂದಾಗಲೂ Kerberos ವಿಫಲವಾದಾಗ
ಸರ್ವರ್ ಉದ್ದೇಶಿತ Windows ಗುರುತನ್ನು ನೋಡಿದರೂ ಸಂಯೋಜಿತ ದೃಢೀಕರಣ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ ವಿನಿಮಯದಲ್ಲೇ ಇದೆ. Kerberos ಗೆ SQL ಸೇವಾ ಖಾತೆಗೆ ನೋಂದಾಯಿತ ಸೇವಾ ಪ್ರಧಾನ ಹೆಸರು (SPN) ಮತ್ತು ಅದಕ್ಕೆ ಹೊಂದುವ ಹೆಸರಿನಿಂದ ಸೇವೆಯನ್ನು ಕೇಳುವ ಕ್ಲೈಂಟ್ ಬೇಕು. IP ವಿಳಾಸದ ಮೂಲಕ ಸಂಪರ್ಕಿಸುವುದು ಹೆಸರು ಆಧಾರಿತ SPN ಗೆ ಹೊಂದಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಉಪನಾಮವೂ ನೋಂದಾಯಿತವಾಗಿದ್ದರೆ ಮಾತ್ರ ಹೊಂದಬಹುದು. ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲು ಕ್ಲೈಂಟ್ ಟೈಪ್ ಮಾಡಿದ ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹೋಸ್ಟ್‌ಹೆಸರಿನಿಂದ ಕೆಲಸ ಮಾಡಿ IP ಯಿಂದ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕ ನಿಖರವಾಗಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.
ನಿರ್ವಾಹಕರನ್ನು ಪ್ರಯೋಗ ಮತ್ತು ದೋಷದ ಮೂಲಕ ನಕಲಿ SPN ಗಳನ್ನು ರಚಿಸುವ ಬದಲು ನೋಂದಾಯಿತ ಗುರುತು ಮತ್ತು ಸೇವಾ ಖಾತೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಕೇಳಿ. ನಕಲಿ ನೋಂದಣಿಗಳು ಮೂಲ ಸಮಸ್ಯೆಗಿಂತ ರೋಗನಿರ್ಣಯ ಮಾಡಲು ಕಷ್ಟವಾದ ಮಧ್ಯಂತರ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
ದೃಢೀಕರಣ ಕೆಲಸ ಮಾಡಿದ ನಂತರವೂ ಲಾಗಿನ್‌ಗೆ ಡೇಟಾಬೇಸ್ ಬಳಕೆದಾರ ಮತ್ತು ಅನುಮತಿಗಳು ಬೇಕು. ಯಶಸ್ವಿ VPN ಲಾಗಿನ್, ಯಶಸ್ವಿ Windows ಲಾಗಿನ್ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕೋಷ್ಟಕವನ್ನು ಓದುವ ಅನುಮತಿ ಮೂರು ಪ್ರತ್ಯೇಕ ಫಲಿತಾಂಶಗಳು, ಮತ್ತು ಟಿಕೆಟ್ ಮುಚ್ಚುವ ಮೊದಲು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹ.