SQL Server وActive Directory: ليش حساب الدومين يدخل ويندوز لكنه ما يقدر يقرأ قاعدة البيانات؟

تسجيل دخولك إلى ويندوز ينجح، والاتصال بخادم SQL يبدو متاحًا، لكن قاعدة التدريب ترفض قراءة جدول. هل المشكلة كلمة المرور؟ مو بالضرورة. أنت أمام طبقات مختلفة: هوية ويندوز، وLogin على SQL Server، وUser داخل قاعدة، وصلاحية على مورد محدد.
في لاب Active Directory ستقابل خدمات تعتمد على Windows Authentication، ومنها SQL Server. فهم الحدود بين هذه الطبقات يفيدك أكثر من تجربة حسابات كثيرة حتى ينجح واحد. بنستخدم قراءات قصيرة لا تغير البيانات، ونوضح ما تثبته كل نتيجة وما السؤال اللي يأتي بعدها. ما نستخدم حسابات من مواقع حقيقية، ولا نجرب قراءة بيانات أعمال؛ كل الأمثلة تخص قاعدة تدريب في بيئة تملكها أو نطاق مصرح واضح.

Windows Authentication مو صلاحية تلقائية على كل SQL

يوفر SQL Server نمط Windows Authentication، ونمطًا مختلطًا يتيح أيضًا SQL Server Authentication. في Windows Authentication يعتمد تأكيد الهوية على سياق ويندوز، وقد تستخدم الاتصالات NTLM أو Kerberos. لكن إثبات هوية الحساب شيء، وتحديد الموارد التي يستطيع استخدامها داخل SQL شيء آخر.
خلنا نفترض أن مستخدم LAB-Student ينجح في تسجيل الدخول إلى CLIENT01. هذا يثبت تجربة تسجيل دخول إلى ذلك الجهاز في ذلك السياق. ما اختبرت إلى الآن هل SQL Server يسمح له باتصال، أو هل هناك وصول لقاعدة التدريب، أو هل جدول معين يمنحه SELECT. لا تحمل نتيجة ويندوز هذه الإجابات كلها.
يمكن أيضًا إدارة الوصول عبر مجموعات ويندوز، فتتعلق تجربة الحساب بعضويته وإعداد SQL المقابل. لذلك اختلاف نتيجتين لحسابين من الدومين نفسه ليس تناقضًا. اشتراكهما في الدومين ما يساوي تطابق العضويات أو الإعدادات على الخدمة. اكتب نوع الهوية المستخدمة قبل أن تقارن النتيجة.
إذا كنت تتعلم، صمم مهمتين واضحتين: اتصال بحساب تدريبي معروف، ثم قراءة مورد تدريب معين. احتفظ بنتيجة كل مهمة منفصلة. هذا الترتيب يجعلك ترى أين ظهر المنع، بدل العودة إلى كلمة المرور كلما فشلت أي خطوة. الهوية قد تكون صحيحة، والقرار المناسب رفض عملية ما لم يكن مصرحًا بها لذلك الحساب.

Login وDatabase User وRole مو أسماء لنفس الشيء

توثق Microsoft Principals على نطاقات مختلفة، منها مستوى الخادم ومستوى قاعدة البيانات. Login يمثل سياقًا على مستوى الخادم، وDatabase User يمثل سياقًا داخل قاعدة. توجد أدوار أيضًا ضمن النطاقات المناسبة. لا تجمع هذه المصطلحات في كلمة مستخدم واحدة ثم تتوقع أن الإعدادات والصلاحيات تتبع معناها نفسه في كل مكان.
مثال تدريبي: الحساب يستطيع الاتصال بالخادم، لكنه لا يملك الوصول المطلوب لقاعدة LabApp. هذا يحتاج مراجعة سياق القاعدة، وليس إعادة إثبات أن المنفذ متاح. وفي مثال آخر، يدخل القاعدة لكن قراءة جدول محدد تُرفض. انتقل إلى المورد والعملية بدل الحكم أن المصادقة كلها فاشلة.
حدد الكائن الذي تتحدث عنه في ملاحظاتك. هل تقصد حساب الدومين، أم Login في SQL، أم User في LabApp، أم عضوية Role؟ ذكر المستوى يمنع كثيرًا من اللبس أثناء التواصل. لما يقول شخص أضف المستخدم، اسأله أين ولأي حاجة، بدل تنفيذ تغيير واسع بناء على جملة مختصرة.
لا تستنتج صلاحية نهائية من اسم دور يبدو مألوفًا بدون مراجعة تعريفه والإعدادات. كذلك لا تخلط dbo user مع db_owner role أو ملكية القاعدة؛ الوثائق تفرق بينها. ما نحتاج نخوض في كل تفاصيل نموذج الصلاحيات حتى نتعلم الأساس: الهوية والدور والمورد والنطاق عناصر تحتاج تسمية واضحة، وليست أربع طرق مختلفة لقول إن الحساب دخل.

ابدأ من الجلسة الحالية: من دخل، وأي قاعدة؟

بعد إنشاء اتصال مصرح إلى خادم اللاب بالأداة المعتمدة لديك، نفذ قراءة سياق قصيرة داخل قاعدة التدريب المقصودة:
SELECT ORIGINAL_LOGIN() AS original_login, USER_NAME() AS database_user, DB_NAME() AS database_name;
ORIGINAL_LOGIN يعرض Login الذي بدأ الاتصال، وUSER_NAME بدون معرف يعرض المستخدم في سياق القاعدة الحالي، وDB_NAME بدون معرف يعرض القاعدة الحالية. الطلب يقرأ سياقًا ولا يعدل بيانات جداول التطبيق.
اكتب النتائج كما هي في ملاحظاتك الخاصة باللاب، ثم فسر سبب حاجتك لكل قيمة. اسم القاعدة مهم لأن تنفيذ طلب على قاعدة غير التي تقصدها يعطيك معنى آخر. واسم المستخدم داخلها يحدد سياق القراءة الحالية. لا تختصر اختلاف الأسماء إلى أن الأداة غلط؛ دلالات الدوال مختلفة أصلًا.
إذا كنت داخل جلسة لها تبديل سياق مشروع، فقد يختلف السياق الحالي عن Login الأصلي. نحن لا ننفذ تبديلًا في هذا المثال، لكن من المهم تعرف لماذا لا تعطي الدوال وعدًا بأن كل القيم ستكون متطابقة دائمًا. راجع تعريف الدالة قبل استخدامها كدليل هوية في تقرير أو تطبيق.
قبل أي استعلام لاحق، تحقق أنك ما زلت في السياق المقصود. فتح نافذة جديدة أو اتصال ثانٍ قد يغير القاعدة أو الهوية التي تقرأ بها. هذه ليست خطوة شكلية: مقارنة مخرجات من اتصالين بدون ذكر اختلافهما ممكن تصنع قصة عن صلاحيات متغيرة بينما السؤال الحقيقي أن كل نتيجة جاءت من سياق مختلف.

تجربة SELECT صغيرة على بيانات مصطنعة

لو عندك جدول تدريبي اسمه dbo.LabStatus داخل قاعدة اللاب، يحتوي قيمًا مصطنعة غير حساسة، تستطيع تنفيذ قراءة محدودة للغرض التعليمي:
SELECT TOP (5) status_name FROM dbo.LabStatus;
المثال يفترض وجود الجدول والعمود وصلاحية القراءة في تصميم اللاب. لا تنقله إلى جداول عمل حقيقية، ولا تعتبر وجود اسم مشابه موافقة على استخراج محتواه. الهدف اختبار عملية محددة على مورد تعرفه مسبقًا.
إذا نجحت القراءة، اكتب أنها نجحت على هذا الجدول بهذه الجلسة. لا تعلن أن الحساب يستطيع قراءة كل القواعد أو تعديل البيانات. SELECT تختلف عن UPDATE أو عمليات إدارة أخرى، والمورد المحدد يختلف عن بقية الموارد. دليل العملية يجب أن يذكر نوعها ونطاقها حتى يكون تفسيره صحيحًا.
إذا ظهر خطأ يتعلق بالاسم أو وجود المورد، افحص القاعدة واسم المخطط والجدول والعمود كما صممتها في اللاب. هذا سؤال يختلف عن رفض صلاحية مثبت على مورد موجود. لا تحول كل خطأ في الاستعلام إلى ضعف في الحساب، ولا تطلب صلاحيات أعلى قبل التأكد أنك تسأل عن الكائن الصحيح.
ولو ظهرت رسالة رفض صلاحية، احتفظ بالنص المناسب بدون أسرار، وسجل الهوية والمورد والوقت. هذه النتيجة قد تكون المتوقعة إذا صممت اللاب لعزل قراءات الحسابات. نجاح الاختبار المهني ما يعني قبول كل طلب؛ قد يعني إثبات أن عملية غير مسموحة رُفضت وفق المتطلبات. قارن النتيجة بالتصميم قبل اقتراح تعديل.

راجع الصلاحيات في نطاقها، لا من اسم الحساب

داخل قاعدة اللاب، توثق Microsoft دالة لعرض الصلاحيات الفعلية الممنوحة للسياق على مورد. لقراءة نطاق قاعدة البيانات الحالية يمكن استعمال:
SELECT permission_name FROM sys.fn_my_permissions(NULL, 'DATABASE');
هذه القراءة تخص نطاق DATABASE الحالي، وليست قائمة بكل صلاحيات نظام التشغيل أو كل الموارد في كل قاعدة. إذا كنت تريد تفسير جدول معين، راجع سؤال المورد المناسب ودلالته في الوثائق بدل نقل النتيجة العامة إليه تلقائيًا.
الغرض من هذا المثال أن تختبر تفسيرًا، لا تجمع قائمة طويلة وتبحث عن أكثر كلمة مثيرة. إذا نجحت قراءة LabStatus لكنك لم تفهم لماذا، تحتاج مراجعة تعريف الصلاحيات والأدوار والمجموعات ذات الصلة ضمن ما يسمح به اللاب. اكتب الدليل الذي يشرح قبول العملية، وليس فقط اسم حساب دخل بنجاح.
لا تغير العضويات أو تمنح أدوارًا واسعة عشان تتجاوز رفضًا أثناء التشخيص. هذا يغير الحالة التي تختبرها، وقد يجعل المشكلة تختفي بدون فهم السبب. في اللاب، إذا كان الهدف دراسة تغيير مصرح، سجل الحالة السابقة والمتطلبات والنتيجة الجديدة بشكل مستقل. وفي العمل، يقرر صاحب النظام التغيير وفق إجراءات الوصول.
فرق بين صلاحية موجودة في نتيجة المصدر وبين الحاجة التشغيلية لها. أداة القراءة تجيب عن الحالة، أما هل يجب أن يمتلك الحساب هذه العملية، فتحتاج معرفة دور الحساب والخدمة. التقييم الأمني الجيد يجمع الأمرين: الحالة الفعلية والمتطلب. بدون المتطلب قد تمدح منعًا يعطل وظيفة لازمة، أو تبرر وصولًا أوسع مما يحتاجه المستخدم.

Kerberos وSPN: اسم الاتصال له معنى

Windows Authentication قد تستخدم Kerberos أو NTLM. وجود علامة نجاح للاتصال ما يحدد وحده أيهما استُخدم. عندما يكون السؤال عن Kerberos، استخدم مصدرًا يصف جلسة الاتصال نفسها وفق صلاحيات نسختك، وراجع متطلبات الخدمة والاسم. لا تستنتج البروتوكول من كون الحساب ينتمي للدومين.
Microsoft توثق دور SPN في اتصالات Kerberos إلى SQL Server. في مقال SPN وsetspn بالمجتمع شرحنا أن هوية الخدمة والاسم الذي تطلبه يؤثران في فهم الاتصال. هنا المهم أن تحافظ على اسم الوجهة وطريقة الاتصال في ملاحظات المقارنة؛ تجربة بالاسم وتجربة بعنوان IP ليستا بالضرورة سياقًا مطابقًا.
تخيل تطبيقًا تدريبيًا يستخدم اسمًا بديلًا للخدمة، بينما تجربتك اليدوية تستخدم اسم الجهاز الأصلي. إذا كانت النتائج مختلفة، ابدأ بمقارنة الاسمين وإعداد الخدمة المتوقع، بدل اعتبار كلمة المرور السبب الوحيد. لا تسجل أو تعدل SPN عشوائيًا؛ أنت تريد أولًا تعرف ما المطلوب وما الموجود ومن المسؤول عن الإعداد.
إذا نجح الاتصال بنمط غير الذي تتوقعه، اكتب النتيجة والسؤال المتبقي. لا تصف استخدام NTLM تلقائيًا كدليل اختراق، ولا نجاح Kerberos كضمان لصحة كل صلاحيات SQL. البروتوكول جزء من مسار تأكيد الهوية، ونموذج الوصول إلى القاعدة جزء آخر. فصل الاثنين يمنعك تحول تشخيص مصادقة إلى حكم شامل على الأمان.

خطأ TLS يختلف عن رفض Login

قد يفشل الاتصال قبل الوصول إلى اختبار الهوية، بسبب متطلبات تشفير أو تحقق شهادة في العميل والخادم. حينها إعادة تجربة كلمة المرور أو تغيير Database User قد لا تعالج المرحلة التي تعثرت. اقرأ رسالة الخطأ والوقت ونسخة العميل، وحدد هل وصلت المحاولة إلى الخدمة المطلوبة وما المرحلة الظاهرة.
توثق Microsoft وجود نسختين من sqlcmd، مبنية على Go أو ODBC، مع اختلافات في بعض الخيارات والسلوك. لذلك لا تنقل تعليمات معالجة اتصال من نسخة إلى أخرى بدون مراجعة المتطلبات. سجل نوع العميل والنسخة وإعداد الاتصال المعتمد قبل المقارنة. اسم الأداة وحده ما يضمن تطابق تفاصيل المحاولتين.
لا تجعل تعطيل التحقق من شهادة الخادم حلًا افتراضيًا لكل مشكلة. في لابك راجع اسم الوجهة والثقة والشهادة والمتطلبات المناسبة، ثم جهز اتصالًا صحيحًا وفق تصميمك. اختفاء رسالة بعد تقليل التحقق ما يثبت أن الحالة الأصلية سليمة، ويغير سؤال التجربة بدل الإجابة عنه.
نفس الفكرة تنطبق على مصادقة Windows مقابل SQL Server Authentication. إذا كانت المشكلة في الاتصال أو TLS، تغيير نوع الهوية بلا سبب واضح قد يخفي الطبقة التي تحتاج مراجعة. حافظ على متغيرات التجربة قدر الإمكان، واكتب لماذا غيرت متغيرًا عند الحاجة. التشخيص الجيد ينتج سببًا مفهومًا، لا مجرد توليفة تعمل بعد عشر تعديلات ما عاد تتذكر ترتيبها.

سيناريو زميلين: نفس القاعدة ونتيجتان مختلفتان

LAB-A وLAB-B يستطيعان الوصول إلى ويندوز الدومين. الأول يقرأ جدول التدريب، والثاني تُرفض قراءته. قبل الحكم أن الثاني يحتاج حسابًا أقوى، قارن السياق: خادم SQL نفسه، والقاعدة نفسها، ونوع المصادقة، والعملية نفسها، والحسابات أو المجموعات المرتبطة بها. إذا اختلف المصدر أو المورد، فالنتيجتان لا تقيسان الطلب نفسه.
افترض أن تصميم اللاب يسمح لمجموعة LAB-Readers بالقراءة، وأن LAB-A عضو فيها وLAB-B ليس عضوًا. هذا تفسير تعليمي محتمل يحتاج تحققًا من العضوية وإعداد SQL المناسب، وليس نتيجة ننسبها تلقائيًا إلى كل فرق. اكتب الفرضية ثم الدليل الذي أكدها أو خالفها، بدل تحويل المثال إلى وصفة تشخيص وحيدة.
إذا كانت الصلاحيات مختلفة عن المتطلبات، التوصية المهنية تحدد أقل وصول لازم للوظيفة مع مراجعة المالك، ولا تطلب دورًا واسعًا لمجرد تسريع العمل. وإذا كانت متوافقة، فرفض الطلب نجاح للضابط الذي اختبرته. ما تحتاج تصنع ثغرة كي يكون تمرينك مفيدًا؛ فهم الحد الصحيح مهارة مهمة أيضًا.
وثّق المقارنة في فقرتين: ما تماثل بين التجربتين، وما اختلف، ثم معنى النتيجة. هذا يعلّمك تقدم سببًا يمكن مراجعته. جملة عندي يشتغل وعنده لا، فيها نتيجة لكن ما فيها سياق كافٍ. أما ذكر الهوية والمورد والعملية والضابط المتوقع، فيسمح للآخر يفهم أين يبحث وما الذي ما زال يحتاج إثباتًا.

جلسة تدريب تنتهي بفهم صلاحية واحدة

اختر قاعدة مصطنعة وجدولًا تدريبيًا تعرف تصميم الوصول إليه. اتصل بهوية مصرح بها، واقرأ Login الأصلي وUser الحالي واسم القاعدة، ثم نفذ SELECT المحددة. إذا كانت النتيجة متوقعة، اكتب لماذا. وإذا اختلفت، حدد أي طبقة تحتاج دليلًا إضافيًا بدل إعادة كل شيء من البداية.
في ملاحظاتك اجمع أربعة عناصر فقط لهذا المثال: الهوية، والقاعدة والمورد، والعملية، والنتيجة. أضف مصدر تعريف الدوال والصلاحية اللازمة عندما تشرح التفسير. لا تحتفظ بكلمات مرور داخل الأوامر أو لقطات الشاشة، ولا تستخدم بيانات حقيقية لتجعل المثال يبدو أكثر احترافًا. الدليل المصطنع الواضح يكفي للتعلم.
عندما تبدأ لاحقًا أداة مثل SQLRecon، ارجع لهذا الأساس. أي مخرج عن خادم أو مستخدم أو دور يحتاج دلالة ونطاقًا، وأي عملية أكبر من القراءة تحتاج خطة وتصريحًا يناسبانها. تعلم SQL داخل لاب الدومين ما يبدأ من تنفيذ كل وظيفة في الأداة، بل من معرفة من يتصل وبأي سياق وما الذي يسمح به المورد.
المراجع الرسمية:
https://learn.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/principals-database-engine
https://learn.microsoft.com/en-us/sql/t-sql/functions/original-login-transact-sql
https://learn.microsoft.com/en-us/sql/relational-databases/system-functions/sys-fn-my-permissions-transact-sql
https://learn.microsoft.com/en-us/sql/tools/sqlcmd/sqlcmd-utility
نجاح حساب الدومين في ويندوز بداية سياق، وليس إذنًا لقراءة كل قاعدة. افصل تأكيد الهوية عن تعريف المستخدم وعن العملية المطلوبة، وبتقدر تفسر الرفض والقبول بدل الاكتفاء بتجربة حساب جديد كل مرة.