الحصول على 401/403 في تطبيق High Trust لـ Sharepoint 2013

Question

لدي هذا بيئة كلاودشير تتكون من 3 آلات:

• واحد لـ Sharepoint 2013 (هذا هو المكان الذي أقوم فيه بالتطوير مع تثبيت VS2012)
• آخر لـ SQL Server 2012
• وآخر للدليل النشط

أحاول إنشاء تطبيق أساسي عالي الثقة لـ Sharepoint 2013 باستخدام بروتوكول خادم إلى خادم.

لقد اتبعت عدة أدلة:

• http://msdn.microsoft.com/en-us/library/fp179901.aspx
• http://blogs.msdn.com/b/shariq/archive/2013/05/07/how-to-set-up-high-trust-apps-for-sharepoint-2013-amp-troubleshooting-tips.aspx
• http://ranvijaysingh.blogspot.com.ar/2013/04/develop-provider-hosted-app-on-single.html

عندما أقوم بتشغيل المشروع (رمز القالب الافتراضي) من VS وأثق في التطبيق، أحصل على استثناء في السطر التالي:

Uri hostWeb = new Uri(Request.QueryString["SPHostUrl"]);

using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
{
    clientContext.Load(clientContext.Web, web => web.Title);
    clientContext.ExecuteQuery(); // throws exception
    Response.Write(clientContext.Web.Title);
}

في Default.aspx.cs

الاستثناء يمكن أن يكون أي مما يلي:

أرجع الخادم البعيد خطأً:(403 ممنوع.

أرجع الخادم البعيد خطأً:(401) غير مصرح به.

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

شكرًا

تحديث

فيما يلي إدخالات سجل ULS ذات الصلة بالطلب:http://pastie.org/pastes/8395956/text

Answer 1

من أجل البساطة سأذكر ما هو واضح!

لم تتم مصادقة المستخدم ويتطلب المورد المصادقة

يخبرني هذا أن هناك خطأ ما يحدث أثناء المصافحة (لم يتم إرسال شهادتك أو أنها خاطئة)، نظرًا لأنه أحد منتجات Microsoft، فإن أفضل مكان هو إلقاء نظرة على msdn.

لتوضيح الأمر يرجى قراءة هذا:

الخطوة التالية اختيارية.ومع ذلك ، نوصيك بتطوير واختبار مع HTTPS تشغيل.قد يؤدي إيقاف تشغيل HTTPs لك كمطور يفوتك بعض المشكلات عند إنشاء تطبيق قد يحدث أثناء نشر الإنتاج حيث تكون HTTPS مطلوبة.

الآن قرأت المذكرة، اقرأ المشكلة التي تواجهك!

تتطلب OAUTH الآن SharePoint لتشغيل HTTPS ، ليس فقط لخدمتك ولكن أيضًا لـ SharePoint 2013.ستحصل على رسالة 403 (محظورة) عند محاولة إجراء مكالمة إلى SharePoint باستخدام شهادة اختبار.

على الكمبيوتر الذي تم تثبيت SharePoint 2013 ، يمكنك إيقاف متطلبات HTTPS أثناء التطوير باستخدام Windows PowerShell CMDLETs التالية.

إذن هذه هي مشكلتك هناك!للالتفاف حوله أثناء التطوير قم بما يلي:

هذا في بوويرشيل للاختبار/التطوير:

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

وبمجرد الانتهاء إعادته كما كان!

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()

الآن أود أيضًا أن أشير إلى:

في تطبيق عالي الثقة ، لا يوجد رمز سياق ، حتى لو كنت تستخدم ملف Appredirect.aspx.رمز السياق محدد للتكوينات التي تستخدم خدمة التحكم في الوصول إلى Windows Azure (ACS).ومع ذلك ، لا يزال هناك حاجة إلى رمز الوصول. إذا كنت تستخدم تكوينًا عاليًا للثقة ، فيجب على تطبيق الويب الخاص بك مصادقة المستخدم بالطريقة نفسها التي يفعلها SharePoint 2013 (أي ، يكون التطبيق مسؤولاً عن إنشاء جزء المستخدم من رمز الوصول).

هل تستخدم فئة tokenhelper للحصول على سياق العميل؟

        using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
        {
            clientContext.Load(clientContext.Web, web => web.Title);
            clientContext.ExecuteQuery();
            Response.Write(clientContext.Web.Title);
        }

وأيضًا ما الذي تحاول فعله بالضبط حيث قد تحتاج إلى المزيد من الأذونات اعتمادًا على ما تفعله!

للوصول إلى الخصائص الأخرى ، قد تحتاج إلى طلب أذونات على الويب المضيف.

http://msdn.microsoft.com/en-us/library/fp179901.aspx

نأمل أن يجيب ما ورد أعلاه على سؤالك!تحتاج إلى التأكد من تنفيذ ما ورد أعلاه بشكل صحيح حتى يعمل!

---

إذا كانت هذه مشكلة لا تزال مشكلة، فهناك خطأ ما في الدليل الإرشادي الصادر عن vs2012، والذي يتم إرساله تلقائيًا عند الضغط على F5، ويتم تعيين ذلك في web.config على هذا السطر:

<add key="IssuerId" 

تغيير الدليل من الأحرف الكبيرة إلى الأحرف الصغيرة:

من:

<add key="IssuerId" value="F2AE6B96-1FC0-43C6-B5D0-900117C491A4"/>

ل

<add key="IssuerId" value="f2ae6b96-1fc0-43c6-b5d0-900117c491a4"/>

من الواضح أن دليلك سيكون مختلفًا عما سبق ;)

أود أيضًا أن أشير إلى أنك بحاجة إلى شهادة فريدة لكل تطبيق على حدة!تأكد أيضًا من أن الدليل الإرشادي هو نفس دليل powershell الذي يستخدمه Get-SPTrustedSecurityTokenIssuer يجب أن يكون هو نفسه web.config!

http://www.jamestsai.net/Blog/post/SharePoint-Provider-Hosted-App-401-Unauthorized-error-on-clientContextExecuteQuery().aspx

تحديث

نظرت للتو إلى ملف السجل الخاص بك!

لكسرها فشلها على الفور مع المصادقة!ما هي الطريقة التي تستخدمها؟NTLM؟كيربوس؟إلخ...

يعد هذا أمرًا أساسيًا لمعرفة كيفية إعداد مزرعتك والمصادقة عليها!

الآن قد يكون هناك العديد من المشكلات التي تحدث هنا بسبب مظهر الأخطاء!أنصحك بقراءة الروابط أدناه!أوصي بشدة بمجرد قراءة الروابط أنه إذا كان كل شيء صحيحًا في الإعداد الخاص بك للتشغيل New-SPTrustedSecurityTokenIssuer يمكن العثور على هذا المثال في الرابط الأخير الخاص بي في أسفل الصفحة!قد يحل هذا مشكلتك المتعلقة بجزء الرمز المميز والمصافحة الصحيحة بين خادمين (التحقق من صحة بعضهما البعض).

1) لم يتم إرسال الرمز المميز بسبب إعدادات الأمان غير المتوافقة!

إذا كنت تستخدم وضع مطالبات Windows لمصادقة المستخدم وتم تكوين تطبيق الويب لاستخدام مصادقة Kerberos فقط دون العودة إلى NTLM كبروتوكول المصادقة ، فإن مصادقة التطبيق لا تعمل.

http://technet.microsoft.com/en-us/library/ee806870.aspx

او و

2) استخدامك لمصادقة خادم لخادم، وهذا هو المكان الذي يمكن أن يحدث فيه خطأ!هل تمت مزامنة ملف التعريف الخاص بك؟؟

بالنسبة لعام 2013 من خادم إلى خادم، تأكد من مزامنة عضويات المجموعة مع تطبيق خدمة ملف تعريف المستخدم.

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

http://technet.microsoft.com/en-us/library/jj219806.aspx

الآن هذا مطلوب حتى يعمل إعداد الخادم إلى الخادم!

تتيح مصادقة الخادم إلى الخادم خوادم قادرة على مصادقة من الخادم إلى الخادم للوصول إلى الموارد وطلبها من بعضها البعض نيابة عن المستخدمين.لذلك ، يجب أن يكون الخادم الذي يعمل على تشغيل SharePoint Server 2013 وأن يخدم طلب الموارد الواردة إكمال مهمتين:

لإعادة ترطيب هوية المستخدم ، يقوم خادم يمكنه إجراء مصادقة خادم إلى خادم الوصول إلى موارد SharePoint.يأخذ SharePoint Server 2013 المطالبات من رمز الأمان الوارد ويحلها إلى مستخدم محدد SharePoint.افتراضيًا ، يستخدم SharePoint Server 2013 تطبيق خدمة ملف تعريف المستخدم المدمج لحل الهوية.

ونتيجة ما سبق هي:

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

http://technet.microsoft.com/en-us/library/jj729797.aspx

النقطة المهمة هي الرمز المميز والمصادقة لا تعمل بشكل صحيح لأن الإعداد لديك خاطئ في نوع الأمان أو التكوين!معرفة ما قمت به سيحدد أين تسير الأمور على نحو خاطئ!من الواضح أنه يبدو أنه تم رفض مصادقة خادم إلى خادم نظرًا لعدم إرسال الرمز المميز بشكل صحيح.

إذا كنت تعتقد أن بروتوكول المصادقة صحيح، فيمكنك اتباع هذا الدليل بمجرد قراءة الروابط أعلاه:

http://technet.microsoft.com/en-us/library/jj655400.aspx

الرابط أعلاه يشرح ويوضح الخطوات من خادم إلى خادم لسيناريوهات محددة

لإنشاء ثقة بين خادمين (إنشاء ثقة بين الخادم والخادم الرئيسي.)

اتبع هذا الدليل!استخدام New-SPTrustedSecurityTokenIssuer

http://technet.microsoft.com/en-us/library/jj219695.aspx

آسف للنص الطويل والعديد من الروابط!نظرًا لأن خادمه إلى خادم والسجل عام/الإعداد يمكنني أن أقدم لك إجابة محددة!ولكن ما أعرفه هو أن المصافحة بين خادمين تسير بشكل خاطئ مما يعني أنك قد فاتك شيء ما أثناء الإعداد الأولي!نأمل أن تحل الروابط أعلاه مشكلتك بين المصافحة لتمرير بيانات الاعتماد الصحيحة للعمل بشكل صحيح!

Answer 2

كان لدي مشاكل مماثلة.بدلا من استخدام ClientContext أو TokenHelper، قمت بتبديل إلى SharePointContext الجديد الذي يمكنك قراءته هنا: http://blogs.msdn.com/b/kaevans/archive/2013/09/24/Inroducing-SharePintContext-For-Provider-Hosted-Sharepoint-apps.aspx

بمجرد أن أذهب إلى هذا التبديل، اختفى مشاكل 401 و 403.يستخدم SharePointContext الجديد tokenhelper الأساسي، لذلك تأكد من أن لديك أحدث إصدار من ملف Tokenhelper أيضا.

Answer 3

أعتقد أنني أعرف ما هي مشكلتك، ونقاط سجل الخادم إلى آلة العميل / الخادم لا تواجه وقت المزامنة. giveacodicetagpre.

قد واجهت خطأ مماثل في أيام قليلة، وكان القرار هو الحصول على خادم آلة الخادم والعميل في المزامنة. giveacodicetagpre.