أستكشاف المشاكل الشائعة مع SAML على ASA و FTD وإصلاحها

المقدمة

يصف هذا المستند المشاكل الأكثر شيوعا التي تتم مصادفتها أثناء أستكشاف أخطاء SAML وإصلاحها على أجهزة Cisco ASA و FTD.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• تكوين موفر هوية SAML (IDp)
• تكوين كائن تسجيل الدخول الأحادي Cisco Secure ASA Firewall أو FirePOWER Threat Defense (FTD)
• Cisco Secure Client AnyConnect VPN

المكونات المستخدمة

يستند دليل أفضل الممارسات إلى إصدارات الأجهزة والبرامج التالية:

• Cisco ASA 9.x
• برنامج الدفاع ضد تهديد Firepower 7.x / FMC 7.x

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

معلومات أساسية

SAML (لغة تمييز تأكيد الأمان) هي إطار عمل يستند إلى XML لتبادل بيانات المصادقة والتفويض بين مجالات الأمان. فهو يعمل على إنشاء دائرة من الثقة بين المستخدم ومزود الخدمة (SP) ومزود الهوية (IDp) مما يسمح للمستخدم بتسجيل الدخول مرة واحدة لعدة خدمات. يمكن إستخدام SAML لمصادقة الوصول عن بعد VPN ل Cisco Secure Client Connections to ASA و FTD VPN HeadEnd، حيث يكون ASA أو FTD هو كيان SP في دائرة الأمان.

يمكن حل معظم مشاكل SAML عن طريق التحقق من التكوين على IdP و ASA/FTD الجاري إستخدامها. في الحالات التي يكون فيها السبب غير واضح، يعطي التصحيح المزيد من الوضوح وتظهر الأمثلة في هذا الدليل من الأمر debug webVPN saml 255.

الغرض من هذا المستند هو أن يكون مرجعا سريعا لمشاكل SAML المعروفة والحلول الممكنة. 

المشاكل الشائعة:

المشكلة 1: عدم تطابق معرف الكيان

الشرح

يعني بشكل عام أن الأمر saml idp [entityID] ضمن تكوين WebVPN لجدار الحماية لا يتطابق مع معرف كيان IdP الذي تم العثور عليه في بيانات تعريف IdP's كما هو موضح في المثال.

مثال تصحيح الأخطاء:

Sep 05 23:54:02 [SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().

من موقع IDP:

<EntityDescriptor ID="_7e53f3f3-7c79-444a-b42d-d60ae13f0948" entityID="https://sts.example.net/69c69fff-03f6-4c9c-be73-9ed4f5f894c/">

من ASA/FTD:

saml idp https://sts.example.net/69c69fff-03f6-4c9c-be73-9ed4f5f894   >>>> The entity ID is missing characters at the end

الحل

تحقق من معرف الكيان الخاص بملف بيانات تعريف IdP وقم بتغيير الأمر saml idp [معرف الكيان] لمطابقة هذا تماما، بما في ذلك أي أحرف شرطة مائلة عكسية (/).

المشكلة 2: التأكيد غير صالح

الشرح

وهذا يعني أن جدار الحماية غير قادر على التحقق من صحة التأكيد المقدم من IdP حيث أن ساعة جدار الحماية خارج نطاق صحة التأكيد.

مثال تصحيح الأخطاء:

[SAML] consume_assertion: assertion is expired or not valid

مثال:

[SAML] NotBefore:2022-06-21T09:52:10.759Z NotOnOrAfter:2022-06-21T10:57:10.759Z timeout: 0    >>>>> Validity of the saml assertion provided by the IDP
Jun 21 15:20:46 [SAML] consume_assertion: assertion is expired or not valid

firepower# show clock
15:26:49.240 UTC Tue Jun 21 2022   >>>> Current time on the firewall

في المثال، يمكننا أن نرى أن التأكيد صالح فقط بين 09:52:10.759 UTC إلى 10:57:10.759 UTC، والوقت على جدار الحماية خارج إطار الصلاحية هذا.

ملاحظة: وفترة الصلاحية المبينة في التأكيد هي في التوقيت العالمي المنسق. إذا تم تكوين ساعة جدار الحماية في منطقة زمنية مختلفة، فإنه يحول الوقت في UTC قبل التحقق من الصحة.

الحل

قم بتكوين الوقت الصحيح على جدار الحماية يدويا أو باستخدام خادم NTP وتحقق من أن الوقت الحالي لجدار الحماية يقع ضمن صحة التأكيد في UTC. إذا تم تكوين جدار الحماية في منطقة زمنية مختلفة عن التوقيت العالمي المنسق (UTC)، فتأكد من تحويل الوقت إلى UTC قبل التحقق من صحة التأكيد.

المشكلة 3: لا يتحقق التوقيع

الشرح

عند فشل جدار الحماية في التحقق من توقيع تأكيد SAML الذي تم إستلامه من IdP بسبب شهادة IdP غير صحيحة تم تكوينها ضمن تكوين WebVPN لجدار الحماية باستخدام الأمر trustPoint idp <trustPoint>.

مثال تصحيح الأخطاء:

[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=evp_signatures.c:line=372:obj=rsa-sha256:subj=unknown:error=18:data do not match:details=EVP_VerifyFinal: signature does not verify

الحل

قم بتنزيل الشهادة من IdP وتثبيتها على جدار الحماية وتعيين TrustPoint جديد تحت تكوين WebVPN لجدار الحماية. يمكن العثور عادة على شهادة توقيع IdP في بيانات تعريف IdP أو إستجابة SAML التي تم فك ترميزها.

المشكلة 4: URL غير صحيح ل Confirmation Consumer Service

الشرح

تم تكوين IDp باستخدام URL غير صحيح للرد (URL خدمة العملاء لتأكيد الهوية).

الأمثلة

مثال تصحيح الأخطاء:

لا يتم عرض أي تصحيح أخطاء بعد إرسال طلب المصادقة الأولية. يمكن للمستخدم إدخال بيانات الاعتماد ولكن بعد فشل الاتصال وعدم طباعة أي تصحيح أخطاء.

من موقع IDP:

من بيانات تعريف FW أو SP:

<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn" />

في المثال، يمكن ملاحظة أن "URL خدمة المستهلك لتأكيد الهوية" على IDp لا يطابق الموقع على بيانات تعريف SP.

الحل

قم بتغيير عنوان URL لخدمة العملاء لتأكيد الهوية على IDp كما هو موضح في بيانات تعريف SP. يمكن الحصول على بيانات تعريف SP باستخدام الأمر show saml metadata <tunnel-group-name>.

المشكلة 5: جمهور التأكيد غير صالح

الشرح

عندما يرسل IdP وجهة غير صحيحة في إستجابة SAML، مثل مجموعة النفق الخطأ.

مثال تصحيح الأخطاء:

[SAML] consume_assertion: assertion audience is invalid

من تتبع SAML:

<samlp:Response ID="_36585f72-f813-471b-b4fd-3663fd24ffe8"
Version="2.0"
IssueInstant="2022-06-21T11:36:26.664Z" 
Destination="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn1"

Recipient="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn1"

<AudienceRestriction> <Audience>https://ac-vpn.local/saml/sp/metadata/acvpnAudience> AudienceRestriction>

من بيانات تعريف جدار الحماية أو SP:

<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ac-vpn.local/+CSCOE+/saml/sp/acs?tgname=acvpn" />

الحل

قم بتصحيح التكوين الموجود على IDP كوجهة ومستلم في إستجابة SAML يجب أن يطابق الموقع كما هو موضح في بيانات تعريف جدار الحماية/SP في إخراج بيانات تعريف show saml <tunnel-group-name>.

المشكلة 6: عدم سريان تغييرات تكوين SAML

الشرح

بعد أي تعديل مع تكوين SAML ضمن WebVPN، يقترح إزالة الأمر saml identity-provider <idp-enttity-id> وإعادة إضافته ضمن مجموعة النفق.

الحل

قم بإزالة الأمر saml identity-provider <idp-enttity-id>وإعادة إضافته تحت مجموعة النفق.

المشكلة 7: كيفية إستخدام نفس المشردين داخليا ضمن توصيفات اتصال/مجموعة أنفاق متعددة

الشرح

لتكوين مصادقة SAML لاستخدام تطبيق IdP SSO نفسه لمجموعات أنفاق متعددة، اتبع خطوات التكوين أدناه.

الحلول

الخيار 1 ل ASA 9. 16 والإصدارات الأقدم، أو FDM Managed FTD أو FMC/FTD 7. 0 والإصدارات الأقدم:

• إنشاء إصدارات SSO منفصلة على IdP، واحد لكل ملف تعريف مجموعة/اتصال نفق.
• قم بإنشاء CSR باستخدام CN الافتراضي المستخدم من قبل IDP.
• توقيع CSR من مرجع مصدق داخلي/خارجي.
• قم بتثبيت نفس شهادة الهوية الموقعة على التطبيقات التي سيتم إستخدامها لمجموعات أنفاق منفصلة أو ملفات تعريف اتصال.

الخيار 2 ل ASA 9.17.1 وفيما بعد أو FTD/FMC 7.1 وفيما بعد:

• إنشاء تطبيقات SSO منفصلة على IdP، بواقع تطبيق لكل ملف تعريف اتصال/مجموعة أنفاق.
• تنزيل الشهادات من كل تطبيق وتحميلها على ASA أو FTD.
• قم بتعيين TrustPoint الذي يتوافق مع تطبيق IdP لكل ملف تعريف لكل مجموعة نفق/اتصال.

المشكلة 8: فشلت المصادقة بسبب مشكلة في إسترداد ملف تعريف إرتباط تسجيل الدخول الأحادي

الشرح

ويمكن ملاحظة ذلك على برنامج Secure Client على جهاز العميل لأسباب متعددة، بما في ذلك على سبيل المثال لا الحصر:

• لا تتجاوز صلاحية التأكيد الوقت الحالي للنموذج.
• تم تعريف معرف الكيان أو عنوان URL لخدمة المستهلك للتأكيد بشكل غير صحيح على IDP.

الحل

• قم بتشغيل تصحيح الأخطاء على FW وابحث عن أخطاء محددة.
• تحقق من معرف الكيان وعنوان URL لخدمة المستهلك للتأكيد الذي تم تكوينه على IDP مقابل بيانات التعريف التي تم الحصول عليها من FW.

المشكلة 9: حالة ترحيل عدم تطابق التجزئة

تفسيرات

• تخدم المعلمة RelayState الغرض من إعادة توجيه IdP للمستخدم مرة أخرى إلى المورد الأصلي المطلوب بعد مصادقة SAML الناجحة. يجب أن تتطابق معلومات RelayState على التأكيد مع معلومات RelayState في نهاية عنوان URL لطلب المصادقة.
• يمكن أن يكون هذا مؤشرا على هجوم MitM ولكن يمكن أن يحدث أيضا بسبب التغييرات على RelayState على جانب IdP.

مثال تصحيح الأخطاء:

[SAML] relay-state hash mismatch.

الحل

• الانتقال إلى إصدار ثابت كما هو مفصل في معرف تصحيح الأخطاء من Cisco CSCwf85757
• تحقق من عدم قيام IdP بتغيير معلومات RelayState.

المزيد من استكشاف الأخطاء وإصلاحها

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

firepower# debug webvpn saml 255
firepower# debug webvpn 255
firepower# debug webvpn session 255
firepower# debug webvpn request 255

معلومات ذات صلة

• الدعم الفني والتنزيلات من Cisco
• أدلة تكوين ASA
• أدلة تكوين FMC/FDM