يفرق بين مستخدمي ويندوز أصيل وأشكال مصادقة عند مصادقة ضد نفسه AD مع SharePoint 2010 باستخدام مطالبات المصادقة المستندة إلى

Question

وأنا أعمل حاليا على 2010 مشروع شير حيث البيئة هي الإعداد مع تطبيق ويب SharePoint باستخدام مطالبات مصادقة. يتم إنشاء تطبيق ويب على المنفذ 8081 باستخدام مصادقة Windows للمصادقة، وتمتد إلى المنفذ 80 باستخدام نماذج استنادا المصادقة.

ومقدم مصادقة النماذج هو الإعداد لاستخدام نفس الدليل النشط كموقع النوافذ المصادقة على أساس، وذلك باستخدام الإدخالات التالية في الملف web.config التطبيق (الإدخالات في الإدارة المركزية والخدمات رمزية الأمنية ملفات web.config كما جيدا ):

    <membership defaultProvider="i">
  <providers>
    <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    <add name="FBA_AD_MP" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADFBAConnectionString" enableSearchMethods="true" attributeMapUsername="userPrincipalName" />
  </providers>
</membership>

وباستخدام هذا الإعداد يعمل كما هو متوقع. وتعرض المستخدمين الذين يزورون تطبيق على المنفذ 8081 مع التحدي ويندوز القياسية المصادقة، يتم توجيه تلك على المنفذ 80 إلى نموذج تسجيل الدخول المخصصة. عند إضافة المستخدمين إلى الموقع عن طريق للخروج من أدوات إدارة مربع، وبحث لمستخدم معين مثل john.smith@mydomain.com عودة ضربتين، واحدة من مزود ويندوز المصادقة، واحدة من مزود أشكال المصادقة. واضاف كل من هؤلاء المستخدمين إلى موقع يكشف عن أن شير بتخزين اسم الحساب مع معرف إلحاق إلى الأمام. ويترجم المستخدم النوافذ المصادقة إلى i: 0 # .w | MYDOMAIN \ johnsmith، يتم تحويل المستخدم FBA إلى i: 0 # .F | fba_ad_mp | john.smith@mydomain.com

وهنا حيث تأتي المشكلة في أننا خلق مجموعات الموقع بكميات كبيرة باستخدام مخصصة لبناء أداة الذي يوزع جدول المدخلات، ويخلق مجموعات الموقع، ويضيف المستخدمين المناسب للموقع تم إنشاؤه حديثا باستخدام الطريقة التالية:

    private static void AddUser(SPSite site, String userName, String spGroupName)
    {
        try
        {
            SPUser spUser = site.RootWeb.EnsureUser(userName);

            if (spUser != null)
            {
                site.RootWeb.Groups[spGroupName].AddUser(spUser);
            }
        }
        catch(Exception ex)
        {
            SharePointManager.Counter.Warnings++;
            SharePointManager.Logger.Warn(String.Format("\t\tUnable to add user {0} to group {1} at site {2}: {3}", userName, spGroupName, site.RootWeb.Url, ex.ToString()));
        }
    }

والمعلمتين اسم المستخدم الذي صدر في هو، اقتداء، john.smith@mydomain.com. ومع ذلك، المستخدم إضافتها إلى الموقع دائما المستخدم النوافذ المصادقة على أساس، ط: 0 # .w | MYDOMAIN \ johnsmith

وكيف يمكنني تحديد أي موفر المصادقة على الانتخابات عندما تدعو EnsureUser حتى استطيع ان اؤكد ان تتم إضافة المستخدم الصحيح إلى الموقع؟

Answer 1

والمشكلة هي أن كلا من مقدمي عضوية التعرف على عنوان البريد الإلكتروني، ويعتاد النتيجة الأولى (AD). محاولة FBA_AD_MP: john.smith@mydomain.com - أن جملة يعمل في عناصر التحكم اسم المستخدم القياسية (باستخدام اسم الاختيار بدلا من الحوار البحث)، وأعتقد EnsureUser يعمل بنفس الطريقة

Answer 2

وباختصار تحتاج إلى تحويل SPUser إلى SPClaim باستخدام SPClaimProviderManager