دليل مقارنة Password Hash Sync وPTA

By Mirko Peters · 2026-04-30 · Updated 2026-07-18

تعرّف على Password Hash Sync مقابل PTA من خلال إرشادات عملية حول الإعداد والبنية والأمان والحوكمة والاستخدام في بيئات العمل الفعلية.

Automatically translated with AI from the original post. Read the English original

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

عند تشغيل Active Directory المحلي وMicrosoft Entra ID (المعروف سابقًا باسم Azure AD) معًا، يصبح السؤال الأهم: “كيف أصادق المستخدمين بأمان ودون تعقيد، بغض النظر عن مكان تسجيل دخولهم؟” وهنا يأتي دور Password Hash Sync (PHS) وPass-Through Authentication (PTA)، فكلاهما مصمم لربط البيئة المحلية بالسحابة، لكنهما يختلفان اختلافًا كبيرًا في التعامل مع الأمان والامتثال والمرونة.

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

يقدم هذا الدليل إجابات عملية لقادة الفرق التقنية وصناع القرار ذوي التوجه التجاري على حد سواء. سنقارن PHS وPTA وجهًا لوجه، ونتعمق في آلية عمل كل منهما، وما الذي يميز بينهما، ونقدم نصائح لاختيار الخيار الأنسب. استعد لجولة شاملة في الإعداد، وطبقات الأمان، والتعافي من الكوارث، والامتثال، والأداء. وبنهاية الدليل ستحصل على خطة عملية لمواءمة استراتيجية الهوية لديك مع أفضل ممارسات Microsoft، دون حشو أو مبالغة أو متاعب إضافية. هيا نبدأ.

مقارنة طرق المصادقة: Password Hash Sync وPass-Through Authentication في Entra ID

الهوية الهجينة تعني في جوهرها ربط Active Directory المحلي بـ Microsoft Entra ID، وطريقة المصادقة التي تختارها هي محور هذا الربط. مع Password Hash Sync (PHS) وPass-Through Authentication (PTA)، لديك طريقتان مختلفتان للتحقق من المستخدمين الذين يسجلون الدخول إلى الموارد السحابية. وتؤثر هاتان الطريقتان على الأمان، وكذلك على الأداء والامتثال وسهولة الاستخدام اليومية. ويمهّد فهم الغرض من كل خيار وسياقه الطريق لاتخاذ القرار الأمثل لبيئتك. وفيما يلي، سنشرح بالتفصيل كيف تعمل PHS وPTA، مع التركيز على التفاصيل والتدفقات الأكثر أهمية.

مصادقة Password Hash وPTA في Azure: كيف تعمل؟

تُعد Password Hash Synchronization (PHS) وPass-Through Authentication (PTA) الخيارين الرئيسيين لربط الهوية المحلية بسحابة Microsoft. يتيح كلاهما للمستخدمين تسجيل الدخول إلى الخدمات السحابية باستخدام بيانات اعتماد AD “التقليدية”، لكنهما يعملان بطرق مختلفة تمامًا.

مع Password Hash Sync، تُعدّ بيئتك Azure AD Connect لتصدير تجزئة (hash) خاصة أحادية الاتجاه لكلمة مرور كل مستخدم مفعّل في AD إلى Entra ID بشكل دوري. وليست هذه التجزئة هي التجزئة الأصلية من وحدة التحكم بالنطاق، بل تجزئة للتجزئة نفسها، ولذلك لا يستطيع حتى Microsoft عكس العملية واستخراج كلمة المرور. وبمجرد وصول هذه التجزئات إلى السحابة، يمكن لـ Entra ID مصادقة المستخدمين مباشرةً، بسرعة ومرونة في مواجهة أي خلل يطرأ على البيئة المحلية.

أما PTA فيُبقي عملية التحقق من كلمة المرور مرتبطة بـ Active Directory المحلي. عندما يحاول المستخدم الوصول إلى خدمة سحابية من Microsoft، يُنقل طلب المصادقة بأمان من Entra ID إلى أحد وكلاء PTA الخفيفين العاملين في بيئتك المحلية. يتحقق الوكيل بعد ذلك من اسم المستخدم وكلمة المرور المقدمين مقابل AD لديك، ويعيد إجابة بنعم أو لا، فيسمح Entra ID للمستخدم بالدخول أو يمنعه.

تخيّل الأمر بهذا الشكل: PHS = تجزئات كلمات المرور موجودة في السحابة، وتتم المصادقة في Azure؛ أما PTA = لا توجد تجزئة لكلمة المرور في السحابة، وتتم جميع عمليات التحقق من بيانات الاعتماد مباشرةً عبر وحدات التحكم بالنطاق المحلية من خلال الوكيل. يحدد اختيارك المكان الذي تتم فيه المصادقة فعليًا، ومدى اعتمادك على سلامة شبكتك واستمرار عملها. وتُشكّل هذه الأسس كل شيء، بدءًا من وضعية الأمان وصولًا إلى القدرة على التعافي من الكوارث وتجربة المستخدم. ولمعرفة كيفية ارتباط ذلك بالمخاطر والامتثال والعمليات، اطّلع على دليل الوصول المشروط في Entra ID للاطلاع على استراتيجيات تحافظ على إحكام حوكمة الهوية.

تخزين تجزئات كلمات المرور وتدفقات المصادقة الآمنة

مع PHS، تُشفَّر نسخة مجزأة من كلمة مرور كل مستخدم، بل ومجزأة مرة أخرى، ثم تُزامن إلى Entra ID. يعني هذا التخزين في السحابة أن Entra ID يستطيع الرد مباشرةً على محاولات تسجيل الدخول، حتى إن تعذّر الوصول إلى Active Directory المحلي.

تتجاوز PTA النسخة السحابية ولا تخزّن أبدًا تجزئات كلمات المرور في Azure. بدلًا من ذلك، تستخدم وكلاء للتحقق من بيانات الاعتماد الحية مقابل Active Directory المحلي في كل مرة يسجّل فيها المستخدم الدخول. تضمن القناة الآمنة عدم بقاء كلمات المرور مكشوفة. باختصار: تعتمد PHS على بيانات اعتماد مخزّنة في السحابة وخاضعة لتجزئة مزدوجة، بينما تفرض PTA فحوصات فورية ومباشرة مع كل طلب مصادقة، مع إبقاء بيانات الاعتماد داخل الشبكة المحلية.

اعتبارات الأمان للهوية في المصادقة الهجينة

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

تواجه المؤسسات ضغوطًا للوفاء بمتطلبات الامتثال ومواكبة التهديدات المتطورة. سواء كان قلقك الأكبر هو سرقة بيانات الاعتماد أو التصيد الاحتيالي أو الحد من نطاق الضرر عند وقوع خرق، فإن طريقة المصادقة الهجينة التي تختارها تلعب دورًا رئيسيًا في ذلك. ستحتاج إلى معرفة مدى صمود كل نهج أمام التهديدات، وكيفية تكامله مع الدفاعات متعددة الطبقات، وكيف يتناسب مع بنية هوية حديثة ومرنة لمؤسستك. للاطلاع على نظرة عملية حول الموازنة بين أمان المستخدم وتجربته الجيدة، راجع دليل الأمان هذا لـ M365 الذي يتناول أفضل الممارسات في بيئات Microsoft.

الحماية المحلية وطبقات الأمان السحابية

تعتمد PHS وPTA كلتاهما على ميزات أمان Active Directory المحلي وتنقلانها إلى السحابة عبر Entra ID. مع PHS، بمجرد وصول التجزئات إلى Azure، يمكنك إضافة دفاعات خاصة بالسحابة: تعمل سياسات الوصول المشروط وتقييم المخاطر في حماية الهوية على جميع عمليات المصادقة، مما يسهّل تطبيق السياسات بإحكام.

تدعم PTA أيضًا ضوابط الطبقات السحابية هذه، لكن بما أن فحوصات كلمات المرور تُجرى داخل الشبكة المحلية، تبقى حمايات AD التقليدية خط الدفاع الأول لديك. تظل ضوابط سحابية إضافية، مثل الوصول المشروط والمصادقة متعددة العوامل، سارية بعد المصادقة. أيًّا كان المسار الذي تختاره، فإن الجمع بين الحمايات المحلية وميزات Entra ID الحديثة يبني منظومة هوية مرنة ومتعددة الطبقات. هل تريد التعمق في أحدث التهديدات السحابية؟ يشرح تحليل هجوم الموافقة عبر OAuth المخاطر والدفاعات الواقعية المرتبطة بـ Entra ID.

قفل الحساب وانتهاء الصلاحية وتجربة تسجيل الدخول مع PHS وPTA

قفل الحساب: تطبّق PTA القفل المحلي فورًا، إذ تمنع المحاولات المتكررة لكلمة المرور الخاطئة تسجيلات الدخول السحابية على الفور. أما مع PHS فيتأخر القفل حتى المزامنة التالية لتجزئات كلمات المرور.
انتهاء صلاحية كلمة المرور: تحترم PTA عمر كلمة المرور في AD لحظيًا، فتطلب التغيير في اللحظة التي تنتهي فيها صلاحية الحساب. أما PHS فترث ذلك مع المزامنة التالية، وقد يحصل المستخدمون على فترة قصيرة بعد انتهاء الصلاحية إذا لم تُحدَّث التجزئات بعد.
سياسات تسجيل الدخول: تعكس PTA جميع ضوابط ساعات تسجيل الدخول في AD. أما PHS فتطبّق تغييرات السياسات بعد المزامنة، مما يسبب تأخرًا قصيرًا في تطبيقها على السحابة.
إدارة المخاطر: يضمن الاتصال الفوري في PTA تطبيق السياسات بصرامة، بينما تقايض PHS قدرًا يسيرًا من الفورية مقابل مرونة أعلى وتوفر أكبر.

تجربة المستخدم: تسجيل دخول سلس وإمكانية الوصول في Entra ID

لا يقتصر تدفق الهوية المناسب على كلمات المرور أو الرموز، بل يتعلق بضمان دخول المستخدمين بسلاسة وأمان ودون الحاجة إلى تخطي عقبات متكررة. يؤثر اختيارك للمصادقة الهجينة، سواء PHS أو PTA، بشكل مباشر في مدى سلاسة (أو صعوبة) تجربة المستخدمين النهائيين، خاصة في عالم العمل عن بُعد والفرق الموزعة.

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

تفعيل تسجيل الدخول الأحادي السلس باستخدام PHS وPTA

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

مشكلات الاتصال المؤقتة مع PTA وسيناريوهات الرجوع إلى السحابة

تعطّل وكلاء PTA: إذا توقف جميع وكلاء PTA عن العمل أو فقدت الاتصال مع Entra ID، فلن يتمكن المستخدمون من المصادقة، إذ لا يوجد فحص محلي يسمح بتسجيل الدخول.
مرونة PHS: يمكن لمستخدمي PHS الاستمرار في تسجيل الدخول حتى لو تعطّل AD المحلي، لأن عمليات المصادقة تُعالج في السحابة باستخدام تجزئات كلمات المرور المخزّنة.
المواقع البعيدة والفروع: بالنسبة إلى المواقع ذات الروابط غير الموثوقة، يوفّر PHS طبقة حماية إضافية، إذ يستطيع المستخدمون مواصلة العمل حتى عند حدوث انقطاع في الاتصال.
استراتيجيات الرجوع الاحتياطي: تفعّل بعض المؤسسات الطريقتين معًا (مع PHS كخيار احتياطي) لزيادة المرونة، ما يتيح التحويل التلقائي عند حدوث اضطراب في PTA.

نشر وإدارة وكلاء المصادقة

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

بالنسبة للفرق التي تطبّق Password Hash Sync، تتمحور المهام الرئيسية حول إدارة Azure AD Connect، أي جدولة المزامنات والتعامل مع التحديثات ومراقبة الأخطاء. أما مع PTA، فينتقل التركيز إلى نشر الوكلاء الخفيفة ومراقبتها عبر عدة خوادم محلية (لتحقيق الاحتياطية)، وإلى استكشاف مشكلات الشبكة التي قد تعطّل حركة المصادقة. كما أن الأذونات والتصحيحات وبروتوكولات الاستجابة للحوادث مهمة أيضًا.

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

توسيع الأذونات لوكلاء Azure AD Connect وPTA

أذونات Azure AD Connect: تحتاج إلى صلاحيات مسؤول المؤسسة أثناء الإعداد، ثم تنتقل إلى الأذونات المفوّضة للمزامنة المستمرة. لا تشغّل الخدمة بصلاحيات أعلى من اللازم، وراجعها مع كل تحديث.
أذونات وكلاء PTA: تحتاج الوكلاء إلى بيانات اعتماد حساب خدمة مع حق "تسجيل الدخول كخدمة" وصلاحيات قراءة في AD، ويجب تجنّب منح أدوار مسؤول النطاق الواسعة لتقليل سطح الهجوم.
أفضل ممارسات التفويض: اعتمد مبدأ أقل الصلاحيات. امنح الأذونات اللازمة فقط، ولا تزيد عنها، وراجع هذه الأدوار بشكل دوري للكشف عن أي انحراف في الصلاحيات.
تدقيق الامتثال: استفد من أدوات مثل Microsoft Purview Audit لمراقبة التغييرات وتتبع نشاط الوكلاء ودعم التحقيقات الجنائية الرقمية إذا ظهرت مشكلات.

تطبيق Password Writeback ومطابقة الحسابات الموجودة

Password Writeback: فعّل Password Writeback عبر Azure AD Connect ليتمكن المستخدمون من إعادة تعيين كلمات المرور في السحابة، ثم تُزامن هذه التغييرات تلقائيًا مع AD المحلي، ما يقلل العبء على مكتب المساعدة.
الخدمة الذاتية للمستخدم: بعد التفعيل، يمكن للمستخدمين إعادة تعيين كلمات المرور وتغييرها من Office.com أو من تطبيق Microsoft Authenticator، فيحافظون على إنتاجيتهم والتزامهم بالامتثال.
استراتيجيات المطابقة: قبل تفعيل PHS أو الانتقال من PTA، تأكد من مطابقة حسابات المستخدمين بشكل صحيح بين Entra ID وAD لمنع تكرار الهويات أو مشكلات الوصول.
أفضل ممارسات الترحيل: اختبر الكتابة العكسية (writeback) مع مجموعة تجريبية، وتحقّق من تطابق الهويات باستخدام السمة immutableID أو سمات البريد، وراقب بعد الإطلاق أخطاء المزامنة أو عدم تطابق بيانات الاعتماد.

الترحيل من PTA إلى PHS: التحضير والتنفيذ والتحقق

التحوّل من المصادقة عبر الوكيل (Pass-Through Authentication) إلى مزامنة تجزئة كلمة المرور (Password Hash Sync) ليس مجرد تبديل زر وأمل في الأفضل. يتطلب الترحيل تخطيطًا دقيقًا، وتوثيقًا لبيئتك، والتأكد من تطابق الإعدادات السحابية والمحلية، والتواصل بوضوح مع المستخدمين وأصحاب المصلحة.

يرشدك هذا القسم خلال العملية كاملةً، من البداية إلى النهاية: كيفية تهيئة المستأجر، والتحقق من توافق البيئة مع PHS، وتوقّع أي تحديات قد تنشأ عن هذا التحوّل. الهدف هو تقليل تعطيل المستخدمين، وتجنب المفاجآت، ووضع مسار سلس مع خطة واضحة للتراجع عند الحاجة. تتضمن كل مرحلة نقاط تحقق وأفضل الممارسات للحفاظ على استقرار هويتك الهجينة طوال فترة الانتقال.

مع خطة ترحيل محكمة، يمكنك نقل مهام المصادقة إلى السحابة، مما يعزز المرونة، ويدعم المواقع البعيدة وفروع الشركة، ويمهّد الطريق لتحسينات مستقبلية. التغيير صعب، لكن عند إدارته بالشكل الصحيح، فإنه يعني تقليل الإطفاء المستمر للأعطال والتركيز أكثر على أعمالك الفعلية.

التحضير، ونظرة عامة على المستأجر، وتقييم الجاهزية للتغيير

توثيق الإعدادات الحالية: وثّق جميع نهج المصادقة وكلمات المرور الحالية، إضافةً إلى تفاصيل نشر الوكلاء، لتجنب أي إغفال.
التأكد من التوافق السحابي: تحقّق من أن جميع الحسابات متزامنة ومناسبة لـ PHS، وانتبه إلى نهج كلمات المرور غير القياسية أو مخططات التشفير القديمة.
تخطيط التواصل: أبلغ أصحاب المصلحة وفريق الدعم الفني والمستخدمين بالتغييرات القادمة، والآثار المحتملة، وتدفقات تسجيل الدخول الجديدة.
إعداد خطة التراجع: ضع خطة احتياطية واضحة في حال حدوث خلل أثناء الترحيل، وحدّد ما الذي يستدعي التراجع، وكيفية العودة دون فقدان الخدمة.
الجدولة لتقليل التأثير: اختر نوافذ صيانة يقل فيها نشاط المستخدمين، وتأكد من أن فريق الدعم جاهز أثناء عملية التحويل وبعدها. لمزيد من المعلومات حول آثار الامتثال على المستأجر، راجع حلقة انحراف الامتثال هذه.

تفعيل PHS، ونقل بيئة الإنتاج، والتحقق من النجاح، والتراجع الطارئ

تفعيل PHS في Azure AD Connect: فعّل مزامنة تجزئة كلمة المرور، وتأكد من بدء مزامنة التجزئات لجميع المستخدمين. تابع التقدم من لوحة معلومات Azure AD Connect، وتحقّق من عدم تسجيل أي أخطاء.
التحقق من تطابق البيئة السحابية: تحقّق من أن الهويات المتزامنة مرتبطة بشكل صحيح وأن تسجيل الدخول يعمل باستخدام PHS قبل نقل حركة مرور الإنتاج. انتبه إلى حالات عدم التطابق أو الحسابات المكررة.
توجيه مصادقة الإنتاج: انقل حركة المصادقة تدريجيًا من PTA إلى PHS، فابدأ بالمجموعات التجريبية، ثم وسّع النطاق على مستوى المستأجر إذا سارت الأمور بسلاسة.
مراقبة النجاح وتجربة المستخدم: راقب عن كثب أوقات تسجيل الدخول، وحالة الخدمة، وملاحظات المستخدمين أثناء عملية التحويل وبعدها. استجب بسرعة لإخفاقات تسجيل الدخول أو الأخطاء غير المتوقعة.
إيقاف وكلاء PTA بأمان: عندما تطمئن إلى PHS، أزل وكلاء PTA باتباع عملية التنظيف الموصى بها من Microsoft. وثّق التغيير، وحدّث خطط الاستجابة للحوادث، وتأكد من عدم بقاء أي تبعيات قديمة.
خطة التراجع الطارئ: إذا خرجت الأمور عن السيطرة، فكن مستعدًا للعودة إلى PTA بإعادة تفعيل الوكلاء وعكس مسار حركة المرور. تأكد من التدرب على ذلك بحيث يمكن إتمام التراجع في أقل من 30 دقيقة عند الحاجة.

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

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

يجمع هذا القسم الختامي بين الجانب العملي، والمزالق المعروفة، والسيناريوهات الشائعة، حتى تتمكن من مواءمة خطة هويتك الهجينة بثقة مع الطريقة الأنسب لأهدافك، وتغيير استراتيجيتك كلما تطورت مؤسستك.

اختيار PTA بدلاً من PHS: متى تُختار كل طريقة

استخدم PTA إذا: كانت لديك لوائح صارمة تمنع تخزين أي شكل من أشكال تجزئة كلمات المرور في السحابة، أو كنت بحاجة إلى تطبيق فوري لنهج AD المحلي.
استخدم PHS إذا: كنت تريد المرونة، إذ تستمر عمليات المصادقة في العمل حتى عند تعطل Active Directory المحلي أو تعذر الوصول إليه (وهذا مناسب جدًا للفرق الموزعة والعاملة عن بُعد).
يناسب PTA: البيئات المركزية الكبيرة أو الخاضعة لتنظيم مشدد، والتي تتمتع باتصال قوي بين السحابة والبنية التحتية المحلية.
يناسب PHS: المؤسسات التي تعطي الأولوية لوقت التشغيل والإدارة المبسطة والمرونة القائمة على السحابة أولًا، خاصة إذا كانت الفروع البعيدة أو عدم استقرار الشبكة من الشواغل لديها.

الأسئلة المتداولة، والمصادقة متعددة العوامل، والنقاط الرئيسية

هل تعمل المصادقة متعددة العوامل (MFA) مع الطريقتين؟ نعم. تدعم كلتا الطريقتين PTA وPHS المصادقة متعددة العوامل الحديثة، بما في ذلك الوصول المشروط والرسائل النصية القصيرة ورموز التطبيقات وFIDO2 وغيرها، ويتم فرض ذلك جميعه من Entra ID بعد المصادقة.
هل سأفقد نهج AD المحلي إذا استخدمت PHS؟ ليس بالكامل. تنتقل معظم تغييرات كلمات المرور وحالات القفل وانتهاء الصلاحية بعد المزامنة، لكن PTA يطبقها في الوقت الفعلي. أما بالنسبة لفرض النهج الحرجة للمهام، فقد يكون PTA الخيار الأنسب.
ماذا لو تعطلت شبكتنا؟ مع PTA، تتوقف جميع عمليات المصادقة السحابية إذا تعذر الوصول إلى وكلاء PTA. أما PHS فيستمر في العمل (ويمكن للمستخدمين تسجيل الدخول) بفضل التجزئات المخزنة في السحابة، لذا خطط لاستراتيجية التحويل إلى الاحتياطي وفقًا لذلك.
كيف أتعامل مع إعداد تقارير الامتثال وتسجيل التدقيق؟ يسجل PTA الأحداث بشكل أساسي محليًا (على الوكلاء ووحدات التحكم بالمجال)، بينما يرسل PHS معظم النشاط إلى Entra ID، مما يوفر رؤية أغنى وأشمل عبر السحابة لفرق SIEM والامتثال. تسجيل السحابة والمراقبة أسهل للحوكمة الشاملة. تعرّف على المزيد حول تقليل مخاطر الهوية في حلقة الوصول المشروط في Entra ID هذه.
الخلاصة الرئيسية: لكل من PTA وPHS دور، فوازن بين الجهد التشغيلي والمرونة والمتطلبات التنظيمية وتجربة المستخدم قبل أن تقرر. ولا تنسَ مراقبة دين الهوية وانتشار الوصول المشروط، فالنهج القوية القابلة للفرض هي أساس الأمان الحقيقي، كما نوقش في الدليل أعلاه. إذا كنت تعمل على الأمان والحوكمة عبر منصات أوسع، فاطّلع على ممارسات أمان Power Platform للاطلاع على استراتيجيات إدارة الهوية التكميلية.

استمع أيضًا إلى هذه الحلقات

إذا كنت تبحث في Password Hash Sync مقابل PTA، فإن هذه الحلقات تضيف سياقًا عمليًا حول البنية والأمان والحوكمة والتنفيذ:

Microsoft AI Agent Harness – Simply Explained — افهم التنسيق والضوابط الوقائية والتقييم وسير عمل الذكاء الاصطناعي الموثوق.
Microsoft Defender XDR – Simply Explained — اربط قرارات الهوية والذكاء الاصطناعي بالمراقبة والاستجابة الأمنية.
Microsoft Teams Governance – The Illusion of Control — تعرّف على كيفية تقليل الحوكمة والملكية والنهج لمخاطر التشغيل.
Azure Virtual Network – Simply Explained — افهم السياق المعماري الذي تقوم عليه الاتصالات السحابية.