Ինչու է SQL Server-ը VPN-ի միջոցով դեռևս անցնում NTLM-ի։

Ձեր կապը աշխատում է, մուտքը ընդունվում է, և SQL Server-ը օգտագործում է NTLM, մինչ բոլորը սպասում էին Kerberos-ի։ Այդ արդյունքը 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, որտեղ վերջածանցը համարի փոխարեն օրինակի անունն է։ Լսողին alias-ով, այլ տեղ լուծվող CNAME-ով կամ մերկ IP հասցեով հասնելը փոխում է պահանջված անունը, և համապատասխան հիմնական սուբյեկտ չունեցող հարցումը վերադարձնելու տոմս չունի։

Այդ պատճառով մի հավելված աշխատում է մի ցանցում և հետ է ընկնում մյուսում՝ DNS պատասխանը, alias գրառումը կամ hosts մուտքը փոխել են հաճախորդի օգտագործած անունը։ Համեմատեք պահանջված անունը գրացուցակում եղածի հետ նախքան գրանցմանը դիպչելը։

Երկրորդ պայման. արդյոք SPN-ը ճիշտ հաշվի վրա է։

SPN-ը պետք է պատկանի այն հաշվին, որը գործարկում է SQL ծառայությունը, ոչ հաճախորդի հաշվին և ոչ էլ պատահաբար համակարգչային օբյեկտի։ SQL Server-ը կարող է գրանցել իր SPN-ները գործարկման պահին, երբ նրա ծառայության հաշիվն ունի դրանք գրելու թույլտվություն, ինչը հարմար է և նաև բացատրում է, թե ինչպես է կրկնօրինակ հայտնվում ծառայության հաշիվը փոխելուց հետո։

Հարցրեք գրացուցակին ձեր սպասած անվան մասին, ապա թվարկեք, թե ինչն է իրականում պատկանում հաշվին։ Թե որ օբյեկտն է պահում գրառումը, ավելի կարևոր է, քան այն, թե արդյոք անունը գոյություն ունի ինչ-որ տեղ անտառում։ Անհամապատասխանությունը նշանակում է, որ մուտքը երբեք խնդիրը չի եղել, և Microsoft-ի SPN ուղեցույցը փաստաթղթավորում է ձևաչափերը և այն դեպքերը, երբ տիրույթի ադմինիստրատորը պետք է ստեղծի գրառումը։

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

Եվս մեկ գրառում ավելացնելը անվտանգ փորձ չէ։ Կրկնօրինակը կամ հակասող գրանցումը կարող է կոտրել աշխատող հաճախորդներին, ուստի ստուգեք սեփականությունը փոփոխությունից առաջ և կրկին ստուգեք դրանից հետո։

Երրորդ պայման. արդյոք հաճախորդը ընդհանրապես կարող է տոմս ստանալ։

Ճիշտ SPN-ն անօգուտ է, եթե հաճախորդը չի կարող հասնել տիրույթի կառավարչին կամ չունի օգտագործելի հավատարմագրային համատեքստ։ Փոխանակմանը անհրաժեշտ են KDC-ն և DNS-ը VPN-ի միջոցով, և միայն SQL պորտը երթուղավորող թունելը ձախողվում է հենց այս քայլում։ Հասանելիությունը պետք է ստուգվի նույն մեքենայից և նույն հաշվից, ոչ թե նրանց դիմացի հրդեհային պատից։

Ստուգեք տոմսերի քեշը մեքենայի վրա և հավելվածը գործարկող հաշվի ներքո։ Բարձրացված պատուհանից ստացված մեքենայական ցանկը ոչինչ չի ասում այլ օգտվողի անունով աշխատող ծառայության մասին, և այդ օգտվողի համար դատարկ քեշը հայտնաբերում է, ոչ թե անհարմարություն։

klist
klist -li 0x3e7

Ապա որոշեք, թե ինչ կարող է անել հետընթացը։ Եթե քաղաքականությունը պահանջում է Kerberos, NTLM-ը պետք է բացահայտ մերժվի, որովհետև լուռ հետընթացը կազմաձևման սխալը վերածում է պահանջը խախտող աշխատող կապի։ Եթե NTLM-ը որոշ հավելվածների համար մնում է ընդունելի, անվանեք դրանք և դադարեք յուրաքանչյուր NTLM նստաշրջան դիտարկել որպես միջադեպ։

Գործարկիչի փոխումը մեկ փոփոխական է, ոչ թե լուծում

SSMS-ը այլ հավատարմագրով գործարկելը կարող է բուժել ակամա արտահոսող ինքնությունը, ինչը խնդիրների իրական դաս է։ Դա ոչինչ չի ապացուցում թիրախ անվան, գրանցման կամ տոմսի ուղու մասին և չի փոխում այն, ինչ ընդունել է սերվերը։

Պահեք համեմատությունը վերահսկվող՝ նույն վերջնակետը, նույն մատակարարը, հայտնի կատարման համատեքստ, ապա նոր կապ, որի սխեման դուք ստուգում եք։ Առանձին հաստատեք ընդունված մուտքը և դրա տվյալների բազայի թույլտվությունները, որովհետև հասանելիությունը և նույնականացումը ձախողվում են տարբեր պատճառներով։

Երբ Kerberos-ը պարտադիր է, գրանցեք, թե ինչու առաջին ուղին հետ ընկավ, կիրառեք մեկ ուղղում և նորից կատարեք հարցումը նույն հաճախորդից։ Գործարկիչը փոխելուց հետո հաջող հարցումը հասանելիության ապացույց է, և դեռ ապացույց չէ, որ նույնականացման պահանջը բավարարվել է։