يوضح هذا المستند كيفية تكوين لغة تمييز تأكيد الأمان (SAML) مع التركيز على ASA AnyConnect من خلال معرف Microsoft Entra.
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
SAML هو إطار عمل يستند إلى XML لتبادل بيانات المصادقة والتفويض بين مجالات الأمان. فهو يعمل على إنشاء دائرة من الثقة بين المستخدم ومزود الخدمة (SP) ومزود الهوية (IDp) مما يسمح للمستخدم بتسجيل الدخول مرة واحدة لعدة خدمات. يتم دمج معرف Microsoft Edition بسلاسة مع جهاز ASA VPN من Cisco لتوفير أمان إضافي لعمليات تسجيل الدخول إلى شبكة VPN الخاصة بالعميل الآمن من Cisco.
البيانات الأولية: إنه مستند مستند مستند إلى XML يضمن معاملة آمنة بين معرف SP ومعرف ID. وهو يسمح للمعرف والمرفق الاستراتيجي بالتفاوض على الاتفاقيات.
الأدوار المدعومة بواسطة الأجهزة (IdP، SP)
يمكن أن يدعم الجهاز أكثر من دور واحد وقد يحتوي على قيم لكل من SP و IDp. تحت حقل EntityDescriptor يكون IDPSSODescriptor، إذا كانت المعلومات الواردة تخص معرف تسجيل دخول أحادي أو محدد SPSSODescriptor إذا كانت المعلومات الواردة تخص SP لتسجيل دخول واحد. وهذا مهم لأنه يجب أخذ القيم الصحيحة من الأقسام المناسبة لإعداد SAML بنجاح.
معرف الكيان: هذا الحقل هو معرف فريد ل SP أو IDp. يمكن أن يحتوي الجهاز الواحد على عدة خدمات ويمكنه إستخدام معرفات كيانات مختلفة للتفريق بينها. على سبيل المثال، يحتوي ASA على معرفات كيان مختلفة لمجموعات النفق المختلفة التي يلزم مصادقتها. تحتوي معرف الهوية الذي يقوم بمصادقة كل مجموعة نفق على إدخالات معرف كيان منفصلة لكل مجموعة نفق لتحديد هذه الخدمات بدقة.
يمكن أن يدعم ASA معرفات متعددة وله معرف كيان منفصل لكل معرف للتمييز بينها. إذا تلقى أي من الجانبين رسالة من جهاز لا يحتوي على معرف كيان تم تكوينه مسبقا، فمن المحتمل أن يسقط الجهاز هذه الرسالة، وتفشل مصادقة SAML. يمكن العثور على معرف الكيان داخل حقل EntityDescriptor بجانب EntityID.
عناوين URL للخدمة: تقوم هذه بتعريف عنوان URL لخدمة SAML التي يتم توفيرها بواسطة SP أو IDp. بالنسبة لمعرف الخدمة (IdPs)، تكون هذه الخدمة هي خدمة تسجيل الخروج الأحادي وخدمة تسجيل الدخول الأحادي. بالنسبة لمزودي الخدمات الاجتماعية، عادة ما تكون هذه الخدمة هي خدمة العملاء المؤكدة وخدمة تسجيل الخروج الأحادي.
يستخدم SP عنوان URL لخدمة تسجيل الدخول الأحادي الذي تم العثور عليه في بيانات تعريف IdP لإعادة توجيه المستخدم إلى IdP للمصادقة. في حالة تكوين هذه القيمة بشكل غير صحيح، لا يتلقى IdP طلب المصادقة المرسل بواسطة SP أو يتعذر عليه معالجته بنجاح.
يتم إستخدام عنوان URL لخدمة العملاء لتأكيد الهوية الذي تم العثور عليه في بيانات تعريف SP بواسطة IDp لإعادة توجيه المستخدم مرة أخرى إلى SP وتوفير معلومات حول محاولة مصادقة المستخدم. في حالة تكوين هذا بشكل غير صحيح، لا يتلقى SP التأكيد (الاستجابة) أو يتعذر معالجته بنجاح.
يمكن العثور على عنوان URL لخدمة تسجيل الخروج الأحادي على كل من SP و IDp. ويتم إستخدامه لتسهيل تسجيل الخروج من جميع خدمات SSO من SP وهو إختياري على ASA. عندما يتم تكوين عنوان URL لخدمة SLO من بيانات تعريف IdP على SP، عندما يقوم المستخدم بتسجيل الخروج من الخدمة على SP، يرسل SP الطلب إلى IdP. بمجرد أن يقوم IdP بتسجيل خروج المستخدم من الخدمات بنجاح، فإنه يعيد توجيه المستخدم مرة أخرى إلى SP ويستخدم عنوان URL لخدمة SLO الموجود ضمن بيانات تعريف SP.
روابط SAML لعناوين URL للخدمة: الروابط هي الطريقة التي يستخدمها SP لنقل المعلومات إلى IdP والعكس بالنسبة للخدمات. ويتضمن ذلك إعادة توجيه HTTP و HTTP POST و Artifact. ولكل طريقة طريقة طريقة مختلفة لنقل البيانات. يتم تضمين طريقة الربط التي تدعمها الخدمة ضمن تعريف هذه الخدمات. على سبيل المثال: SingleSignOnService Binding="urn:oasis:names:tc:saml:2.0:bindings:http-redirect" location= خدمة SSO >. لا يدعم ASA ربط Artifact. يستخدم ASA دائما طريقة إعادة توجيه HTTP لطلبات مصادقة SAML، لذلك من المهم إختيار عنوان URL لخدمة SSO الذي يستخدم ربط HTTP لإعادة التوجيه بحيث يتوقع IdP هذا.
لتوفير السرية والنزاهة للرسائل المرسلة بين SP و IDp، يتضمن SAML إمكانية تشفير البيانات وتوقيعها. يمكن تضمين الشهادة المستخدمة لتشفير البيانات و/أو توقيعها ضمن بيانات التعريف بحيث يمكن للطرف الذي يستلم التحقق من رسالة SAML والتأكد من أنها تأتي من المصدر المتوقع. يمكن العثور على الشهادات المستخدمة للتوقيع والتشفير ضمن بيانات التعريف ضمن KeyDescriptor use=signature و KeyDescriptor use=encryption، بكل إحترام، ثم X509Certificate. لا يدعم ASA تشفير رسائل SAML.

الخطوة 1. قم بتسجيل الدخول إلى مدخل Azure واختر معرف Microsoft Entra.

الخطوة 2. كما هو موضح في هذه الصورة، أختر تطبيقات المؤسسات.

الخطوة 3. الآن، أختر تطبيق جديد، كما هو موضح في هذه الصورة.

الخطوة 4. في قسم إستعراض معرض Microsoft Entra، اكتب AnyConnect في مربع البحث، واختر جدار حماية Cisco الآمن - مصادقة العميل الآمن (المعروفة سابقا باسم AnyConnect) من لوحة النتائج، ثم إنشاء التطبيق.

الخطوة 5. أختر عنصر قائمة تسجيل الدخول الأحادي، كما هو موضح في هذه الصورة.

الخطوة 6. أختر SAML، كما هو موضح في الصورة.

الخطوة 7. قم بتحرير القسم 1 بهذه التفاصيل.
a. Identifier (Entity ID) - https://<VPN URL>/saml/sp/metadata/<TUNNEL-GROUP NAME> b. Reply URL (Assertion Consumer Service URL) - https://<VPN URL>/+CSCOE+/saml/sp/acs?tgname=<TUNNEL-GROUP NAME> Example: vpn url called asa.example.com and tunnel-group called AnyConnectVPN-1

الخطوة 8. في قسم شهادة توقيع SAML، أختر تنزيل لتنزيل ملف الشهادة، واحفظه على الكمبيوتر.

الخطوة 9. هذا مطلوب لتكوين ASA.

في هذا القسم، يتم تمكين Test1 لاستخدام تسجيل الدخول الأحادي ل Azure، نظرا لأنك تمنح الوصول إلى تطبيق AnyConnect العميل الآمن من Cisco.
الخطوة 1. في صفحة نظرة عامة على التطبيق، أختر المستخدمون والمجموعات، ثم إضافة مستخدم/مجموعة.

الخطوة 2. أختر مستخدمين ومجموعات في مربع حوار إضافة مهمة.
إضافة مهمة
الخطوة 3. في مربع الحوار إضافة مهمة، انقر فوق الزر تعيين.

الخطوة 1. قم بإنشاء TrustPoint واستيراد شهادة SAML الخاصة بك.
config t
crypto ca trustpoint AzureAD-AC-SAML revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate AzureAD-AC-SAML -----BEGIN CERTIFICATE----- … PEM Certificate Text you downloaded goes here … -----END CERTIFICATE----- quit
الخطوة 2. توفر هذه الأوامر معرف SAML الخاص بك.
webvpn saml idp https://xxx.windows.net/xxxxxxxxxxxxx/ - [Azure AD Identifier] url sign-in https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/saml2 - [Login URL] url sign-out https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 – Logout URL trustpoint idp AzureAD-AC-SAML - [IdP Trustpoint] trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint] no force re-authentication no signature base-url https://asa.example.com
الخطوة 3. تطبيق مصادقة SAML على تكوين نفق VPN.
tunnel-group AnyConnectVPN-1 webvpn-attributes saml identity-provider https://xxx.windows.net/xxxxxxxxxxxxx/ authentication saml end write memory
الخطوة 1. اتصل بعنوان URL الخاص بالشبكة الخاصة الظاهرية (VPN) وأدخل تفاصيل Azure AD.
الخطوة 2. الموافقة على طلب تسجيل الدخول.
الخطوة 3. يتم توصيل AnyConnect.



مثال تصحيح الأخطاء:
[SAML] Consumption_Confirmation: معرف الموفر غير معروف ل #LassoServer. لتسجيل موفر في كائن #LassoServer، يجب إستخدام الأساليب lasso_server_add_provider() أو lasso_server_add_provider_from_buffer().
المشكلة: بشكل عام، يعني أن الأمر saml idp [entityID] ضمن تكوين WebVPN الخاص ب ASA لا يطابق معرف كيان IdP الذي تم العثور عليه في بيانات تعريف IdP'.
الحل: تحقق من معرف الكيان الخاص بملف بيانات تعريف IdP وقم بتغيير الأمر saml idp [entity id] لمطابقة هذا الأمر.
مثال تصحيح الأخطاء:
[SAML] ليست قبل:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z المهلة: 0
[SAML] Consumption_Confirmation: التأكيد منتهي الصلاحية أو غير صالح
المشكلة 1. لم تتم مزامنة وقت ASA مع وقت IdP.
الحل 1. قم بتكوين ASA باستخدام نفس خادم NTP المستخدم من قبل IdP.
المشكلة 2. التأكيد غير صالح بين الوقت المحدد.
الحل 2. قم بتعديل قيمة المهلة التي تم تكوينها على ASA.
مثال تصحيح الأخطاء:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data لا تتطابق:signature لا تتطابق
[SAML] Consumption_Confirmation: يتعذر على ملف التعريف التحقق من توقيع الرسالة
المشكلة: تعذر على ASA التحقق من الرسالة الموقعة من قبل IdP أو لا يوجد توقيع ل ASA للتحقق من صحته.
الحل: تحقق من شهادة توقيع IdP المثبتة على ASA للتأكد من مطابقتها لما تم إرساله بواسطة IdP. إذا تم تأكيد ذلك، فتأكد من تضمين التوقيع في إستجابة SAML.
مثال تصحيح الأخطاء:
[SAML] Consumption_Confirmation: جمهور التأكيد غير صالح
المشكلة: يحدد IDp الجمهور غير الصحيح.
الحل: قم بتصحيح تكوين الجمهور على IdP. يجب أن تطابق معرف كيان ASA.
مثال تصحيح الأخطاء: يتعذر تلقي أي تصحيح بعد إرسال طلب المصادقة الأولية. يمكن للمستخدم إدخال بيانات الاعتماد في IdP ولكن IdP لا يعيد التوجيه إلى ASA.
المشكلة: تم تكوين IDp ل URL خدمة المستهلك للتأكيد الخاطئ.
الحل (الحلول): تحقق من URL الأساسي في التكوين وتأكد من صحته. تحقق من بيانات تعريف ASA مع إظهار للتأكد من صحة URL خدمة المستهلك للتأكيد. لاختبار هو، تصفح هو، إن يكون كلا صحيح على ال ASA، فحصت ال idP أن يتأكد أن ال url صحيح.
مثال: بعد تعديل أو تغيير عنوان URL أحادي لتسجيل الدخول، شهادة SP، لا يزال SAML لا يعمل ويرسل التكوينات السابقة.
المشكلة: يحتاج ASA إلى إعادة إنشاء بيانات التعريف الخاصة به عندما يكون هناك تغيير في التكوين يؤثر عليه. وهو لا يفعل ذلك تلقائيا.
الحل: بعد إجراء التغييرات، أسفل أمر إزالة مجموعة النفق المتأثرة وإعادة تطبيق الأمر saml idp [entity-id].
تتضمن معظم أدوات أستكشاف أخطاء SAML وإصلاحها تكوين غير صحيح يمكن العثور عليه عند التحقق من تكوين SAML، أو تشغيل تصحيح الأخطاء. يمكن إستخدام debug webVPN saml 255 لاستكشاف أخطاء معظم المشاكل وإصلاحها، ومع ذلك، في السيناريوهات التي لا يوفر فيها تصحيح الأخطاء هذا معلومات مفيدة، يمكن تشغيل المزيد من تصحيح الأخطاء:
debug webvpn saml 255 debug webvpn 255 debug webvpn session 255 debug webvpn request 255
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
5.0 |
22-Apr-2026
|
نص بديل محدث وتنسيق. |
4.0 |
28-Aug-2024
|
تم تحديث الترجمة الآلية والتنسيق. |
3.0 |
11-Aug-2023
|
إزالة PII.
SEO المحدث، النص البديل، متطلبات النمط، الترجمة الآلية والتنسيق. |
1.0 |
19-Aug-2020
|
الإصدار الأولي |