ولې VPN له لارې SQL Server لا هم 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 ثبتوي، چېرې چې پایښت د عدد پرځای د مثال نوم دی. د شنونکي ته د لقب، بل ځای کې حل کېدونکي 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 اړین وي، ولیکئ چې لومړۍ لار ولې شاته شوه، یو اصلاح تطبیق کړئ او پوښتنه له هماغه کلینټ څخه بیا چل کړئ. د پیلوونکي له بدلون وروسته بریالې پوښتنه د لاسرسي ثبوت دی، او لا هم د دې ثبوت نه دی چې د تصدیق غوښتنه پوره شوې.