ويندوز هيلو للأعمال: شرح مفاتيح الأجهزة وتسجيل الدخول الموحد

ويندوز هيلو للأعمال (WHfB) لقد أصبح هذا عنصرًا أساسيًا في استراتيجية مايكروسوفت لإدارة الهوية للشركات: وداعًا لكلمات المرور التقليدية ومرحبًا بنموذج مصادقة يعتمد على المفاتيح المشفرة والبيانات البيومترية وأرقام التعريف الشخصية والأجهزة الموثوقة. بالإضافة إلى معرّف تسجيل الدخول إلى مايكروسوفت وتسجيل الدخول الموحد (SSO)يتيح ذلك للمستخدمين الوصول إلى موارد السحابة والموارد المحلية بحركة واحدة، مع الحفاظ على ضوابط الأمان على مستوى المؤسسة.

في هذه المقالة سوف نتناول، بهدوء ولكن بشكل مباشر، كيف تعمل مصادقة Windows Hello للأعمال عند استخدام مفاتيح الأجهزة، والأجهزة التي تدعم TPM، وسيناريوهات تسجيل الدخول الموحد (SSO)؟ بالمقارنة مع Microsoft Entra ID و Active Directory، سنلقي نظرة على المراحل الداخلية (تسجيل الجهاز، والتزويد، ومزامنة المفاتيح، والشهادات، والمصادقة)، ودور PRT في SSO، وكيفية تكامله مع Kerberos في البيئات المختلطة، ومتطلبات البنية التحتية لكي يعمل كل شيء بسلاسة.

البنية العامة لـ Windows Hello للأعمال ونموذجها بدون كلمة مرور

لا يقتصر Windows Hello للأعمال على "إدخال رمز PIN أو إظهار وجهك" فقط. لتسجيل الدخول، يُستخدم نظام موزع يجمع بين هوية المستخدم وهوية الجهاز ومفاتيح التشفير المحمية بواسطة الأجهزة. وتعتمد المصادقة على زوج من المفاتيح العامة والخاصة أو الشهادات، المرتبطة بالجهاز (TPM) ويتم فتحها بواسطة شيء يعرفه المستخدم (رمز PIN) أو شيء يتعلق به (البيانات البيومترية).

الفرق الكبير مقارنة بكلمات المرور التقليدية والسبب هو أنه لم يعد هناك "سر مشترك" ينتقل عبر الشبكة أو يُخزّن مركزيًا: إذ يخزن الخادم (Microsoft Entra ID أو Active Directory) الجزء العام من المفتاح فقط، بينما يبقى الجزء الخاص ثابتًا على الجهاز. عندما يرغب المستخدم في المصادقة، يُوقّع نظام Windows قيمة عشوائية (nonce) باستخدام المفتاح الخاص، ويتحقق موفر الهوية من صحة هذا التوقيع باستخدام المفتاح العام المُسجّل.

هذا النهج يجعل WHfB مقاومًا للتصيد الاحتياليحتى لو تمكن مهاجم من خداع مستخدم لإدخال اسم المستخدم الخاص به على موقع خبيث، فلن يتمكن من تكرار عملية المصادقة بدون المفتاح الخاص المرتبط بوحدة TPM الخاصة بالجهاز. والنتيجة هي نظام مصادقة ثنائي العوامل (مفتاح + رقم تعريف شخصي/بيانات بيومترية) يفي بمعايير المصادقة متعددة العوامل القوية، ولكنه يوفر تجربة مستخدم أكثر سلاسة وأمانًا مُعززًا. نوافذ 11.

يتكامل WHfB بشكل أصلي مع Microsoft Entra ID و Active Directoryيُتيح ذلك نماذج نشر مختلفة: سحابية بالكامل، أو هجينة، أو محلية بالكامل. علاوة على ذلك، يمكنه العمل بالتوازي مع البطاقات الذكية ومفاتيح FIDO2، بل ويمكنه إعادة استخدام البنية التحتية للمفاتيح العامة (PKI) الحالية للمؤسسة عند اختيار النماذج القائمة على الشهادات.

مراحل تشغيل Windows Hello للأعمال

لفهم ما يحدث "خلف الكواليس" بشكل كاملالنهج الأكثر عملية هو تقسيم دورة حياة Windows Hello for Business إلى عدة مراحل مترابطة: تسجيل الجهاز، والتزويد، ومزامنة المفاتيح (في الوضع المختلط)، وتسجيل الشهادة (إذا تم استخدامها)، وأخيرًا، المصادقة وتسجيل الدخول الموحد.

1. تسجيل الجهاز

قبل إصدار بيانات اعتماد WHfB للمستخدم، يجب أن يكون للجهاز هويته الخاصة.تُسمى هذه العملية تسجيل الجهاز، وهي تربط الجهاز بمزود هوية المؤسسة (IdP).

يتغير كل من موفر الهوية وخدمة التسجيل تبعاً لنوع النشر.:

• التطبيقات السحابية أو الهجينة: موفر الهوية هو Microsoft Enter ID. يسجل الجهاز لدى خدمة تسجيل الأجهزة يصبح جهازًا من نوع "Microsoft Entra-joined device" أو "Microsoft Entra-joined hybrid".
• تطبيقات محلية بحتة: موفر الهوية هو AD FS، والجهاز مسجل في خدمة تسجيل أجهزة المؤسسات وهذا يكشف خدمة AD FS.

ونتيجةً للتسجيل، يمنح موفر الهوية الفريق هويته الخاصة.سيُستخدم هذا في عمليات تبادل مصادقة المستخدم اللاحقة واسترجاع الرموز المميزة. توجد أنواع مختلفة من "التركيبات" أو حالات الانضمام (تسجيل الدخول فقط، هجين، منضم إلى نطاق تقليدي + مسجل، إلخ) تحدد كيفية عمل الجهاز في البيئات المختلطة.

2. توفير خدمة Windows Hello للأعمال

مرحلة التزويد هي المرحلة التي يتم فيها إنشاء بيانات اعتماد Hello لمستخدم معين على جهازهنا يظهر مفهوم أساسي: الـ حاوية Windows Hello، وهو عبارة عن بنية منطقية يتم فيها تخزين جميع "المواد الأساسية" المرتبطة بهويات المستخدم على ذلك الكمبيوتر.

تتضمن عملية الشراء النموذجية عدة خطوات مترابطة:

1. يقوم المستخدم بتسجيل الدخول باستخدام بيانات الاعتماد التقليدية الخاصة به (عادة اسم المستخدم وكلمة المرور) ويقوم النظام بتشغيل تجربة إعداد WHfB، ويطلب المصادقة متعددة العوامل من موفر الهوية (Microsoft Entra ID أو AD FS).
2. بعد إتمام برنامج الماجستير في الفنون الجميلة بنجاح، يُطلب من المستخدم تحديد رقم تعريف شخصي (PIN)، وإذا سمحت الأجهزة بذلك، تسجيل البيانات البيومترية. (البصمة، الوجه، القزحية).
3. بمجرد تأكيد رمز PIN، يقوم نظام التشغيل Windows بإنشاء حاوية Windows Hello على الجهاز.
4. يتم إنشاء A زوج مفاتيح المصادقة العامة والخاصة، المرتبطة بوحدة TPM (إن وجدت) أو، في حالة عدم وجودها، محمية بواسطة برنامج.
5. يتم تخزين المفتاح الخاص محليًا ويتم ختمه على وحدة TPM، ولا يمكن تصديره.
6. يتم تسجيل المفتاح العام في موفر الهوية وربطه بحساب المستخدم:
   1. في سيناريوهات السحابة أو السيناريوهات المختلطة، تقوم خدمة تسجيل الجهاز بكتابتها إلى كائن مستخدم Microsoft Entra ID.
   2. في السيناريوهات المحلية مع AD FS، يتم تخزينها في Active Directory.

داخل الحاوية، يحتفظ كل "واقي" (رقم التعريف الشخصي، أو الإيماءة البيومترية، وما إلى ذلك) بنسخة مشفرة خاصة به من مفتاح المصادقة.في حال وجود وحدة TPM، يُستخدم رقم التعريف الشخصي (PIN) كمصدر عشوائية في عملية التشفير؛ وإلا، يُشتق مفتاح متماثل لتشفير البيانات. وهذا يسمح للمستخدم بفتح نفس زوج المفاتيح بإيماءات مختلفة، دون المساس بالأمان.

بالإضافة إلى مفتاح المصادقة الأساسي، قد تتضمن الحاوية عناصر أخرى، مثل مفتاح إداري لسيناريوهات إعادة تعيين رقم التعريف الشخصي، والكائنات الثنائية الكبيرة مع شهادات TPM، وقبل كل شيء، أنواع مختلفة من مفاتيح تعريف المستخدم المستخدمة لبروتوكولات محددة (WebAuthn/FIDO2، Entra ID، شهادات المستخدم لـ VPN أو RDP، إلخ).

تفاصيل مفاتيح المصادقة ومعرف المستخدم

مفتاح مصادقة Windows Hello هو دائمًا زوج غير متماثل يتم إنشاء مفتاح (عام/خاص) أثناء التسجيل. في كل مرة يُستخدم فيها، يجب فتحه باستخدام رمز PIN أو البيانات البيومترية. إذا أعاد المستخدم تعيين رمز PIN الخاص به، يتم إنشاء زوج مفاتيح مصادقة جديد، ويتم إعادة تشفير جميع البيانات المحمية بالزوج السابق.

يمكن أن تكون مفاتيح تعريف المستخدم متناظرة أو غير متناظرة.يعتمد ذلك على موفر الهوية والسيناريو. في بيئات الأعمال الحديثة (مثل Microsoft Entra ID وActive Directory وحسابات Microsoft الشخصية)، عادةً ما تكون أزواج مفاتيح غير متماثلة، يتم إنشاؤها وتخزينها على الجهاز، مع تسجيل الجزء العام منها لدى موفر الهوية.

هناك طريقتان رئيسيتان لإنشاء مفاتيح تعريف المستخدم في المنظمات:

• اربطهم بـ البنية التحتية للمفاتيح العامة للشركاتبحيث يتم ربط المفتاح بشهادة صادرة عن هيئة إصدار الشهادات التابعة للشركة. وهذا يسهل الانتقال من البنى التحتية القائمة على الشهادات (مثل VPN وRDP مع شهادات المستخدم، وما إلى ذلك) إلى WHfB.
• اسمح بأن يكون ذلك بشكل مباشر موفر الهوية (Entra ID أو AD FS) هو المسؤول عن إدارة زوج المفاتيح مرتبط بالهوية، مما يقلل من تعقيد البنية التحتية للمفاتيح العامة عندما لا يكون ذلك ضرورياً.

تُستخدم هذه المفاتيح لإثبات الملكية عن طريق توقيع أرقام عشوائية (nonces). أو رموز المصادقة، سواءً مع وحدات تحكم المجال (Kerberos) أو مع خدمات الويب التي تستخدم WebAuthn (FIDO2). يمكن لجهاز واحد استضافة العديد من بيانات اعتماد FIDO المرتبطة بمواقع ويب أو تطبيقات مختلفة، وكلها تُدار داخل حاوية Windows Hello.

التخزين المحلي للبيانات البيومترية

إحدى النقاط التي غالباً ما تثير قلق العديد من المستخدمين والمدققين هي ما يحدث لخصائصهم البيومترية.في Windows Hello for Business، قوالب القياسات الحيوية يتم تخزينها فقط على الجهاز، في قاعدة بيانات محلية لا يمكن الوصول إليها بواسطة مايكروسوفت ولا تتم مزامنتها مع السحابة.

يحتفظ كل مستشعر بيومتري بقاعدة بيانات خاصة به من القوالب. (على سبيل المثال ، في C:\WINDOWS\System32\WinBioDatabaseيتم تشفير هذه البيانات باستخدام مفتاح عشوائي فريد لكل قاعدة بيانات، وهي محمية بتقنية AES في وضع CBC وبخوارزمية التجزئة SHA-256. حتى لو تمكن مهاجم من الحصول على هذه القاعدة، فلن يتمكن من إعادة بناء الصور الأصلية للوجه أو بصمة الإصبع؛ فهي بيانات نموذجية غير قابلة للعكس.

3. مزامنة المفاتيح في البيئات الهجينة

في عمليات النشر المختلطة، يجب أن يصل المفتاح العام المسجل في Microsoft Entra ID أيضًا إلى Active Directory بحيث يمكن للمستخدم المصادقة بدون كلمة مرور لكل من الخدمات السحابية والموارد المحلية.

تتولى مايكروسوفت إدارة هذه العملية. أدخل Connect Sync.، والذي يقوم بمزامنة المفتاح العام للمستخدم من "أدخل المعرف" إلى السمة msDS-KeyCredentialLink من كائن المستخدم في Active Directory. وبهذه الطريقة، يمكن لوحدات تحكم المجال التحقق من صحة عمليات المصادقة المستندة إلى المفاتيح (سيناريو ثقة المفاتيح) أو استخدام المعلومات المرتبطة بها لنماذج ثقة Kerberos السحابية.

4. تسجيل الشهادة (عند استخدام النموذج القائم على الشهادة)

إذا كانت مؤسستك قد نشرت بالفعل بنية مفاتيح عامة (PKI) وترغب في الاستفادة منها مع WHfBبدلاً من ذلك، يمكنك اختيار نموذج الثقة القائم على الشهادات. في هذه الحالة، بعد تسجيل المفتاح لدى موفر الهوية، يقوم العميل بإنشاء طلب شهادة وإرساله إلى جهة إصدار الشهادات (CRA) التي عادةً ما تكون مستضافة على خادم AD FS.

تقوم وكالة الإيرادات الكندية بالتحقق من صحة الطلب وإحالته إلى هيئة التصديق المؤسسيةوالذي يصدر شهادة مستخدم. يتم تخزين هذه الشهادة داخل حاوية Windows Hello وسيتم استخدامها للمصادقة على الموارد المحلية التي تتطلب شهادات العميل (على سبيل المثال، مصادقة Kerberos باستخدام الشهادات أو IPsec VPN).

5. مرحلة المصادقة: كيفية "إصدار" المفتاح

بمجرد اكتمال المراحل السابقة، تصبح تجربة المستخدم اليومية بسيطة للغاية.لتسجيل الدخول أو فتح الجهاز، استخدم رمز PIN أو بياناتك البيومترية. من الناحية التقنية، تتيح هذه العملية الوصول إلى الجزء الخاص من بيانات اعتماد WHfB المخزنة في وحدة TPM.

لا يغادر رقم التعريف الشخصي ولا المفتاح الخاص الجهاز ولا يتم إرسالهما إلى موفر الهوية.يعمل رمز التعريف الشخصي (PIN) كمصدر عشوائية لعمليات توقيع المفتاح الخاص؛ بمعنى آخر، هو بمثابة مُشغّل محلي يُصرّح باستخدام المفتاح. عندما يحتاج تطبيق أو النظام نفسه إلى المصادقة لدى موفر هوية (IdP)، يقوم نظام ويندوز بتوقيع كتلة من البيانات باستخدام المفتاح الخاص، ثم يرسل التوقيع إلى الخادم الذي يتحقق من صحته باستخدام المفتاح العام المُسجّل.

يتكرر هذا النمط لكل من المصادقة المباشرة وإدخال المعرف. (عبر بروتوكولات الويب ومزود خدمة نقطة الوصول السحابية) مثل مصادقة Kerberos ضد Active Directory (إما من خلال مفتاح أو شهادة أو ثقة Kerberos في السحابة).

رمز التحديث الأساسي (PRT) وتسجيل الدخول الموحد (SSO)

تعتمد تقنية تسجيل الدخول الموحد الحديثة في بيئات مايكروسوفت على رمز التحديث الأساسي أو PRT.بينما في Kerberos الكلاسيكي يكون "الرمز الرئيسي" هو TGT، في سيناريوهات Entra ID يكون PRT هو رمز JWT يحتوي على معلومات المستخدم والجهاز، ويسمح بالحصول على رموز الوصول لتطبيقات مختلفة دون أن يضطر المستخدم إلى إعادة المصادقة بشكل صريح.

يتم إصدار إشارة PRT عادةً أثناء تسجيل الدخول إلى الجهاز أو فتحه. عند مصادقة المستخدم مع WHfB على جهاز كمبيوتر منضم إلى شبكة مايكروسوفت إنترناشونال أو جهاز كمبيوتر هجين منضم إلى إنترناشونال. أما على الأجهزة الشخصية المسجلة فقط، فيتم الحصول على PRT عن طريق إضافة حساب عمل أو حساب مدرسي إلى نظام ويندوز.

بدون PRT، لا يوجد تسجيل دخول موحد حقيقي للتطبيقات المحمية بواسطة Entra ID أو AD FSإذا لم يكن لدى الجهاز، لأي سبب من الأسباب، PRT صالح، فسيرى المستخدمون طلبات بيانات اعتماد متكررة وستفشل سياسات الوصول المشروط التي تتطلب معلومات الجهاز (على سبيل المثال، "الأجهزة التي تم وضع علامة عليها بأنها متوافقة فقط").

في سيناريوهات الوصول عن بعد باستخدام VPN و SAML SSOبمجرد مصادقة المستخدم مع WHfB على نظام التشغيل، يسمح PRT لـ Entra ID بتذكر استيفاء متطلبات المصادقة متعددة العوامل المقاومة للتصيد الاحتيالي. وبالتالي، أثناء تسجيل الدخول إلى VPN عبر SAML، يمكن لـ Entra ID وضع علامة على الجلسة بأنها متوافقة مع المصادقة متعددة العوامل دون الحاجة إلى عامل مصادقة ثانٍ، وهو أمر غالبًا ما يثير جدلاً مع شركات التأمين والمراجعين.

عملية مصادقة الجهاز المشتركة مع مايكروسوفت: أدخل لإدخال المعرف

على جهاز متصل بـ Entra، سلسلة الأحداث أثناء تسجيل الدخول إلى WHfB وبعبارة مبسطة، يكون الأمر كما يلي:

• يقوم المستخدم بإغلاق شاشة القفل وإدخال رقم التعريف الشخصي أو البيانات البيومترية الخاصة به في موفر بيانات اعتماد WHfB.
• يقوم Winlogon بتمرير بيانات الاعتماد هذه إلى LSASS، والتي بدورها تقوم بتسليمها إلى موفر أمان المصادقة السحابية (Cloud AP).
• يطلب Cloud AP السفير البابوي أدخل معرف Microsoft؛ يستجيب إدخال المعرف بهذه القيمة.
• يقوم العميل بتوقيع قيمة nonce باستخدام المفتاح الخاص للمستخدم ويرسل النتيجة إلى Entra ID.
• يقوم Entra ID بالتحقق من التوقيع باستخدام المفتاح العام المسجل مسبقًا، وإذا كان كل شيء صحيحًا، فإنه يقوم بإنشاء PRT مشفر باستخدام مفتاح النقل الخاص بالجهاز.
• يقوم Cloud AP بفك تشفير مفتاح جلسة PRT باستخدام مفتاح النقل الخاص (المحمي بواسطة TPM) ويخزن PRT في ذاكرة تخزين مؤقتة محمية.
• يقوم LSASS بإبلاغ Winlogon بنجاح عملية المصادقة وإنشاء جلسة المستخدم.

من تلك اللحظة فصاعدًا، سيتم استخدام PRT للحصول على رموز الوصول والترقية لتطبيقات مختلفة (Microsoft 365، SaaS التابعة لجهات خارجية، تطبيقات SAML، إلخ) دون أن يضطر المستخدم إلى إعادة كتابة أي شيء، مع مراعاة سياسات الوصول المشروطة المُكوّنة دائمًا.

مقارنة بين مصادقة Windows Hello للأعمال و Active Directory

عندما يكون الجهاز "متصلاً بـ Entra" فقط ولكنه يحتاج إلى الوصول إلى الموارد المحليةهنا تبرز أهمية التكامل مع Active Directory من خلال نماذج مختلفة: ثقة Kerberos السحابية، وثقة المفاتيح، وثقة الشهادات. تتيح جميع هذه النماذج لبيانات اعتماد WHfB إنشاء تذاكر Kerberos دون الحاجة إلى كلمات مرور.

ثق ببروتوكول Kerberos في السحابة مع مايكروسوفت. ابدأ الآن.

في نموذج ثقة كيربيروس السحابييُصدر Microsoft Entra ID تذكرة منح تذاكر جزئية (TGT) مرتبطة بهوية المستخدم وموقعة من خدمة Kerberos السحابية. عندما يحتاج الجهاز إلى تذكرة منح تذاكر كاملة من وحدة تحكم المجال المحلية، فإنه يرسل تلك التذكرة الجزئية إلى مركز توزيع المفاتيح المحلي (KDC)، الذي يتحقق منها ويصدر تذكرة منح تذاكر كاملة للمستخدم.

هذا النهج يبسط البنية التحتية بشكل كبيرلأنه يفوض جزءًا من منطق المصادقة إلى Entra ID، ولكنه يتطلب تحديث وحدات التحكم في المجال وتكوينها بشكل صحيح للتعرف على تلك TGTs الجزئية القادمة من السحابة والتحقق من صحتها.

نموذج الثقة الرئيسي

في نموذج الثقة الرئيسية، يقوم متحكم المجال بالتحقق مباشرة من صحة التوقيع الذي تم إنشاؤه باستخدام المفتاح الخاص للمستخدم. مسجلة في Active Directory. التسلسل العام هو:

• يقوم موفر Kerberos على العميل بتوقيع بيانات ما قبل المصادقة باستخدام المفتاح الخاص ويرسل التوقيع مع المفتاح العام (في شهادة موقعة ذاتيًا) إلى KDC.
• يتحقق مركز توزيع المفاتيح (KDC) من أن الشهادة موقعة ذاتيًا، ويحدد موقع المفتاح العام في السمة. msDS-KeyCredentialLink من المستخدم ويتحقق من صحة التوقيع.
• إذا تطابقت جميع العناصر (UPN، المفاتيح، التوقيع)، فإن KDC يعيد TGT إلى العميل.

بعد ذلك، يقوم العميل بالتحقق من صحة شهادة KDC (سلسلة تصل إلى جذر الثقة، مصادقة KDC EKU، اسم بديل مطابق للمجال، خوارزميات آمنة مثل SHA-256 و RSA 2048، إلخ) قبل قبول TGT وتخزينه مؤقتًا لطلبات تذاكر الخدمة المستقبلية.

صندوق شهادات الائتمان

في النموذج القائم على الشهادات، يقدم المستخدم إلى مركز توزيع المفاتيح شهادة عميل صادرة عن هيئة إصدار الشهادات التابعة للمنظمة.يستخدم Kerberos معلومات الشهادة (اسم الموضوع المميز أو اسم المستخدم الرئيسي في SAN) كدليل لتحديد موقع الحساب في Active Directory.

يقوم متحكم المجال بالتحقق من صحة سلسلة الشهادات حتى جذر الثقةيتحقق النظام من أن الشهادة لا تزال سارية المفعول ولم يتم إلغاؤها، ويستخدم المفتاح العام للشهادة للتحقق من بيانات المصادقة المسبقة الموقعة. إذا كانت جميع البيانات صحيحة، يصدر النظام تذكرة منح التذاكر (TGT)، والتي يقبلها العميل بعد التحقق من شهادة مركز توزيع المفاتيح (KDC).

متطلبات البنية التحتية للبيئات الهجينة الآمنة

لضمان مصادقة الجهاز المتصل بـ Microsoft Entra بنجاح في Active Directory يتضمن ذلك إيلاء اهتمام دقيق لتكوين البنية التحتية للمفاتيح العامة للشركات، ونقاط توزيع قوائم إبطال الشهادات، والثقة في شهادات وحدة التحكم بالمجال.

نقاط توزيع قائمة الإلغاء (CDP/CRL)

من الأخطاء الشائعة جدًا ترك بيانات CDP في LDAP فقط داخل النطاقالأجهزة المنضمة إلى Entra ID والتي ليست جزءًا من المجال لا يمكنها قراءة مسار LDAP هذا قبل المصادقة، مما يؤدي إلى إنشاء حلقة: فهي تحتاج إلى التحقق من صحة شهادة DC للمصادقة، ولكن لا يمكنها قراءة CRL بدون المصادقة.

الحل الموصى به هو نشر قائمة إبطال الشهادات (CRL) في نقطة يمكن الوصول إليها عبر بروتوكول HTTP بدون مصادقة.عادةً ما يكون هذا موقعًا إلكترونيًا داخليًا، ويتم إضافة عنوان URL الخاص به كنقطة توزيع شهادات (CDP) إلى شهادات المرجع المصدق (CA) وشهادة وحدة تحكم المجال. تتضمن العملية ما يلي:

• قم بتهيئة خادم ويب (IIS) باستخدام دليل افتراضي (على سبيل المثال، cdp) وتمكين تصفح الدليل.
• قم بضبط أذونات NTFS والمشاركة بحيث يمكن لهيئة إصدار الشهادات نشر ملفات CRL تلقائيًا في ذلك الدليل.
• قم بتحديث تكوين CA ليشمل عنوان URL الجديد لـ HTTP كـ CDP وكـ CRL وموقع نشر دلتا CRL.
• أعد إصدار شهادات وحدة تحكم المجال لتضمين بروتوكول HTTP CDP الجديد.

بعد هذه الخطوات، يمكن للأجهزة المتصلة بـ Entra التحقق من صحة شهادة DC دون الحاجة إلى المصادقة.القضاء على المشكلة الدائرية والسماح للمصادقة القائمة على الشهادات أو المفاتيح بالعمل بشكل صحيح.

متطلبات شهادة وحدة تحكم المجال

لفرض "التحقق الصارم من KDC" في Windows Hello للأعمال عند المصادقة من جهاز متصل بـ Entra، يجب أن تستوفي شهادات وحدة تحكم المجال عدة معايير:

• يجب أن يكون المرجع المصدق الجذري المُصدر موجودًا في مستودع جهات إصدار شهادات الجذر الموثوقة الجهاز.
• يجب أن تستند الشهادة إلى قالب مصادقة Kerberos كافية.
• يجب أن يتضمن رمز EKU الخاص بـ مصادقة مركز توزيع المفاتيح (KDC).
• يجب أن يحتوي اسم الموضوع البديل (SAN) على اسم DNS يطابق النطاق.
• يجب أن تكون خوارزمية التوقيع SHA-256 ويجب أن يكون المفتاح العام RSA لا يقل عن 2048 بت.

في حال فشل أي من هذه الإجراءات، قد ترفض الأجهزة المتصلة بـ Entra شهادة DC. ولن ينجح التحقق من الهوية باستخدام WHfB إلى Active Directory، على الرغم من أن كل شيء يبدو أنه يعمل بشكل جيد باستخدام كلمات المرور التقليدية.

توزيع شهادة الجذر الخاصة بهيئة التصديق على الأجهزة المنضمة إلى Entra

حتى يثقوا بشهادات وحدة تحكم المجاليجب تثبيت شهادة الجذر الخاصة بالمؤسسة على الأجهزة المتصلة بـ Microsoft Intune. عادةً ما يتم تصدير هذه الشهادة من وحدة تحكم المجال ونشرها على أجهزة الكمبيوتر باستخدام Microsoft Intune مع سياسة "الشهادة الموثوقة".

ينبغي أن يشير التوجيه إلى مخزن شهادات الفريق (جذر الثقة). ويتم تخصيصها لمجموعات المستخدمين أو الأجهزة المناسبة. وبمجرد تطبيقها، ستتعرف الأنظمة على الشهادات الصادرة عن جهة إصدار الشهادات هذه، بما في ذلك شهادة مركز توزيع المفاتيح، باعتبارها "موثوقة"، ويمكن إكمال عملية التحقق الصارمة بنجاح.

نماذج النشر، والتحديات، وأفضل الممارسات

يدعم Windows Hello for Business عمليات النشر السحابية فقط، أو المختلطة، أو المحلية بالكاملولكل نموذج آثار عملية مختلفة من حيث التعقيد والتوافق والتكاليف.

في المؤسسات التي تعتمد على الحوسبة السحابية أولاً والتي لا تستخدم Active Directory محلياًأبسط الحلول هو نموذج يعتمد على الحوسبة السحابية فقط، حيث تتولى Microsoft Entra ID إدارة جميع المفاتيح والمصادقة، دون الحاجة إلى بنية مفاتيح عامة محلية أو AD FS. ويتمكن المستخدمون من الوصول إلى تطبيقات Microsoft 365 و SaaS عبر تسجيل الدخول الموحد باستخدام WHfB كأداة مصادقة بدون كلمة مرور.

في معظم الشركات المتوسطة والكبيرة، يظل النموذج الهجين هو السيناريو الأكثر واقعية.تبقى الموارد الحيوية محلية، وتوجد تطبيقات Kerberos خالصة، ويتم استهلاك الخدمات السحابية في الوقت نفسه. هنا تبرز الحاجة إلى اتخاذ قرارات بشأن المفاضلة بين موثوقية Kerberos السحابية، وموثوقية المفاتيح، وموثوقية الشهادات؛ كما يجب تقييم التوافق مع التطبيقات القديمة؛ وفي كثير من الحالات، يجب الاستمرار في استخدام الطرق القائمة على كلمات المرور أو البطاقات الذكية لبعض الوقت.

في القطاعات الخاضعة لتنظيمات صارمة أو تلك التي تتطلب سيادة بيانات بالغة الصرامة (في القطاع الحكومي، أو بعض المؤسسات المالية أو الصحية)، قد يكون من المنطقي اعتماد نموذج محلي بالكامل مع خدمة Active Directory Federation Services (AD FS) وبنية مفاتيح عامة خاصة به، حيث يُستخدم نظام Windows Home for Business (WHfB) كبديل لكلمات المرور دون الاعتماد على الحوسبة السحابية. مع ذلك، يأتي هذا على حساب زيادة تعقيد العمليات والصيانة.

في جميع الحالات، توجد تحديات مشتركة: الأجهزة المتوافقة، ومحطات العمل المشتركة، ومقاومة المستخدمين للتغيير، وتبرير لشركات التأمين والمراجعين بأن العمل عن بُعد يُعتبر بالفعل وسيلة مصادقة متعددة العوامل.يكمن المفتاح في الجمع بين WHfB وسياسات الوصول المشروط التي تتطلب مصادقات مقاومة للتصيد الاحتيالي، وتمكين إعادة المصادقة أو رفع مستوى المصادقة متعددة العوامل عند الضرورة (على سبيل المثال، في العمليات الحساسة للغاية أو اتصالات VPN الحرجة)، وتوثيق نموذج التهديد بشكل كامل.

ويصاحب ذلك تدريب جيد، وسياسات واضحة لأرقام التعريف الشخصية، ومراقبة تسجيل الدخول، ونشر تدريجي مدعوم من Intune أو GPO.تتيح خدمة Windows Hello for Business للمؤسسات القيام بقفزة نوعية نحو نموذج هوية بدون كلمة مرور، مما يقلل من مساحة الهجوم، ويحسن الامتثال التنظيمي، ويوفر للمستخدمين تجربة تسجيل دخول أكثر طبيعية وسرعة.