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