تكوين تسجيل الدخول الأحادي في AppDynamics واستكشاف أخطائه وإصلاحها

المقدمة

يصف هذا المستند كيفية تكوين تسجيل الدخول الأحادي (SSO) في مشاكل AppDynamics واستكشاف الأخطاء وإصلاحها.

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

المتطلبات

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

• لتكوين تسجيل دخول أحادي، يجب أن يكون لدى المستخدم دور مالك الحساب (الافتراضي) أو دور مخصص مع الإدارة والوكلاء وأذن معالج بدء التشغيل.
• وصول المسؤول إلى IdPaccount الخاص بك.
• بيانات التعريف أو تفاصيل التكوين من AppDynamics (على سبيل المثال، معرف الوحدة وعنوان URL ل ACS).

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

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• وحدة التحكم في AppDynamics

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

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

تسجيل الدخول الأحادي (SSO) هو آلية مصادقة تتيح للمستخدمين تسجيل الدخول مرة واحدة والحصول على حق الوصول إلى تطبيقات أو أنظمة أو خدمات متعددة دون الحاجة إلى المصادقة مرة أخرى لكل واحد.

لغة تمييز تأكيد الأمان (SAML) هي إحدى التقنيات المستخدمة لتنفيذ SSO. وهو يوفر الإطار والبروتوكولات التي تمكن SSO من خلال تبادل بيانات المصادقة والتفويض بشكل آمن بين موفر الهوية (IDp) ومزود الخدمة (SP).

تأكيد SAML

• يتم تبادل الرسائل المستندة إلى XML بين IdP و SP.
• وهو يقدم ثلاثة أنواع من التأكيدات:
  • تأكيدات المصادقة: تأكيد مصادقة المستخدم.
  • تأكيدات السمة: مشاركة سمات المستخدم، مثل اسم المستخدم أو الأدوار.
  • يؤكد قرار التخويل: الإشارة إلى ما هو المخول للمستخدم القيام به.

الأدوار الرئيسية في SAML

• موفر الهوية (IDp)
  • التحقق من هوية المستخدم.
  • قم بإنشاء تأكيد SAML الذي يحتوي على معلومات تعريف المستخدم.
• مزود الخدمة (SP)
  • التطبيق أو النظام الذي يرغب المستخدم في الوصول إليه.
  • يعتمد على IdP لمصادقة المستخدم.
  • يقبل تأكيد SAML لمنح المستخدم حق الوصول إلى الموارد أو التطبيق الخاص به.
• مستخدم (رئيسي)
  • المستخدم الفعلي الذي يقوم ببدء الطلب أو يحاول الوصول إلى مورد من موفر الخدمة.
  • يتفاعل مع كل من IdP (المصادقة) و SP.

ملاحظة: يدعم AppDynamics كلا من IdP الذي تم بدؤه وبدء SP SSO.

تدفق SP الذي بدأه:

• ينتقل المستخدم إلى مزود الخدمة بكتابة عنوان URL الخاص بالتطبيق (على سبيل المثال، AppDynamics) أو النقر فوق إرتباط.
• يقوم SP بالتحقق من جلسة عمل موجودة. في حالة عدم وجود جلسة عمل، يتعرف SP على عدم مصادقة المستخدم ويبدأ عملية SSO.
• يقوم SP بإنشاء طلب مصادقة SAML ويعيد توجيه المستخدم إلى IdP للمصادقة.
  • يتضمن هذا الطلب:
    • معرف الكيان: المعرف الفريد لموفر الخدمة.
    • عنوان URL لخدمة العملاء لتأكيد البيانات (ACS): حيث يقوم IdP بإرسال تأكيد SAML بعد المصادقة.
    • بيانات تعريف حول SP وتفاصيل الأمان (على سبيل المثال، الطلب الموقع ومتطلبات التشفير).
• تتم إعادة توجيه المستخدم إلى صفحة تسجيل الدخول إلى IdP.
• يصادق IdP المستخدم (على سبيل المثال، عبر اسم المستخدم/كلمة المرور أو المصادقة متعددة العوامل).
• بعد المصادقة الناجحة، يقوم IdP بإنشاء تأكيد SAML (الرمز المميز للأمان).
• يتم إرسال تأكيد SAML مرة أخرى إلى SP عبر مستعرض المستخدم باستخدام HTTP POST Binding (في معظم الحالات) أو HTTP Redirect Binding.
• يتحقق SP من تأكيد SAML لضمان:
  • تم إصداره بواسطة IdP الموثوق به.
  • ويتم توجيهها إلى SP (عبر معرف كيان SP).
  • لم تنتهي صلاحيته أو تم العبث به (تم التحقق منه باستخدام المفتاح العام IdP).

• إذا كان تأكيد SAML صحيحا، يقوم SP بإنشاء جلسة عمل للمستخدم.
• يتم منح المستخدم حق الوصول إلى التطبيق أو الموارد.

بدأ IDp التدفق:

• ينتقل المستخدم إلى مدخل تسجيل الدخول إلى IdP ويدخل بيانات الاعتماد الخاصة به.
• يصادق IdP المستخدم (على سبيل المثال، مع مجموعة اسم المستخدم/كلمة المرور، والمصادقة متعددة العوامل).
• بعد المصادقة، يقدم المعرف (IDp) للمستخدم قائمة بالتطبيقات أو الخدمات المتاحة (SP) التي يمكن الوصول إليها.
• يقوم المستخدم بتحديد SP المطلوب (على سبيل المثال، AppDynamics).
• يقوم IdP بإنشاء تأكيد SAML ل SP المحدد.

• يقوم IdP بإعادة توجيه المستخدم إلى عنوان URL الخاص ب "خدمة العملاء لتأكيد SP" (ACS) وإرسال تأكيد SAML معه (باستخدام ربط HTTP POST أو ربط إعادة توجيه HTTP).
• يتلقى SP تأكيد SAML ويتحقق منه:
  • يضمن إصدار التأكيد بواسطة معرف موثوق به.
  • التحقق من سلامة التأكيد وانتهاء صلاحيته.
  • تأكيد هوية المستخدم والسمات الأخرى.

• إذا كان تأكيد SAML صحيحا، يقوم SP بإنشاء جلسة عمل للمستخدم.
• يتم منح المستخدم حق الوصول إلى التطبيق أو الموارد.

التكوين

يمكن لوحدة التحكم في AppDynamics إستخدام معرف عميل Cisco أو موفر هوية SAML خارجي (IDp) لمصادقة المستخدمين وتخويلهم.

موفرو الهوية المدعومون

خطوات تكوين SAML في AppDynamics

الخطوة 1. تجميع تفاصيل وحدة تحكم AppDynamics

• معرف الكيان (معرف كيان SP): معرف فريد ل AppDynamics (على سبيل المثال، https://<controller-host>:<port>/controller). 
  
  • الصيغة:  https://<controller_domain>/controller
  • مثال: https://<your_controller_domain>/controller
    
    
• عنوان URL للرد (Confirmation Consumer Service، ACS URL): نقطة النهاية على مزود الخدمة (على سبيل المثال، AppDynamics) حيث يقوم IdP بإرسال إستجابة SAML بعد المصادقة. 
  • الصيغة: https://<controller_domain>/controller/saml-auth؟accountName=<account_name>
  • مثال: https://your_controller_domain/controller/saml-auth?accountName=youraccountname
    
    

    ملاحظة: في حالة وحدة التحكم في التشغيل المسبق، يكون اسم الحساب الافتراضي هو customer1 إلا إذا كان لديك وحدة تحكم متعددة المستأجرين ذات اسم حساب مختلف.

• عنوان URL أحادي لتسجيل الخروج (إختياري):نقطة النهاية على SP للتعامل مع طلبات تسجيل الخروج من SAML (على سبيل المثال، https://<controller_domain>/controller).

الخطوة 2. إنشاء تطبيق جديد في IDp وتنزيل بيانات التعريف

• حدد موقع منطقة إنشاء التطبيق: عادة ما يكون ذلك داخل وحدة التحكم الإدارية أو لوحة المعلومات الخاصة ب IDp، والتي غالبا ما تسمى شيئا مثل التطبيقات أو تطبيقات الويب أو المحمول أو تطبيقات المؤسسات أو أطراف الاعتماد.
• إضافة تطبيق SAML مخصص أو عام: حدد خيارا يتيح لك تكوين تطبيق SAML مخصص أو دمج موفر خدمة SAML عام.
• توفير تفاصيل التطبيق: قم بتسمية التطبيق واحتمال تحميل رمز للتعريف (إختياري).
• قم بإضافة تعيينات السمات (اسم المستخدم أو اسم العرض أو البريد الإلكتروني أو الأدوار) لتمرير معلومات المستخدم إلى AppDynamics.
• قم بتنزيل ملف بيانات تعريف IdP، أو بدلا من ذلك، قم بملاحظة التفاصيل التالية:
  • URL تسجيل دخول IDp
  • عنوان URL لتسجيل الخروج
  • أسماء السمات
  • شهادة

الخطوة 3. تكوين مصادقة SAML في وحدة التحكم AppDynamics

• سجل الدخول إلى UIas UIas UIas Account Owner Role مع Administration، Agents، Get Start Wizard Permission.
• انقر فوق اسم المستخدم (الجانب الأيمن العلوي)> الإدارة > موفر المصادقة > تحديد SAML.
  
  
• في قسم تكوين SAML، أضف التفاصيل التالية:

  • عنوان URL لتسجيل الدخول: عنوان URL لتسجيل الدخول إلى IdP حيث يقوم AppDynamics Controller بتوجيه طلبات تسجيل الدخول التي بدأها موفر الخدمة (SP).

  • عنوان URL لتسجيل الخروج (إختياري): عنوان URL حيث يقوم AppDynamics Controller بإعادة توجيه المستخدمين بعد تسجيل خروجهم. إذا لم تحدد عنوان URL لتسجيل الخروج، يحصل المستخدمون على شاشة تسجيل الدخول إلى AppDynamics عند تسجيل الخروج.

  • الشهادة: شهادة X.509 من IDp. الصق الشهادة بين محددات شهادة البدء والشهادة النهائية. تجنب مضاعفة محددات شهادة BEGIN و END من الشهادة المصدر نفسها.

  • تشفير SAML (إختياري): يمكنك تحسين أمان مصادقة SAML من خلال تشفير إستجابة SAML من IdP إلى موفر الخدمة. لتشفير استجابات SAML في AppDynamics، تحتاج إلى تكوين موفر الهوية (IdP) لتشفير تأكيد SAML ثم تكوين وحدة التحكم AppDynamics لاستخدام شهادة محددة ومفتاح خاص لفك التشفير.
    
    
• في قسم تعيينات سمات SAML، قم بتعيين سمات SAML (مثال: اسم المستخدم و DisplayName و Email) إلى الحقول المقابلة في AppDynamics.
  
  

  ملاحظة: يعرض AppDynamics اسم المستخدم والبريد الإلكتروني واسم العرض الخاص بمستخدم SAML. بشكل افتراضي، يستخدم سمة NameID من إستجابة SAML لإنشاء اسم مستخدم، والذي يتم إستخدامه أيضا كاسم العرض. يمكن تخصيص هذا السلوك بتضمين سمات اسم المستخدم والبريد الإلكتروني واسم العرض في إستجابة SAML. أثناء تكوين إعدادات IdP في AppDynamics، يمكن للمستخدم تحديد أسماء السمات هذه. أثناء تسجيل الدخول، يتحقق AppDynamics من تكوين تعيين السمة. إذا تم تكوين التعيينات وكانت السمات المطابقة موجودة في إستجابة SAML، فإن AppDynamics يستخدم قيم السمات هذه لتعيين اسم المستخدم والبريد الإلكتروني واسم العرض.

  
• في قسم تعيينات مجموعة SAML، أضف هذه التفاصيل.
  • اسم سمة مجموعة SAML: أدخل اسم سمة SAML التي تحتوي على معلومات المجموعة. عادة ما تكون هذه المجموعات أو المجموعات أو الأدوار أو الأدوار أو عضوية المجموعة.
  • قيمة سمة المجموعة: حدد تنسيق القيمة المناسب لسمة المجموعة. تتضمن الخيارات الشائعة قيم مجموعة متداخلة متعددة أو قيمة مفردة بناء على كيفية هيكلة IdP الخاص بك لمعلومات المجموعة.
    
    

    ملاحظة: تكون قيمة التحديد بتنسيق LDAP إذا كانت معلومات المجموعة واردة بتنسيق LDAP (بروتوكول الوصول إلى الدليل خفيف الوزن).

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

      ملاحظة: يوصى بتعيين دور يحتوي على الحد الأدنى من الأذونات للأذونات الافتراضية.

      
      
      

      
      

• في قسم سمة الوصول إلى SAML، أضف التفاصيل التالية (إختياري):
  • سمة الوصول إلى SAML: أدخل اسم السمات من إستجابة SAML. سيتم إستخدام هذا للتحقق من صحة الوصول.
  • قيمة مقارنة الوصول: هناك خياران متاحان:
    1. يساوي: يتم منح الوصول فقط إذا كانت قيمة السمة في إستجابة SAML تطابق القيمة المحددة في التكوين تماما.
    2. يحتوي على: يتم منح الوصول إذا كانت قيمة السمة في إستجابة SAML تحتوي على القيمة المحددة في التكوين.
  • كيفية عملها إذا تم تمكينها:
    1. يسترجع AppDynamics السمة المحددة في حقل سمة الوصول إلى SAML من إستجابة SAML.
    2. إنه يقارن قيمة السمة بقيمة مقارنة الوصول المعرفة من قبل المستخدم بناء على الطريقة المحددة (يساوي أو يحتوي).
    3. في حالة نجاح المقارنة، يتم منح المستخدم حق الوصول.
    4. في حالة فشل المقارنة، يتم رفض محاولة تسجيل الدخول.
• انقر فوق حفظ (في الركن السفلي الأيمن) لحفظ التكوين.
  
  
  
  

التحقق من الصحة

• افتح مستعرض وانتقل إلى وحدة التحكم في AppDynamics. يظهر مربع حوار تسجيل الدخول لخدمة IdP الخاصة بالطرف الثالث.
• انقر على تسجيل الدخول باستخدام تسجيل الدخول الأحادي. يقوم النظام بإعادة توجيهك إلى المعرف الخاص بك.
• أدخل بيانات الاعتماد الخاصة بك وقم بإرسالها.
• بعد المصادقة بنجاح، يقوم IdP بإعادة توجيهك إلى وحدة التحكم في AppDynamics.

المشاكل المشتركة والحل

400 طلب سيئة

• المشكلة: يواجه المستخدمون خطأ 400 طلب غير صالح عند محاولة تسجيل الدخول إلى وحدة التحكم في AppDynamics.
• نموذج الخطأ:
  

  HTTP status 400 - Bad Request
  Message: Error while processing SAML Authentication Response - see server log for details
  Description: The request sent by the client was syntactically incorrect.

  
  
• الأسباب الجذرية الشائعة: 
  • شهادة SAML غير صالحة
  • الاستجابة في SAML أكبر من الحد الأقصى للطول
  • معرف الكيان أو عنوان URL ل ACS غير صالح
• الحل: 
  • شهادة SAML غير صالحة
    • تأكد من أن الشهادة التي يوفرها موفر الهوية (IDp) صحيحة ومحدثة.
    • تحقق من تاريخ انتهاء صلاحية شهادة IdP. في حالة انتهاء صلاحيته، احصل على شهادة جديدة من المعرف.
    • إذا تم تحديث الشهادة على جانب IdP، فتأكد من تحميل الشهادة الجديدة وتكوينها في AppDynamics.
    • خطوات تحديث الشهادة في AppDynamics:
      • سجل الدخول إلى واجهة مستخدم وحدة التحكم كدور مالك حساب أو دور مع إدارة، وكلاء، الحصول على إذن معالج بدء التشغيل.
      • انقر على اسم المستخدم (أعلى الركن الأيمن)> الإدارة > موفر المصادقة > تحديد SAML.
      • في قسم تكوين SAML، حدد موقع حقل الشهادة واستبدل الشهادة القديمة بالشهادة الجديدة المقدمة من قبل IdP.
      • انقر فوق حفظ لتحديث تكوين SAML.
        
        
  • إستجابة SAML أكبر من الحد الأقصى للطول.
    • وتنشأ هذه المشكلة عند نقل وحدة التحكم من GlassFish إلى Tty Server، بدءا من الإصدار 23.11 من وحدة التحكم وما فوقها. في Tty Server، هناك خاصية مسماة -dorg.eclipse.tty.server. Request.maxFormContentSize الموجود في .../appserver/jetty/start.d/start.ini file. إذا تجاوز حجم إستجابة SAML القيمة التي تم تعيينها لهذه الخاصية، يرفض جهاز التحكم الحمولة ويعيد 400 طلب غير صالح الخطأ.
      
    • أسباب استجابات SAML الكبيرة:
      • السمات الزائدة: يوجد سمات كثيرة جدا مضمنة في تأكيد SAML.
      • استجابات SAML الموقعة أو المشفرة: التوقيع أو التشفير يزيد من حجم الاستجابة.
      • بيانات إضافية خاصة بالمستخدم أو المجموعة: يحتوي موفر الهوية (IdP) على بيانات إضافية خاصة بالمستخدم أو المجموعة.
        
        
    • هناك طريقتان لحل هذه المشكلة. من خلال تنفيذ أحد هذين الحلين أو كليهما، يمكنك حل المشكلة ومنع رفض الحمولة.
      1. زيادة قيمة maxFormContentSize
         • بالنسبة لوحدات التحكم في الذاكرة المؤقتة: تحديث الخاصية -dorg.eclipse.tty.server.Request.maxFormContentSize في .../appserver/jetty/start.d/start.ini ملف إلى قيمة أكبر وإعادة تشغيل وحدة التحكم.
         • لوحدات تحكم SAAs: قم بتقديم تذكرة دعم لمعالجة هذه المشكلة بواسطة فريق الدعم.

      2. تحسين إستجابة SAML

         اعمل مع موفر الهوية (IdP) لتقليل حجم إستجابة SAML عن طريق إجراء هذه التعديلات:

         • إستبعاد السمات غير الضرورية: قم بإزالة السمات غير المستخدمة أو المكررة من تأكيد SAML عبر تكوين IdP.
         • تعطيل التشفير (إذا كان مسموحا به): يزيد التشفير من حجم إستجابة SAML. إذا كان الاتصال مؤمنا بالفعل عبر HTTPS، فعليك تعطيل التشفير لتقليل الحجم.
  • معرف الكيان أو عنوان URL ل ACS غير صالح
    
    • بشأن النازحين:
      • تأكد من أن معرف الكيان هو https://your_controller_domain/controller. إذا كان معرف الكيان مختلفا، فقم بتحديثه.
      • تأكد من أن عنوان URL ل ACS هو https://your_controller_domain/controller/saml-auth?accountName=youraccountname. إذا كان عنوان URL ل ACS مختلفا، فقم بتحديثه وفقا لذلك.
        
        

        ملاحظة: يجب أن يتطابق اسم الحساب مع اسم حساب AppDynamics. (على سبيل المثال، customer1)

• أذونات المستخدم مفقودة

  • المشكلة: لقد قمت بتسجيل الدخول إلى وحدة التحكم بنجاح. ومع ذلك، لم تحصل على الأدوار والأذونات المقصودة.
  • مثال على التهيئة والاستجابة في SAML:
    
    • في مستخدم SAML سمة المجموعة، الاسم هو مجموعات ذات قيم AppD_Admin و AppD_Power_User.
      

      
        AppD_Admin
        AppD_Power_User
      ​
      ​

    • في AppDynamics، تحت قسم تعيينات مجموعة SAML، يتم تكوين هذه العناصر.
      • اسم سمة مجموعة SAML: مجموعات
      • قيمة سمة المجموعة: قيم مجموعة متداخلة متعددة
      • التعيين إلى أدوار المجموعة:
        

        مجموعة SAML	أدوار AppDynamics
        AppD_Account_Owner	مالك الحساب (الافتراضي)
        الأذونات الافتراضية	لا يوجد وصول

        
        لا يوجد حق وصول عبارة عن دور مخصص بدون أذونات.
        
        
        
        
  • القضايا المشتركة والحل 
    • لم يتم العثور على سمات مجموعة في إستجابة SAML.
      • تفتقد إستجابة SAML من IdP سمات المجموعة المطلوبة أو تم تعيين اسم السمة للمجموعات في إستجابة SAML كأدوار أثناء تكوينها في AppDynamics كمجموعات.
      • عند عدم توفير سمات مجموعة، يتم تعيين الأدوار المقترنة بالأذونات الافتراضية تلقائيا إلى المستخدم في AppDynamics.
      • لحل هذه المشكلة، تأكد من تكوين IdP لتضمين سمات المجموعة الصحيحة في إستجابة SAML وأن اسم السمة للمجموعات يطابق التكوين في AppDynamics.
        
        
    • لا يوجد تعيين مجموعة SAML مطابق تم تكوينه في AppDynamics لمجموعات المستخدمين الموفرة في إستجابة SAML. 
      
      • في إستجابة SAML، تحتوي سمة المجموعات على القيم AppD_Admin و AppD_Power_User. ومع ذلك، في AppDynamics، توجد تعيينات المجموعة فقط لمجموعة AppD_Account_Owner.
      • نظرا لعدم وجود تعيين مطابق ل AppD_Admin أو AppD_Power_User، لم يتم تعيين أي أدوار أو أذونات للمستخدم.
      • لحل هذه المشكلة، أضف تعيينات المجموعة المفقودة (على سبيل المثال، AppD_Admin و AppD_Power_User) في AppDynamics لضمان الدور المناسب وتعيين الأذونات.

ملاحظة: يتم تطبيق الأذونات الافتراضية فقط على مستخدمي SAML عندما لا يكون اسم سمة مجموعة SAML الذي تم تكوينه في AppDynamics مماثلا لسمات المجموعات في إستجابة SAML.

• البريد الإلكتروني و/أو الاسم الخاص بمستخدمي SAML مفقود أو غير صحيح

  • المشكلة: يحدث هذا عادة عندما لا يتوافق تكوين السمة في AppDynamics مع السمات الواردة في إستجابة SAML.
  • مثال على إستجابة SAML: السمات في إستجابة SAML هي: User.email و User.FullName و Groups
    

    
      example@domain.com
      
    
    
      FirstName LastName
      
    
    
      AppD_Admin
      AppD_Power_User
    ​
    ​

  • مثال تعيينات سمة SAML في AppDynamics

    • سمة اسم المستخدم: user.name
    • سمة اسم العرض: User.FirstName أو فارغ
    • سمة البريد الإلكتروني: User.UserPrincipal أو فارغ
      
      
  • السبب الجذري: لا تتطابق سمات اسم العرض والبريد الإلكتروني التي تم تكوينها في AppDynamics مع أي من السمات التي تم توفيرها في إستجابة SAML.
    • ونتيجة لذلك:
      • تم تعيين البريد الإلكتروني إلى فارغ.
      • اسم العرض الافتراضي لاسم المستخدم.
        
        
  • الحل: تأكد من مطابقة سمات اسم العرض والبريد الإلكتروني التي تم تكوينها في AppDynamics للسمات المقابلة في إستجابة SAML.
    • على سبيل المثال:
      • قم بتحديث سمة "اسم العرض" إلى User.fullName.
      • قم بتحديث سمة البريد الإلكتروني إلى User.email.

• خطأ HTTP 404

• المشكلة: يتعذر على المستخدم تسجيل الدخول إلى وحدة التحكم ولم يتم العثور على 404 خطأ.
• نموذج الخطأ: في سجلات وحدة التحكم (فقط لوحدة التحكم الداخلية) ترى هذا الخطأ:
  

  [#|2025-01-10T21:16:35.222+0000|SEVERE|glassfish 4.1|com.singularity.ee.controller.auth.saml.SAMLAuthenticationServlet|_ThreadID=53;_ThreadName=http-listener-1(4);_TimeMillis=1736543795222;_LevelValue=1000;|Error while creating SAML Authentication request
  com.appdynamics.platform.services.auth.exception.SamlException: Requested url validation failed
      at com.appdynamics.platform.services.auth.impl.saml.SamlRequestResponseHandler.validateRequestedUrl(SamlRequestResponseHandler.java:576)
      at com.appdynamics.platform.services.auth.impl.saml.SamlRequestResponseHandler.getSamlAuthenticationRequest(SamlRequestResponseHandler.java:132)

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

      curl -k --basic --user root@system --header "Content-Type: application/json" --data '{ "controllerURL": "https:///controller" }' http:///controller/rest/accounts//update-controller-url
      ​

    • بدلا من ذلك، يمكنك تشغيل هذه الأوامر في قاعدة بيانات وحدة التحكم لتحديث عنوان URL لوحدة التحكم.
      

      UPDATE controller.account SET controller_url ='' WHERE id=;
      UPDATE mds_auth.account SET controller_url='' WHERE name='';​

      • قم بتشغيل هذا الأمر للحصول على <ACCOUNT_ID>.
        

        Select id from controller.account where name = '';​

        

        ملاحظة: قم بتشغيل curl -X POST -u root@system https://<controller_domain>/controller/api/controlRMDS/syncAll إذا كنت لا تزال تراقب نفس المشكلة.

      • إستبدال:
        • <new_CONTROLLER_URL> بعنوان URL لوحدة التحكم الفعلية التي تستخدمها للوصول إلى وحدة التحكم.
        • <controller_domain> بمجال وحدة التحكم لديك.
        • <YourAccountName> باسم حسابك.
          
          
  • لوحدات تحكم SAAs: قم بتقديم تذكرة دعم لمعالجة هذه المشكلة بواسطة فريق الدعم.

الحاجة إلى مزيد من المساعدة

إذا كان لديك سؤال أو لديك مشكلات، فيرجى إنشاء تذكرة دعم مع هذه التفاصيل:

• تفاصيل الخطأ أو لقطة الشاشة: قم بتوفير رسالة خطأ محددة أو لقطة شاشة للمشكلة.
• إستجابة SAML: تجميع ملف SAML-Trace و HAR
• Controller Server.log (On-PREM فقط): إذا كان ذلك ممكنا، فقم بتوفير سجلات خادم وحدة التحكم من <controller-install-dir>/logs/server.log

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

وثائق AppDynamics

عمليات نشر SAML ل SAAs

تشفير استجابات SAML لعمليات نشر SAAs