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 తప్పనిసరి అయినప్పుడు మొదటి మార్గం ఎందుకు వెనక్కి తగ్గిందో నమోదు చేయండి, ఒక సవరణను వర్తింపజేయండి మరియు అదే క్లయింట్ నుండి ప్రశ్నను మళ్లీ అమలు చేయండి. లాంచర్ మార్పు తర్వాత విజయవంతమైన ప్రశ్న యాక్సెస్కు సాక్ష్యం, మరియు ప్రామాణీకరణ అవసరం నెరవేరిందని ఇంకా సాక్ష్యం కాదు.