@vibronet

क्या इस पर कोई अपडेट है?

मैं भी इस पर एक अपडेट चाहता हूं। मेरी कंपनी मुझे एक नया ऐप बना रही है जिसके लिए एलडीएपी के माध्यम से सक्रिय निर्देशिका से पूछताछ करने की क्षमता की आवश्यकता है लेकिन ऐसा लगता है कि यह वर्तमान में संभव नहीं है। क्या इसके लिए योजनाबद्ध समर्थन है, क्या इसे किसी और चीज़ के पक्ष में छोड़ा जा रहा है, या यह पहले से ही काम कर रहा है, कहीं भी प्रलेखित नहीं है?

एलडीएपी और सक्रिय निर्देशिका समर्थन को लागू करने पर एक नया, ताजा रूप .NET CoreFX में होना बहुत अच्छा होगा।

हमें वास्तव में एक सक्रिय निर्देशिका/एलडीएपी समाधान की आवश्यकता है जिसका हम .NET कोर में लाभ उठा सकें। चाहे वह क्लीन शीट कार्यान्वयन हो या System.DirectoryServices का पोर्ट मेरे लिए उतना मायने नहीं रखता। बहुत सारे व्यवसाय-केंद्रित विंडोज़ अनुप्रयोग हैं जिन्हें पूरी तरह से AD प्रमाणन की आवश्यकता होती है, और LDAP प्रमाणन क्रॉस-प्लेटफ़ॉर्म डेवलपर्स के लिए एक बेहतरीन फीचर बुलेट पॉइंट होगा।

उपरोक्त बैकवर्ड संगत नोट्स पर सहमत - मुझे नहीं लगता कि वास्तव में एक डायरेक्ट पोर्ट की आवश्यकता है, हमें सक्रिय निर्देशिका या किसी भी एलडीएपी प्रदाता के खिलाफ प्रमाणीकरण (और अन्य क्रियाएं: खोज, अनलॉक, हटाएं, आदि) तक पहुंचने का एक तरीका चाहिए। .

@निकक्रावर

मुझे नहीं लगता कि वास्तव में एक प्रत्यक्ष बंदरगाह की आवश्यकता है, हमें सक्रिय निर्देशिका के खिलाफ प्रमाणीकरण [...] तक पहुंचने का एक तरीका चाहिए

यह जानकर अच्छा लगा। मेरे द्वारा अभी-अभी लागू किए गए मेरे पोर्ट-टू-कोर लेबल में बहुत अधिक न पढ़ें। यह .NET कोर ऑफ़रिंग में कमियों को ट्रैक करने का मेरा तरीका है जो आपके जैसे ग्राहकों को उनके ऐप को .NET कोर में पोर्ट करने से रोकता है।

@terrajobst गोचा । मैं जरूरी नहीं सोचता कि इसकी प्रतिरूपकता के कारण यह 1.0 आइटम होना चाहिए (और यह _sounds_ जैसा कि वैसे भी पोस्ट-आरटीएम के लिए स्लेट किया गया है), लेकिन मैं इसके लिए तत्पर हूं। यह मेरे लिए Opserver को पोर्ट करने में एक अवरोधक होगा, अगर हम उपयोग में आ सकते हैं तो API चर्चाओं में भाग लेने में खुशी होगी। हमारे पास चीजों के sysadmin पक्ष पर उपयोग के मामलों की एक विस्तृत श्रृंखला है जो मददगार हो सकती है, अगर मैं मदद कर सकता हूं तो पिंग करें।

बस एक और टोपी रिंग में फेंकने के लिए। फिलहाल यही मेरे लिए सबसे बड़ा अवरोधक भी बचा है। बस प्रमाणीकरण में सक्षम होना अभी के लिए बहुत बड़ी मदद होगी।

क्या हमें इसके लिए योजनाओं पर देव टीम के किसी व्यक्ति से आधिकारिक प्रतिक्रिया मिल सकती है, अगर इसका समर्थन करने के लिए कोई योजना भी है?

मुझे नहीं लगता कि वास्तव में एक प्रत्यक्ष बंदरगाह की आवश्यकता है

क्यों? क्षमा करें मैं भ्रमित हूँ। क्या यह सभी के लिए और DRY सिद्धांत के अनुसार सबसे आसान समाधान नहीं होगा?
फिर भी, यदि पूरे एपीआई को खरोंच से लिखने का कोई कारण है, तो पुराने एपीआई (समान विधि हस्ताक्षर) के साथ कुछ स्थिरता उपभोक्ता के लिए कम भ्रमित करने वाली होगी।

@ jasonwilliams200OK मुझे स्पष्ट करने दें, मेरा मतलब वास्तव में DirectoryServices.ActiveDirectory विशेष रूप से था। मुझे लगता है कि प्रमाणीकरण, और इसके आस-पास की चीजें: उदाहरण के लिए समूह सदस्यता नामस्थान का 95-99% उपयोग केस है। मुझे लगता है कि _that_ के हस्ताक्षर का सीधा बंदरगाह बहुत उपयोगी है। अगर किसी कारण से बाकी वारंट बदल जाते हैं, तो मैं इसके साथ बहुत ठीक हूं, और ठीक है अगर यह बाद में आया ... तो दरवाजे से बाहर निकलना अच्छा होगा क्योंकि यह कई लोगों के लिए अवरोधक है।

सक्रिय निर्देशिका उपयोगकर्ताओं को खोजने और उन्हें ASP.NET 5 के साथ कस्टम भूमिकाओं के साथ मैप करने की कम से कम एक बुनियादी कार्यक्षमता को एकीकृत करने से ASP.NET वेब अनुप्रयोगों में विंडोज प्रमाणीकरण के कार्यान्वयन में आसानी होगी। हमें अपनी इंट्रानेट साइट पर इस कार्यक्षमता की आवश्यकता है।

यह हमारे लिए भी अवरोधक है। हमें एलडीएपी सर्वर के खिलाफ प्रमाणीकरण, क्वेरी उपयोगकर्ताओं और समूहों, नए उपयोगकर्ता और समूह आदि बनाने में सक्षम होना चाहिए।

यह मेरे लिए एक अवरोधक भी है - मुझे उपयोगकर्ताओं से पूछताछ और प्रमाणीकरण की आवश्यकता है।

मैं .NET Core rc1 वेब एप्लिकेशन में सक्रिय निर्देशिका के विरुद्ध प्रमाणीकरण के लिए एक समाधान लेकर आया हूं। आपको बस UserManager वर्ग में CheckPasswordAsync विधि को ओवरराइड करना होगा। आप क्या सोचते हैं मुझे बताओ।

सबसे पहले आपको एक कस्टम रजिस्टर पेज बनाने की आवश्यकता है जो उपयोगकर्ता को ईमेल पते और पासवर्ड के बजाय एडी उपयोगकर्ता नाम इनपुट करने की अनुमति देता है। वह उपयोगकर्ता नाम ApplicationUser वर्ग के UserName गुण में जाता है जो ASP.NET 5 टेम्पलेट द्वारा उत्पन्न होता है जब आपने व्यक्तिगत उपयोगकर्ता खाता प्रमाणीकरण चुना था। साथ ही, आपको पासवर्ड प्रॉपर्टी को किसी ऐसी चीज़ पर डिफॉल्ट करना होगा जो IdentityUser क्लास में आंतरिक सत्यापन पास करता है।

मेरा रजिस्टर पेज कंट्रोलर एक वेब एपीआई 2 विधि को कॉल करता है जो एडी में उपयोगकर्ता नाम ढूंढता है और उस उपयोगकर्ता के लिए एडी जानकारी रखने वाला JSON देता है। मैंने AD जानकारी रखने के लिए ApplicationUser वर्ग में कुछ कस्टम गुण जोड़े हैं। मैं अगले हफ्ते अपने प्रोजेक्ट से कोड पोस्ट करूंगा।

फिर सर्विसेज फोल्डर में क्लास फाइल जोड़ें। मैंने अपना नाम 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() ConfigureServices विधि में AddIdentity कॉल के लिए जैसा कि नीचे दिखाया गया है।

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

यह कम से कम मुझे DirectoryServices समर्थन की प्रतीक्षा करते हुए नीति/दावा आधारित प्राधिकरण स्थापित करने की अनुमति देता है।

मैं इस पुस्तकालय पर निर्भर हूं। यह शर्म की बात है कि मैं अभी पोर्ट नहीं कर सकता।

@ClintBailiff मुझे यहां झंकार करना है - क्योंकि उपयोगकर्ता के पासवर्ड को फिर से वायर के पार प्लेनटेक्स्ट में किसी अन्य एप्लिकेशन पर रिले करना एक _really_ बुरा विचार है। कृपया, इस दृष्टिकोण का प्रयोग न करें। यह एक सुरक्षा छेद है।

@terrajobst यह मेरे बड़े अनुप्रयोगों जैसे कि Opserver को पोर्ट करने में अवरोधक होगा - क्या हम इसे प्राथमिकता दे सकते हैं?

@NickCraver मैंने कभी भी क्रेडेंशियल्स को प्लेनटेक्स्ट के रूप में पास करने का सुझाव नहीं दिया। एक नियम के रूप में मैं अपने सभी वेब एप्लिकेशन/सेवाओं के लिए एसएसएल का उपयोग करता हूं क्योंकि वे आम तौर पर डेटा लौटाते हैं जो केवल अधिकृत उपयोगकर्ताओं को ही देखना चाहिए। मैंने यह निर्दिष्ट करने के लिए नहीं सोचा था क्योंकि शायद यह इतना स्पष्ट है कि आप सादे टेक्स्ट में प्रमाण-पत्र नहीं भेजना चाहेंगे।

मैं कम से कम System.DirectoryServices.Protocols का एक बंदरगाह प्रदान करने का समर्थन करूंगा। हमने हाल ही में एलडीएपी सर्वरों की एक बड़ी रेंज का समर्थन करने के लिए हमारे एलडीएपी-संबंधित कोड को इसमें बदल दिया है, क्योंकि System.DirectoryServices.ActiveDirectory नेमस्पेस केवल एडी सर्वर से बात करना पसंद करता है।

मुझे लगता है, तीसरे पक्ष के पुस्तकालय के लिए इस तरह के समर्थन को स्पिन करना संभव होगा, लेकिन चूंकि यह ढांचे में पहले से मौजूद है, इसलिए मैं कल्पना करता हूं कि एक बंदरगाह आसान होगा।

डब्ल्यूटीएफ एएसपी टीम यह बुनियादी कार्यक्षमता प्रदान नहीं कर रही है
यह वास्तव में एक अवरोधक मुद्दा है :(

CoreCLR में LDAP सपोर्ट पर कोई अपडेट?

मैं इस पर एक अपडेट भी चाहूंगा। मैं ASP.NET कोर के साथ एक एंटरप्राइज़ एप्लिकेशन विकसित कर रहा हूँ, जिसे AD-सर्वर के विरुद्ध उपयोगकर्ताओं को प्रमाणित करने की आवश्यकता है।

मैं v1.1.0 (https://github.com/dotnet/corefx/milestones) के लिए System.DirectoryServices को .NET कोर में पोर्ट करने पर ध्यान दूंगा।

@joshfree
मुझे ADLDS के उपयोगकर्ताओं को भी प्रमाणित करना है कृपया System.DirectoryServices.AccountManagement पर भी विचार करें

कुछ साल पहले जिस कंपनी के लिए मैंने काम किया, उसने नोवेल (मोनो) एलडीएपी लाइब्रेरी सोर्स कोड लिया ताकि हमारा एप्लिकेशन एक्टिव डायरेक्ट्री, ओपनएलडीएपी और ओरेकल सिस्टम से बात कर सके, और हमने पेजेड कंट्रोल के लिए सपोर्ट जोड़ा और कुछ टीएलएस फिक्स को अपडेट किया। हमने ऐसा इसलिए किया क्योंकि हम लिनक्स पर चलना चाहते थे। हमारे परिवर्तनों के साथ एक पीआर मालिकों को भेजा गया था। जैसा कि अब हम CoreCLR पर जाना चाहते हैं कि पुस्तकालय को RC2 में परिवर्तित करने की आवश्यकता है। यहां काम शुरू हो गया है https://github.com/VQComms/CsharpLDAP/pull/1 , 17 कंपाइलर त्रुटियां बाकी हैं जिन्हें संबोधित करने की आवश्यकता है। वे मुख्य रूप से Thread.Abort , ThreadInterruptedException हैं, जो मोनो से कोरसीएलआर में टीएलएस स्ट्रीम की जगह लेते हैं SslStream यदि कोई दिलचस्पी रखता है और कोरसीएलआर के लिए एलडीएपी समर्थन की आवश्यकता है तो मदद करने के लिए स्वतंत्र महसूस करें।

मैंने पुष्टि की है कि ASP.NET कोर वेब एप्लिकेशन (.NET Framework) RC2 प्रोजेक्ट एक क्लास लाइब्रेरी को संदर्भित कर सकता है जो System.DirectoryServices.AccountManagement का उपयोग करता है। मैं इसे केवल तभी काम करने के लिए प्राप्त कर सकता हूं जब वीएस 2015 अपडेट 2 के साथ वेब एप्लिकेशन और क्लास लाइब्रेरी दोनों बनाए जाते हैं और दोनों .NET Framework 4.6.1 का उपयोग करते हैं।

दूसरों की भावनाओं को प्रतिध्वनित करने के लिए, हम LDAP और इसी तरह की क्वेरी किए बिना पानी के पोर्टिंग में मृत हैं।

@h3स्मिथ
मेरी पिछली पोस्ट देखें। RC2 के जारी होने के साथ अब आप एक क्लास लाइब्रेरी का संदर्भ दे सकते हैं जो System.DirectoryServices.AccountManagement का उपयोग करती है।

नेटस्टैंडर्ड पर नहीं।

हालांकि, जैसा कि मैं कहता हूं, हम इसे काम करने के लिए काम कर रहे हैं। उम्मीद है
लगभग 2-3 सप्ताह में कुछ

शुक्रवार, 17 जून 2016 को, क्लिंटन बेलीफ नोटिफिकेशन @github.com ने लिखा:

@h3smith https://github.com/h3smith
मेरी पिछली पोस्ट देखें। RC2 के जारी होने के साथ अब आप a का संदर्भ ले सकते हैं
क्लास लाइब्रेरी जो _System.DirectoryServices.AccountManagement_ का उपयोग करती है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

इस पर कोई अपडेट? मुझे कॉलिंग उपयोगकर्ता को प्रमाणित करने की आवश्यकता है, जब उपयोगकर्ता लैन पर एक कोणीय वेब ऐप का उपयोग कर रहा है, एडी में लॉग इन किया गया है, एस्पनेट कोर आरसी 2 में एक वेबएपीआई नियंत्रक विधि (उपयोगकर्ता द्वारा वेब ब्राउज़र में पासवर्ड दर्ज किए बिना) को कॉल कर रहा है। संभव? जल्द ही संभव है?

ऐसा करने के लिए आपको क्लाइंट से अपने http अनुरोधों में केवल क्रेडेंशियल के साथ उपयोग करने की आवश्यकता है। फिर आप User.Identity का उपयोग करके अपने नियंत्रकों में उपयोगकर्ता जानकारी और दावे प्राप्त कर सकते हैं।
यह यानी और क्रोम में काम करता है लेकिन फ़ायरफ़ॉक्स के साथ एक पॉपअप स्वचालित रूप से Le उपयोगकर्ता को उनके विंडोज़ उपयोगकर्ता और पासवर्ड में दिखाया जाएगा

हमने लगभग दो महीने पहले इसी मुद्दे को मारा (उदाहरण के लिए उपयोगकर्ता स्टोर के रूप में एलडीएपी सर्वर का उपयोग करने का प्रयास)। हमें नोवेल एलडीएपी लाइब्रेरी (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) को .net कोर में पोर्ट करने के अलावा कोई समाधान नहीं मिला (यहां देखें https://github.com/dsbenghe/Novell. Directory.Ldap.NETStandard)। एक नगेट पैकेज प्रकाशित किया गया है। हम OpenDJ LDAP सर्वर के साथ लाइब्रेरी का उपयोग कर रहे हैं (किसी भी LDAP सर्वर के साथ काम करना चाहिए) - 1.5 महीने के उपयोग में कोई समस्या नहीं है।

@dsbenghe हमने अभी-अभी अपना नोवेल LDAP लिब नेटस्टैंडर्ड पर संकलित किया है, हमारे पास पेजिंग भी है। यह @igorshmukler द्वारा किया गया था। क्या आप तुलना और सहयोग करना चाहेंगे? हमारा यहां डब्ल्यूआईपी है https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenge इसके .NET कोर कार्यान्वयन पर आपके काम के लिए धन्यवाद।
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

cc @tquerec @jimuphaus जो .NET कोर के लिए System.DirectoryServices सपोर्ट पर काम करेगा।

इंतजार नहीं कर सकता! ईटीए? डिजाइन चश्मा?

जब इसे अंत में पोर्ट कर दिया जाएगा, तो क्या हमारे पास इस तक पहुंच होगी:

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

मुझे पता है कि उस नामस्थान में कुछ मामूली दोष हैं, लेकिन फिर भी यह काफी मददगार है।

@GArrigotti परीक्षण में, LdapDirectoryIdentifier का उपयोग करना आमतौर पर प्रिंसिपल कॉन्टेक्स्ट से तेज़ होता है।

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 कोर एप्लिकेशन में लीगेसी क्लास लाइब्रेरी को संदर्भित करने में समस्या हुई है। लेकिन अगर आप वीएस 2015 अपडेट 3 में वेब ऐप और क्लास लाइब्रेरी बनाते हैं और वेब ऐप और क्लास लाइब्रेरी में .NET Framework 4.61 को लक्षित करते हैं तो कोई समस्या नहीं है।

क्या कोई कारण है कि आप कक्षा पुस्तकालय में एडी कोड नहीं डाल सकते हैं?

क्या आपका मतलब .NET Core TxM के लिए Project.json में PCL के बाद "imports": "portable-net45+win8" है? इसके लिए मोनो पीसीएल संदर्भ असेंबलियों को यूनिक्स पर उपस्थित होने की आवश्यकता होगी, न कि "शुद्ध डोनेट-कोर" समाधान, जो यूनिक्स पर आत्मनिर्भरता प्रदान करता है। यह कंपाइलर को चुप कराने के लिए एक अच्छा हैक है, लेकिन केवल तभी काम करता है जब CoreFX BCL के पास संबंधित कार्यान्वयन हो। एक नियम के रूप में, netcoreapp/netstandard1.x के लिए कोई "imports" वाला project.json हमेशा बेहतर होता है। उदाहरण के लिए https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

ईटीए पर कोई अपडेट? मैं स्वयं सेवा के लिए कहाँ जा सकता हूँ जो आवर्ती प्रश्न है?

_Really_ इस सुविधा के लिए तत्पर हैं!

वास्तव में इस सुविधा की भी प्रतीक्षा है !!

वास्तव में इस सुविधा की भी प्रतीक्षा है !!

मुझे भी इस सुविधा की सख्त जरूरत है!

दोस्तों, क्या आप सभी मुख्य पोस्ट पर प्रतिक्रियाएँ जोड़ सकते हैं?

या उन पुस्तकालयों का उपयोग करें जिन्हें 2 अलग-अलग लोगों द्वारा नगेट पर रखा गया है। इसका
सभी ओ.एस.एस. अगर आपको पैकेज पसंद नहीं है, तो एक पीआर भेजें

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
.

@jchannon नोवेल एलडीएपी के लिए +1। इसने हमें आगे बढ़ाया और हमारे एलडीएपी कार्यान्वयन में वस्तुतः कोई बदलाव नहीं किया। मेरा मतलब है कि आप सही ढंग से सारगर्भित कर रहे हैं;)

हां, मैंने @jchannon नोवेल एलडीएपी का भी उपयोग किया, इसने अच्छा काम किया है।

अगर मैंने पहले ऐसा नहीं कहा है, तो यह शाखा https://github.com/VQComms/CsharpLDAP/commits/coreclrPort पर है।

इस समय हमारी आवश्यकताओं के लिए अच्छा काम करता है ...

@h3smith @johnkwaters किसी भी मुद्दे को बेझिझक एक मुद्दा उठाएं

मैंने नोवेल के साथ प्रयास करने का फैसला किया, नमूने काफी अच्छे दिखते हैं लेकिन मुझे नहीं पता कि उपयोगकर्ता सदस्य को नोवेल एलडीएपी के साथ समूह से कैसे निकालना (निकालना) है।
मैं MSAD LDAP पर अपना पासवर्ड नहीं बदल सकता क्योंकि मैं userPassword नहीं देख सकता और यह LDAP सर्वर पर सेट नहीं था।

वास्तव में इसकी आवश्यकता है!

@joshfree या किसी और को पता है ...
हम एक नई परियोजना शुरू करना चाहते हैं जिसके लिए ActiveDirectoryServices.AccountManagement Question तक पहुंच की आवश्यकता है, क्या पोर्ट 1.1 या 1.2 के लिए लक्षित है?

यह 1.1 का हिस्सा नहीं है (जिसे अंतिम रूप दिया जा रहा है)। @tquerec , क्या आप कृपया यहां अपनी योजनाओं पर टिप्पणी कर सकते हैं?

cc: @danmosemsft

तो, अगर 1.1 का हिस्सा नहीं है तो किसी के पास कोई योजना है? ऐसा लगता है कि यह समर्थन न होना एक प्रमुख मुद्दा है। स्पष्ट रूप से, सभी का Microsoft यह एकीकरण चाहेगा।

बस एक और वोट के लिए। .NET कोर पर एंटरप्राइज क्लास सिस्टम बनाने के लिए निवेश करना मुश्किल है जब इसमें मौलिक उद्यम कार्यक्षमता का अभाव है। उपन्यास परियोजना काम करती है, लेकिन सूंघने के लिए नहीं है।

एक और वोट। मैं उसी कथन को प्रतिध्वनित करूंगा कि यह किसी भी उद्यम अनुप्रयोग को बनाने के लिए अभिन्न है।

@nevcoBpalacio मुझे लगता है कि वे हमें नीला सक्रिय निर्देशिका का उपयोग करने के लिए धक्का देने की कोशिश कर रहे हैं

यह उन लोगों के लिए कभी भी काम नहीं करेगा जो कॉर्पोरेट समझौतों के साथ उपयोग में हैं, जिनके लिए घर में रहने के लिए सेवाओं की आवश्यकता होती है।

मैं संघीय और अब स्थानीय काउंटी दोनों सरकारी एजेंसियों के लिए काम कर रहा हूं और किसी भी तरह से आपको अभी भी कुछ निर्देशिका सेवा में एकीकृत करने के लिए कुछ इंटरफ़ेस या क्षमताओं की आवश्यकता होगी, या तो क्लाउड आधारित या आधार पर। मेरे पास अरबों डॉलर का प्रबंधन करने वाले सह-विकसित अनुप्रयोग हैं और हमेशा निर्देशिका सेवाओं की कुछ आवश्यकता उत्पन्न होती है। मुझे लगता है कि यह एक और वोट से ज्यादा है, बल्कि यह एक बयान है कि आप किसकी प्रतीक्षा कर रहे हैं? मैं पहले के एक पोस्ट से सहमत हूं कि यह मूल रूप से पूर्व .NET रिलीज में बॉक्स समाधान से बाहर था। मैं समझता हूं कि कोर की अधिक खुली संरचना को समुदाय की गति प्राप्त करनी चाहिए और यदि माइक्रोसॉफ्ट यही इंतजार करना चुनता है, तो शायद उन्होंने यह कहा है और मैंने इसे याद किया है, उन्हें यह कहना चाहिए ताकि कोई समय निवेश करने की पहल कर सके इसे करवाने के लिए।

हाँ, कृपया System.DirectoryServices को .NET कोर में जोड़ें!

हमारी अगले साल के भीतर System.DirectoryServices.Protocols को पोर्ट करने की योजना है। इस समय मैं एक निश्चित तिथि प्रदान नहीं कर सकता। हमारे पास अभी तक System.DirectoryServices या System.DirectoryServices.AccountManagement को पोर्ट करने की कोई योजना नहीं है, लेकिन मुझे रुचि जानने में दिलचस्पी है। क्या उन नामस्थानों की विशेषताएं हैं जिनका लोग उपयोग कर रहे हैं जिन्हें प्रोटोकॉल के साथ हल नहीं किया जा सकता है?

@tquerec मैं प्रोटोकॉल से परिचित नहीं हूँ। खाता अनलॉक और खाता पासवर्ड रीसेट करने के लिए हमारे पास सक्रिय निर्देशिका स्वयं सेवा करने का एक प्रोजेक्ट है। हम प्रोजेक्ट में UserPrincipal का उपयोग करते हैं और FindByIdentity, UnlockAccount, SetPassword,, ExpirePasswordNow, जैसी विधियों को लागू करते हैं।
मुझे यकीन नहीं है कि ये प्रोटोकॉल पर किया जा सकता है, लेकिन ऐसा लगता है कि प्रोटोकॉल निचले स्तर का कार्यान्वयन है बनाम खाता प्रबंधन ActiveDirectory के साथ काम करने के लिए एक बेहतर अमूर्तता है।
धन्यवाद
रॉकमेस्टर

@nevcoBpalacio निश्चित रूप से मेरे द्वारा सहमत एक वोट से अधिक होना चाहिए। मुझे लगता है कि इसे वास्तव में अधिक प्राथमिकता की आवश्यकता है।

@CalebMacdonaldBlack यह उपयोगी होगा यदि आप उपयोग पैटर्न के बारे में @tquerec प्रश्न का उत्तर दे सकते हैं और इसकी आवश्यकता क्यों है। परिदृश्यों के बिना अधिक अपवोट या "मैं सहमत/यह महत्वपूर्ण है" इस समय प्राथमिकता बढ़ाने में मदद नहीं करेगा ... धन्यवाद!

हमारा उपयोग एलडीएपी को स्कैन/खोज कर रहा है, क्रेडेंशियल्स को सत्यापित करने के लिए बाइंड कर रहा है, एलडीएपी ऑब्जेक्ट्स (उपयोगकर्ताओं, समूहों) को जोड़/हटा रहा है, समूहों में सदस्यता को संशोधित कर रहा है।

@tquerec मुझे वास्तव में System.DirectoryServices.AccountManagement की आवश्यकता है ताकि मैं अपने उपयोगकर्ताओं को सक्रिय निर्देशिका के विरुद्ध प्रमाणित कर सकूं और उन्हें उन समूहों पर अधिकृत कर सकूं जिनके पास उनकी पहुंच है।

निश्चित रूप से h3smith से सहमत हैं .. हमें v1 के लिए इसकी आवश्यकता है और इसके बजाय हमें उपन्यास पथ पर जाने के लिए मजबूर होना पड़ता है, जिसे हमने एक साथ रखा है (विशेष रूप से प्रतिकृति बिट्स) और रखरखाव आदि के ऊपरी हिस्से के साथ हमें दुखी कर रहा है। यह .NETCore बना रहा है साइड इफेक्ट के रूप में खराब दिखें ..

@liquidboy

हमें v1 . के लिए इसकी आवश्यकता थी

क्या आपका मतलब .NET कोर v1 है? - जो किया जाता है और भेज दिया जाता है। हम अभी 1.2 पर काम कर रहे हैं। या आपका मतलब कुछ और था?

इसके बजाय उपन्यास पथ पर जाने को मजबूर हैं

इसका क्या मतलब है? (क्षमा करें, मेरे पास DirectoryServices पर शून्य संदर्भ है, लेकिन मुझे यह समझना अच्छा लगेगा कि हम परिदृश्यों के दृष्टिकोण से क्या खो रहे हैं)

@karelz बस "उपन्यास" शब्द के लिए इस धागे में एक खोज करें और आप देखेंगे कि मेरा क्या मतलब है। मेरी टीम के एक अन्य देव (dsbenge) ने (दूसरों के साथ) उस अंतर के बारे में टिप्पणी की जिसके कारण हमें उपन्यास का उपयोग करना पड़ा। [यहाँ ऊपर टिप्पणी के लिए लिंक https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

और हाँ मेरा मतलब .NET Core v1 से था जो पहले ही भेज दिया गया है, हम एक साल से अधिक समय से अपने समाधान पर काम कर रहे हैं और हमें उस समय एक अच्छे DirectoryServices समाधान की आवश्यकता थी .. हमने एक दीवार मारा और इस प्रकार उपन्यास का उपयोग करने के अलावा कोई विकल्प नहीं था .

@liquidboy लिंक के लिए धन्यवाद - अगर यह मोनो में है, तो हमें .NET कोर AFAIK में स्रोत कोड का पुन: उपयोग करने में सक्षम होना चाहिए। @tquerec ने रुचि दी, क्या यह कुछ ऐसा है जिस पर आपकी टीम विचार करेगी?

@tquerec : हमें निम्नलिखित की आवश्यकता है:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory, और System.DirectoryServices.Protocols।

सक्रिय निर्देशिका (और अन्य एलडीएपी सर्वर) उपयोगकर्ताओं, समूहों, विशेषताओं से जुड़ने और प्रबंधित करने के लिए इनकी आवश्यकता होती है, जैसा कि ऊपर दिए गए उत्तरों में भी वर्णित है। नेट कोर में इन सुविधाओं का होना जरूरी है!

मैं दूसरों से सहमत हूं। मुझे अपने किसी भी ऐप को पोर्ट करने के लिए इसकी आवश्यकता है जो कि ActiveDirectory के विरुद्ध .NET Core में प्रमाणित है। यह काफी मौलिक है, यह निश्चित रूप से जल्द से जल्द रिलीज में होना चाहिए। यह बहुत सी चीजों को पोर्ट करने में अवरोधक है।

.NET कोर रोडमैप पेज (https://github.com/dotnet/core/blob/master/roadmap.md) में .NET Core 1.2 के लिए यह योजना है: आधार प्रकारों का बड़ा संग्रह।"

मुझे लगता है कि सिस्टम को पोर्ट करना। डायरेक्टरी सर्विसेज उस योजना को बहुत अच्छी तरह से फिट करती है, और वास्तव में 1.2 रिलीज का हिस्सा होना चाहिए। बस मेरे 5 (यूरो) सेंट :)

बस स्पष्ट करने के लिए: 1.2 में पोर्ट किए गए एपीआई को उपयोग डेटा (और शायद ही कभी जटिलता) के आधार पर चुना गया था - @weshaggard @danmosemsft क्या आप विवरण के साथ झंकार कर सकते हैं, हमने System.DirectoryServices को शामिल क्यों नहीं किया?

हमने जिन विधानसभाओं का मिलान करने के लिए चुना है, उनकी सूची यहां है । @weshaggard को मुझे याद दिलाना होगा कि उन्होंने उस सूची को कैसे चुना। (मोनो में S.DirectoryServices है)

मेरा मानना ​​है कि आप System.DirectoryServices.Protocols का उपयोग करके ActiveDirectory (और अन्य ldap सर्वर) के साथ बात करने के संबंध में आवश्यक सभी चीजों के बारे में करने में सक्षम होंगे, लेकिन बहुत से लोगों को S.DS.Protocols का उपयोग करने के लिए अपने कोड को फिर से लिखना होगा।

व्यक्तिगत रूप से मैं एमएस को एस.डीएस.प्रोटोकॉल और एमएस या समुदाय को इसके शीर्ष पर उपयोगकर्ता/समूह प्रबंधन के लिए उपयोग में आसान पुस्तकालय बनाने के लिए प्राथमिकता दूंगा।

हमने जिन विधानसभाओं का मिलान करने के लिए चुना है, उनकी सूची यहां है। @weshaggard को मुझे याद दिलाना होगा कि उन्होंने उस सूची को कैसे चुना। (मोनो में S.DirectoryServices है)

प्रारंभिक सीडिंग .NET फ्रेमवर्क के साथ Xamarin प्रोफाइल को इंटरसेक्ट करने से की गई थी। Xamarain प्रोफाइल (जो मोनो का एक सबसेट है) DirectoryServices का समर्थन नहीं करता है, इसलिए यह चौराहे पर नहीं था।

इस पर बहस करने के लिए हम क्या कर सकते हैं? Microsoft अनुप्रयोगों में सबसे आम प्रमाणीकरण योजना का उपयोग करने में असमर्थता एक अवरोधक है, नहीं? क्या यहाँ Azure और AAD पर ध्यान केंद्रित किया गया है? या यह अवरोधक है कि इसे प्लेटफॉर्म पर पोर्ट करना प्रोटोकॉल का एक बड़ा अज्ञात है?

क्या कोई तरीका है जिससे हम यहां प्राथमिकता बढ़ा सकते हैं? 2.0 बहुत दूर है, और अगर _everything_ और काम करता है तो यह वास्तव में दुर्भाग्यपूर्ण है, लेकिन हम उपयोगकर्ताओं को प्रमाणित नहीं कर सकते। यह इतने सारे अनुप्रयोगों के लिए वर्चुअल फ्रंट डोर है। आईएमओ, प्राथमिकता के मामले में यह थोड़ा अलग है क्योंकि यह आंशिक अवरोधक नहीं है, लेकिन अक्सर प्रकृति द्वारा पूर्ण अवरोधक है।

मुझे नहीं लगता कि कोई असहमति है कि हम .NET कोर में इसका समर्थन करना चाहते हैं, जो कि .NET मानक का हिस्सा होने से अलग है, यह कब की बात है। @tquerec क्षेत्र का मालिक है और वह वही होगा जो उससे बात करेगा।

.NET Foundation के किसी व्यक्ति ने पूछा, लेकिन हम जिन नामस्थानों का विशेष रूप से उपयोग कर रहे हैं वे हैं:
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

तो, @tquerec , हम System.DirectoryServices को .NET Core 1.2 के लिए कैसे फ़्लैग कर सकते हैं? कम से कम System.DirectoryServices.Protocols। क्या यह संभव है?

बहुत - बहुत धन्यवाद!

[@tquerec से अधिक जानकारी के साथ अपडेट किया गया]
मैं सोमवार को @tquerec से मिला। मैं सभी को एक लिखने देता हूँ। संक्षेप में:

• प्रणाली। DirectoryServices केवल विंडोज़ पर करने योग्य है (यह विंडोज़ डीएलएल में कॉल करता है जहां सभी कार्यान्वयन रहता है), लिनक्स/मैक के लिए पूरी तरह से अज्ञात
• System.DirectoryServices. AccountManagement इसके शीर्ष पर बैठता है, इसलिए केवल-योग्य विंडोज़, और Linux/Mac . के लिए अज्ञात है
• System.DirectoryServices. ActiveDirectory केवल विंडोज़ पर करने योग्य है (यह बहुत से विंडोज़ विशिष्ट एपीआई में कॉल करता है)
• System.DirectoryServices. विंडोज के लिए प्रोटोकॉल काफी सरल होना चाहिए और लिनक्स के लिए अधिक काम करना चाहिए (हमें उपयोग करने के लिए एलडीएपी लाइब्रेरी खोजने की जरूरत है)।
  हम @tquerec के साथ यह पता लगाने की कोशिश कर रहे हैं कि काम को कैसे फंड किया जाए - आदर्श रूप से 1.2 के लिए, लेकिन अभी तक कोई वादा नहीं किया गया है। मुझे उम्मीद है कि निर्णय में कम से कम दो सप्ताह लगेंगे।

सभी से प्रश्न :

• क्या उपरोक्त विंडोज़-ओनली स्कोपिंग प्रमुख उपयोग के मामलों के लिए स्वीकार्य है? (Sys.DirSer और Sys.DirSer.AccountManagement and Sys.DirSer.ActiveDirectory)
• यदि Sys.DirSer.Protocols Linux 1.2 के बाद आता है या सामुदायिक योगदान पर निर्भर करता है, तो क्या यह एक प्रमुख अवरोधक होगा?

@karelz System.DirectoryServices.ActiveDirectory बड़ी संख्या में Windows विशिष्ट API पर आधारित है, इसलिए यह S.DS और S.DS.AM के समान बकेट में आता है।

@karelz मुझे यकीन नहीं है कि विंडोज़ द्वारा केवल 1.2 के लिए समाधान का आपका क्या मतलब है। हमारे पास पहले से ही केवल विंडोज़ समाधान है जो काम करता है।

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

@ रॉक-मेस्टर मेरा मतलब है .NET कोर। जिसका आपने उल्लेख किया है वह "पूर्ण" .NET 4.5.2+ को लक्षित करता है।

हां, केवल विंडोज़ समर्थन हमारे लिए एक बड़ा अनब्लॉकर है। हम .NET कोर पोर्टिंग के लिए सभी काम कर सकते हैं और बाद में "मुफ्त में" प्लेटफॉर्म सपोर्ट का विस्तार कर सकते हैं, जब अंतर्निहित बिट्स करते हैं। _स्टार्टिंग_ से पोर्ट तक का अवरोधक भी बहुत बड़ा नहीं है। उसका जाना एक बड़ी जीत है।

विंडोज शॉप होने के कारण यहां भी यह बड़ी जीत होगी। इतने सारे बड़े उद्यम इसे एक बड़ी जीत मानेंगे! आपकी जानकारी के साथ अद्यतित रहने के लिए धन्यवाद। हमें तैनात रखें। धन्यवाद।

@karelz स्पष्टीकरण के लिए धन्यवाद। हां, 1.2 के लिए केवल विंडोज़ स्कोपिंग हमारे लिए काम करता है।
रॉकमेस्टर

System.DirectoryServices.Protocols with Linux /LDAP समर्थन हम जो काम करते हैं उसके लिए सर्वोच्च प्राथमिकता है ..

पीएस विंडोज़-ओनली स्कोपिंग .netcore / .netstandard . के लक्ष्यों के विपरीत लगता है

हमने कुछ समय पहले System.DirectoryServices का उपयोग करने से System.DirectoryServices.Protocols का उपयोग करने के लिए स्विच किया ताकि हम गैर-एडी एलडीएपी सर्वर का समर्थन कर सकें। प्रोटोकॉल नेमस्पेस तक पहुंच हमें अपने कोड को .NET कोर में पोर्ट करने की अनुमति देने के करीब एक कदम होगा।

हालांकि, अगर यह प्लेटफॉर्म-विशिष्ट होने जा रहा है तो हमारे लिए कम उपयोग होता है। .NET कोर में जाने की इच्छा का एक मुख्य बिंदु प्लेटफॉर्म पोर्टेबिलिटी है। हमें शायद इसके लिए अभी भी इंतजार करना होगा।

हमारे लिए .NET कोर तक पहुंचना डॉकर का लाभ उठाने और पूरी तरह से प्लेटफॉर्म अज्ञेयवादी होने की क्षमता थी। इसलिए केवल विंडोज़ के साथ एलडीएपी समर्थन के साथ फंसना फायदेमंद नहीं होगा।

आंतरिक चर्चा के लिए धन्यवाद।

मेरा वोट प्लेटफॉर्म इंडिपेंडेंट रूट से जा रहा है

मुझे मंच अज्ञेयवादी टिप्पणी से सहमत होना है, जितना कि यह दर्द होता है कि जब तक यह पूरा नहीं हो जाता तब तक मैं कोर का उपयोग नहीं कर सकता। मैं समझता हूं कि यह ऐसी चीज है जिसकी उच्च स्तर पर समीक्षा की जानी चाहिए। जो चीज मुझे नहीं मिलती वह है अवधारणा की जटिलता? कई निर्देशिका समाधान हैं, एडी, नोवेल, आदि ... यह एक क्रॉस प्लेटफॉर्म (अज्ञेयवादी) इंटरफ़ेस समाधान के लिए कहता है ... हैप्पी हॉलिडे!

जबकि व्यक्तिगत रूप से मैं विंडोज़-ओनली स्कोप के साथ पूरी तरह से ठीक रह सकता था, मेरी राय में यह .NET कोर और इसकी पोर्टेबिलिटी के विचार को तोड़ता है।
एक मंच स्वतंत्र समाधान पर ध्यान केंद्रित करने का मार्ग होना चाहिए।

हाँ, सहमत, .NET कोर क्रॉस-प्लेटफ़ॉर्म होना चाहिए और सुविधाएँ/एपीआई सभी समर्थित प्लेटफ़ॉर्म पर काम करना चाहिए!
तो अगर System.DirectoryServices.Protocols को पहले पोर्ट/कार्यान्वित किया जा रहा है, तो इसे लिनक्स पर भी काम करना चाहिए।

मैं सहमत हूं कि आदर्श रूप से एक मंच स्वतंत्र समाधान लक्ष्य होना चाहिए। हालाँकि अभी भी इसे विंडोज़ पर नहीं होना बहुत सारे डेवलपर्स के लिए एक अवरोधक है जो सिर्फ मेरे जैसे कॉर्पोरेट (एडी) पर्यावरण में मंच के साथ प्रयोग करना चाहते हैं। इसलिए मैं फिलहाल के लिए केवल विंडोज़ समाधान का स्वागत करूंगा।

मैं बस इसमें शामिल होना चाहता हूं और कहता हूं कि मैं केवल विंडोज़ समाधान के साथ ठीक हूं जब तक कि कुछ क्रॉस-प्लेटफ़ॉर्म एक साथ नहीं रखा जा सके।

मुझे लगता है कि 99.9% डेवलपर्स जिन्हें सक्रिय निर्देशिका से कनेक्ट करने की आवश्यकता है, वे एंटरप्राइज़ वातावरण में ऐसा कर रहे हैं जहां वे विंडोज़ बॉक्स पर विकास कर रहे हैं।

हम अपनी तरफ से फंडिंग पर चर्चा कर रहे हैं (~ 2 सप्ताह में अपडेट की उम्मीद है), यह वर्तमान में एपीआई से सर्वोच्च प्राथमिकता है जो अभी तक .NET मानक 2.0 का हिस्सा नहीं हैं।

क्या ऐसे लोग हैं जो विंडोज़ कार्यान्वयन और/या लिनक्स कार्यान्वयन में सहायता/योगदान देने के इच्छुक होंगे? (हम डेस्कटॉप से ​​​​कोड में ड्रॉप कर सकते हैं और इसे बनाने के लिए और अधिक मालिश की आवश्यकता होगी + कुछ परीक्षण)

@karelz मुझे चीजों के लिनक्स पक्ष के लिए योगदान करना अच्छा लगेगा। हमें Windows और गैर-Windows प्रमाणीकरण (ऑन-प्रिमाइसेस) दोनों के लिए इस समर्थन की आवश्यकता है। यह हमारे लिए एक अवरोधक है, और हम अपने क्रॉस प्लेटफॉर्म प्रोजेक्ट के लिए .NET कोर को लक्षित कर रहे हैं (पहले लिनक्स की तरफ मोनो और विंडोज की तरफ .NET था)।

जहां हम कर सकते हैं, बिना किसी संदेह के मदद करना चाहेंगे।

मुझे मदद करना अच्छा लगेगा लेकिन मुझे यकीन है कि आप लोग खुद से ज्यादा अनुभवी हैं और मैं किसी काम का नहीं होगा।

@karelz @tquerec मुझे विंडोज़ और भविष्य में, लिनक्स पर परीक्षण में मदद करने में खुशी होगी। मैंने थ्रेड की सदस्यता ली है, इसलिए बस यहां उत्तर दें या जब भी आपको शामिल होने के लिए मेरी आवश्यकता हो, तो संपर्क करने के लिए मेरा उल्लेख करें। इस पर आपके काम के लिए धन्यवाद। यह लंबे समय से प्रतीक्षित है और, भले ही वृद्धिशील हो, यह .NET कोर को आगे बढ़ाने के लिए एक अच्छा कदम होगा।

मुझे लगता है कि "विस्तारित विंडोज" शुरू में एक अच्छा लक्ष्य है, "विस्तारित" जिसका अर्थ है कि यह नैनोसेवर और कंटेनरों में काम करता है (यानी गैर-डोमेन में शामिल मशीनें जो पूर्ण .NET सीएलआर नहीं चला सकती हैं)। यह आपको एक त्वरित जीत और अन्य सर्वरों पर इसे लागू करने के लिए पीछे की ओर काम करने के लिए एक प्रारंभिक बिंदु देगा।

हमने इस काम को जल्द से जल्द अनब्लॉक करने का सबसे अच्छा तरीका खोजने के लिए @tquerec और हमारी प्रबंधन श्रृंखलाओं के साथ काम किया। दुर्भाग्य से हमारे पास जनवरी के अंत से पहले कोई भी व्यक्ति मुक्त नहीं है, इसलिए हम इस बीच केवल सीमित संसाधनों के साथ सामुदायिक योगदान को अनवरोधित करने के लिए अपना सर्वश्रेष्ठ प्रयास करेंगे और हमारी तरफ से कुछ स्वयंसेवी काम करेंगे ( @ianhays @tquerec and @karelz)।

यहाँ हम क्या करने की योजना बना रहे हैं:
@ianhays हमें CoreFX रेपो में प्रोजेक्ट शुरू करने में मदद करेगा (कुछ स्रोत कोड जोड़ें, उदाहरण दिखाते हुए कि इसे कैसे करना है, बिल्ड, पैकेजिंग स्थापित करने, भविष्य के लिनक्स/मैक पोर्ट आदि के लिए प्रोजेक्ट तैयार करने की सलाह दें)।
हम केवल विंडोज़ के कार्यान्वयन के साथ शुरू करेंगे (योगदान का स्वागत है)। हम इस बिंदु पर कार्यान्वयन या एपीआई सतह में कोई कार्यात्मक परिवर्तन नहीं करेंगे, जब तक कि वे पोर्ट के लिए .NET कोर के लिए आवश्यक न हों।
अगला (संभावित रूप से समानांतर) चरण परीक्षण जोड़ना होगा। हमें मौजूदा (क्लोज्ड-सोर्स .NET फ्रेमवर्क) परीक्षण डिजाइन पर @tquerec के साथ चर्चा शुरू करनी चाहिए, यदि कुछ है जिसका हम लाभ उठा सकते हैं, या यदि हमें शुरुआत से शुरुआत करनी है।
बाद में, हम Linux/Mac पोर्ट पर ध्यान केंद्रित कर सकते हैं।

@gortok @ h3smith @CalebMacdonaldBlack @ SOM-fermonte, और किसी और को दिलचस्पी है, @ianhays किक के प्रयास शुरू होने के बाद हमें आपका योगदान लेने में खुशी होगी (ETA: अगले सप्ताह के मध्य में मुझे लगता है)। यदि आपके कोई प्रश्न या सुझाव हैं, तो कृपया हमें बताएं।

क्या यह कार्य SqlClient जैसे पुस्तकालयों को लिनक्स पर चलते समय विंडोज प्रमाणीकरण करने की अनुमति देता है लेकिन एक SQL सर्वर से कनेक्ट होता है जिसके लिए विंडोज प्रमाणीकरण की आवश्यकता होती है?

लिनक्स पर चल रहे .NET कोर में चीजों को पोर्ट करने में सक्षम होने के लिए यह मेरे रोड-ब्लॉक में से एक है। हमारे सभी एंटरप्राइज़ Microsoft SQL सर्वर केवल एक सेवा आईडी (गैर-संवादात्मक) के माध्यम से कनेक्शन की अनुमति देते हैं जो AD में है।

BLGMboy. आपकी समस्या इस बात का एक प्रमुख उदाहरण है कि नए सुझाए गए मॉडलों के साथ वास्तविक क्रॉस-प्लेटफ़ॉर्म संगतता सुनिश्चित करने के लिए चीजों को "जांच" करने की आवश्यकता क्यों है। यदि आपके पास अधिक परिदृश्य हैं तो मुझे लगता है कि आपका पर्यावरण इस बात का एक अच्छा उदाहरण है कि चीजों को कैसे पार करने की आवश्यकता है और आपको कोर के एडी हिस्से के साथ होने वाली किसी भी अन्य समस्या को सूचीबद्ध करना चाहिए।

हां, मैं इस सूत्र को जरूर ध्यान में रखूंगा और जो कुछ भी मुझे मिले उसे साझा करूंगा। बस सभी को यह बताना चाहता था कि यह SQL फ़ार्म वाले उद्यमों के लिए एक बहुत बड़ा शो स्टॉपर है, जिसमें वर्णित के रूप में सख्त सुरक्षा है।

यह ईएफ कोर जैसी किसी चीज का उपयोग करने के लिए एक शो स्टॉपर भी है जो अंततः एक ही समस्या होगी।

System.DirectoryServices को अब CoreFX में मिला दिया गया है। अगला कदम इसे .NET कोर - विंडोज़ के लिए तैयार करना और परीक्षण जोड़ना है।

धन्यवाद इयान। इस मुद्दे पर कुछ कर्षण देखना अच्छा है!

धन्यवाद इयान!

अद्यतन निष्पादन योजना: संपादित करें: बेहतर खोज योग्यता के लिए इस अंक में सबसे शीर्ष पद पर ले जाया गया

यदि कोई किसी भी कदम पर काम कर रहा है, तो कृपया उसका उल्लेख करें और दोहराए गए प्रयास से बचने के लिए यहां समन्वय करें। मैं इस मुद्दे को आपको भी सह-असाइन कर दूंगा।

System.DirectoryServices नेमस्पेस में ऑन-प्रिमाइसेस एंटरप्राइज़ विंडोज़ ऐप्स के लिए ऐसी महत्वपूर्ण कार्यक्षमता शामिल है जो इस मुद्दे पर कुछ प्रगति देखने के लिए बहुत बढ़िया है। अच्छा काम करते रहें।

मैंने स्रोतों को ठीक कर लिया है और System.DirectoryServices अब निर्माण कर रहा है। मुझे जल्द ही एक पीआर भेजना चाहिए।

दूसरे दौर में योगदान देने के लिए धन्यवाद @tquerec !
क्या शेष 2 नामस्थानों या परीक्षणों में सहायता करने के लिए कोई स्वयंसेवक हैं? ( @gortok @h3smith @CalebMacdonaldBlack @ 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 प्राप्त करना एक उच्च प्राथमिकता है।

क्या मैं पुल अनुरोध सही पढ़ रहा हूँ? ऐसा लगता है कि इसे कुछ दिन पहले स्वीकार किया गया था, इसलिए यदि हम स्रोत से निर्माण करते हैं तो हमें इसे आज़माने में सक्षम होना चाहिए?

हां, मुझे लगता है कि हमारे पास सभी DirectoryServices बिल्डिंग हैं, हालांकि हमारे पास कोई परीक्षण नहीं है - जो हमें पैकेज को स्थिर के रूप में शिपिंग करने और कोड बेस (बग फिक्स, एन्हांसमेंट इत्यादि) में सुधार से रोकता है।
यदि आप इसे स्रोत से बनाने का प्रयास कर सकते हैं, तो यह बहुत अच्छा होगा। यदि आप (या कोई और) हमें परीक्षण जोड़ने में मदद करना चाहते हैं, या लिनक्स पोर्ट शुरू करना चाहते हैं, तो यह और भी बेहतर होगा :)

हेलो सब लोग,

हम एक उद्यम परियोजना शुरू करने के लिए तैयार हो रहे हैं जिसके लिए सक्रिय निर्देशिका समर्थन की आवश्यकता है क्योंकि हम अपने डोमेन के लिए 100% आंतरिक हैं। क्या कोई कृपया इस मुद्दे की स्थिति और अगली मुख्य रिलीज़ के लिए अपेक्षाएं प्रदान कर सकता है? मैं क्षमा चाहता हूं, लेकिन मैं गिटहब समुदाय के लिए नया हूं और अभी तक सभी विभिन्न शब्दावली और स्थिति की जानकारी नहीं समझता हूं।

पूरी तरह से अलग पहचान मॉडल के बजाय सदस्यता के लिए सक्रिय निर्देशिका का उपयोग करना बहुत अच्छा होगा, जिसे अलग से प्रबंधित करना होगा और साथ ही डेटा बेमेल भी होगा।

अग्रिम में धन्यवाद!

उस प्रश्न के लिए @karelz , लेकिन मुझे लगता है कि उत्तर यह है कि वर्तमान में 2.0 रिलीज में इसकी उम्मीद नहीं है, क्योंकि हमारे पास इसके लिए एक डेवलपर निर्धारित नहीं है। सामुदायिक योगदान का स्वागत है। इसे 2.0 रिलीज _in_ शिप करने की आवश्यकता नहीं है, यह किसी भी समय जहाज तैयार होने पर NuGet पर जा सकता है।

उत्तम! आपने मेरे प्रश्न का उत्तर दिया।

धन्यवाद।

@nevcoBpalacio योगदान पर शॉट लेने में कोई दिलचस्पी है?

मेरी रुचि है, विशेष रूप से इस विषय के साथ क्योंकि मुझे पता है कि यह कई लोगों को उद्यम समाधानों के साथ मूल में जाने से रोकता है। हालाँकि, हमारे पास एक काम है और मुझे इसके लिए दिन (बच्चों के साथ शाम) में समय नहीं मिल रहा है। मैं गिटहब के साथ काम करने के लिए घर पर अपने सिस्टम को फिर से टूल करने का प्रयास करूंगा। मैं आपकी सराहना करता हूं हालांकि पूछ रहा हूं! धन्यवाद।

Nevcobpalacio, यदि आप vs17 का उपयोग करते हैं और आपको क्रॉस प्लेट की आवश्यकता नहीं है, तो आप संपूर्ण .net ढांचे को लक्षित करने वाले कोर वेब ऐप टेम्प्लेट का उपयोग करके अपनी इच्छित चीज़ों के करीब पहुंच सकते हैं और पुराने तरीके से system.directoryservices.accountmanagement dll को रेफरी कर सकते हैं और इस दौरान ऐसा करने के लिए अपना खुद का मिडलवेयर रोल करें। मैंने जो देखा है उससे एक ही कोड को लक्ष्यीकरण .net कोर तक ले जाना चाहिए, सिवाय इसके कि आप nuget पैकेज का उपयोग करेंगे और रेफरी छोड़ देंगे। आशा है कि यह जानकारी आपके प्रोजेक्ट को पटरी पर लाने में मदद करेगी।

@ los93sol उस सुझाव के लिए धन्यवाद। हमारी प्रारंभिक चर्चा यह है कि इसे उस सुझाव के समान बनाया जाए और इसे एक मिडल वेयर मॉड्यूल बनाया जाए जिसे हम बाद में नुगेट में किसी भी भूमि पर "कट ओवर" कर सकें। बहुत बहुत धन्यवाद!

मुझे इस सुझाव पर आपकी टिप्पणी और प्रशंसा करनी है। कोर में इस बदलाव के बारे में मुझे पहले संदेह था। हालाँकि, इस सामुदायिक दृष्टिकोण के साथ, इस तरह की चर्चाएँ प्रकाश में आती हैं और इन बड़े बदलावों के दौरान सभी चीजों को हल करने में हमारी मदद करती हैं।

धन्यवाद।

क्या कोई वर्तमान में लापता परीक्षणों को जोड़ने पर काम कर रहा है, या System.DirectoryServices.Protocols को Linux/Mac में पोर्ट करने पर काम कर रहा है?

@pasikarkkainen AFAIK इस समय Microsoft टीमों की ओर से ऐसा कोई सक्रिय प्रयास नहीं है (जो निकट भविष्य में बदल भी सकता है और नहीं भी)। मैंने समुदाय से किसी को भी इस पर काम करना शुरू करते नहीं देखा।
क्या आप योगदान देने में रुचि रखते हैं, या सिर्फ स्थिति के बारे में उत्सुक हैं?

@karelz ऐसा लगता है कि वे इस गर्मी में .NET Core 2.0 रिलीज़ के लिए DirectoryServices को लक्षित कर रहे हैं।

@shanselman . से उद्धरण

एडी - पूरी तरह से, यह एक अंतर है यदि आप सीधे एलडीएपी को कॉल करना चाहते हैं। आप निश्चित रूप से अब विंडोज ऑथ के खिलाफ प्रमाणित कर सकते हैं। हम गर्मियों की समय सीमा के आसपास कोर 2.0 के लिए विशेष रूप से DirectoryServices नाम स्थान रखने की योजना बना रहे हैं

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

हां, यह दालान की चर्चाओं के अनुरूप है जो मैंने सुना है। मुझे अभी यकीन नहीं था कि यह सार्वजनिक जानकारी है और इसके लिए कितना (और किसने) प्रतिबद्ध किया है। मैं समझता हूं कि यह कहना सुरक्षित है, इस पर बहुत गहन विचार किया जा रहा है और ऐसा होने की संभावना है। मैंने @shanselman और DirectoryServices के मालिकों को समयसीमा पर टिप्पणी करने दिया।

@karelz : अपडेट के लिए धन्यवाद! मैं ज्यादातर स्थिति के बारे में उत्सुक था .. मैं निश्चित रूप से कम से कम परीक्षण में मदद कर सकता हूं, जब यह उपलब्ध हो जाता है।

@pasikarkkainen अगर आप कुछ परीक्षण मामलों को लिखने में मदद करने के इच्छुक हैं, तो इसकी बहुत सराहना की जाएगी।
यदि आप "बस" अपने ऐप/कोड पर पैकेज का परीक्षण करना चाहते हैं, तो यह आज ही करने योग्य होना चाहिए। हमें बस पैकेज को myget पर पूर्वावलोकन के रूप में प्रकाशित करना शुरू करना होगा (मुझे लगता है कि प्रकाशन आज अक्षम है)।

@karelz मुझे विशेष रूप से मैक कार्यान्वयन में मदद करने में कोई फर्क नहीं पड़ता। मुझे थोड़ा ज्ञान है, इसलिए मुझे यकीन नहीं है कि मैं कितना अच्छा योगदान दे सकता हूं। मैंने इसके चारों ओर शोध किया है और एक उपन्यास पुस्तकालय है जिसे लोग सुझाव देते हैं। उस उपन्यास पुस्तकालय के आसपास किसी और का कार्यान्वयन यहां मिला: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt पैकेज के लेखक ने यहां पहले ही इसका उल्लेख किया है।
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

तो क्या यह कुछ ऐसा है जो कोर 2.0 में होगा? मैं इसकी स्थिति को लेकर थोड़ा भ्रमित हूं।

नहीं, यह .NET Core 2.0 का हिस्सा नहीं होगा, हालांकि, बिल्ड कॉन्फ्रेंस में हमने समर के दौरान पैकेज की उपलब्धता का वादा किया था। (Windows) पैकेज .NET Core 2.0 के शीर्ष पर, .NET Core 2.0 जहाजों के समय के आसपास उपलब्ध होना चाहिए।
हम वर्तमान में मास्टर शाखा (#18090) में पूर्वावलोकन के रूप में पैकेज उपलब्ध कराने और समानांतर में परीक्षण संपत्तियों पर काम कर रहे हैं (#20669)।

जब हम साझा रनटाइम या गैर-विंडोज रनटाइम को लक्षित करते हैं तो क्या हमें संकलन त्रुटियां मिलेंगी? या हम PlatformNotSupported -ट्रैप के साथ समाप्त हो जाएंगे?

यह बिना किसी गैर-विंडोज संपत्ति के स्टैंडअलोन पैकेज होगा। संकलन टूटना चाहिए। @ericstj पुष्टि कर सकता है।

आपको संकलन त्रुटियां नहीं मिलेंगी, वे रनटाइम "प्लेटफ़ॉर्म नॉट सपोर्टेड" अपवाद होंगे।

हाँ, यह पुराना है - क्या हम इसका उपयोग करने वाले लोगों को .NET मानक पुस्तकालयों से ब्लॉक करते हैं, या क्या हम संकलन-समय त्रुटियों को PlatformNotSupported अपवादों में बदल देते हैं? ... सौभाग्य से एक बीच का रास्ता है: ApiCompat टूलिंग आपको समय से पहले बताएगी कि आप किसी ऐसी चीज़ का उपयोग कर रहे हैं जो हर जगह नहीं है।

जब मैं नेटस्टैंडर्ड 1.6 प्रोजेक्ट में System.DirectoryServices पैकेज का प्रयास करता हूं तो मुझे निम्न त्रुटि मिल रही है:

इंस्टाल-पैकेज: पैकेज सिस्टम। डायरेक्टरी सर्विसेज 4.0.0 नेटस्टैंडर्ड 1.6 (.NETStandard,Version=v1.6) के साथ संगत नहीं है। पैकेज System.DirectoryServices 4.0.0 सपोर्ट करता है: नेट (.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)

क्या प्रिंसिपल कॉन्टेक्स्ट को मैक पर काम करने की उम्मीद है?

@ ब्रूनो-गार्सिया विंडोज़ को छोड़कर निर्देशिका सेवाओं के लिए अभी कोरएफएक्स में कोई कार्यान्वयन नहीं है। @karelz को योजनाओं/आकांक्षाओं से बात करनी होगी यदि कोई हो।

केवल System.DirectoryServices.Protocol संभावित रूप से एक्स-प्लेट करने योग्य है (अभी तक लागू नहीं किया गया है) - ऊपर और शीर्ष पोस्ट में मेरे कुछ उत्तरों में विवरण देखें।

System.DirectoryServices.Protocols काम कर रहे क्रॉस प्लेटफॉर्म (लिनक्स/मैक पर भी) महत्वपूर्ण है। विंडोज़ पर काम करता है?

अगर मैंने इसे सही ढंग से समझा है, तो ADSI COM इंटरफेस पर बहुत सारी निर्भरता के कारण System.DirectoryServices को xplat बनाना मुश्किल होगा, जो कि विंडोज़ पर उपलब्ध है।

System.DirectoryServices.Protocols अभी भी रन xplat बनाने के लिए संभव होना चाहिए।

उसी कोड को चलाना जिसका मैंने पहले उल्लेख किया था:
```सी#
का उपयोग कर (var संदर्भ = नया प्रिंसिपल कॉन्टेक्स्ट (संदर्भ टाइप। डोमेन, डोमेन, $ "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" />

[संपादित करें] फिक्स्ड कॉलस्टैक और एक्सएमएल/सी # कोड सिंटैक्स हाइलाइटिंग @ karelz . द्वारा

@ ब्रूनो-गार्सिया कृपया अलग से मामला दर्ज करें। यह समग्र बंदरगाह प्रयास को ट्रैक कर रहा है, विशेष बग/मतभेद नहीं। धन्यवाद!

@ ब्रूनो-गार्सिया जिसे https://github.com/dotnet/corefx/issues/23605 द्वारा ट्रैक किया जाता है

अगला कदम डेस्कटॉप के माध्यम से डिबग करना और यह देखना हो सकता है कि व्यवहार कहां बदलता है। मैं इसे देखने के लिए एक देव को मुक्त करने का प्रयास करूंगा।

विंडोज़ सर्वर पर एक ही समस्या :( (संस्करण = "4.5.0-पूर्वावलोकन 2-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 का उपयोग करें

डॉटनेट पैकेज जोड़ें System.DirectoryServices --version 4.5.0-preview2-25707-02 --source 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 अगर मैं टिप्पणियों को सही ढंग से समझ रहा हूं तो यह लिनक्स आधारित तैनाती पर काम नहीं कर रहा है?

@euclid47 System.DirectoryServices.* वर्तमान में Linux पर समर्थित नहीं है। जैसा कि ऊपर चर्चा की गई है, पर्याप्त सामुदायिक हित/भागीदारी को देखते हुए इसके कुछ हिस्सों को संभावित रूप से पोर्ट किया जा सकता है।

@danmosemsft मुझे नहीं पता कि आप इस पूरे धागे को अक्टूबर 2015 से पर्याप्त सामुदायिक हित के रूप में कैसे खोल सकते हैं। अगर मेरे पास एलडीएपी संचार परत के रूप में जटिल कुछ लिखने के लिए आवश्यक कौशल है, तो मैं पहले से ही इस पर काम कर रहा होता, क्योंकि एडी एक उद्यम वातावरण में मुख्य प्रमाणीकरण तंत्र में से एक था। मैं यह बताऊंगा कि अधिकांश बड़े उद्यमों के लिए, लिनक्स पर इस प्रकार की बातचीत करने में असमर्थता सचमुच कोर के उद्देश्य को हरा देती है और उन्हें डॉटनेट के प्री-कोर बिल्ड से चिपके रहने का कारण बनेगी, इस प्रकार आपकी बहुमूल्य सामुदायिक बातचीत को सीमित कर देगी।

@danmosemsft इसके अलावा, यदि आप सचमुच इस पर काम करने की योजना नहीं बना रहे हैं, तो समुदाय को निश्चित रूप से बताएं ताकि अन्य डेवलपर्स टुकड़े उठा सकें।

@shairozan अब तक हमने 54 में से 7 वोट नोट किए हैं जो Linux पर DirectoryServices को विंडोज़ की तुलना में उच्च प्राथमिकता मानते हैं - देखें https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
डेवलपर्स को .NET कोर से केवल एक्स-प्लेटफ़ॉर्म की तुलना में अन्य लाभ भी मिलते हैं (हालाँकि मैं मानता हूँ कि एक्स-प्लेट शीर्ष कारणों में से एक है)।

मैं अनुशंसा करता हूं कि पहले केवल-विंडोज पैकेज के रिलीज को समाप्त करें, फिर हम लिनक्स पोर्ट के लिए रुचि को और अधिक सटीक रूप से ट्रैक करने के लिए नया मुद्दा खोल सकते हैं।

हमने समुदाय को पहले ही बता दिया है कि हम मदद की तलाश में हैं और इस मुद्दे को अप-फॉर-ग्रैब्स के रूप में चिह्नित किया गया है - 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) में परिणाम हुआ।

हमारी टीम को Linux पर समर्थन LDAP की आवश्यकता है।
क्योंकि हमारे अधिकांश ग्राहक LDAP के माध्यम से प्रमाणीकरण का उपयोग करते हैं।

@balkarov यदि आप कर सकते हैं, तो उस मुद्दे पर अपवोट करें जो @karelz ने अभी बनाया था ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 यदि आप पहले से ही जागरूक नहीं हैं तो Novell.Directory.Ldap.NETStandard Nuget पैकेज है जिसका उपयोग आप LDAP को अपनी परियोजनाओं में एकीकृत करने के लिए कर सकते हैं। हम उन्नत एलडीएपी उपयोगकर्ता नहीं हैं, हम इसका उपयोग केवल प्रमाण-पत्रों को सत्यापित करने और उपयोगकर्ता जानकारी प्राप्त करने के लिए करते हैं, लेकिन यह डॉटनेट कोर रनटाइम डॉकर छवि पर चलने वाले 1.0 और 2.0 दोनों पर हमारे लिए ठीक काम करता है। यह एक आधिकारिक तरीका नहीं है, लेकिन यह तब तक काम करता है जब तक कि System.DirectoryServices का क्रॉस प्लेटफॉर्म पोर्ट न हो।

@OskarKlintrot धन्यवाद। लेकिन यह पुस्तकालय डोमेन के बिना लॉगिन का समर्थन नहीं करता है।
मैं समस्या बनाता हूँ https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
क्या आप इस समस्या को हल करने में मेरी मदद कर सकते हैं?

मैं उस परियोजना या उन्नत उपयोगकर्ता का हिस्सा नहीं हूं, लेकिन मैं देख लूंगा, वहां मिलते हैं!

(हम किसी डोमेन से लॉगिन नहीं कर रहे हैं)

यह देखते हुए कि @karelz ने यूनिक्स के लिए एक मुद्दा तोड़ दिया, मैंने इसे स्पष्टता के लिए पुनः शीर्षक दिया।

@danmosemsft लेकिन मुद्दे की योजना है
लिनक्स / मैक पोर्ट।

@balkarov मैंने अन्य ट्रैकिंग मुद्दों से लिंक करने की योजना को अपडेट किया है और उन आइटमों के लिए चेक बॉक्स हटा दिए हैं जिन्हें अलग से ट्रैक किया गया है (टूटा हुआ काम) या विंडोज़ काम को अवरुद्ध नहीं करता है।

क्या System.DS पोर्ट RODC सर्वर (केवल-पढ़ने के लिए डोमेन नियंत्रक) के साथ संगत होगा?

@PKGeorgiev आपको वही System.DirectoryServices समर्थन मिलना चाहिए जो हमारे पास पूर्ण ढांचे में है।

Windows के लिए DirectoryServices पर कार्य समाप्त हो गया है, जिससे समस्या समाप्त हो गई है।
ध्यान दें:

• अंतिम पैकेज प्रकाशन को dotnet/corefx#24909 . द्वारा ट्रैक किया जाता है
• Linux/Mac पोर्ट को dotnet/corefx#24843 . द्वारा अलग से ट्रैक किया जाता है

नमस्ते, क्या यह UWP में काम करेगा?

नमस्ते, क्या यह UWP में काम करेगा?

नहीं, यह केवल विंडोज़ और पूर्ण ढांचे पर चलने वाले नेट कोर ऐप्स के लिए समर्थित है। यदि आप इसे UWP या Linux पर उपयोग करते हैं, तो आपको PlatformNotSupported अपवाद मिलेगा।

मैं इस कोड का उपयोग एडब्ल्यूएस में लैम्ब्डा फ़ंक्शन में कर रहा हूं जो पृष्ठभूमि में लिनक्स पर चलता है और मुझे यह त्रुटि मिल रही है। "System.DirectoryServices.AccountManagement इस प्लेटफॉर्म पर समर्थित नहीं है।"
मैं कोर 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 पर समर्थित नहीं है। यह केवल विंडोज़ पर समर्थित है।

@sscoleman इस पर एक समस्या बनाई गई है, https://github.com/dotnet/corefx/issues/24843। यह कहा गया था कि इसमें पर्याप्त सामुदायिक हित नहीं थे, अपवाद के साथ यह प्रश्न हर समय सामने आता है। तो अब आप एक बकवास जगह पर हैं। आपने निर्देशिका सेवाओं को लागू करने में समय बिताया और फिर पता चला कि लिनक्स समर्थित है। अब आप खुद से पूछें कि अगर विंडोज़ में केवल विशेषताएं हैं तो इसे प्लेटफॉर्म अज्ञेयवादी क्यों कहा जा रहा है।

यदि आप अधिक से अधिक Microsoft रणनीति को देखें तो यह काफी स्पष्ट है। Microsoft अपने सभी विकास संसाधनों को Azure में फेंक रहा है, और इसमें सक्रिय निर्देशिका शामिल है। "2016 में नया क्या है" देखें, यह ज्यादातर AzureAD/हाइब्रिड निवेश है। https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft इस लाइब्रेरी में Linux के लिए निवेश नहीं कर रहा है क्योंकि वे चाहते हैं कि हर कोई इसके बजाय Azure AD में चले जाए। यह समझ में आता है, आप उस चीज़ में निवेश क्यों करेंगे जिससे आप ग्राहकों को दूर करने की कोशिश कर रहे हैं?

हालांकि आप अपेक्षाकृत सरल कुछ कर रहे हैं। आप उपन्यास एलडीएपी पुस्तकालयों का उपयोग कर सकते हैं, वे एडी के साथ और लिनक्स के लिए .NET कोर पर काम करते हैं। आपको प्रोटोकॉल को स्वयं करने की आवश्यकता है, लेकिन यह अत्यधिक जटिल नहीं है, और वहाँ बहुत सारे नमूने हैं। नकारात्मक पक्ष यह है कि आपको स्वयं को बाध्य करने का प्रबंधन करने की आवश्यकता है, जिसके लिए उपयोगकर्ता डीएन और पासवर्ड की आवश्यकता होती है।

System.DirectoryServices वर्तमान में केवल विंडोज़ एपीआई है और यह .NET कोर के लिए विंडोज़ संगतता-पैक का हिस्सा है। सिद्धांत रूप में, हम System.DirectoryServices के कुछ हिस्सों को Linux पर काम कर सकते हैं लेकिन हमारे पास अभी तक ऐसा करने के लिए संसाधन नहीं हैं। dotnet/corefx#24843 इस कार्य आइटम को ट्रैक कर रहा है।

हम ऐसे पैकेज स्थापित करने की अनुमति क्यों दे रहे हैं जो Linux पर काम नहीं करेंगे? विकल्प एपीआई सतह को फोर्क करना होगा लेकिन यह सभी मामलों के लिए अच्छा काम नहीं करता है और समग्र प्रणाली को कोड के खिलाफ कठिन बनाता है। बेशक, हमारी पसंद समस्याओं के बिना नहीं है, क्योंकि इससे यह अनुमान लगाना कठिन हो सकता है कि कोड क्रॉस-प्लेटफ़ॉर्म पर काम करेगा या नहीं। हमारे पास एक संगतता विश्लेषक का पूर्वावलोकन है जो आपको कोड के रूप में लाइव फीडबैक देता है।

हम Windows संगतता पैक और क्रॉस-प्लेटफ़ॉर्म विश्लेषक को एक साथ काम करते हुए कैसे देखते हैं, इस बारे में अधिक संदर्भ के लिए यह वीडियो देखें:

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

@thedevopsmachine

Microsoft इस लाइब्रेरी में Linux के लिए निवेश नहीं कर रहा है क्योंकि वे चाहते हैं कि हर कोई इसके बजाय Azure AD में चले जाए।

ऐसा नहीं है कि मैं इसे देखता हूं। जैसा कि आपने बताया, हम Azure के माध्यम से पैसा कमाना चाहते हैं। और Azure एक क्लाउड प्लेटफ़ॉर्म है जो विभिन्न प्रकार की तकनीकों और ऑपरेटिंग सिस्टम की पेशकश करता है। क्लाउड में लिनक्स पर क्लाउड में विंडोज को बढ़ावा देने के लिए हमारा कोई व्यावसायिक हित नहीं है। लेकिन निश्चित रूप से, .NET की विंडोज़ पर 15 वर्षों से मजबूत उपस्थिति रही है। सभी ऑपरेटिंग सिस्टम में चीजों को पूरी तरह कार्यात्मक बनाने में समय लगता है, लेकिन मुझे ईमानदारी से लगता है कि हमारे ओपन सोर्स प्रयासों का अनुसरण करने वाले अधिकांश लोग देख सकते हैं कि हम उद्देश्य से लिनक्स को बाधित नहीं कर रहे हैं। बस समय लगता है।

मैं लगातार एपीआई एक्स-प्लेट और एक्स-फ्रेमवर्क रखने के दृष्टिकोण से सहमत हूं, लेकिन जब भी आईव को उस भयानक त्रुटि का सामना करना पड़ता है तो यह आत्मा को नष्ट कर देता है .. मुझे @sscoleman के लिए लगता है ...

क्या यह DirectoryServices पैकेज CentOS 7 पर काम कर सकता है?

क्या यह DirectoryServices पैकेज CentOS 7 पर काम कर सकता है?

पैकेज स्थापित किया जा सकता है लेकिन काम नहीं करेगा। इसका उपयोग करते समय आपको प्लेटफ़ॉर्म समर्थित अपवाद नहीं मिलेगा। हम देख रहे हैं कि हम सामान्य रूप से लिनक्स पर निर्देशिका सेवाओं का समर्थन कैसे कर सकते हैं। यह हमारे रडार पर है।

इसे वास्तव में समर्थन की आवश्यकता है linux

सीसी @joperezr

@niemyjski देखें डॉटनेट/कोरएफएक्स#24843

इसे वास्तव में समर्थन की आवश्यकता है linux

.. प्लस एक डॉकटर कंटेनर में चलने में सक्षम हो। इम्हो यह गधे में दर्द है कि किसी को पुराने नोवेल निर्देशिका कार्यान्वयन पर वापस आने की जरूरत है जब कोई लिनक्स पर .NET कोर 2+ का उपयोग करना चाहता है।
वैसे भी इस पर काम करने के लिए धन्यवाद!

इस मुद्दे को क्यों बंद करें? System.DirectoryServices.AccountManagement अभी भी विंडोज़ के बाहर .NET कोर में नहीं है:

# 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 बहुत बड़ा है और मुझे संदेह है कि पूरी कार्यक्षमता केवल एक रिलीज में समर्थित हो सकती है। विशिष्ट अनुरोध होने से संपूर्ण डीएस पुस्तकालयों का समर्थन करने का अनुरोध करने से बेहतर मदद मिल सकती है। .NET 5.0 में हमने https://github.com/dotnet/runtime/issues/23944 एक परिदृश्य सक्षम किया है।

सीसी @joperezr

@tarekgh
मुझे System.DirectoryServices.Protocols के बारे में पता नहीं था, लेकिन ऐसा लगता है कि यह अभी भी security.principal.windows पर निर्भरता है, क्या यह लिनक्स में भी काम करता है (मूल लेख आदि के माध्यम से) या यह एक लापता फेंक देगा असेंबली त्रुटि?

लक्ष्य एक्सप्लेट होने के लिए ActiveDirectory Powershell मॉड्यूल जैसे कुछ को फिर से कार्यान्वित करना है, मैं उस उद्देश्य के लिए उपन्यास 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 क्या आप प्रोटोकॉल का उपयोग करके इसे प्राप्त नहीं कर सकते?

शायद मैं कर सकता हूँ। मैंने नोवेल लाइब्रेरी का उपयोग करने के लिए कुछ चीजें फिर से लिखीं। लेकिन इसके लिए मेरे मौजूदा .NET फ्रेमवर्क कोड में एक पुनर्लेखन और इस प्रकार अनावश्यक कोड की आवश्यकता है। मैं निश्चित रूप से सभी कोड के कोड विभाजन से बचना पसंद करता हूं, और मुझे यकीन है कि अन्य लोग भी इस विचार को नापसंद करते हैं।
मैं यह भी सोच रहा हूं कि प्रमाणीकरण कैसे काम करता है। नोवेल (पुराने संस्करण की मैंने कोशिश की) के साथ मुझे क्रेडेंशियल निर्दिष्ट करना होगा, जबकि मेरे मौजूदा कोड के साथ मुझे इसकी आवश्यकता नहीं है।
धन्यवाद, जोआचिमो