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 లాగిన్ మరియు నిర్దిష్ట పట్టికను చదవడానికి అనుమతి మూడు వేర్వేరు ఫలితాలు, మరియు టికెట్ మూసివేయడానికి ముందు ప్రతిదీ దాని స్వంత తనిఖీకి అర్హత పొందుతుంది.