تضمين التغريدة

هل هناك أي تحديث على ذلك؟

أنا أيضا أود الحصول على تحديث لهذا. تطلب مني شركتي إنشاء تطبيق جديد يتطلب القدرة على الاستعلام عن Active Directory عبر LDAP ولكن يبدو أن هذا غير ممكن حاليًا. هل هناك دعم مخطط لها ، هل يتم إسقاطها لصالح شيء آخر ، أم أنها تعمل بالفعل فقط ولم يتم توثيقها في أي مكان؟

سيكون من الرائع الحصول على نظرة جديدة وجديدة على تنفيذ LDAP ودعم Active Directory في .NET CoreFX.

نحتاج حقًا إلى حل Active Directory / LDAP يمكننا الاستفادة منه في .NET Core. سواء كان ذلك تطبيقًا نظيفًا أو منفذ System.DirectoryServices لا يهمني كثيرًا. هناك الكثير من تطبيقات Windows التي تركز على الأعمال التجارية والتي تحتاج تمامًا إلى مصادقة AD ، وستكون مصادقة LDAP نقطة مهمة رائعة لمطوري الأنظمة الأساسية.

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

تضمين التغريدة

لا أشعر بالحاجة إلى منفذ مباشر حقًا ، فنحن فقط بحاجة إلى طريقة للوصول إلى المصادقة [...] ضد Active Directory

من الجيد أن تعرف. لا تقرأ كثيرًا في ملصق من المنفذ إلى النواة الخاص بي الذي تقدمت به للتو. إنها مجرد طريقتي لتتبع الثغرات في عرض .NET Core الذي يمنع العملاء مثلك من نقل تطبيقاتهم إلى .NET Core.

تضمين التغريدة لا أعتقد بالضرورة أن هذا يجب أن يكون عنصرًا 1.0 بسبب نمطيته (وهو _ أصوات _ كما لو كان مقررًا لما بعد RTM على أي حال) ، لكنني أتطلع إلى ذلك. سيكون مانعًا من نقل Opserver بالنسبة لي ، ويسعدني جدًا المشاركة في مناقشات API إذا كان بإمكاننا الاستفادة. لدينا مجموعة كبيرة من حالات الاستخدام على جانب مسؤول النظام للأشياء التي قد تكون مفيدة ، ping إذا كان بإمكاني المساعدة.

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

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

لا أشعر بالحاجة إلى منفذ مباشر حقًا

لماذا ا؟ آسف أنا في حيرة من أمري. ألن يكون هذا هو الحل الأسهل للجميع وبما يتوافق مع مبدأ DRY؟
ومع ذلك ، إذا كان هناك سبب لكتابة واجهة برمجة التطبيقات بالكامل من البداية ، فإن بعض الاتساق مع واجهة برمجة التطبيقات القديمة (توقيعات الطريقة نفسها) سيكون أقل إرباكًا للمستهلك.

@ jasonwilliams200OK اسمحوا لي أن أوضح ، لقد قصدت حقًا DirectoryServices.ActiveDirectory على وجه التحديد. أعتقد أن المصادقة والأشياء المحيطة بها: على سبيل المثال ، عضوية المجموعة هي 95-99٪ حالة استخدام لمساحة الاسم. أعتقد أن المنفذ المباشر لتوقيعات _that_ مفيد جدًا. إذا تغيرت الضمانات الباقية لسبب ما ، فسأكون على ما يرام مع ذلك ، ولا بأس إذا جاء لاحقًا ... ستكون المصادقة جيدة للخروج من الباب في أسرع وقت ممكن لأن هذا مانع للكثيرين.

سيؤدي دمج وظيفة أساسية على الأقل للبحث عن مستخدمي Active Directory وتعيينهم بأدوار مخصصة مع ASP.NET 5 إلى تسهيل تطبيق مصادقة Windows في تطبيقات الويب ASP.NET. نحن بحاجة إلى هذه الوظيفة في موقع الإنترانت الخاص بنا.

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

إنه أيضًا مانع بالنسبة لي - أطلب الاستعلام عن المستخدمين والمصادقة عليهم.

توصلت إلى حل للمصادقة مقابل Active Directory في تطبيق ويب .NET Core rc1. عليك فقط تجاوز طريقة CheckPasswordAsync في فئة UserManager. اسمحوا لي أن أعرف ما هو رأيك.

تحتاج أولاً إلى إنشاء صفحة تسجيل مخصصة تسمح للمستخدم بإدخال اسم مستخدم AD بدلاً من عنوان البريد الإلكتروني وكلمة المرور. ينتقل اسم المستخدم هذا إلى خاصية UserName لفئة ApplicationUser التي تم إنشاؤها بواسطة قالب ASP.NET 5 عند اختيار مصادقة حسابات المستخدمين الفرديين. أيضًا ، سيتعين عليك تعيين خاصية كلمة المرور افتراضيًا إلى شيء يمرر التحقق الداخلي في فئة IdentityUser.

تستدعي وحدة التحكم في صفحة التسجيل الخاصة بي طريقة Web API 2 التي تبحث عن اسم المستخدم في AD وترجع JSON الذي يحتوي على معلومات AD لهذا المستخدم. لقد أضفت بعض الخصائص المخصصة إلى فئة ApplicationUser للاحتفاظ بمعلومات AD. سأقوم بنشر الرمز من مشروعي الأسبوع المقبل.

ثم أضف ملف فصل دراسي في مجلد الخدمات. قمت بتسمية ApplicationUserManager.cs المنجم. أضف الكود أدناه إلى ملف الفصل هذا.

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNet.Http;
using Microsoft.AspNet.Identity;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.OptionsModel;
using [YourApp].Models;

namespace [YourApp].Services
{
    public class ApplicationUserManager : UserManager<ApplicationUser>
    {
        public ApplicationUserManager(IUserStore<ApplicationUser> store, IOptions<IdentityOptions> optionsAccessor, IPasswordHasher<ApplicationUser> passwordHasher,
                                      IEnumerable<IUserValidator<ApplicationUser>> userValidators, IEnumerable<IPasswordValidator<ApplicationUser>> passwordValidators,
                                      ILookupNormalizer keyNormalizer, IdentityErrorDescriber errors, IServiceProvider services, ILogger<UserManager<ApplicationUser>> logger,
                                      IHttpContextAccessor contextAccessor)
        : base(store, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer, errors, services, logger, contextAccessor)
        {

        }

        public override async Task<bool> CheckPasswordAsync(ApplicationUser user, string password)
        {
            //Pass user.UserName and password to an ASP.NET Web API 2 method that 
            //does the Active Directory authentication and returns a bool.
        }
    }
}

ثم افتح ملف Startup.cs. أضف .AddUserManager() لاستدعاء AddIdentity في طريقة ConfigureServices كما هو موضح أدناه.

services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddUserManager<ApplicationUserManager>()
       .AddDefaultTokenProviders();

هذا يسمح لي على الأقل بإعداد التخويل المستند إلى السياسة / المطالبات أثناء انتظار دعم DirectoryServices.

أنا أعتمد على هذه المكتبة. إنه لأمر مخز لا أستطيع أن أخرج الآن.

ClintBailiff لا بد لي من الرنين هنا - لأن نقل كلمة مرور المستخدم عبر السلك مرة أخرى إلى تطبيق آخر في نص عادي فكرة سيئة _ حقًا. من فضلك ، لا تستخدم هذا النهج. إنها ثغرة أمنية.

terrajobst ، سيكون هذا مانعًا في نقل تطبيقاتي الكبيرة مثل Opserver - هل يمكننا من فضلك إعطاء الأولوية لهذا؟

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

سأدعم على الأقل توفير منفذ System.DirectoryServices.Protocols . لقد قمنا مؤخرًا بتحويل التعليمات البرمجية المتعلقة بـ LDAP إلى هذا لدعم نطاق أكبر من خوادم LDAP ، حيث إن مساحة الاسم System.DirectoryServices.ActiveDirectory تحب التحدث إلى خوادم AD فقط.

أفترض أنه سيكون من الممكن لمكتبة تابعة لجهة خارجية أن تقوم بتدوير هذا النوع من الدعم ، ولكن نظرًا لأنه موجود بالفعل في إطار العمل ، فإنني أتخيل أن المنفذ سيكون أبسط.

فريق WTF asp لا يوفر هذه الوظيفة الأساسية
هذه مشكلة مانع حقًا :(

أي تحديث على دعم LDAP في CoreCLR؟

أود أيضًا الحصول على تحديث حول هذا. سوف أقوم بتطوير تطبيق مؤسسة باستخدام ASP.NET Core يحتاج إلى مصادقة المستخدمين مقابل خادم AD.

سأبحث في نقل System.DirectoryServices إلى .NET Core لـ v1.1.0 (https://github.com/dotnet/corefx/milestones)

تضمين التغريدة
لا بد لي أيضًا من مصادقة المستخدمين من ADLDS ، يرجى أيضًا مراعاة System.DirectoryServices.AccountManagement

قبل عامين ، أخذت الشركة التي عملت بها كود مصدر مكتبة Novell (Mono) LDAP حتى يتمكن تطبيقنا من التحدث إلى أنظمة Active Directory و OpenLDAP و Oracle ، وقمنا بإضافة دعم لعناصر التحكم المُقسمة إلى صفحات وتحديث بعض إصلاحات TLS. لقد فعلنا ذلك كما أردنا التشغيل على Linux. تم إرسال PR مع التغييرات التي أجريناها إلى المالكين. نظرًا لأننا نريد الآن الوصول إلى CoreCLR ، فقد احتاجت المكتبة إلى التحويل إلى RC2. بدأ العمل هنا https://github.com/VQComms/CsharpLDAP/pull/1 ، هناك 17 خطأ مترجم متبقي يحتاج إلى معالجة. إنها بشكل أساسي Thread.Abort ، ThreadInterruptedException ، لتحل محل تدفقات TLS من Mono إلى CoreCLR SslStream إذا كان أي شخص مهتمًا ويحتاج إلى دعم LDAP لـ CoreCLR فلا تتردد في المساعدة.

لقد أكدت أن مشروع ASP.NET Core Web Application (.NET Framework) RC2 يمكن أن يشير إلى مكتبة فئة تستخدم System.DirectoryServices.AccountManagement. يمكنني تشغيله فقط عندما يتم إنشاء كل من تطبيق الويب ومكتبة الفصل الدراسي باستخدام التحديث 2 لـ VS 2015 وكلاهما يستخدم .NET Framework 4.6.1.

فقط لترديد مشاعر الآخرين ، نحن ميتون في نقل المياه دون أن نكون قادرين على الاستعلام عن LDAP وما شابه.

@ h3smith
انظر رسالتي السابقة. مع إصدار RC2 ، يمكنك الآن الرجوع إلى مكتبة فئة تستخدم System.DirectoryServices.AccountManagement .

ليس على Netstandard.

ومع ذلك ، كما أقول ، فإننا نعمل على إنجاح هذا الأمر. نأمل أن يكون
شيء في حوالي 2-3 أسابيع

في يوم الجمعة ، 17 يونيو 2016 ، كتب Clinton Bailiff [email protected] :

@ h3smith https://github.com/h3smith
انظر رسالتي السابقة. مع إصدار RC2 ، يمكنك الآن الرجوع إلى ملف
مكتبة الفئة التي تستخدم _System.DirectoryServices.AccountManagement_.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

أي تحديثات على هذا؟ أحتاج إلى مصادقة المستخدم المتصل ، عندما يستخدم المستخدم تطبيق الويب الزاوي على الشبكة المحلية ، وقم بتسجيل الدخول إلى AD ، واستدعاء طريقة تحكم WebAPI (بدون إدخال المستخدم كلمة المرور في متصفح الويب) في aspnet core RC2. المستطاع؟ ممكن قريبا؟

للقيام بذلك ، تحتاج فقط إلى استخدام مع أوراق الاعتماد في طلبات http من العميل. ثم يمكنك الحصول على معلومات المستخدم والمطالبات في وحدات التحكم الخاصة بك باستخدام User.Identity.
يعمل هذا في ie و chrome ولكن مع Firefox ، سيتم عرض نافذة منبثقة تلقائيًا إلى Le اكتب المستخدم في مستخدم windows وكلمة المرور

لقد واجهنا نفس المشكلة (على سبيل المثال ، محاولة استخدام خادم LDAP كمخزن مستخدم) منذ حوالي شهرين. لم نتمكن من إيجاد أي حل بخلاف نقل مكتبة Novell LDAP (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) إلى .net core (انظر هنا https://github.com/dsbenghe/Novell. الدليل. ldap.net قياسي). تم نشر حزمة nuget. نحن نستخدم المكتبة مع خادم OpenDJ LDAP (يجب أن يعمل مع أي خادم LDAP) - لا توجد مشاكل في 1.5 شهر من الاستخدام.

dsbenghe ، لقد حصلنا للتو على تجميع Novell LDAP lib الخاص بنا على netstandard ، يحتوي نظامنا على الترحيل أيضًا. تم ذلك بواسطة igorshmukler . هل ترغب في المقارنة والتعاون؟ لدينا العمل قيد التقدم هنا https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

dsbenghe شكرًا لعملك على تنفيذ .NET Core له.
بعد الحصول على حزمة nuget ، قمت بإنشاء الكود التالي لاختبار ما إذا كانت كلمة مرور ActiveDirectory للمستخدم صحيحة

using Novell.Directory.Ldap;

private async Task<JsonResult> LoginActiveDirectory(LoginModel model)
{
    var user = await _userManager.FindByNameAsync(model.Username);
    if (user != null)
    {
        var result = AuthenticateWithActiveDirectory(model.Username, model.Password);
        if(result == string.Empty)
        {
            await _signInManager.SignInAsync(user, false);
            return Json(new LoginResult {Success = true});
        }
        return Json(new LoginResult { Success = false, Message = result });
    }

    return Json(new LoginResult { Success = false, Message = "User not found in local database" });
}

يستدعي AuthenticateWithActiveDirectory:

private string AuthenticateActiveDirectory(string username, string password)
{
    const int ldapVersion = LdapConnection.Ldap_V3;
    var conn = new LdapConnection();

    try
    {
        conn.Connect(_loginSettings.LdapHost, _loginSettings.LdapPort);
        conn.Bind(ldapVersion, $"{_loginSettings.LdapDomain}\\{username}", password);
        conn.Disconnect();
    }
    catch (LdapException e)
    {
        return e.Message;
    }
    catch (System.IO.IOException e)
    {
        return e.Message;
    }

    return string.Empty;
}

ويستخدم فئة مساعدة بسيطة للسماح للتطبيق الزاوي بمعرفة ما يجري

public class LoginResult
{
    public bool Success { get; set; }
    public string Message { get; set; }
}

بالنسبة إلى UWP ، هناك طلب لهذه الميزة في UserVoice لدينا: https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cctquerecjimuphaus الذي سيعمل على دعم System.DirectoryServices لـ .NET Core.

لا استطيع الانتظار! إيتا؟ مواصفات التصميم؟

عندما يتم نقله أخيرًا ، هل سنتمكن من الوصول إلى:

using(var context = new PrincipalContext(ContextType.Domain, "Domain"))
     return context.ValidateCredentials("user", "password");

أعلم أن هناك بعض العيوب الطفيفة داخل مساحة الاسم هذه ، لكنها لا تزال مفيدة جدًا.

GArrigotti في الاختبار ، عادةً ما يكون استخدام LdapDirectoryIdentifier أسرع من PrincipalContext.

using System.DirectoryServices.Protocols;
/////////
try
{
    using (LdapConnection conn = new LdapConnection(new LdapDirectoryIdentifier(domain)))
    {
        conn.Bind(new System.Net.NetworkCredential(username, password, domain));
        return true;
    }
}
catch (LdapException e)
{
    return false;  
}

هل هناك وقت مقدر للوصول؟ يمكنني استخدام هذا في نظام من المقرر أن يكتمل في نهاية هذا الشهر ...

johnkwaters هل هناك سبب يمنعك من وضع رمز AD في مكتبة الفصل؟ واجه بعض الأشخاص (بما فيهم أنا) مشكلات في الرجوع إلى مكتبات الفئات القديمة في تطبيق ASP.NET Core. ولكن لا توجد مشكلات إذا قمت بإنشاء تطبيق الويب ومكتبة الفصل الدراسي في VS 2015 Update 3 واستهدفت .NET Framework 4.61 في تطبيق الويب ومكتبة الفصل الدراسي.

هل هناك سبب يمنعك من وضع رمز AD في مكتبة الفصل؟

هل تقصد PCL متبوعًا بـ "imports": "portable-net45+win8" في project.json لـ .NET Core TxM؟ سيتطلب ذلك وجود تجميعات مرجعية Mono PCL على نظام Unix وليس حلًا "أساسيًا خالصًا" ، والذي يمنح الاكتفاء الذاتي على Unix. إنه اختراق جيد لإسكات المحول البرمجي ، لكن العمل فقط من خلاله ومن خلاله إذا كان لدى CoreFX BCL التنفيذ المقابل. كقاعدة عامة ، فإن project.json بدون "imports" لـ netcoreapp / netstandard1.x هو الأفضل دائمًا. على سبيل المثال https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

أي تحديث على ETA؟ أين يمكنني الذهاب إلى الخدمة الذاتية هذا السؤال المتكرر؟

_ Really_ أتطلع إلى هذه الميزة!

أتطلع إلى هذه الميزة أيضًا !!

أتطلع إلى هذه الميزة أيضًا !!

أنا أيضًا في حاجة ماسة لهذه الميزة!

يا رفاق ، هل يمكنكم جميعًا إضافة ردود أفعال على المنشور الرئيسي؟

أو استخدم المكتبات التي تم وضعها على nuget بواسطة شخصين منفصلين. انها
كل OSS. إذا لم تعجبك الحزمة ، أرسل PR

في 8 سبتمبر 2016 الساعة 12:19 ، أرسل ميخائيل أورلوف إخطارات github.com
كتب:

يا رفاق ، هل يمكنكم جميعًا إضافة ردود أفعال على المنشور الرئيسي؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 لـ jchannon Novell LDAP. لقد دفعنا إلى المضي قدمًا ولم يأخذ أي تغييرات تقريبًا في تنفيذ LDAP الخاص بنا. أعني أنك تستخلص بشكل صحيح ؛)

نعم ، انتهى بي الأمر باستخدام jchannon Novell LDAP أيضًا ، لقد نجح الأمر.

إذا لم أقل ذلك من قبل ، فإليك الفرع كله على https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

يعمل بشكل جيد لمتطلباتنا في الوقت الحالي ...

@ h3smith johnkwaters ، أي مشاكل لا تتردد في إثارة مشكلة 😄

قررت أن أجرب مع Novell ، تبدو العينات جيدة بما يكفي ولكني لا أعرف كيفية طرد (إزالة) عضو مستخدم من مجموعة باستخدام Novell LDAP.
لا يمكنني تغيير كلمة المرور الخاصة بي على MSAD LDAP لأنني لا أستطيع رؤية كلمة مرور المستخدم ولم يتم تعيينها على خادم LDAP.

حقا بحاجة الى هذا!

joshfree أو أي شخص آخر يعرف ...
نحن نتطلع لبدء مشروع جديد يحتاج إلى الوصول إلى ActiveDirectoryServices.AccountManagement سؤال ، هل المنفذ مستهدف إما 1.1 أو 1.2؟

إنه ليس جزءًا من 1.1 (الذي على وشك الانتهاء). tquerec ، هل يمكنك من فضلك التعليق على خططك هنا؟

سم مكعب: danmosemsft

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

مجرد تصويت آخر. من الصعب القيام بالاستثمار لبناء أنظمة من فئة المؤسسات على .NET Core عندما تفتقر إلى وظائف المؤسسة الأساسية. يعمل مشروع Novel ، لكن لا يرقى إلى المستوى المطلوب.

بعد تصويت آخر. سأردد نفس العبارة التي مفادها أن هذا جزء لا يتجزأ من إنشاء أي تطبيق مؤسسي.

nevcoBpalacio أعتقد أنهم يحاولون دفعنا لاستخدام الدليل النشط azure

لن ينجح ذلك أبدًا مع أولئك الذين يستخدمون اتفاقيات الشركات التي تتطلب بقاء الخدمات في المنزل.

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

نعم ، الرجاء إضافة System.DirectoryServices إلى .NET Core!

لدينا خطط لنقل System.DirectoryServices.Protocols خلال العام المقبل. في هذه المرحلة لا يمكنني تقديم تاريخ أكثر ثباتًا. ليست لدينا خطط حتى الآن لنقل System.DirectoryServices أو System.DirectoryServices.AccountManagement ولكني مهتم بقياس الاهتمام. هل توجد ميزات لمساحات الأسماء تلك التي يستخدمها الأشخاص والتي لا يمكن حلها باستخدام البروتوكولات؟

tquerec لست على دراية بالبروتوكولات. لدينا مشروع للقيام بخدمة Active Directory الذاتية للقيام بإلغاء تأمين الحساب وإعادة تعيين كلمة مرور الحساب. نستخدم UserPrincipal في المشروع واستدعاء طرق مثل FindByIdentity و UnlockAccount و SetPassword ،، ExpirePasswordNow ،.
لست متأكدًا مما إذا كان يمكن القيام بذلك على البروتوكولات ولكن يبدو أن البروتوكولات هي تطبيق ذو مستوى أقل مقابل AccountManagement هو تجريد أفضل للعمل مع ActiveDirectory.
شكرا
Rockmeister

يجب أن يكون nevcoBpalacio بالتأكيد أكثر من مجرد تصويت. أعتقد أن هذا يحتاج حقًا إلى مزيد من الأولوية.

CalebMacdonaldBlack سيكون مفيدًا إذا كان بإمكانك الإجابة على سؤال tquerec حول أنماط الاستخدام ولماذا هو المطلوب. المزيد من الأصوات المؤيدة أو "أوافق / إنه أمر مهم" بدون سيناريوهات لن تساعد في رفع الأولوية في هذه اللحظة ... شكرًا!

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

tquerec أحتاج حقًا إلى System.DirectoryServices.AccountManagement حتى أتمكن من مصادقة مستخدمينا مقابل الدليل النشط وتفويضهم في المجموعات التي يمكنهم الوصول إليها.

أتفق تمامًا مع h3smith .. لقد احتجنا إلى هذا لـ v1 وبدلاً من ذلك اضطررنا إلى السير في مسار الرواية ، الذي قمنا بتجميعه معًا (خاصة بتات النسخ المتماثل) ويسبب لنا حزنًا بسبب النفقات العامة للصيانة وما إلى ذلك .. هذا يجعل .NETCore تبدو سيئة كأثر جانبي ..

تضمين التغريدة

كنا بحاجة إلى هذا الإصدار v1

هل تقصد .NET Core v1؟ - يتم ذلك وشحنه. نحن نعمل على 1.2 الآن. او هل قصدت شئ اخر؟

بدلا من ذلك يضطرون للذهاب في طريق الرواية

ماذا يعني ذلك؟ (عذرًا ، ليس لدي أي سياق في DirectoryServices ، لكني أرغب في فهم ما ينقصنا من وجهة نظر السيناريوهات)

karelz فقط ابحث في هذا الموضوع عن كلمة "رواية" وسترى ما أعنيه. علق مطور آخر (dsbenge) في فريقي (مع آخرين) على الفجوة التي أدت بنا إلى استخدام الرواية. [هنا رابط التعليق أعلاه https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

نعم ، لقد قصدت بالفعل .NET Core v1 الذي تم شحنه بالفعل ، لقد عملنا على حلنا لأكثر من عام وكنا بحاجة إلى حل جيد لخدمة DirectoryServices في ذلك الوقت .. لقد اصطدمنا بالحائط وبالتالي لم يكن لدينا خيار سوى استخدام الرواية .

l Liquidboy شكرا للرابط - إذا كان في Mono ، يجب أن نكون قادرين على إعادة استخدام كود المصدر في .NET Core AFAIK. tquerec بالنظر إلى الاهتمام ، هل هو شيء قد يفكر فيه فريقك؟

tquerec : نحتاج إلى ما يلي:
System.DirectoryServices و System.DirectoryServices.AccountManagement و System.DirectoryServices.ActiveDirectory و System.DirectoryServices.Protocols.

تلك مطلوبة للاتصال بالمستخدمين والمجموعات والسمات Active Directory (وخوادم LDAP الأخرى) وإدارتها تمامًا كما هو موضح في الردود أعلاه أيضًا. من المهم أن يكون لديك هذه الميزات في .Net Core!

أنا أتفق مع الآخرين. أحتاج إلى هذا لنقل أي من تطبيقاتنا التي تصادق على ActiveDirectory إلى .NET Core. هذا أمر أساسي جدًا ، يجب أن يكون بالتأكيد في أقرب وقت ممكن. إنه مانع نقل الكثير من الأشياء.

تحتوي صفحة خارطة طريق .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) على هذه الخطة لـ .NET Core 1.2: "تحقيق تكافؤ .NET Core مع .NET Framework و Mono من أجل مجموعة كبيرة من الأنواع الأساسية ".

أعتقد أن نقل System.DirectoryServices يناسب هذه الخطة جيدًا ، ويجب أن يكون بالفعل جزءًا من الإصدار 1.2. فقط 5 سنتات (يورو) الخاصة بي :)

فقط للتوضيح: تم اختيار واجهات برمجة التطبيقات التي تم نقلها في الإصدار 1.2 بناءً على بيانات الاستخدام (ونادرًا ما تكون معقدة) -weshaggarddanmosemsft هل يمكنك التناغم مع التفاصيل ، لماذا لم نقم بتضمين System.DirectoryServices؟

قائمة التجميعات التي اخترنا مطابقتها هنا . سيتعين على weshaggard أن يذكرني بكيفية اختياره لتلك القائمة. (لدى Mono خدمات دليل S.)

أعتقد أنك ستكون قادرًا على القيام بكل ما هو مطلوب تقريبًا فيما يتعلق بالتحدث مع ActiveDirectory (وخوادم ldap الأخرى) باستخدام System.DirectoryServices.Protocols ، ولكن سيتعين على الكثير من الأشخاص إعادة كتابة التعليمات البرمجية الخاصة بهم لاستخدام بروتوكولات S.DS.

أنا شخصياً أفضل أن يقوم MS بمنفذ S.DS.Protocols و MS أو المجتمع لإنشاء مكتبة سهلة الاستخدام لإدارة المستخدم / المجموعة علاوة على ذلك.

قائمة التجميعات التي اخترنا مطابقتها هنا. سيتعين على weshaggard أن يذكرني بكيفية اختياره لتلك القائمة. (لدى Mono خدمات دليل S.)

تم إجراء البذر الأولي من تقاطع ملفات تعريف Xamarin مع .NET Framework. ملفات تعريف Xamarain (وهي مجموعة فرعية من mono) لا تدعم DirectoryServices ولهذا السبب لم يكن ذلك في التقاطع.

ما الذي يمكننا فعله للجدل في هذا؟ يعد عدم القدرة على استخدام نظام المصادقة الأكثر شيوعًا في تطبيقات Microsoft بمثابة مانع إلى حد ما ، أليس كذلك؟ هل التركيز على Azure هنا و AAD بدلاً من ذلك؟ أم أن مانع هذا النقل عبر المنصات هو أكبر مجهول للبروتوكولات؟

هل هناك طريقة يمكننا من خلالها زيادة الأولوية هنا؟ الإصدار 2.0 بعيد جدًا ، وهذا أمر مؤسف حقًا إذا نجح كل شيء آخر ، لكن لا يمكننا مصادقة المستخدمين. هذا هو الباب الأمامي الافتراضي للعديد من التطبيقات. IMO ، من حيث الأولوية ، يختلف قليلاً لأنه ليس مانعًا جزئيًا ، ولكنه غالبًا مانع كامل بطبيعته.

لا أعتقد أن هناك أي خلاف حول أننا نريد دعم ذلك في .NET Core ، والذي يختلف عن كونه جزءًا من .NET Standard ، إنها مجرد مسألة وقت. يمتلك tquerec المنطقة وسيكون الشخص الذي يتحدث عن ذلك.

سأل شخص ما من .NET Foundation ، ولكن مساحات الأسماء التي نستخدمها على وجه التحديد هي:
System.DirectoryServices ، System.DirectoryServices.Protocols ، System.DirectoryServices.AccountManagement

لذا ، tquerec ، كيف يمكننا

شكرا جزيلا!

[تم التحديث بمزيد من المعلومات منtquerec]
التقيت مع tquerec يوم الاثنين. أنا مدين للجميع بالكتابة. باختصار:

• نظام. يمكن تنفيذ DirectoryServices على نظام Windows فقط (يستدعي Windows DLL حيث تستمر جميع عمليات التنفيذ) ، وهو غير معروف تمامًا لنظامي Linux / Mac
• System.DirectoryServices. AccountManagement يجلس على رأسه ، لذلك يمكن أيضًا تنفيذه لنظام Windows فقط ، وغير معروف لنظام التشغيل Linux / Mac
• System.DirectoryServices. ActiveDirectory قابل للتنفيذ على Windows فقط (يستدعي الكثير من واجهات برمجة التطبيقات الخاصة بنظام Windows)
• System.DirectoryServices. يجب أن تكون البروتوكولات بسيطة بشكل معقول لنظام التشغيل Windows والمزيد من العمل لنظام التشغيل Linux (نحتاج إلى العثور على مكتبة LDAP لاستخدامها).
  نحن نحاول معرفة كيفية تمويل العمل من خلال tquerec - من الناحية المثالية بالنسبة لـ 1.2 ، ولكن دون وعود حتى الآن. أتوقع أن يستغرق القرار أسبوعين على الأقل.

أسئلة للجميع :

• هل نطاق Windows أعلاه مقبول فقط لحالات الاستخدام الرئيسية؟ (Sys.DirSer و Sys.DirSer.AccountManagement and Sys.DirSer.ActiveDirectory)
• إذا كان Sys.DirSer.Protocols Linux يأتي بعد 1.2 أو يعتمد على مساهمات المجتمع ، فهل سيكون هذا مانعًا رئيسيًا؟

karelz System.DirectoryServices.ActiveDirectory يعتمد على عدد كبير من واجهات برمجة التطبيقات الخاصة بنظام Windows ، لذا فهو يقع في نفس المجموعة مثل S.DS و S.DS.AM.

karelz لست متأكدًا مما تقصده بحل windows فقط لـ 1.2. لدينا بالفعل حل windows فقط يعمل.

"frameworks": {
    "net452": {
      "frameworkAssemblies": {
        "System.DirectoryServices": "4.0.0.0",
        "System.DirectoryServices.AccountManagement": "4.0.0.0"
      }
    }
  },

@ rock-meister أعني .NET Core. الشخص الذي ذكرته يستهدف .NET 4.5.2+ "الكامل".

نعم ، دعم Windows فقط هو أداة فك تشفير ضخمة بالنسبة لنا. يمكننا القيام بكل العمل من أجل نقل .NET Core وتوسيع دعم النظام الأساسي "مجانًا" لاحقًا ، عندما تعمل البتات الأساسية. ليس حق مانع حتى _ البدء_ في المنفذ ضخمًا. رحيل ذلك هو فوز كبير.

كونك متجر Windows ، سيكون هذا فوزًا كبيرًا هنا أيضًا. الكثير من الشركات الكبيرة تعتبر هذا فوزًا كبيرًا! شكرا لمواكبة المعلومات الخاصة بك. يبقينا على اطلاع. شكرا.

@ karelz شكرا للتوضيح. نعم ، يناسبنا تحديد نطاق Windows فقط لـ 1.2.
Rockmeister

System.DirectoryServices.Protocols مع دعم Linux / LDAP هو الأولوية القصوى للعمل الذي نقوم به ..

ملاحظة: يبدو أن تحديد نطاق النوافذ فقط يتعارض مع أهداف. netcore / .netstandard

لقد قمنا بالتبديل من استخدام System.DirectoryServices إلى استخدام System.DirectoryServices.Protocols في الوقت السابق حتى نتمكن من دعم خوادم غير AD LDAP. سيكون الوصول إلى مساحة اسم البروتوكولات خطوة أقرب للسماح لنا بنقل الكود الخاص بنا إلى .NET core.

ومع ذلك ، إذا كان هذا خاصًا بالنظام الأساسي ، فسيقل استخدامنا. إحدى النقاط الرئيسية عند الرغبة في الانتقال إلى .NET core هي إمكانية نقل النظام الأساسي. ربما لا نزال بحاجة إلى انتظار ذلك.

بالنسبة لنا ، كان الوصول إلى .NET Core هو القدرة على الاستفادة من Docker وأن نكون محايدًا تمامًا للنظام الأساسي. لذلك لن يكون من المفيد أن تكون عالقًا مع Windows فقط مع دعم LDAP.

شكرا للمناقشة داخليا.

تصويتي يذهب مع طريق منصة مستقلة 🦃

يجب أن أتفق مع التعليق الحيادي للمنصة ، بقدر ما يؤلمني أنه لا يمكنني استخدام النواة حتى يتم تحقيق ذلك. أعتقد أن هذا شيء يجب مراجعته على مستوى أعلى. الشيء الذي لا أحصل عليه هو تعقيد المفهوم؟ هناك العديد من حلول الدليل ، AD ، Novell ، إلخ ... هذا يستدعي حل واجهة عبر النظام الأساسي (غير محدد) ... إجازات سعيدة!

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

نعم ، موافق ، يجب أن يكون NET Core عبر الأنظمة الأساسية ويجب أن تعمل الميزات / واجهات برمجة التطبيقات على جميع الأنظمة الأساسية المدعومة!
لذلك إذا كان سيتم نقل / تنفيذ System.DirectoryServices.Protocols أولاً ، فيجب أن يعمل أيضًا على Linux.

أوافق على أنه من الناحية المثالية ، يجب أن يكون الحل المستقل للنظام الأساسي هو الهدف. على الرغم من عدم وجوده على Windows ، إلا أنه يمثل مانعًا لكثير من المطورين الذين يرغبون فقط في تجربة النظام الأساسي في بيئة شركة (AD) ، مثلي. لهذا السبب سأرحب بحل Windows فقط في الوقت الحالي.

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

أتصور أن 99.9٪ من المطورين الذين يحتاجون إلى الاتصال بـ Active Directory يفعلون ذلك في بيئة مؤسسة حيث يطورون على مربعات Windows.

نحن نناقش التمويل من جانبنا (نتوقع التحديث في غضون أسبوعين تقريبًا) ، هذه أولوية قصوى حاليًا من واجهات برمجة التطبيقات التي لم تعد جزءًا من .NET Standard 2.0.

هل يوجد أشخاص حولك على استعداد للمساعدة / المساهمة في تطبيق Windows و / أو تطبيق Linux؟ (يمكننا إسقاط الكود من سطح المكتب وسيتطلب الأمر مزيدًا من التدليك للبناء + بعض الاختبارات)

karelz أحب المساهمة في جانب Linux من الأشياء. نحن بحاجة إلى هذا الدعم لكل من مصادقة Windows وغير المصادقة على Windows (محليا). هذا مانع بالنسبة لنا ، ونحن نستهدف .NET core لمشروعنا عبر الأنظمة الأساسية (كان سابقًا Mono على جانب Linux و .NET على جانب Windows).

نرغب في المساعدة حيثما نستطيع ، دون أدنى شك.

أرغب في المساعدة ولكني متأكد من أنكم يا رفاق أكثر خبرة مني ولن أكون ذا فائدة.

karelztquerec ، يسعدني مساعدتك في الاختبار على Windows وفي المستقبل على Linux. لقد اشتركت في سلسلة الرسائل ، لذا ما عليك سوى الرد هنا أو ذكرني للتواصل عندما تريدني للمشاركة. شكرا لعملك في هذا. لقد طال انتظارها ، وحتى لو كانت تزايديًا ، فستكون خطوة جيدة لزيادة اعتماد NET Core.

أعتقد أن "Windows الممتد" هو هدف جيد في البداية ، "ممتد" بمعنى أنه يعمل على NanoServer وفي الحاويات (على سبيل المثال ، الأجهزة غير المرتبطة بالمجال التي لا يمكنها تشغيل .NET بالكامل CLR). سيعطيك هذا ربحًا سريعًا ، ونقطة بداية للعمل للخلف لتنفيذه على خوادم أخرى.

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

إليك ما نخطط للقيام به:
سيساعدناianhays على بدء المشروع في CoreFX repo (أضف بعض الكود المصدري ، وأظهر أمثلة عن كيفية القيام بذلك ، ونصحك بإعداد الإنشاء ، والتعبئة ، وتحضير المشروع لمنافذ Linux / Mac المستقبلية ، وما إلى ذلك).
سنبدأ بتطبيق Windows فقط (نرحب بالمساهمات). لن نتخذ أي تغييرات وظيفية في التنفيذ أو سطح واجهة برمجة التطبيقات في هذه المرحلة ما لم تكن ضرورية للمنفذ إلى NET Core.
ستكون الخطوة التالية (الموازية المحتملة) هي إضافة الاختبارات. يجب أن نبدأ المناقشة مع tquerec حول تصميم اختبار (.NET Framework مغلق المصدر) الحالي إذا كان هناك أي شيء يمكننا الاستفادة منه ، أو إذا كان علينا البدء من نقطة الصفر.
لاحقًا ، يمكننا التركيز على منافذ Linux / Mac.

gortok @ h3smithCalebMacdonaldBlack @ SOM-fermonte ، وأي شخص آخر مهتم ، سنكون سعداء بتلقي مساهماتك بمجرد أن تبدأ ianhays هذه الجهود (ETA: منتصف الأسبوع المقبل على ما أعتقد). إذا كان لديك أي أسئلة أو اقتراحات ، فيرجى إخبارنا بذلك.

هل يسمح هذا العمل أيضًا للمكتبات مثل SqlClient بأداء مصادقة Windows عند التشغيل على Linux مع الاتصال بخادم SQL الذي يتطلب مصادقة Windows؟

هذا هو أحد العوائق التي أحاول أن أتمكن من نقل الأشياء إلى .NET Core الذي يعمل على Linux. تسمح جميع خوادم Microsoft SQL الخاصة بنا بالاتصال فقط عبر معرف الخدمة (غير التفاعلي) الموجود في AD.

blgmboy. مشكلتك هي مثال رئيسي على سبب الحاجة إلى "فحص" الأشياء لضمان التوافق الحقيقي عبر الأنظمة الأساسية مع النماذج المقترحة الجديدة. إذا كان لديك المزيد من السيناريوهات ، أعتقد أن بيئتك هي مثال جيد لكيفية عبور الأشياء ويجب عليك سرد أي مشاكل أخرى تواجهها مع جزء AD من Core.

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

إنه أيضًا مانع للعرض لاستخدام شيء مثل EF Core والذي سيكون له نفس المشكلة في النهاية.

تم الآن دمج System.DirectoryServices في CoreFX. والخطوة التالية هي إنشاءه لـ .NET Core - Windows وإضافة الاختبارات.

شكرا ايان. من الجيد أن نرى بعض الجاذبية في هذه القضية!

شكرا ايان!

خطة التنفيذ المحدثة: تحرير: تم الانتقال إلى أعلى مشاركة في هذا العدد لتحسين قابلية الاكتشاف

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

تحتوي مساحات الأسماء System.DirectoryServices على مثل هذه الوظائف المهمة لتطبيقات Windows للمؤسسات المحلية ، وهي رائعة للغاية لمشاهدة بعض التقدم في هذه المشكلة. ثابر على العمل الجيد.

لقد أصلحت المصادر ويتم الآن إنشاء System.DirectoryServices. يجب أن أرسل PR قريبًا.

شكرا tquerec للمساهمة في الجولة الثانية!
هل هناك أي متطوعين للمساعدة في مساحتي الأسماء أو الاختبارات المتبقيتين؟ ( gortok @ h3smithCalebMacdonaldBlack @ SOM-fermonte)

@ jay98014 لديه علاقات عامة هنا https://github.com/dotnet/corefx/pull/15324 لإضافة المزيد من الدعم والحصول على البروتوكولات / بناء إدارة الحساب.

لما يستحق ، لقد قمت بتجربة System.DirectoryServices.Protocols مؤخرًا ووجدت أن العديد من سيناريوهات System.DirectoryServices البسيطة ليس من الصعب تقليدها مع System.DirecotryServices.Protocols. بناءً على ذلك ، أعتقد أن الحصول على نظام التشغيل عبر النظام الأساسي لكل من S.DS و S.DS.AM يمكن أن يكون ذا أولوية أقل نظرًا لأن النظام متعدد المنصات System.DirectoryServices.Protocols يمكن أن يكون حلًا قابلاً للخدمة للعديد من المستخدمين.

بالطبع ، هذا يعني أن الحصول على System.DirectoryServices.Protocols يعمل كحل LDAP عبر الأنظمة الأساسية يظل أولوية عالية.

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

نعم ، أعتقد أن لدينا جميع خدمات DirectoryServices ، ولكن ليس لدينا أي اختبارات - مما يمنعنا من شحن الحزمة على أنها مستقرة ومن إدخال تحسينات على قاعدة الكود (إصلاحات الأخطاء والتحسينات وما إلى ذلك).
إذا كان بإمكانك تجربته على البناء من المصدر ، فسيكون ذلك رائعًا. إذا كنت تريد (أو أي شخص آخر) مساعدتنا في إضافة الاختبارات ، أو بدء تشغيل منفذ Linux ، فسيكون ذلك أفضل :)

مرحبا جميعا،

نحن نستعد لبدء مشروع مؤسسي يتطلب دعم Active Directory لأننا داخليون بنسبة 100٪ في مجالنا. هل يمكن لشخص ما تقديم حالة هذه المشكلة والتوقعات للإصدار الأساسي التالي؟ أعتذر ، لكنني جديد على مجتمع GitHub ولا أفهم بعد جميع المصطلحات المختلفة ومعلومات الحالة.

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

شكرا لك مقدما!

karelz لهذا السؤال ، لكنني أعتقد أن الإجابة هي أن هذا غير متوقع حاليًا في إصدار 2.0 ، حيث ليس لدينا مطور مجدول لذلك. مساهمات المجتمع موضع ترحيب. لا يحتاج إلى شحن _in_ الإصدار 2.0 ، يمكنه الخروج على NuGet في أي وقت يكون جاهزًا للشحن.

في احسن الاحوال! أجبت على سؤالي.

شكرا.

nevcoBpalacio هل من مصلحة في الحصول على مساهمة؟

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

Nevcobpalacio ، إذا كنت تستخدم vs17 ولا تتطلب عرضًا متقاطعًا ، فيمكنك الاقتراب قليلاً مما تريده باستخدام قالب تطبيق الويب الأساسي الذي يستهدف إطار. قم بتدوير البرامج الوسيطة الخاصة بك للقيام بذلك في غضون ذلك. من ما رأيته ، يجب أن ينتقل الرمز نفسه إلى استهداف .net core بمجرد توفر ذلك ، إلا أنك ستستخدم حزمة nuget وإسقاط المرجع. آمل أن تساعد هذه المعلومات في وضع مشروعك على المسار الصحيح.

@ los93sol شكرا على هذا الاقتراح. تتمثل مناقشاتنا الأولية في بنائه مشابهًا لذلك الاقتراح وجعله وحدة أدوات متوسطة يمكننا "قطعها" إلى أي مكان في Nuget لاحقًا. اشكرك كثيرا!

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

شكرا.

هل يعمل أي شخص حاليًا على إضافة الاختبارات المفقودة أو على نقل System.DirectoryServices.Protocols إلى Linux / Mac؟

pasikarkkainen AFAIK لا توجد مثل هذه الجهود النشطة في الوقت الحالي من فرق Microsoft (والتي قد تتغير أو لا تتغير في المستقبل القريب). لم أر أي شخص من المجتمع يبدأ العمل عليه أيضًا.
هل أنت مهتم بالمساهمة أو مهتم فقط بالوضع؟

karelz يبدو أنهم يستهدفون DirectoryServices لإصدار .NET Core 2.0 هذا الصيف.

اقتبس من shanselman

AD - تمامًا ، هذه فجوة إذا كنت تريد استدعاء LDAP مباشرة. يمكنك بالتأكيد المصادقة ضد Windows Auth NOW. نخطط لأن يكون لدينا مساحة اسم DirectoryServices لـ Core 2.0 على وجه التحديد في الإطار الزمني الصيفي

=> https://github.com/aspnet/Home/issues/2022#issuecomment -299536123

نعم ، هذا يتماشى مع مناقشات المدخل التي سمعتها. لم أكن متأكدًا مما إذا كانت معلومات عامة ومدى التزامها بها (ومن). أعتقد أنه من الآمن القول ، إنه يخضع لدراسة قوية للغاية ومن المرجح أن يحدث. لقد سمحت لمالكيshanselman & DirectoryServices بالتعليق على الجداول الزمنية.

@ Karelz : شكرا على التحديث! كنت أشعر بالفضول في الغالب بشأن الحالة .. يمكنني بالتأكيد المساعدة في الاختبار على الأقل ، عندما يصبح ذلك متاحًا.

pasikarkkainen إذا كنت على استعداد أيضًا للمساعدة في كتابة بعض حالات الاختبار ، فسيكون ذلك موضع تقدير كبير.
إذا كنت تريد "فقط" اختبار الحزمة على تطبيقك / رمزك ، فيجب أن تكون قابلة للتنفيذ اليوم. نحتاج فقط إلى البدء في نشر الحزمة كمعاينة على Myget (أعتقد أن النشر معطل اليوم).

karelz لا أمانع في المساعدة في تطبيق Mac على وجه التحديد. لدي القليل من المعرفة ، لذلك لست متأكدًا من مدى جودة مساهمتي. لقد أجريت بحثًا حوله وهناك مكتبة روايات يبدو أن الناس يقترحونها. تم العثور على تطبيق شخص آخر حول مكتبة الروايات هذه هنا: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

carlowahlstedt ذكر مؤلف الحزمة ذلك هنا بالفعل.
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

فهل هذا شيء سيكون في core 2.0؟ أنا في حيرة من أمري فيما يتعلق بوضعه.

لا ، لن يكون جزءًا من .NET Core 2.0 ، ومع ذلك ، في مؤتمر Build ، وعدنا بتوفر الحزمة خلال الصيف. يجب أن تكون الحزمة (Windows) متاحة فوق .NET Core 2.0 ، في وقت قريب من شحن .NET Core 2.0.
نحن نعمل حاليًا على إتاحة الحزم كمعاينة في الفرع الرئيسي (# 18090) والعمل على أصول اختبار بالتوازي (# 20669).

هل سنحصل على أخطاء في التجميع عندما نستهدف وقت التشغيل المشترك أو وقت تشغيل بخلاف Windows؟ أم سننتهي مع المصيدة PlatformNotSupported ؟

ستكون حزمة قائمة بذاتها بدون أي أصول بخلاف Windows. يجب كسر التجميع. ericstj يمكنه التأكيد.

لن تحصل على أخطاء تجميع ستكون استثناءات وقت تشغيل "PlatformNotSupported".

نعم ، إنه قديم - هل نحظر الأشخاص الذين يستخدمونه من مكتبات .NET Standard ، أم هل نحول أخطاء وقت الترجمة إلى استثناءات PlatformNotSupported؟ ... لحسن الحظ ، هناك حل وسط: ستخبرك أدوات

أتلقى الخطأ التالي عندما أحاول استخدام حزمة System.DirectoryServices في مشروع netstandard 1.6:

حزمة التثبيت: حزمة System.DirectoryServices 4.0.0 غير متوافقة مع netstandard1.6 (.NETStandard ، الإصدار = v1.6). حزمة System.DirectoryServices 4.0.0 تدعم: net (.NETFramework، Version = v0.0)

هل هناك عمل أو حل لهذا؟
يعتبر،
فارون

@ vrn11 هذه الحزمة من بائع آخر وتدعم فقط إطار عمل الشبكة الكامل

على أي حال أردت أن أسأل ما إذا كان هناك تحديث على هذا. ربما حزمة معاينة يمكننا الحصول عليها من myget؟ سيكون من الرائع اختبار ذلك

StefanKert https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.DirectoryServices

كما ذكر @ MarcusKohnert ، يمكنك الحصول عليها من https://dotnet.myget.org/F/dotnet-core/api/v3/index.json. هناك System.DirectoryServices و System.DirectoryServices.AccountManagement و System.DirectoryServices.Protocols.

مدهش! بفضل @ MarcusKohnert و ericstj على الروابط!

أحاول الحزم من myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
أثناء التشغيل على نظام التشغيل MacOS 10.12.6 ، وعند التشغيل:

using (var context = new PrincipalContext(ContextType.Domain, "DOMAIN"))

انا احصل:

System.PlatformNotSupportedException: Operation is not supported on this platform. at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name)

هل من المتوقع أن يعمل PrincipalContext على جهاز Mac؟

@ bruno-garcia لا يوجد تطبيق في CoreFX الآن لخدمة DirectoryServices باستثناء Windows. سيتعين على karelz التحدث إلى الخطط / التطلعات إن وجدت.

فقط System.DirectoryServices.Protocol من المحتمل أن يكون x-plat ممكنًا (لم يتم تنفيذه بعد) - انظر التفاصيل في بعض إجاباتي أعلاه وفي المنشور العلوي.

من المهم الحصول على System.DirectoryServices.Protocols التي تعمل عبر النظام الأساسي (أيضًا على Linux / Mac) .. هل فهمت بشكل صحيح المشكلة الرئيسية حاليًا هي أن مكتبة LDAP المستخدمة بواسطة System.DirectoryServices (على Windows) ليست مفتوحة المصدر ، وبالتالي فقط يعمل على الويندوز؟

إذا كنت قد فهمت ذلك بشكل صحيح ، فسيكون من الصعب جعل System.DirectoryServices xplat بسبب الكثير من التبعيات على واجهات ADSI COM ، التي تتوفر فقط على windows.

System.DirectoryServices.Protocols لا يزال من الممكن تشغيل xplat.

تشغيل نفس الكود الذي ذكرته من قبل:
ج #
باستخدام (var Context = new PrincipalContext (ContextType.Domain، domain، $ "OU = someou، DC = somedomain، DC = bla"))
""

على Win7 x64 مع .NET Core 2.0 ينتج عنه:

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

استخدمت الحزم:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" />
<PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />

[EDIT] Fixed callstack & xml / C # code تسليط الضوء بواسطةkarelz

@ bruno-garcia الرجاء ملف منفصل. هذا واحد يتتبع جهد المنفذ الإجمالي ، وليس أخطاء / اختلافات معينة. شكرا!

@ bruno-garcia التي يتم تتبعها من خلال https://github.com/dotnet/corefx/issues/23605

قد تكون الخطوة التالية هي التصحيح من خلال سطح المكتب ومعرفة أين يتباعد السلوك. سأحاول تحرير أحد المطورين للنظر في الأمر.

نفس المشكلة على خادم windows :( (الإصدار = "4.5.0-preview2-25701-02")

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

ما رأيك ، متى ستعمل؟

لديك مشكلة عند محاولة تثبيت حزمة

Install-Package : Unable to find package System.IO.FileSystem.AccessControl with version (>= 4.5.0-preview2-25707-02)
  - Found 15 version(s) in nuget.org [ Nearest version: 4.4.0 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages
  - Found 0 version(s) in Package source
At line:1 char:2
+  Install-Package System.DirectoryServices -Version 4.4.0-preview2-257 ...
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

=================================================
إذا كان لدى أي شخص نفس المشكلة مثلي ، استخدم .NET CLI بدلاً من ذلك

إضافة حزمة dotnet System.DirectoryServices - الإصدار 4.5.0-preview2-25707-02 - المصدر https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

papamamadoii هذا لأنك تفتقد https://dotnet.myget.org/F/dotnet-core/api/v3/index.json كمصدر ولم تستخدم حزمة التثبيت المناسبة خلاصتك المحددة للعثور على التبعيات. قد ترغب في تسجيل خطأ على http://github.com/nuget/home بخطوات إعادة بروز محددة.

karelz إذا كنت أفهم التعليقات بشكل صحيح ، فهذا لا يعمل على عمليات النشر المستندة إلى Linux؟

@ euclid47 System.DirectoryServices. * غير مدعوم حاليًا على Linux. كما تمت مناقشته أعلاه ، من المحتمل أن يتم نقل أجزاء منه نظرًا لاهتمام / مشاركة المجتمع الكافي.

@ danmosemsft لا أفهم كيف لا يمكنك رؤية هذا الموضوع بالكامل مفتوحًا منذ أكتوبر 2015 كاهتمام مجتمع كافٍ. إذا كنت أمتلك مجموعة المهارات المطلوبة لكتابة شيء معقد مثل طبقة اتصال LDAP ، كنت سأعمل بالفعل على ذلك ، حيث كانت AD إحدى آليات المصادقة الأساسية في بيئة المؤسسة. سأشير إلى أنه بالنسبة لمعظم المؤسسات الكبيرة ، فإن عدم القدرة على أداء هذه الأنواع من التفاعلات على لينكس يهزم حرفيًا الغرض من Core وسيجعلهم يلتزمون بالبنيات الأساسية من dotnet ، وبالتالي يحد من تفاعل المجتمع الثمين.

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

shairozan حتى الآن لاحظنا 7 أصوات من أصل 54 ممن يعتبرون DirectoryServices على نظام Linux أولوية أعلى من Windows - راجع https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
هناك أيضًا مزايا أخرى يخرجها المطورون من .NET Core من منصة x فقط (على الرغم من أنني أوافق على أن x-plat هو أحد أهم الأسباب).

أوصي بإنهاء إصدار حزمة Windows فقط أولاً ، ثم يمكننا فتح مشكلة جديدة لتتبع الفائدة لمنفذ Linux بشكل أكثر دقة.

أخبرنا المجتمع بالفعل أننا نبحث عن المساعدة وتم وضع علامة على المشكلة - راجع https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. وساعدت hughbe في الجولة الأولى من اختبارات DirectoryServices - شاهد التاريخ هنا وهنا وهنا .

karelz أين يتم إدارة التصويت لهذه المكونات؟ يمكنني أن أضمن بعد SELF / POSSCON أنك ستلاحظ زيادة كبيرة في الاهتمام.

karelz أين التصويت لهذه الميزة؟ أتفق تمامًا مع shairozan مع الحاجة. يوجد تعليق في هذه المشكلة يصف بيئة التطوير والإنتاج لدينا. إنه لأمر مروع للغاية أنه لم يكن هناك أي تحرك بشأن التنفيذ منذ ذلك الحين.

لقد قمت بإنشاء إصدار جديد لتتبع منفذ Linux / Mac dotnet / corefx # 24843 لتصويت أسهل من التعليق في منتصف هذه المشكلة (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

أضفت الرابط أيضًا إلى أعلى مشاركة لهذه المشكلة.

@ euclid47 كان التصويت حتى الآن في هذه المشكلة - انظر الروابط أعلاه. هذا ما نتج عنه 7 أصوات (+1 لمقدم الإصدار الأصلي).

يحتاج فريقنا إلى دعم LDAP على Linux.
لأن معظم عملائنا يستخدمون المصادقة عبر LDAP.

balkarov إذا استطعت ، فقم بالتصويت على المشكلة التي أنشأها @ Karelz للتو ( https://github.com/dotnet/corefx/issues/24843 )

balkarovshairozan @ euclid47 إذا لم تكن تعلم بالفعل فهناك حزمة Novell.Directory.Ldap.NETStandard Nuget التي يمكنك استخدامها لدمج LDAP في مشاريعك. لسنا من مستخدمي LDAP المتقدمين ، فنحن نستخدمه فقط للتحقق من صحة بيانات الاعتماد والحصول على معلومات المستخدم ، ولكنه يعمل بشكل جيد بالنسبة لنا ، سواء على الإصدار 1.0 أو 2.0 الذي يعمل على صورة عامل تشغيل dotnet core. إنها ليست طريقة رسمية ولكنها تنجز المهمة حتى يتوفر منفذ عبر النظام الأساسي System.DirectoryServices .

تضمين التغريدة لكن هذه المكتبة لا تدعم تسجيل الدخول بدون مجال.
أقوم بإنشاء مشكلة https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
هل يمكنك مساعدتي في حل هذه المشكلة؟

أنا لست جزءًا من هذا المشروع أو مستخدمًا متقدمًا ، لكنني سألقي نظرة ، أراك هناك!

(نحن لا نقوم بتسجيل الدخول باستخدام مجال)

نظرًا لأنkarelz قد أحدث مشكلة في Unix ، فقد أعدت تسمية هذه المشكلة للتوضيح.

danmosemsft لكن المشكلة لها خطة
منافذ Linux / Mac.

balkarov لقد قمت بتحديث الخطة للارتباط بقضايا التتبع الأخرى وأزلت مربعات الاختيار للعناصر التي يتم تعقبها بشكل منفصل (العمل المقسم) أو لا تحظر عمل Windows.

هل سيكون منفذ System.DS متوافقًا مع خوادم RODC (وحدات تحكم المجال للقراءة فقط)؟

PKGeorgiev يجب أن تحصل على نفس دعم System.DirectoryServices الذي لدينا في إطار العمل الكامل.

انتهى العمل في DirectoryServices لنظام التشغيل Windows ، وأغلق المشكلة.
ملحوظة:

• يتم تتبع نشر الحزمة النهائية بواسطة dotnet / corefx # 24909
• يتم تتبع منفذ Linux / Mac بشكل منفصل عن طريق dotnet / corefx # 24843

مرحبًا ، هل سيعمل هذا في UWP؟

مرحبًا ، هل سيعمل هذا في UWP؟

لا ، فهو مدعوم فقط لتطبيقات net core التي تعمل على Windows والإطار الكامل. إذا كنت تستخدمه في UWP أو على Linux ، فستحصل على استثناء PlatformNotSupported.

أنا أستخدم هذا الرمز في وظيفة lambda في AWS والتي تعمل على Linux في الخلفية ويظهر لي هذا الخطأ. "System.DirectoryServices.AccountManagement غير معتمد على هذا النظام الأساسي."
أنا أستخدم Core 2.0

 public static List<string> GetGroups(string userName, string domainString)
        {
            List<string> result = new List<string>();
            List<GroupPrincipal> gprList = new List<GroupPrincipal>();
            // establish domain context
            PrincipalContext yourDomain = new PrincipalContext(ContextType.Domain, null, domainString);

            // find your user
            UserPrincipal user = UserPrincipal.FindByIdentity(yourDomain, userName);

            // if found - grab its groups
            if (user != null)
            {
                PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups();

                // iterate over all groups
                foreach (Principal p in groups)
                {
                    // make sure to add only group principals
                    if (p is GroupPrincipal)
                    {
                        gprList.Add((GroupPrincipal)p);
                    }
                }
            }

            foreach (var gp in gprList)
            {
                result.Add(gp.Name);
            }

            return result;
        }

sscoleman نعم ، هذا غير مدعوم على Linux حتى الآن. إنه مدعوم على نظام Windows فقط.

sscoleman هناك مشكلة تم إنشاؤها عليها ، https://github.com/dotnet/corefx/issues/24843. قيل أنه لم يكن هناك اهتمام كافٍ من المجتمع به باستثناء طرح هذا السؤال طوال الوقت. حتى الآن أنت في بقعة سيئة. لقد أمضيت وقتًا في تنفيذ خدمات الدليل ثم اكتشفت أن Linux مدعوم. الآن تسأل نفسك لماذا يتم وصف هذا على أنه حيادي النظام الأساسي إذا كانت هناك ميزات Windows فقط.

من الواضح إلى حد ما إذا نظرت إلى استراتيجية Microsoft الكبرى. تقوم Microsoft بإلقاء جميع موارد التطوير الخاصة بها في Azure ، بما في ذلك Active Directory. تحقق من "الجديد في 2016" ، إنه في الغالب استثمارات AzureAD / Hybrid. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

لا تستثمر Microsoft في هذه المكتبة لنظام التشغيل Linux لأنهم يريدون أن ينتقل الجميع إلى Azure AD بدلاً من ذلك. من المنطقي ، لماذا تستثمر في شيء تحاول دفع العملاء إلى الابتعاد عنه؟

لكنك تفعل شيئًا بسيطًا نسبيًا. يمكنك استخدام مكتبات Novel LDAP ، فهي تعمل مع AD وعلى .NET Core لنظام Linux. تحتاج إلى القيام بعمل البروتوكول بنفسك ، لكنه ليس شديد التعقيد ، وهناك الكثير من العينات هناك. الجانب السلبي هو أنك تحتاج إلى إدارة الربط بنفسك ، الأمر الذي يتطلب اسم مستخدم وكلمة مرور.

System.DirectoryServices هو حاليًا واجهة برمجة تطبيقات Windows فقط وهو جزء من حزمة توافق Windows لـ .NET Core . من حيث المبدأ ، يمكننا جعل أجزاء من System.DirectoryServices تعمل على Linux ولكن لم يكن لدينا الموارد للقيام بذلك حتى الآن. تتعقب dotnet / corefx # 24843 عنصر العمل هذا.

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

شاهد هذا الفيديو لمزيد من السياق حول كيفية رؤيتنا لحزمة توافق Windows والمحلل عبر الأنظمة الأساسية جنبًا إلى جنب:

https://channel9.msdn.com/Events/Connect/2017/T123

تضمين التغريدة

لا تستثمر Microsoft في هذه المكتبة لنظام التشغيل Linux لأنهم يريدون أن ينتقل الجميع إلى Azure AD بدلاً من ذلك.

هذا ليس كيف أراه. كما أشرت ، نعتزم كسب المال عبر Azure. و Azure عبارة عن نظام أساسي سحابي يقدم مجموعة متنوعة من التقنيات وأنظمة التشغيل. ليست لدينا مصلحة تجارية في الترويج لـ Windows في السحابة عبر Linux في السحابة. لكن بالطبع ، يتمتع .NET بحضور قوي على نظام التشغيل Windows لمدة 15 عامًا. يستغرق جعل الأشياء تعمل بكامل طاقتها عبر جميع أنظمة التشغيل وقتًا ، لكنني أعتقد بصدق أن معظم الأشخاص الذين يتابعون جهودنا مفتوحة المصدر يمكنهم رؤية أننا لا نعطل Linux عن قصد. يستغرق الأمر وقتًا فقط.

أنا أتفق مع النهج مع وجود واجهة برمجة تطبيقات متسقة وإطار عمل x ، لكنه يدمر الروح كلما واجهت هذا الخطأ المخيف .. أشعر بـ sscoleman ...

هل يمكن أن تعمل حزمة DirectoryServices على CentOS 7؟

هل يمكن أن تعمل حزمة DirectoryServices على CentOS 7؟

يمكن تثبيت الحزمة ولكنها لن تعمل. عند استخدامه ستحصل على استثناء غير معتمد للنظام الأساسي. نحن نبحث في كيفية دعم خدمات الدليل بشكل عام على Linux. هذا على رادارنا.

هذا حقا يحتاج إلى دعم لينكس

CCjoperezr

nemyjski انظر dotnet / corefx # 24843

هذا حقا يحتاج إلى دعم لينكس

.. بالإضافة إلى أن تكون قادرة على الركض في حاوية عامل ميناء. Imho هو ألم في المؤخرة أن يحتاج المرء إلى الرجوع إلى تطبيق دليل Novell القديم عندما يريد المرء استخدام .NET Core 2+ على لينكس.
شكرا على كل حال للعمل على ذلك!

لماذا نغلق هذه القضية؟ System.DirectoryServices.AccountManagement لا يزال غير موجود في .NET Core خارج Windows:

# dotnet --list-runtimes
Microsoft.AspNetCore.All 2.2.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

إعادة فتح 14734

tarekgh لا يزال على الرادار؟

إعادة فتح 14734

JustinGrote ما هي الوظيفة الدقيقة التي تريدها للسيناريو؟ DirectoryServices ضخمة وأشك في إمكانية دعم الوظائف بالكامل في إصدار واحد فقط. قد يساعد وجود طلبات محددة بشكل أفضل من مجرد طلب دعم مكتبات DS بأكملها. في .NET 5.0 ، قمنا بتمكين سيناريو https://github.com/dotnet/runtime/issues/23944.

CCjoperezr

تضمين التغريدة
لم أكن على علم بأن System.DirectoryServices.Protocols قد تم نقلها ولكن يبدو أنها لا تزال تعتمد على الأمان. خطأ في التجميع؟

الهدف هو إعادة تنفيذ شيء مثل وحدة ActiveDirectory Powershell لتكون xplat ، كنت أفكر إما في وحدة ldap أو ldap4net لهذا الغرض إذا لم يكن هناك دعم أساسي للتفاعل متاح على الأقل.

من المحتمل أن يكون تنفيذ ActiveDirectory Powershell حالة استخدام كبيرة جدًا. اسمحوا لي أن أشارك حالتي الاستخدام:

1) أنا مشتق من UserPrincipal لأنني أحتاج إلى سمات غير مدعومة خارج الصندوق. لقد اتبعت https://stackoverflow.com/questions/24798037/extend-userprincipal-class وأعتقد أن هذا نوع من المعايير في إطار عمل .NET القديم ، ومن المحتمل أن يساعد هذا الأسلوب في العمل المزيد من المطورين.

2) لدي أيضًا رمز مثل ما يلي:

"

        DirectoryEntry entry = new DirectoryEntry("LDAP://CN=some base address");
        String objectClass = "some object";
        String filter = "(objectClass=" + objectClass + ")";
        using (DirectorySearcher search = new DirectorySearcher(entry, filter,
             new string[] { "some attribute" },
             SearchScope.Subtree))
        {
            using (SearchResultCollection src = search.FindAll())
                foreach (SearchResult s in src)
                {
                    /* do something with */ s.Properties["some attribute"][0]);
                }
        }

"

لا يوجد دليل على ما هو مدعوم بالفعل اليوم ، آخر مرة تحققت فيها كانت في فبراير.
شكرا يواكيم

@ jol64 ألا يمكنك تحقيق الشيء نفسه باستخدام البروتوكولات؟

@ jol64 ألا يمكنك تحقيق نفس الشيء باستخدام البروتوكولات؟

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