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 ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਾਂ ਦਰਜ ਕਰੋ ਕਿ ਪਹਿਲਾ ਰਾਹ ਕਿਉਂ ਵਾਪਸ ਗਿਆ, ਇੱਕ ਸੁਧਾਰ ਲਾਗੂ ਕਰੋ ਅਤੇ ਉਸੇ ਕਲਾਇੰਟ ਤੋਂ ਕਵੈਰੀ ਦੁਬਾਰਾ ਚਲਾਓ। ਲਾਂਚਰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਸਫਲ ਕਵੈਰੀ ਪਹੁੰਚ ਦਾ ਸਬੂਤ ਹੈ, ਅਤੇ ਇਹ ਅਜੇ ਸਬੂਤ ਨਹੀਂ ਹੈ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਜ਼ਰੂਰਤ ਪੂਰੀ ਹੋਈ।