دليل الفدرالية مع Entra ID باستخدام AD FS
By Mirko Peters · · Updated
تعرّف على فدرالية AD FS وتسجيل الدخول الموحّد (SSO) وعلاقات الثقة والأمان، ثم اطّلع على الانتقال من AD FS إلى Microsoft Entra ID وأكثر مشكلات استكشاف الأخطاء وإصلاحها شيوعاً.
Automatically translated with AI from the original post. Read the English original

تلعب الفدرالية باستخدام خدمات اتحاد Active Directory (AD FS) دوراً محورياً في الطريقة التي تدير بها المؤسسات الحديثة الهوية الرقمية وتسجيل الدخول الموحّد (SSO). ومع نمو الأعمال وتطوّر احتياجاتها، ولا سيما مع انتشار تطبيقات السحابة ومنصات التعاون، أصبح فهم AD FS أكثر أهمية من أي وقت مضى. يستعرض هذا الدليل ما تقوم به AD FS، وكيف تندرج ضمن منظومة Microsoft الأوسع، وسبب تحوّل المؤسسات نحو حلول متقدمة مثل Entra ID وAzure AD، وكيف يعيد هذا التحوّل تشكيل مشهد المصادقة في المؤسسات.
من المفاهيم الأساسية مثل الهوية المفدَّرَلة، وصولاً إلى استراتيجيات الانتقال التفصيلية وأفضل ممارسات الأمان، ستحصل على نظرة شاملة على طريقة عمل AD FS، إضافة إلى ما ينبغي أن تعرفه عند التخطيط للانتقال إلى الهوية السحابية الحديثة. سواء كنت تستكشف أخطاء إعداد قائم أو ترسم نهجاً جديداً، فهذا المصدر يساعدك على اتخاذ قرارات مدروسة والحفاظ على قوة مصادقتك.
أساسيات خدمات اتحاد Active Directory
تقع خدمات اتحاد Active Directory (AD FS) في قلب الطريقة التي تربط بها كثير من المؤسسات أنظمة المصادقة المختلفة، خاصةً عندما تتعدد الموارد المحلية وخدمات السحابة. والفكرة الأساسية بسيطة: تتيح الهوية المفدَّرَلة للمستخدمين الوصول إلى التطبيقات خارج بيئتهم الأساسية باستخدام بيانات اعتمادهم المألوفة. فالهدف هو كسر الحواجز الرقمية بين المؤسسات والخدمات، وجعل الوصول أكثر أماناً وسلاسة للجميع.
تخيّل أن لديك شركاء أو موردين أو فرقاً عن بُعد يحتاجون إلى العمل على أنظمتك، لكنك لا تريد توزيع أسماء مستخدمين وكلمات مرور إضافية. هنا تأتي AD FS لتنشئ "جسوراً موثوقة" يمكن لهؤلاء المستخدمين عبرها تسجيل الدخول كما لو كانوا في بيئتهم المعتادة. إنها إجابة Microsoft عن السؤال القديم: "كيف نشارك الموارد دون التفريط في الأمان؟"، وتستند إلى معايير تقنية راسخة مثل SAML وOAuth.
إن كنت تخطو خطواتك الأولى في عالم الفدرالية الهوياتية، أو كنت تدير علاقات الثقة بين النطاقات منذ سنوات، فإن هذا القسم يضع الأسس. سنتناول ما تقوم به AD FS فعلياً، ولماذا ما زالت ذات صلة، وكيف تطوّرت جنباً إلى جنب مع واقع السحابة والبيئات الهجينة في المؤسسات. ستأتي التفاصيل في الأجزاء اللاحقة، لكن المهم الآن أن AD FS هي نقطة انطلاقك نحو مصادقة آمنة تعبر حدود الأنظمة في البيئات التي تعتمد بكثافة على Microsoft.
ما هي الفدرالية في Active Directory وكيف تعمل؟
خدمات اتحاد Active Directory (AD FS) أداة طوّرتها Microsoft لتمكين مصادقة آمنة وسلسة تتجاوز حدود المؤسسات والنطاقات. وجوهرها تطبيق "الهوية المفدَّرَلة"، أي أن مستخدميك يستطيعون الوصول إلى أنظمة أو تطبيقات أو خدمات لا يتحكم فيها نطاقك، باستخدام بيانات اعتمادهم المعتادة. وبذلك لا يحتاج أحد إلى تذكّر عشرات كلمات المرور أو التنقل بين عدة عمليات تسجيل دخول لإنجاز عمله.
كيف يحقق ذلك؟ تستخدم AD FS بروتوكولات معيارية في الصناعة مثل SAML (لغة ترميز تأكيدات الأمان) وOAuth لإنشاء علاقات موثوقة، وغالباً ما تُسمّى "الثقات الفدرالية"، بين مؤسستك (موفّر الهوية) وأي تطبيقات أو شركاء خارجيين (الأطراف المعتمِدة). وتكمن الفكرة الجوهرية في المصادقة القائمة على المطالبات: بعد التحقق من المستخدم، تُصدر AD FS "رمز أمان" يحتوي على مطالبات (أي تفاصيل عن هوية المستخدم وصلاحياته). ويتحقق التطبيق المستهدف من الرمز، ويسمح للمستخدم بالدخول إذا اجتاز كل شيء الفحص.
تاريخياً، ساعدت AD FS المؤسسات الكبيرة على توفير تسجيل الدخول الموحّد لكل من التطبيقات المحلية وموارد السحابة مثل Office 365. وفي الماضي، قبل أن تصبح الأدلة السحابية الأصلية مثل Entra ID شائعة، كانت AD FS الجسر الذي يحافظ على سلاسة المصادقة حتى عبر حدود الشركات. أما اليوم، فهي مكوّن أساسي في الإعدادات الهجينة، حتى مع اتجاه كثير من المؤسسات نحو حلول الهوية السحابية لمزيد من المرونة والأمان.
المكوّنات الأساسية لبنية AD FS
- خادم الفدرالية: المحرك الرئيسي لـ AD FS الذي يصادق على المستخدمين، ويُصدر الرموز القائمة على المطالبات، ويتولى علاقات الثقة مع الأطراف المعتمِدة.
- Web Application Proxy (WAP): يعمل كبوابة، ويوفّر وصولاً آمناً عبر الوكيل للمستخدمين الخارجيين، ويحمي خوادم الاتحاد من التعرّض المباشر للإنترنت.
- Claims Provider: يوفّر بيانات هوية المستخدم، وغالباً ما يسحبها من Active Directory، لتغذية عملية إنشاء الرموز المميزة وإصدار الادعاءات.
- Relying Party Trust: يمثّل التطبيقات أو الأنظمة الخارجية التي تستهلك رموز AD FS المميزة وتتحقق منها؛ ويحدد كيفية تحويل الادعاءات والمستخدمين المصرّح لهم.
- Domain Controller: يصادق على المستخدمين مقابل Active Directory، ويتحقق من بيانات الاعتماد قبل إصدار الرمز المميز.
شرح تدفقات مصادقة ADFS والثقة الاتحادية
عندما يتعلق الأمر بتسجيل الدخول الموحّد والوصول الآمن، يتميّز AD FS بجعل المصادقة بسيطة للمستخدمين النهائيين، حتى عندما تكون البنية الخلفية معقدة للغاية. يقوم هذا على طريقة تعامل AD FS مع تدفقات المصادقة والثقة الاتحادية. الأمر كله يتعلق بنقل بيانات الاعتماد والرموز المميزة والادعاءات بأمان وكفاءة، منذ لحظة محاولة المستخدم تسجيل الدخول وحتى وصوله فعلياً إلى التطبيق أو المورد المستهدف.
هنا تظهر القيمة الحقيقية لتفاصيل البروتوكولات، مثل SAML وWS-Federation وOAuth. تسير العملية بسرعة: التحقق من بيانات اعتماد المستخدم، وإصدار الادعاءات، وتحويل السمات، وإرسال الرموز المميزة الصحيحة إلى الأنظمة الصحيحة. وفي الوقت نفسه، تضمن علاقات الثقة الاتحادية أن المؤسستين على طرفي عملية التصافح واثقتان من هوية من يعبر البوابة الرقمية.
سنتناول لاحقاً مسار المصادقة النموذجي في AD FS خطوة بخطوة، ثم نتعمق في كيفية تهيئة الثقة الاتحادية بحيث تتمكن مؤسستان مستقلتان تماماً من السماح بوصول آمن عبر الشركات دون قلق. إن فهم هذه المفاهيم يزوّد محترفي تكنولوجيا المعلومات وفرق الأمان بما يلزمهم، بدءاً من بناء اتحاد آمن وصولاً إلى استكشاف أخطاء الوصول أو مشكلات الادعاءات المستعصية لاحقاً.
فهم تدفقات مصادقة ADFS
- وصول المستخدم إلى التطبيق: يحاول المستخدم فتح تطبيق اتحادي. إذا كان الوصول من خارج الشبكة، فإنه يمرّ أولاً عبر Web Application Proxy؛ أما الطلبات الداخلية فتتجه مباشرة إلى AD FS.
- إرسال طلب المصادقة: يعيد الطرف المعتمد (relying party) للتطبيق توجيه متصفح المستخدم إلى خادم AD FS مع طلب مصادقة يتضمن المورد الذي يريد الوصول إليه.
- التحقق من بيانات الاعتماد: يطلب AD FS من المستخدم تسجيل الدخول (باستخدام بيانات اعتماد Windows أو النماذج أو المصادقة متعددة العوامل أو الشهادة)، ويتحقق من هذه البيانات مع وحدة تحكم المجال في Active Directory.
- إنشاء الادعاءات: بعد التحقق، ينشئ AD FS رمزاً مميزاً قائماً على الادعاءات. يتضمن هذا الرمز سمات عن المستخدم، مثل اسم المستخدم وعضويات المجموعات أو البريد الإلكتروني، وذلك استناداً إلى قواعد مُعدّة مسبقاً.
- إصدار الرمز المميز: يوقّع AD FS الرمز المميز القائم على الادعاءات بأمان ويعيده إلى متصفح المستخدم.
- التطبيق يتحقق من الرمز المميز: يمرّر المتصفح الرمز المميز إلى التطبيق المستهدف، الذي يتحقق من صحته باستخدام الجزء العام من شهادة AD FS.
- منح الوصول: إذا تحقق التطابق بين الرمز المميز والادعاءات والقواعد، يسمح التطبيق للمستخدم بالدخول أخيراً، دون طلب كلمة مرور أخرى.
يصلح هذا التدفق خطوة بخطوة لتسجيل الدخول الموحّد النموذجي، سواء كان المستخدمون داخليين أو قادمين عبر شريك اتحادي. ينطبق منطق مماثل على OAuth (الشائع في تطبيقات SaaS)، ما يمنح AD FS مرونة في التعامل مع مجموعة واسعة من سيناريوهات المصادقة والبروتوكولات.
إقامة الثقة الاتحادية بين المؤسسات
إعداد الثقة الاتحادية في AD FS يعني إنشاء علاقة تتفق فيها مؤسستان على قبول رموز المصادقة الخاصة بكل منهما. من الناحية التقنية، يتضمن ذلك تهيئة كل طرف ليتعرّف على الطرف الآخر بوصفه مزوّد ادعاءات موثوقاً أو طرفاً معتمداً. يجري تبادل شهادات SSL لتأمين الاتصال، وتُضبط نهج ثقة مخصصة لتحديد الادعاءات المقبولة وكيفية ربط هويات المستخدمين.
تشكّل الثقة المهيأة بشكل صحيح أساساً لتسجيل دخول موحّد آمن وسلس مع الشركاء التجاريين والموردين والشركات التابعة، بما يتيح التعاون دون التنازل عن معايير أمان المؤسسة.
أمان AD FS وأفضل الممارسات عند النشر
أينما تحدثت عن الاتحاد (Federation) وتسجيل الدخول الموحد (SSO)، تصبح الأمنية الأولوية القصوى، فخرق واحد أو علاقة ثقة مُعدّة بشكل خاطئ يمكن أن ينتشر بسرعة كبيرة. مع AD FS، ينصبّ التركيز على حماية سلسلة إصدار الرموز المميزة بأكملها، والتأكد من أن الأشخاص المناسبين فقط يمكنهم المصادقة، وإبعاد المهاجمين عن أثمن مواردك.
يشمل المشهد التهديدي كل شيء من التصيّد لسرقة بيانات الاعتماد وسرقة الرموز المميزة، إلى هجمات حجب الخدمة ومحاولات القوة الغاشمة. أنت بحاجة إلى دفاعات قوية في كل خطوة: من سياسات المصادقة الصارمة إلى تدفقات الرموز المشفّرة، ومن التحديث الدوري إلى المراقبة في الوقت الفعلي. هذا النوع من الأمان متعدد الطبقات لا يكتفي بإبعاد المتسللين، بل يساعد المؤسسات أيضاً على الامتثال لمتطلبات التدقيق والحوكمة.
في الأقسام التالية، سنستعرض الدفاعات العملية لـ AD FS، ونسلّط الضوء على أكثر متجهات الهجوم شيوعاً واستراتيجيات التخفيف منها، ونلخّص أفضل الممارسات المثبتة للإعداد الآمن، والتدقيق المستمر، والتكامل مع برامج الأمان والحوكمة الأوسع. إذا كنت تبحث عن استراتيجيات عملية لتقليل المخاطر، بما في ذلك الدروس المستفادة من بيئات Microsoft Entra ID وAzure، فتابع القراءة. وإذا كنت مهتماً بكيفية عمل الهوية والوصول المشروط والحوكمة معاً في السحابة، فاطّلع على هذه الحلقة حول استراتيجية أمان الهوية للحصول على رؤى أعمق.
تأمين إصدار الرموز المميزة والمصادقة في AD FS
- فرض سياسات قوية لكلمات المرور وبيانات الاعتماد: اضبط كلمات مرور معقدة وقواعد انتهاء صلاحية صارمة للحد من تعرّض بيانات الاعتماد الضعيفة.
- تفعيل المصادقة متعددة العوامل (MFA): أضف خطوة تحقق ثانية (مثل رمز الهاتف أو جهاز الأمان المادي) لمنع تسجيلات الدخول غير المصرّح بها، حتى لو تم اختراق كلمة المرور.
- استخدام قنوات رموز مميزة آمنة ومشفّرة: اشترط استخدام SSL/TLS لجميع تبادلات الرموز المميزة، وتأكد من توقيع الرموز المميزة وتشفيرها لمنع العبث بها أو التنصت عليها.
- تقييد عمر الرمز المميز: استخدم رموزاً مميزة قصيرة الصلاحية للحد من نافذة الهجوم في حال سُرق الرمز المميز أو أُعيد استخدامه.
لمزيد من المعلومات حول منع الهجمات التي تتجاوز حتى MFA، مثل إساءة استخدام الموافقة على OAuth، اطّلع على هذه الضوابط الأساسية لتأمين Entra ID.
أهم الاعتبارات الأمنية وتخفيف التهديدات
- التصيّد لسرقة بيانات الاعتماد: درّب المستخدمين على اكتشاف رسائل التصيّد، واشترط MFA لحماية نقطة تسجيل الدخول.
- إعادة التشغيل وسرقة الرموز المميزة: استخدم فترات صلاحية قصيرة للرموز المميزة والتحقق المستمر منها للحد من الضرر الناتج عن الرموز المعترَض عليها.
- هجمات حجب الخدمة (DoS): انشر خوادم AD FS والخوادم الوكيلة في تكوينات عالية التوفر، وقلّل تعرّضها للشبكات غير الموثوقة.
- إدارة التحديثات: حدّث جميع خوادم AD FS والأنظمة المعتمدة عليها بانتظام لمعالجة الثغرات قبل أن يستغلها المهاجمون.
- التدقيق والمراقبة: طبّق تسجيلاً ومراقبة قوية للكشف المبكر عن النشاط المشبوه؛ ولنهج أوسع يقوم على مبدأ عدم الثقة (Zero Trust)، اطّلع على هذه حلقة البودكاست حول Zero Trust.
أفضل الممارسات لنشر AD FS ومراقبته
- التكرار وموازنة الأحمال: انشر عدة خوادم اتحاد وخوادم وكيلة لإزالة نقاط الفشل الفردية ودعم أعداد كبيرة من المستخدمين.
- المراقبة المستمرة: استخدم سجلات التدقيق ومراقبة الأحداث والتنبيه في الوقت الفعلي لرصد الأنماط المشبوهة بسرعة.
- عمليات التدقيق الأمني الدورية: راجع التكوينات وعلاقات الثقة بحثاً عن الانحراف أو الثغرات، وواكب تحديثات أفضل الممارسات.
- التكامل مع منصات أمان السحابة: اربط سجلات الأحداث في AD FS بأدوات SIEM مثل Microsoft Sentinel أو Microsoft Purview Audit لاكتشاف المخاطر الموحّد وإعداد تقارير الامتثال.
- إدارة دورة الحياة: حدّث الرموز المميزة والشهادات وإعدادات النهج بشكل دوري لتقليل "الدين الهوياتي" والمخاطر التقنية.
قيود ADFS ومشكلات استكشاف الأخطاء وإصلاحها في المؤسسات الحديثة
رغم أن AD FS ساعد مؤسسات كثيرة على ربط الأنظمة والمستخدمين في السنوات الماضية، فليس سرًا أن هذه التقنية تُسبب اليوم عددًا من المتاعب الحديثة. إذا كنت تدير بنية AD FS التحتية، فأنت تعرف الواقع جيدًا: هناك تكاليف صيانة، وإعدادات ثقة معقدة، وتحديثات تظهر في أسوأ الأوقات. ومع بيئات السحابة سريعة النمو، قد تبدو الطرق القديمة متهالكة بشكل واضح.
لا تقتصر القيود على الجانب التقني، بل قد تتحول إلى مخاطر على مستوى الأعمال. فكّر في موثوقية المصادقة، وفي سهولة توسيع النطاق، وفي سرعة التكيّف عندما تظهر متطلبات جديدة لخدمات SaaS. هذه هي النقاط الحساسة التي تدفع فرقًا كثيرة إلى النظر في الهويات المستندة إلى السحابة مثل Entra ID. لكن قبل أي خطوة كبيرة، من الضروري معرفة ما يجب الحذر منه، وما الذي يجب فعله عندما يتعطل شيء في بيئة AD FS.
سنتناول فيما يلي أهم القيود التي تُعيق AD FS أمام المؤسسات اليوم، ونشرح خطوات عملية لاستكشاف الأخطاء وإصلاحها للمشكلات الأكثر احتمالًا أن تصل إلى فريق الدعم الفني. إتقان هذه الأساسيات يمنحك وقتًا ثمينًا وثقة أكبر، سواء كنت تحافظ على استمرارية الخدمة الحالية أو تستعد للترحيل.
أهم قيود AD FS في مصادقة المؤسسات
- عبء صيانة مرتفع: تتطلب نشرات AD FS تحديثات أمنية مستمرة، ومراقبة دائمة، وصيانة للأجهزة، مما يرفع التكاليف التشغيلية.
- تكامل سحابي محدود: لا يستطيع AD FS القديم مضاهاة التكاملات العميقة والأصلية مع خدمات SaaS أو الأمان السحابي الأصلي الموجودة في Entra ID أو Azure AD.
- إعداد معقّد: يؤدي إعداد سيناريوهات الغابات المتعددة أو النطاقات المتقاطعة إلى إضافة مكونات متحركة أكثر، وفرص أكبر لأخطاء التهيئة.
- تحديات في التوسع: غالبًا ما تتطلب قواعد المستخدمين المتنامية أو احتياجات الوصول العالمي خوادم إضافية وإعدادات شبكية متقدمة.
استكشاف أخطاء AD FS الشائعة وإصلاحها
- إخفاقات المصادقة: تحقق من أذونات حساب الخدمة، واتصال وحدة تحكم النطاق، ومحاولات تسجيل الدخول الفاشلة في سجلات أحداث AD FS (يشير معرّف الحدث 364 إلى مشكلات في إصدار الرموز المميزة).
- أخطاء إصدار الرموز المميزة: راجع قواعد المطالبات وإعدادات الشهادات، فغالبًا ما تسبب الشهادات غير المتطابقة أو منتهية الصلاحية حالات الفشل.
- أطراف اعتماد مُهيّأة بشكل خاطئ: تحقق من نقاط النهاية، وعلاقات الثقة، وتحويلات المطالبات لضمان الربط الصحيح بين الأنظمة.
- أقفال الحسابات أو مشكلات كلمات المرور: تأكد من اتساق مزامنة كلمات المرور ونهج الحسابات عبر الغابات والنطاقات.
- مراقبة سجلات AD FS: استخدم معرّفات الأحداث ذات الصلة (مثل 100 لإصدار الرموز المميزة بنجاح، أو سلسلة 300 لمشكلات التهيئة) لتحديد الأسباب الجذرية بسرعة.
الترحيل من AD FS إلى Entra ID ومستقبل الاتحاد
بالنسبة للمؤسسات التي تُبقي قدمًا في AD FS القديم وتخطو الأخرى نحو السحابة، يتضح الطريق أمامها أكثر فأكثر. توفر حلول الهوية السحابية مثل Azure AD وEntra ID مصادقة قوية ومرنة وأكثر أمانًا للأحمال الحديثة، حتى للتطبيقات القديمة الصعبة التي كانت تعتمد على AD FS وحده. ويتجه القطاع نحو هذا النهج لأسباب وجيهة: انخفاض عبء الأجهزة، ونماذج ثقة أبسط، ووضعية أمنية مصممة للتعامل مع التهديدات المتطورة ومتطلبات الامتثال المتزايدة.
لكن الانتقال من AD FS ليس مسألة تبديل بضغطة زر. فالترحيل إلى Entra ID (العلامة الجديدة الجامعة لخدمات الهوية من Microsoft) يعني إعادة تقييم علاقات الثقة، وتكامل التطبيقات، وكيفية عمل نهج مثل الوصول المشروط والحوكمة في البيئة الجديدة. وعند تنفيذه بالشكل الصحيح، تحصل على رضا أعلى للمستخدمين، وضوابط أقوى وأكثر اتساقًا عبر الأنظمة السحابية والمحلية.
فيما يلي مقارنة مباشرة بين AD FS والهوية السحابية، إلى جانب استراتيجيات مجربة لانتقال تدريجي وسلس لا يُربك المستخدمين ولا يفتح ثغرات أمنية جديدة. وإذا أردت لمحة عن تحديات المخاطر والحوكمة المرتبطة بالوصول المشروط في Entra ID، فإن هذا التعمق في حلقات أمان الهوية نقطة بداية جيدة أيضًا.
مقارنة AD FS بالهوية السحابية باستخدام Azure AD وEntra ID
- قيود AD FS: متطلبات أجهزة محلية، وصيانة وتحديثات، وإدارة معقدة لعلاقات الثقة وقواعد المطالبات، وتكامل سحابي/SaaS أصلي محدود، واستجابة أبطأ للتهديدات الأمنية الناشئة.
- مزايا Azure AD وEntra ID: تكامل أصلي مع Microsoft 365، وإعداد أسهل، ووصول مشروط مدمج، وإعداد سريع لتطبيقات SaaS، وتطبيق متسق للنهج، وحماية محسّنة للهوية لأحمال العمل السحابية.
- محركات الترحيل الاستراتيجية: تقليل أعباء الصيانة، وتبسيط الإدارة، وإمكانية توسيع الوصول، ونماذج أمان قائمة على النهج تتكيف مع نمو الأعمال.
لمزيد من المعلومات حول كيفية تحوّل الاستثناءات والتفويضات المتراكمة إلى "دَين هوية"، وكيف يُحدث الحوكمة السليمة في Entra ID فرقًا في أمان هوية السحابة، راجع هذا البودكاست حول الهوية بوصفها مستوى التحكم.
استراتيجيات الترحيل لتحقيق انتقال سلس من AD FS إلى Entra ID
- الاكتشاف: احصر جميع الثقات المعتمِدة على الأطراف (relying party trusts) وقواعد المطالبات (claims rules) والتطبيقات المتكاملة المرتبطة بـ AD FS؛ وارسم خريطة التبعيات، وحدّد أحمال العمل الجاهزة للترحيل.
- التخطيط: صمّم خطة ترحيل مرحلية، مع إعداد Entra ID والتحقق من موصلات السحابة للتعايش الهجين عند الحاجة.
- التعايش: شغّل AD FS بالتوازي مع Entra ID، ونقل التطبيقات تدريجيًا لتتم المصادقة عبر Azure AD، مع مراقبة تجربة المستخدم وسجلات الوصول.
- التحويل النهائي: انقل المستخدمين وأحمال العمل النهائية إلى Entra ID، واحذف الثقات القديمة والقواعد المخصصة، وأوقف تشغيل البنية التحتية لـ AD FS المحلية بعد اكتمال التحقق.
- ضبط ما بعد الترحيل: راجع نهج الوصول المشروط، وتوفير المستخدمين، والتقارير في Entra ID لإغلاق الحلقة وتهيئة ممارسات الهوية لدعم المستقبل.
استمع أيضًا إلى هذه الحلقات
إذا كنت تبحث في اتحاد ADFS مع Entra ID، فإن هذه الحلقات تضيف سياقًا عمليًا حول البنية والأمان والحوكمة والتنفيذ:
- Microsoft AI Agent Harness – Simply Explained — افهم التنسيق وضوابط الحماية والتقييم وسير عمل الذكاء الاصطناعي الموثوق.
- Microsoft Defender XDR – Simply Explained — اربط قرارات الهوية والذكاء الاصطناعي بالمراقبة الأمنية والاستجابة لها.
- Microsoft Teams Governance – The Illusion of Control — تعرّف على كيفية تقليل الحوكمة والملكية والنهج للمخاطر التشغيلية.
- Azure Virtual Network – Simply Explained — افهم السياق المعماري الكامن وراء الاتصال السحابي.