VPN ಮೂಲಕ SQL Server ಇನ್ನೂ NTLM ಗೆ ಏಕೆ ಹಿಂತಿರುಗುತ್ತದೆ?

ನಿಮ್ಮ ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಲಾಗಿನ್ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತಿದೆ, ಮತ್ತು ಎಲ್ಲರೂ Kerberos ನಿರೀಕ್ಷಿಸಿದಾಗ SQL Server NTLM ಬಳಸುತ್ತಿದೆ. ಈ ಫಲಿತಾಂಶ VPN ದೋಷವಲ್ಲ, ಏಕೆಂದರೆ ಸುರಂಗ ಕೇವಲ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ; ಕ್ಲೈಂಟ್ ಕೇಳಿದ ಹೆಸರು, ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನೋಂದಾಯಿತ ಪ್ರಿನ್ಸಿಪಾಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಪಡೆಯಲು ಸಾಧ್ಯವಾದ ಟಿಕೆಟ್ ಸ್ಕೀಮ್ ಅನ್ನು ನಿರ್ಧರಿಸಿದವು. ಮೂರು ಷರತ್ತುಗಳು ಒಟ್ಟಿಗೆ ಇರಬೇಕು, ಮತ್ತು ಯಾವುದು ಬಿಟ್ಟುಕೊಟ್ಟಿತು ಎಂಬುದನ್ನು ಸೆಷನ್ ಸ್ವತಃ ಹೇಳುತ್ತದೆ. ಯಾರಾದರೂ ಸೇವಾ ಪ್ರಿನ್ಸಿಪಾಲ್ ಹೆಸರನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಇದನ್ನು ಓದಿ.

ಸೆಷನ್ ನೀವು ನಿಜವಾಗಿ ಪಡೆದ ಸ್ಕೀಮ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ

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

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

ಡೇಟಾಬೇಸ್ ಹೋಸ್ಟ್ನಲ್ಲಿನ ಸ್ಥಳೀಯ SSMS ವಿಂಡೋದ ಸಾಲು ಸಂಪೂರ್ಣ ಬೇರೆ ಸಂಪರ್ಕವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಚಲಾಯಿಸಬೇಕು. ಔಟ್ಪುಟ್ ಅನ್ನು ಸಮಯ ಮುದ್ರೆಯೊಂದಿಗೆ ಉಳಿಸಿ, ಏಕೆಂದರೆ ಅದನ್ನು ಓದುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ಯಾವಾಗ ತೆಗೆದುಕೊಳ್ಳಲಾಯಿತು ಎಂದು ಕೇಳುತ್ತಾರೆ. ಹಲವು ಅಪ್ಲಿಕೇಶನ್ಗಳು ಒಂದು ಅಂತ್ಯಬಿಂದುವನ್ನು ಹಂಚಿಕೊಂಡಾಗ ಪ್ರತಿಯೊಂದರಿಂದ ಮಾದರಿ ತೆಗೆದುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಎರಡು ಅಪ್ಲಿಕೇಶನ್ಗಳ ನಡುವಿನ ಡೇಟಾ ಮೂಲ ವ್ಯತ್ಯಾಸವೇ ಹೆಚ್ಚಾಗಿ ಇಡೀ ಕಥೆ.

ಮೊದಲ ಷರತ್ತು: ಹೆಸರು SPN ಗೆ ಹೊಂದುತ್ತದೆಯೇ?

Kerberos ಹೆಸರಿಸಿದ ಸೇವೆಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಿನ್ಸಿಪಾಲ್ಗಾಗಿ ಡೈರೆಕ್ಟರಿಯಿಂದ ಟಿಕೆಟ್ ಕೇಳುತ್ತದೆ. TCP ಪೂರೈಕೆದಾರರಿಗೆ ದಾಖಲಿತ ರೂಪ MSSQLSvc/, ನಂತರ ಸಂಪೂರ್ಣ ಅರ್ಹ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ ಪೋರ್ಟ್. ಹೆಸರಿಸಿದ ಇನ್ಸ್ಟಾನ್ಸ್ MSSQLSvc/db01.corp.example:SQLPROD ನೋಂದಾಯಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಪ್ರತ್ಯಯ ಸಂಖ್ಯೆಯ ಬದಲು ಇನ್ಸ್ಟಾನ್ಸ್ ಹೆಸರು. ಅಲಿಯಾಸ್, ಬೇರೆಡೆ ಪರಿಹರಿಸುವ CNAME ಅಥವಾ ಬರಿಯ IP ವಿಳಾಸದ ಮೂಲಕ ಆಲಿಸುವವರನ್ನು ತಲುಪುವುದು ಕೇಳಿದ ಹೆಸರನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಹೊಂದುವ ಪ್ರಿನ್ಸಿಪಾಲ್ ಇಲ್ಲದ ವಿನಂತಿಗೆ ಹಿಂತಿರುಗಿಸಲು ಟಿಕೆಟ್ ಇಲ್ಲ.

ಆದ್ದರಿಂದ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಲ್ಲಿ ಹಿಂದಕ್ಕೆ ಹೋಗುತ್ತದೆ: DNS ಉತ್ತರ, ಅಲಿಯಾಸ್ ದಾಖಲೆ ಅಥವಾ hosts ನಮೂದು ಕ್ಲೈಂಟ್ ಬಳಸಿದ ಹೆಸರನ್ನು ಬದಲಿಸಿತು. ನೋಂದಣಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಕೇಳಿದ ಹೆಸರನ್ನು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಎರಡನೇ ಷರತ್ತು: SPN ಸರಿಯಾದ ಖಾತೆಯಲ್ಲಿದೆಯೇ?

SPN SQL ಸೇವೆಯನ್ನು ಚಲಾಯಿಸುವ ಖಾತೆಗೆ ಸೇರಿರಬೇಕು, ಕ್ಲೈಂಟ್ನ ಖಾತೆಗಲ್ಲ ಮತ್ತು ಆಕಸ್ಮಿಕವಾಗಿ ಕಂಪ್ಯೂಟರ್ ಆಬ್ಜೆಕ್ಟ್ಗೂ ಅಲ್ಲ. SQL Server ತನ್ನ ಸೇವಾ ಖಾತೆಗೆ ಅವುಗಳನ್ನು ಬರೆಯುವ ಅನುಮತಿ ಇದ್ದಾಗ ಪ್ರಾರಂಭದಲ್ಲಿ ತನ್ನದೇ SPN ಅನ್ನು ನೋಂದಾಯಿಸಬಹುದು, ಇದು ಅನುಕೂಲಕರ ಮತ್ತು ಸೇವಾ ಖಾತೆ ಬದಲಾದ ನಂತರ ನಕಲು ಹೇಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನೂ ವಿವರಿಸುತ್ತದೆ.

ನೀವು ನಿರೀಕ್ಷಿಸುವ ಹೆಸರನ್ನು ಡೈರೆಕ್ಟರಿಗೆ ಕೇಳಿ, ನಂತರ ಖಾತೆ ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ. ಯಾವ ಆಬ್ಜೆಕ್ಟ್ ನಮೂದನ್ನು ಹಿಡಿದಿದೆ ಎಂಬುದು ಹೆಸರು ಕಾಡಿನ ಎಲ್ಲಾದರೂ ಇದೆಯೇ ಎಂಬುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಲಾಗಿನ್ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ ಎಂದರ್ಥ, ಮತ್ತು Microsoft ನ SPN ಮಾರ್ಗದರ್ಶಿ ಸ್ವರೂಪಗಳನ್ನು ಮತ್ತು ಡೊಮೇನ್ ನಿರ್ವಾಹಕರು ನಮೂದನ್ನು ರಚಿಸಬೇಕಾದ ಸಂದರ್ಭಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

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

ಮೂರನೇ ಷರತ್ತು: ಕ್ಲೈಂಟ್ ಟಿಕೆಟ್ ಪಡೆಯಲು ಸಾಧ್ಯವೇ?

ಸರಿಯಾದ SPN ನಿಷ್ಪ್ರಯೋಜಕ, ಕ್ಲೈಂಟ್ ಡೊಮೇನ್ ನಿಯಂತ್ರಕವನ್ನು ತಲುಪದಿದ್ದರೆ ಅಥವಾ ಬಳಸಬಹುದಾದ ರುಜುವಾತು ಸಂದರ್ಭ ಇಲ್ಲದಿದ್ದರೆ. ವಿನಿಮಯಕ್ಕೆ VPN ಮೂಲಕ KDC ಮತ್ತು DNS ಬೇಕು, ಮತ್ತು SQL ಪೋರ್ಟ್ ಮಾತ್ರ ಮಾರ್ಗನಿರ್ದೇಶನ ಮಾಡುವ ಸುರಂಗ ನಿಖರವಾಗಿ ಈ ಹಂತದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ತಲುಪುವಿಕೆಯನ್ನು ಅವರ ಮುಂದಿನ ಫೈರ್ವಾಲ್ನಿಂದಲ್ಲ, ಅದೇ ಯಂತ್ರ ಮತ್ತು ಅದೇ ಖಾತೆಯಿಂದ ಪರೀಕ್ಷಿಸಬೇಕು.

ಯಂತ್ರದಲ್ಲಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಲಾಯಿಸುವ ಖಾತೆಯ ಅಡಿಯಲ್ಲಿ ಟಿಕೆಟ್ ಕ್ಯಾಶ್ ಪರಿಶೀಲಿಸಿ. ಎತ್ತರಿಸಿದ ವಿಂಡೋದಿಂದ ಪಡೆದ ಯಂತ್ರ-ವ್ಯಾಪಿ ಪಟ್ಟಿ ಬೇರೆ ಬಳಕೆದಾರರಾಗಿ ಚಲಿಸುವ ಸೇವೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಬಳಕೆದಾರರಿಗೆ ಖಾಲಿ ಕ್ಯಾಶ್ ಅನಾನುಕೂಲವಲ್ಲ, ಒಂದು ಅನ್ವೇಷಣೆ.

klist
klist -li 0x3e7

ನಂತರ ಹಿಂತಿರುಗುವಿಕೆ ಏನು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿ. ನೀತಿ Kerberos ಅನ್ನು ಬಯಸಿದರೆ, NTLM ಸ್ಪಷ್ಟವಾಗಿ ನಿರಾಕರಿಸಬೇಕು, ಏಕೆಂದರೆ ಮೌನ ಹಿಂತಿರುಗುವಿಕೆ ಸಂರಚನಾ ದೋಷವನ್ನು ಅಗತ್ಯವನ್ನು ಉಲ್ಲಂಘಿಸುವ ಕೆಲಸದ ಸಂಪರ್ಕವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ NTLM ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದ್ದರೆ, ಅವುಗಳನ್ನು ಹೆಸರಿಸಿ ಮತ್ತು ಪ್ರತಿ NTLM ಸೆಷನ್ ಅನ್ನು ಘಟನೆಯಾಗಿ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

ಲಾಂಚರ್ ಬದಲಾಯಿಸುವುದು ಒಂದು ಚರ, ಪರಿಹಾರವಲ್ಲ

ಬೇರೆ ರುಜುವಾತಿನ ಅಡಿಯಲ್ಲಿ SSMS ಪ್ರಾರಂಭಿಸುವುದು ಅನುದ್ದೇಶಿತ ಹೊರಹೋಗುವ ಗುರುತನ್ನು ಗುಣಪಡಿಸಬಹುದು, ಇದು ಸಮಸ್ಯೆಯ ನಿಜವಾದ ವರ್ಗ. ಅದು ಗುರಿ ಹೆಸರು, ನೋಂದಣಿ ಅಥವಾ ಟಿಕೆಟ್ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸರ್ವರ್ ಏನನ್ನು ಸ್ವೀಕರಿಸಿತು ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಹೋಲಿಕೆಯನ್ನು ನಿಯಂತ್ರಿತವಾಗಿರಿಸಿ: ಅದೇ ಅಂತ್ಯಬಿಂದು, ಅದೇ ಪೂರೈಕೆದಾರ, ತಿಳಿದಿರುವ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಂದರ್ಭ, ನಂತರ ನೀವು ಸ್ಕೀಮ್ ಪರಿಶೀಲಿಸುವ ಹೊಸ ಸಂಪರ್ಕ. ಸ್ವೀಕರಿಸಿದ ಲಾಗಿನ್ ಮತ್ತು ಅದರ ಡೇಟಾಬೇಸ್ ಅನುಮತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಪ್ರವೇಶ ಮತ್ತು ದೃಢೀಕರಣ ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಗೆ ವಿಫಲವಾಗುತ್ತವೆ.

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