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 د اټکلونو پر ځای لیدل شوي حقایق کیږي۔ هغه نښلون چې د 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 ننوتل او د یوې ټاکلې جدول لوستلو اجازه درې جلا پایلې دي، او هر یو یې د ټکټ بندولو دمخه خپله څېړنه مستحق دی۔