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;SQL-մուտքին անցնելը, քանի որ Windows-ի մուտքը ձախողվել է, շրջանցող լուծում է, որը թաքցնում է ինքնության հարցը, և այն սովորաբար միևնույն է պահանջում է նոր մուտքի և գաղտնաբառի ստեղծում։ Եթե տեղակայումը պահանջում է 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 դառնում են տեսանելի փաստեր՝ ենթադրությունների փոխարեն։ Կապը, որը հաղորդում է NTLM այնտեղ, որտեղ սպասում էիք Kerberos-ի, անվան լուծման կամ 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-մուտքը և որոշակի աղյուսակ կարդալու թույլտվությունը երեք առանձին արդյունք են, և յուրաքանչյուրը արժանի է իր ստուգմանը մինչև տոմսը փակելը։