@vibronet

이에 대한 업데이트가 있습니까?

저도 이에 대한 업데이트를 원합니다. 회사에서 LDAP를 통해 Active Directory를 쿼리하는 기능이 필요한 새 앱을 빌드하도록 하고 있지만 현재로서는 불가능한 것으로 보입니다. 그것에 대한 계획된 지원이 있습니까, 아니면 다른 것을 위해 삭제되고 있습니까, 아니면 어디에도 문서화되지 않은 이미 작동하고 있습니까?

.NET CoreFX에서 LDAP 및 Active Directory 지원 구현에 대한 새롭고 신선한 관점이 있으면 좋을 것입니다.

.NET Core에서 활용할 수 있는 Active Directory/LDAP 솔루션이 정말 필요합니다. 클린 시트 구현이든 System.DirectoryServices의 포트이든 저에게는 그다지 중요하지 않습니다. AD 인증이 절대적으로 필요한 비즈니스 중심 Windows 애플리케이션이 많이 있으며, LDAP 인증은 플랫폼 간 개발자에게 훌륭한 기능 글머리 기호가 될 것입니다.

위의 이전 버전과 호환되는 참고 사항에 동의 - 직접 포트가 실제로 필요하다고 생각하지 않습니다. Active Directory 또는 모든 LDAP 공급자에 대해 인증에 액세스(및 기타 작업 수행: 검색, 잠금 해제, 삭제 등)하는 방법만 있으면 됩니다. .

@NickCraver

직접 포트가 실제로 필요하지 않다고 생각합니다. Active Directory에 대해 인증 [...]에 액세스하는 방법만 있으면 됩니다.

알아두시면 좋습니다. 방금 적용한 포트 대 코어 레이블을 너무 많이 읽지 마십시오. 귀하와 같은 고객이 앱을 .NET Core로 이식하지 못하도록 하는 것은 .NET Core 제품의 격차를 추적하는 제 방식일 뿐입니다.

@terrajobst 갓챠 . 모듈성 때문에 이것이 반드시 1.0 항목이어야 한다고 생각하지는 않지만(어쨌든 RTM 이후로 예정된 것처럼 _소리_), 저는 그것을 기대합니다. 그것은 나를 위해 Opserver를 이식하는 데 방해가 될 것이므로 우리가 사용할 수 있다면 API 토론에 참여하게 되어 기쁩니다. sysadmin 측에서 도움이 될 수 있는 다양한 사용 사례가 있습니다. 도움이 될 수 있으면 핑(ping)하십시오.

링에 또 다른 모자를 던지기 위해서입니다. 현재 이것은 나에게도 남은 가장 큰 차단기입니다. 단순히 인증할 수 있다는 것만으로도 지금은 큰 도움이 될 것입니다.

이를 지원할 계획이 전혀 없다면 이에 대한 계획에 대해 개발팀의 누군가로부터 공식 응답을 받을 수 있습니까?

직접 포트가 실제로 필요하다고 느끼지 않습니다

왜요? 혼란스러워 죄송합니다. DRY 원칙에 따라 모두에게 가장 쉬운 솔루션이 아닐까요?
그럼에도 불구하고 전체 API를 처음부터 작성해야 하는 이유가 있다면 이전 API(동일한 메서드 서명)와의 일부 일관성이 소비자에게 덜 혼란스러울 것입니다.

@jasonwilliams200OK 분명히 말씀드리겠습니다. 저는 구체적으로 DirectoryServices.ActiveDirectory 를 의미했습니다. 내 생각에 인증과 그 주변의 것들: 예를 들어 그룹 멤버십은 네임스페이스의 95-99% 사용 사례입니다. 나는 _that_의 직접 서명 포트가 꽤 유용하다고 생각합니다. 나머지 영장이 어떤 이유로 변경되면 나는 그것에 대해 꽤 괜찮고 나중에 오면 괜찮습니다. 많은 사람들에게 방해가 되기 때문에 인증은 최대한 빨리 문을 나가는 것이 좋습니다.

Active Directory 사용자를 검색하고 ASP.NET 5를 사용하여 사용자 지정 역할과 매핑하는 기본 기능을 통합하면 ASP.NET 웹 응용 프로그램에 Windows 인증을 쉽게 구현할 수 있습니다. 인트라넷 사이트에서 이 기능이 필요합니다.

이것은 우리에게도 방해가 됩니다. ldap 서버에 대해 인증, 사용자 및 그룹 쿼리, 새 사용자 및 그룹 생성 등을 할 수 있어야 합니다.

그것은 또한 나를 위한 차단기입니다. 사용자를 쿼리하고 인증해야 합니다.

.NET Core rc1 웹 애플리케이션에서 Active Directory에 대해 인증하기 위한 솔루션을 생각해 냈습니다. UserManager 클래스에서 CheckPasswordAsync 메서드를 재정의하기만 하면 됩니다. 당신이 무슨 생각을하는지 제게 알려주세요.

먼저 사용자가 이메일 주소와 비밀번호 대신 AD 사용자 이름을 입력할 수 있는 사용자 정의 등록 페이지를 만들어야 합니다. 해당 사용자 이름은 개별 사용자 계정 인증을 선택할 때 ASP.NET 5 템플릿에 의해 생성된 ApplicationUser 클래스의 UserName 속성에 들어갑니다. 또한 Password 속성을 IdentityUser 클래스의 내부 유효성 검사를 통과하는 것으로 기본 설정해야 합니다.

내 등록 페이지 컨트롤러는 AD에서 사용자 이름을 찾고 해당 사용자에 대한 AD 정보를 보유하는 JSON을 반환하는 Web API 2 메서드를 호출합니다. AD 정보를 보유하기 위해 ApplicationUser 클래스에 몇 가지 사용자 정의 속성을 추가했습니다. 다음 주에 내 프로젝트의 코드를 게시하겠습니다.

그런 다음 Services 폴더에 클래스 파일을 추가합니다. 내 이름을 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 여기에서 차임을 해야 합니다. 유선을 통해 일반 텍스트로 다른 응용 프로그램에 다시 사용자의 암호를 릴레이하는 것은 _정말로_ 나쁜 생각이기 때문입니다. 이 방법을 사용하지 마십시오. 보안 구멍입니다.

@terrajobst 이것은 Opserver와 같은 더 큰 애플리케이션을 포팅 하는 데 방해가 될 것입니다. 우선 순위를 지정할 수 있습니까?

@NickCraver 자격 증명을 일반 텍스트로 전달하는 것을 제안한 적이 없습니다. 일반적으로 승인된 사용자만 볼 수 있는 데이터를 반환하기 때문에 일반적으로 모든 웹 응용 프로그램/서비스에 SSL을 사용합니다. 자격 증명을 일반 텍스트로 보내지 않으려는 것이 너무 분명하기 때문에 지정하지 않았습니다.

나는 최소한 System.DirectoryServices.Protocols 의 포트를 제공하는 것을 지지할 것입니다. System.DirectoryServices.ActiveDirectory 네임스페이스는 AD 서버와만 통신하기를 좋아하기 때문에 최근에 LDAP 관련 코드를 이 코드로 변경하여 더 넓은 범위의 LDAP 서버를 지원했습니다.

제 생각에는 타사 라이브러리가 이러한 지원을 시작하는 것이 가능하지만 프레임워크에 이미 존재하므로 포트가 더 간단할 것이라고 상상합니다.

WTF asp 팀은 이 기본 기능을 제공하지 않습니다.
이것은 정말 차단 문제입니다 :(

CoreCLR에서 LDAP 지원에 대한 업데이트가 있습니까?

나는 또한 이것에 대한 업데이트를 원합니다. AD 서버에 대해 사용자를 인증해야 하는 ASP.NET Core로 엔터프라이즈 애플리케이션을 개발할 것입니다.

System.DirectoryServices를 v1.1.0용 .NET Core로 이식하는 방법을 살펴보겠습니다(https://github.com/dotnet/corefx/milestones).

@joshfree
또한 ADLDS에서 사용자를 인증해야 합니다. System.DirectoryServices.AccountManagement도 고려하십시오.

몇 년 전에 내가 일했던 회사는 Novell(모노) LDAP 라이브러리 소스 코드를 사용하여 우리 애플리케이션이 Active Directory, OpenLDAP 및 Oracle 시스템과 통신할 수 있도록 했으며 페이징 컨트롤에 대한 지원을 추가하고 일부 TLS 수정 사항을 업데이트했습니다. 우리는 Linux에서 실행하기를 원했기 때문에 이 작업을 수행했습니다. 변경 사항이 포함된 PR이 소유자에게 전송되었습니다. 이제 CoreCLR을 사용하려면 라이브러리를 RC2로 변환해야 합니다. 작업은 https://github.com/VQComms/CsharpLDAP/pull/1 에서 시작되었으며 주소 지정이 필요한 17개의 컴파일러 오류가 남아 있습니다. 주로 Thread.Abort , ThreadInterruptedException 이며 Mono에서 CoreCLR로 TLS 스트림을 대체합니다. SslStream 관심이 있고 CoreCLR에 대한 LDAP 지원이 필요한 사람이 있으면 언제든지 도와주세요.

ASP.NET Core 웹 애플리케이션(.NET Framework) RC2 프로젝트가 System.DirectoryServices.AccountManagement를 사용하는 클래스 라이브러리를 참조할 수 있음을 확인했습니다. 웹 응용 프로그램과 클래스 라이브러리가 모두 VS 2015 업데이트 2로 생성되고 둘 다 .NET Framework 4.6.1을 사용하는 경우에만 작동하도록 할 수 있습니다.

다른 사람들의 감정을 반영하기 위해 우리는 LDAP 등을 쿼리할 수 없는 물 이식에서 죽었습니다.

@h3smith
내 이전 게시물을 참조하십시오. RC2 릴리스로 이제 System.DirectoryServices.AccountManagement 를 사용하는 클래스 라이브러리를 참조할 수 있습니다.

넷스탠다드에는 없습니다.

그러나 내가 말했듯이 우리는 이것을 작동시키기 위해 노력하고 있습니다. 바라건대
약 2-3주 안에 뭔가

2016년 6월 17일 금요일에 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
.

이에 대한 업데이트가 있습니까? 사용자가 LAN에서 각도 웹 앱을 사용하고 AD에 로그인하고 aspnet core RC2에서 WebAPI 컨트롤러 메서드(사용자가 웹 브라우저에 암호를 입력하지 않고)를 호출할 때 호출 사용자를 인증해야 합니다. 가능한? 곧 가능?

이렇게 하려면 클라이언트의 http 요청에서 withCredentials를 사용해야 합니다. 그런 다음 User.Identity를 사용하여 컨트롤러에서 사용자 정보와 클레임을 가져올 수 있습니다.
이것은 ie 및 chrome에서 작동하지만 Firefox를 사용하면 사용자가 Windows 사용자와 암호를 입력하도록 팝업이 자동으로 표시됩니다.

우리는 약 두 달 전에 동일한 문제(예: LDAP 서버를 사용자 저장소로 사용하려고 함)에 부딪쳤습니다. Novell LDAP 라이브러리(https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html)를 .net core(여기 https://github.com/dsbenghe/Novell 참조)로 이식하는 것 외에는 솔루션을 찾을 수 없습니다. 디렉토리.Ldap.NETStandard). 너겟 패키지가 게시되었습니다. 우리는 OpenDJ LDAP 서버와 함께 라이브러리를 사용하고 있습니다(모든 LDAP 서버와 함께 작동해야 함) - 1.5개월 사용에 문제가 없습니다.

@dsbenghe 우리는 Netstandard에서 Novell LDAP lib 컴파일을 가지고 있으며 우리 것도 페이징을 포함합니다. 이것은 @igorshmukler 가 수행했습니다. 비교하고 협업하시겠습니까? 우리는 여기에서 WIP입니다. 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;
}

간단한 도우미 클래스를 사용하여 Angular 애플리케이션에 진행 상황을 알립니다.

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 Core에 대한 System.DirectoryServices 지원에 대해 작업할 것입니다.

기다릴 수 없어! 예상 시간? 디자인 스펙?

마침내 이식되면 다음 항목에 액세스할 수 있습니다.

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;  
}

ETA가 있습니까? 이달말에 완료될 예정인 시스템에서 사용할 수 있는데...

@johnkwaters 클래스 라이브러리에 AD 코드를 넣을 수 없는 이유가 있습니까? 일부 사람들(저 포함)은 ASP.NET Core 애플리케이션에서 레거시 클래스 라이브러리를 참조하는 데 문제가 있었습니다. 그러나 VS 2015 업데이트 3에서 웹 앱 및 클래스 라이브러리를 만들고 웹 앱 및 클래스 라이브러리에서 .NET Framework 4.61을 대상으로 하는 경우 문제가 없습니다.

클래스 라이브러리에 AD 코드를 넣을 수 없는 이유가 있나요?

.NET Core TxM용 project.json에서 PCL 다음에 "imports": "portable-net45+win8" 를 의미합니까? 이를 위해서는 Mono PCL Reference Assemblies가 Unix에서 자급자족을 허용하는 "순수 도넷 코어" 솔루션이 아니라 Unix에 있어야 합니다. 컴파일러를 침묵시키는 것은 좋은 해킹이지만 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

ETA에 대한 업데이트가 있습니까? 반복되는 질문이 있는 셀프 서비스는 어디로 가야 하나요?

_정말_ 이 기능을 기대합니다!

이 기능도 정말 기대됩니다!!

이 기능도 정말 기대됩니다!!

저도 이 기능이 절실히 필요합니다!

얘들아, 당신은 모두 메인 게시물에 반응을 추가 할 수 있습니까?

또는 2명의 다른 사람이 너겟에 올려놓은 라이브러리를 사용하십시오. 그것의
모든 OSS. 패키지가 마음에 들지 않으면 PR을 보내십시오.

2016년 9월 8일 12:19 Mikhail Orlov 알림 @github.com
썼다:

얘들아, 당신은 모두 메인 게시물에 반응을 추가 할 수 있습니까?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

@jchannon Novell LDAP의 경우 +1입니다. 이를 통해 우리는 앞으로 나아갈 수 있었고 LDAP 구현에 거의 변경 사항이 없었습니다. 나는 당신이 올바르게 추상화하고 있다는 것을 의미합니다 ;)

예, @jchannon Novell LDAP도 사용하게

내가 전에 그렇게 말하지 않았다면, https://github.com/VQComms/CsharpLDAP/commits/coreclrPort 에 모든 것이 있습니다.

현재 우리의 요구 사항에 잘 작동합니다 ...

@h3smith @johnkwaters 문제가 있으면 언제든지 문제를 제기하세요 😄

Novell로 시도하기로 결정했습니다. 샘플은 충분히 좋아 보이지만 Novell LDAP를 사용하여 그룹에서 사용자 구성원을 추방(제거)하는 방법을 모르겠습니다.
userPassword를 볼 수 없고 LDAP 서버에 설정되지 않았기 때문에 MSAD LDAP에서 비밀번호를 변경할 수 없습니다.

이건 정말 필요해!

@joshfree 또는 아는 사람...
ActiveDirectoryServices.AccountManagement에 대한 액세스가 필요한 새 프로젝트를 시작하려고 합니다. 질문, 포트가 1.1 또는 1.2를 대상으로 합니까?

이것은 1.1의 일부가 아닙니다(곧 마무리될 예정입니다). @tquerec , 여기에 당신의 계획에 대해 의견을 말씀해 주시겠습니까?

참조: @danmosemsft

1.1에 포함되지 않은 경우 계획이 있는 사람이 있습니까? 지원하지 않는 것이 큰 문제인 것 같습니다. 분명히 Microsoft는 이러한 통합을 원할 것입니다.

또 한 표입니다. 기본적인 엔터프라이즈 기능이 부족한 경우 .NET Core에서 엔터프라이즈급 시스템을 구축하기 위한 투자를 하기 어렵습니다. 소설 프로젝트는 작동하지만 스너프까지는 아닙니다.

또 한 표. 나는 이것이 모든 엔터프라이즈 애플리케이션을 만드는 데 필수적이라는 동일한 진술을 반복할 것입니다.

@nevcoBpalacio 나는 그들이 우리에게 azure Active Directory를 사용하도록 강요하려고 한다고 생각합니다.

서비스가 집에 남아 있어야 하는 기업 계약을 사용하는 사람들에게는 결코 작동하지 않을 것입니다.

저는 연방 및 현재 지역 카운티의 정부 기관에서 일해 왔으며 어느 쪽이든 클라우드 기반 또는 온프레미스의 일부 디렉토리 서비스에 통합하려면 여전히 일부 인터페이스 또는 기능이 필요합니다. 수십억 달러를 관리하는 응용 프로그램을 공동 개발했으며 항상 디렉터리 서비스가 필요합니다. 나는 이것이 다른 투표 이상이라고 생각합니다. 오히려 당신이 무엇을 기다리고 있는지에 대한 진술입니까? 나는 이것이 원래 이전 .NET 릴리스에서 즉시 사용 가능한 솔루션이었다는 이전 게시물에 동의합니다. CORE의 보다 개방적인 구조가 커뮤니티의 추진력을 얻어야 한다는 점을 이해합니다. 이것이 Microsoft가 기다리기로 선택한 것이라면, 아마도 그들이 이것을 말하고 제가 놓쳤다면 누군가가 주도적으로 시간을 투자할 수 있도록 말해야 한다는 것을 이해합니다. 완료합니다.

예, .NET Core에 System.DirectoryServices를 추가하십시오!

우리는 내년 안에 System.DirectoryServices.Protocols를 이식할 계획이 있습니다. 이 시점에서 더 확실한 날짜를 제공할 수 없습니다. System.DirectoryServices 또는 System.DirectoryServices.AccountManagement를 이식할 계획은 아직 없지만 관심을 측정하는 데 관심이 있습니다. 프로토콜로 해결할 수 없는 네임스페이스의 기능이 사람들이 사용하고 있습니까?

@tquere 저는 프로토콜에 익숙하지 않습니다. 계정 잠금 해제 및 계정 암호 재설정을 수행하기 위해 Active Directory 셀프 서비스를 수행하는 프로젝트가 있습니다. 프로젝트에서 UserPrincipal을 사용하고 FindByIdentity, UnlockAccount, SetPassword, ExpirePasswordNow와 같은 메서드를 호출합니다.
이것이 프로토콜에서 수행될 수 있는지 확실하지 않지만 프로토콜이 낮은 수준의 구현인 것처럼 보입니다. AccountManagement는 ActiveDirectory 작업을 위한 더 나은 추상화입니다.
감사 해요
록마이스터

@nevcoBpalacio 는 내가 동의하는 한 표 이상이어야 합니다. 이것이 더 우선시되어야 한다고 생각합니다.

@CalebMacdonaldBlack 사용 패턴과 왜 필요한지에 대한 @tquerec 질문에 답할 수 있다면 도움이 될 것입니다. 시나리오가 없는 더 많은 찬성 또는 "동의합니다/중요합니다"는 현재 우선 순위를 높이는 데 도움이 되지 않습니다... 감사합니다!

우리의 용도는 LDAP 스캔/검색, 자격 증명 확인을 위한 BIND 수행, LDAP 개체(사용자, 그룹) 추가/제거, 그룹의 구성원 수정 등입니다.

@tquere 저는 System.DirectoryServices.AccountManagement가 정말 필요하므로 Active Directory에 대해 사용자를 인증하고 액세스 권한이 있는 그룹에 권한을 부여할 수 있습니다.

h3smith에 확실히 동의합니다. 우리는 v1에 이것을 필요로 했고 대신에 우리가 함께 호벨링한(특히 복제 비트) 새로운 경로로 이동해야 했으며 유지 관리 등의 오버헤드로 인해 슬픔을 겪고 있습니다. 이것은 .NETCore를 만들고 있습니다. 부작용으로 안좋아보임..

@liquidboy

우리는 v1에 이것을 필요로했습니다

.NET Core v1을 의미합니까? -- 완료되어 배송됩니다. 우리는 지금 1.2에서 작업하고 있습니다. 아니면 다른 뜻이었나요?

대신 소설의 길을 가야 한다

무슨 뜻인가요? (DirectoryServices에 대한 컨텍스트가 없어 죄송하지만 시나리오의 관점에서 우리가 놓치고 있는 부분을 이해하고 싶습니다.)

@karelz 는 이 스레드에서 "novel"이라는 단어를 검색하면 무슨 말인지 알 수 있습니다. 우리 팀의 다른 개발자(dsbenge)는 우리가 소설을 사용하게 된 격차에 대해 (다른 사람들과 함께) 논평했습니다. [위 댓글 링크 https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

그리고 네, 이미 출시된 .NET Core v1을 의미했습니다. 우리는 1년 넘게 솔루션을 개발해 왔으며 당시에는 좋은 DirectoryServices 솔루션이 필요했습니다. .

@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에 대한 다음과 같은 계획이 있습니다. 기본 유형의 대규모 컬렉션입니다."

System.DirectoryServices를 이식하는 것은 그 계획에 아주 잘 부합하며 실제로 1.2 릴리스의 일부여야 한다고 생각합니다. 내 5(유로) 센트만 :)

명확히 하자면: 1.2에서 포팅된 API는 사용 데이터(그리고 드물게 복잡성)를 기반으로 선택되었습니다. @weshaggard @danmosemsft 자세한 내용을 알려 주시겠습니까? System.DirectoryServices를 포함하지 않은 이유는 무엇입니까?

일치하도록 선택한 어셈블리 목록은 여기 에 있습니다. @weshaggard 는 그가 그 목록을 어떻게 선택했는지 나에게 상기시켜야 할 것입니다. (Mono에는 S.DirectoryServices가 있습니다)

System.DirectoryServices.Protocols를 사용하여 ActiveDirectory(및 기타 ldap 서버)와 통신하는 데 필요한 거의 모든 작업을 수행할 수 있다고 생각하지만 많은 사람들이 S.DS.Protocols를 사용하기 위해 코드를 다시 작성해야 합니다.

개인적으로 나는 MS가 S.DS.Protocols를 포팅하고 MS 또는 커뮤니티를 선호하여 이것 위에 사용자/그룹 관리를 위한 사용하기 쉬운 라이브러리를 만드는 것을 선호합니다.

일치시키기로 선택한 어셈블리 목록은 여기에 있습니다. @weshaggard 는 그가 그 목록을 어떻게 선택했는지 나에게 상기시켜야 할 것입니다. (Mono에는 S.DirectoryServices가 있습니다)

초기 시딩은 Xamarin 프로필을 .NET Framework와 교차하여 수행되었습니다. 모노의 하위 집합인 Xamarain 프로필은 DirectoryServices를 지원하지 않으므로 이것이 교차점에 없습니다.

이것이 포함되어야 한다고 주장하기 위해 우리는 무엇을 할 수 있습니까? Microsoft 응용 프로그램에서 가장 일반적인 인증 체계를 사용할 수 없다는 것은 약간의 방해 요소입니다. 여기에서 Azure와 AAD에 중점을 두나요? 아니면 이를 플랫폼 간에 이식하는 것이 프로토콜에 대해 더 큰 알려지지 않은 차단기입니까?

여기서 우선 순위를 높일 수 있는 방법이 있습니까? 2.0은 멀리 떨어져 있고 _모든 것이_ 작동하지만 사용자를 인증할 수 없다면 정말 불행한 일입니다. 이것은 많은 응용 프로그램의 가상 현관입니다. IMO는 우선순위 면에서 부분 차단이 아니라 본질적으로 전체 차단인 경우가 많기 때문에 약간 다릅니다.

.NET Standard의 일부가 되는 것과 다른 .NET Core에서 이것을 지원하고 싶다는 데에는 이견이 없다고 생각합니다. 그것은 단지 언제의 문제일 뿐입니다. @tquerec 가 이 지역을 소유하고 있으며 이에 대해 이야기할 사람이 될 것입니다.

.NET Foundation의 누군가가 물었지만 우리가 구체적으로 사용하는 네임스페이스는 다음과 같습니다.
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

그렇다면 @tquerec , .NET Core 1.2에 대해 System.DirectoryServices에 플래그를 지정하려면 어떻게 해야 합니까? 최소한 System.DirectoryServices.Protocols. 그게 가능한가요?

정말 감사합니다!

[@tquerec의 추가 정보로 업데이트됨]
월요일에 @tquerec님 을 만났습니다. 나는 모두에게 쓸 빚을 지고 있다. 간단히 말해서:

• 체계. DirectoryServices 는 Linux/Mac에서 완전히 알려지지 않은 Windows 전용(모든 구현이 있는 Windows DLL을 호출함)에서만 수행할 수 있습니다.
• 시스템.디렉토리 서비스. AccountManagement 가 그 위에 있으므로 Windows에서만 실행 가능하고 Linux/Mac에서는 알려지지 않음
• 시스템.디렉토리 서비스. ActiveDirectory 는 Windows에서만 실행 가능(많은 Windows 전용 API를 호출함)
• 시스템.디렉토리 서비스. 프로토콜 은 Windows의 경우 상당히 단순해야 하고 Linux의 경우 더 많은 작업을 수행해야 합니다(사용할 LDAP 라이브러리를 찾아야 함).
  우리는 @tquerec 와 함께 작업 자금을 조달하는 방법을 알아 내려고 노력하고 있습니다. 이상적으로는 1.2에 적합하지만 아직 약속은 없습니다. 결정은 최소 2주가 소요될 것으로 예상합니다.

모두에게 질문 :

• 위의 Windows 전용 범위가 주요 사용 사례에 허용됩니까? (Sys.DirSer 및 Sys.DirSer.AccountManagement 및 Sys.DirSer.ActiveDirectory)
• Sys.DirSer.Protocols Linux가 1.2 이후에 출시되거나 커뮤니티 기여에 의존한다면 이것이 주요 차단 요소가 될까요?

@karelz System.DirectoryServices.ActiveDirectory는 다수의 Windows 전용 API를 기반으로 하므로 S.DS 및 S.DS.AM과 동일한 버킷에 속합니다.

@karelz 1.2에 대한 Windows 전용 솔루션이 무엇을 의미하는지 잘 모르겠습니다. 우리는 이미 작동하는 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 이식을 위한 모든 작업을 수행할 수 있으며 기본 비트가 수행되는 경우 나중에 "무료로" 플랫폼 지원을 확장할 수 있습니다. 포트에 _starting_하는 것조차 차단하는 것은 아닙니다. 사라지는 것은 큰 승리입니다.

Windows 상점이기 때문에 여기에서도 큰 승리가 될 것입니다. 많은 대기업들이 이것을 엄청난 승리로 여길 것입니다! 최신 정보를 제공해 주셔서 감사합니다. 우리에게 계속 알려줘. 감사 해요.

@karelz 설명 감사합니다. 예, 1.2에 대한 Windows 전용 범위 지정이 적합합니다.
록마이스터

Linux /LDAP를 지원하는 System.DirectoryServices.Protocols는 우리가 수행하는 작업의 최우선 순위입니다.

ps windows 전용 범위 지정은 .netcore / .netstandard의 목표에 반대되는 것 같습니다.

우리는 비 AD LDAP 서버를 지원할 수 있도록 얼마 전에 System.DirectoryServices 에서 System.DirectoryServices.Protocols 로 전환했습니다. Protocols 네임스페이스에 액세스하면 코드를 .NET Core로 이식하는 데 한 걸음 더 다가갈 수 있습니다.

그러나 이것이 플랫폼에 따라 달라지면 우리에게는 덜 사용됩니다. .NET Core로 이동하려는 주요 사항 중 하나는 플랫폼 이식성입니다. 우리는 아마도 그것을 기다려야 할 것입니다.

.NET Core에 도달하는 것은 Docker를 활용하고 완전히 플랫폼에 구애받지 않는 기능이었습니다. 따라서 Windows 전용 LDAP 지원을 고수하는 것은 도움이 되지 않습니다.

내부적으로 논의해 주셔서 감사합니다.

내 투표는 플랫폼 독립적인 경로로 진행됩니다 🦃

플랫폼에 구애받지 않는 의견에 동의해야 합니다. 이것이 달성될 때까지 코어를 사용할 수 없다는 것이 마음이 아프기 때문입니다. 더 높은 차원에서 검토해야 할 부분이라고 생각합니다. 내가 이해하지 못하는 것은 개념의 복잡성입니까? AD, Novell 등의 여러 디렉토리 솔루션이 있습니다. 이것은 크로스 플랫폼(불가분한) 인터페이스 솔루션을 요구합니다... 즐거운 휴일 보내세요!

개인적으로 Windows 전용 범위로 완벽하게 살 수는 있지만 제 생각에는 이것은 .NET Core 및 이식성에 대한 아이디어를 깨뜨립니다.
플랫폼에 독립적인 솔루션이 초점을 맞춰야 합니다.

예, 동의합니다. .NET Core는 플랫폼 간이어야 하고 기능/API는 지원되는 모든 플랫폼에서 작동해야 합니다!
따라서 System.DirectoryServices.Protocols가 먼저 이식/구현될 예정이라면 Linux에서도 작동해야 합니다.

이상적으로는 플랫폼 독립적인 솔루션이 목표여야 한다는 데 동의합니다. Windows에 아직 설치하지 않은 것은 저와 같은 기업(AD) 환경에서 플랫폼을 실험하고 싶어하는 많은 개발자에게 방해가 됩니다. 그렇기 때문에 당분간 Windows 전용 솔루션을 환영합니다.

플랫폼 간 무언가를 결합할 수 있을 때까지는 Windows 전용 솔루션을 사용해도 괜찮다고 말씀드리고 싶습니다.

Active Directory에 연결해야 하는 개발자의 99.9%가 Windows 상자에서 개발 중인 엔터프라이즈 환경에서 그렇게 하고 있다고 상상할 수 있습니다.

우리는 우리 측에서 자금 조달에 대해 논의하고 있습니다(~2주 후 업데이트 예상). 이것은 현재 아직 .NET Standard 2.0의 일부가 아닌 API의 최우선 순위입니다.

Windows 구현 및/또는 Linux 구현에 기꺼이 도움을 줄 사람이 주변에 있습니까? (Desktop에서 코드를 가져올 수 있으며 빌드 + 일부 테스트를 위해 추가 마사지가 필요합니다.)

@karelz 저는 Linux 측면에 기여하고 싶습니다. Windows 및 비 Windows 인증(온프레미스) 모두에 대해 이 지원이 필요합니다. 이것은 우리를 위한 차단기이며 크로스 플랫폼 프로젝트를 위해 .NET 코어를 대상으로 합니다(이전에는 Linux 측에서는 Mono, Windows 측에서는 .NET).

의심의 여지없이 우리가 할 수있는 곳에서 돕고 싶습니다.

도와드리고 싶지만 여러분이 저보다 훨씬 경험이 많으며 저는 아무 소용이 없을 것이라고 확신합니다.

@karelz @tquerec 기꺼이 Windows 및 Linux에서 테스트하는 데 도움을 드리겠습니다. 나는 스레드를 구독했으므로 여기에 회신하거나 나를 언급하여 내가 참여해야 할 때 연락할 수 있습니다. 작업해 주셔서 감사합니다. 오랫동안 기다려 왔으며 증분식이라 하더라도 .NET Core를 추가로 채택하는 좋은 단계가 될 것입니다.

"확장된 Windows"는 처음에는 좋은 대상이라고 생각합니다. "확장된"은 NanoServer 및 컨테이너(즉, 전체 .NET CLR을 실행할 수 없는 도메인에 가입되지 않은 시스템)에서 작동한다는 의미입니다. 이것은 당신에게 빠른 승리와 다른 서버에서 그것을 구현하기 위해 거꾸로 작업하기 위한 출발점을 줄 것입니다.

우리는 이 작업을 최대한 빨리 차단 해제하는 가장 좋은 방법을 찾기 위해 @tquerec 및 관리 체인과 협력했습니다. 불행히도 1월 말 이전에는 무료로 사용할 수 있는 사람이 없으므로 제한된 리소스와 우리 측의 자원 봉사 활동( @ianhays @tquerec 및 @karelz)으로 커뮤니티 기여 차단을 해제하기 위해 최선을 다할 것입니다.

우리가 할 계획은 다음과 같습니다.
@ianhays 는 CoreFX 리포지토리에서 프로젝트를 시작하는 데 도움이 됩니다(일부 소스 코드 추가, 수행 방법 예제 표시, 빌드 설정 조언, 패키징, 향후 Linux/Mac 포트용 프로젝트 준비 등).
우리는 Windows 전용 구현으로 시작할 것입니다(기부 환영). .NET Core로의 포트에 필요한 경우가 아니면 이 시점에서 구현 또는 API 표면에 대한 기능 변경을 수행하지 않습니다.
다음(잠재적으로 병렬) 단계는 테스트를 추가하는 것입니다. 활용할 수 있는 것이 있거나 처음부터 시작해야 하는 경우 기존(비공개 소스 .NET Framework) 테스트 디자인에 대해 @tquerec 와 논의를 시작해야 합니다.
나중에 Linux/Mac 포트에 집중할 수 있습니다.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte 및 관심 있는 다른 사람은 @ianhays 킥이 노력을 시작하면 기꺼이 여러분의 기여를 받을 것입니다(ETA: 다음 주 중반으로 생각합니다). 질문이나 제안 사항이 있으면 알려주십시오.

이 작업을 통해 SqlClient와 같은 라이브러리가 Linux에서 실행되지만 Windows 인증이 필요한 SQL Server에 연결할 때 Windows 인증을 수행할 수 있습니까?

이는 Linux에서 실행되는 .NET Core로 항목을 이식할 수 있는 데 장애가 되는 것 중 하나입니다. 모든 엔터프라이즈 Microsoft SQL 서버는 AD에 있는 서비스 ID(비대화형)를 통한 연결만 허용합니다.

블엠보이. 귀하의 문제는 새로운 제안된 모델과의 진정한 교차 플랫폼 호환성을 보장하기 위해 "검토"해야 하는 이유에 대한 대표적인 예입니다. 더 많은 시나리오가 있는 경우 귀하의 환경은 상황이 어떻게 교차해야 하는지에 대한 좋은 예라고 생각하며 Core의 AD 부분에서 겪고 있는 다른 문제를 나열해야 합니다.

예, 이 스레드를 염두에 두고 내가 찾은 모든 것을 공유할 것입니다. 설명된 대로 보안이 엄격한 SQL 팜을 사용하는 기업에게 이것은 꽤 큰 쇼 스토퍼라는 것을 모두에게 알리고 싶었습니다.

또한 궁극적으로 동일한 문제가 발생하는 EF Core와 같은 것을 사용하는 것에 대한 쇼 스토퍼입니다.

System.DirectoryServices가 이제 CoreFX에 병합되었습니다. 다음 단계는 .NET Core - Windows용으로 빌드하고 테스트를 추가하는 것입니다.

고마워 이안. 이 문제에 대해 관심을 갖는 것이 좋습니다!

고마워 이안!

업데이트된 실행 계획: 편집: 더 나은 검색 가능성을 위해 이 문제의 최상위 게시물 로 이동했습니다.

누군가가 어떤 단계에서 작업하는 경우 중복 작업을 피하기 위해 여기에 언급하고 조정하십시오. 문제도 함께 할당하겠습니다.

System.DirectoryServices 네임스페이스에는 온-프레미스 엔터프라이즈 Windows 앱을 위한 중요한 기능이 포함되어 있어 이 문제에 대한 진행 상황을 볼 수 있어 좋습니다. 좋은 일을 계속하십시오.

소스를 수정했고 이제 System.DirectoryServices가 구축 중입니다. 빨리 PR을 보내야겠습니다.

두 번째 라운드에 참여해 주신 @tquerec님께 감사드립니다!
나머지 2개의 네임스페이스 또는 테스트를 도와줄 자원봉사자가 있습니까? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 는 여기에 추가 지원을 추가하고 Protocols/AccountManagement 구축을 위한 PR이 있습니다 .

그만한 가치가 있기 때문에 최근에 System.DirectoryServices.Protocols를 실험해 보았고 많은 간단한 System.DirectoryServices 시나리오가 System.DirecotryServices.Protocols를 사용 하여 모방하기 어렵지 않다는 것을 발견했습니다. 이를 바탕으로 S.DS 및 S.DS.AM을 교차 플랫폼에서 작동시키는 것은 플랫폼 간 System.DirectoryServices.Protocols가 많은 사용자에게 서비스 가능한 해결 방법이 될 수 있기 때문에 우선 순위가 낮을 수 있다고 생각합니다.

물론 이는 System.DirectoryServices.Protocols가 플랫폼 간 LDAP 솔루션으로 작동하도록 하는 것이 높은 우선 순위를 유지한다는 것을 의미합니다.

내가 풀 리퀘스트를 읽고 있는 것이 맞습니까? 이것이 며칠 전에 승인된 것 같으니 소스에서 빌드하면 시도해 볼 수 있어야 합니까?

예, 모든 DirectoryServices 빌드가 있다고 생각합니다. 그러나 테스트가 없기 때문에 패키지를 안정적인 상태로 배송하고 코드 기반 개선(버그 수정, 개선 등)을 방해합니다.
소스에서 빌드를 시도해 볼 수 있다면 정말 좋을 것입니다. 당신(또는 다른 누군가)이 테스트를 추가하거나 Linux 포트를 시작하는 데 도움을 주고 싶다면 훨씬 더 좋을 것입니다. :)

안녕하세요 여러분,

우리는 100% 우리 도메인 내부에 있으므로 Active Directory 지원이 필요한 엔터프라이즈 프로젝트를 시작할 준비를 하고 있습니다. 누군가 이 문제에 대한 상태와 다음 핵심 릴리스에 대한 기대치를 제공할 수 있습니까? 죄송합니다. 저는 GitHub 커뮤니티가 처음이라 다양한 용어와 상태 정보를 아직 모두 이해하지 못합니다.

별도로 관리해야 하고 데이터 불일치도 유발하는 완전히 별도의 ID 모델 대신 Active Directory를 멤버십에 사용하는 것이 좋습니다.

미리 감사드립니다!

@karelz 가 그 질문에 답했지만, 나는 이것이 현재 예정된 개발자가 없기 때문에 2.0 릴리스에서는 이것이 예상되지 않는다고 생각합니다. 커뮤니티 기여를 환영합니다. 2.0 릴리스를 _in_ 배송할 필요가 없으며, 배송 준비가 되면 언제든지 NuGet에서 배포할 수 있습니다.

완벽한! 당신은 내 질문에 대답했습니다.

감사 해요.

@nevcoBpalacio 기부 에 관심이 있으십니까?

많은 사람들이 엔터프라이즈 솔루션의 핵심으로 나아가는 데 방해가 된다는 것을 알고 있기 때문에 특히 이 주제에 관심이 있습니다. 그러나 우리는 해결 방법이 있고 하루 중(아이들과 함께하는 저녁) 시간을 찾을 수 없는 것 같습니다. GitHub와 함께 작동하도록 집에서 시스템을 다시 만들려고 합니다. 그래도 물어봐주셔서 감사합니다! 감사 해요.

Nevcobpalacio, vs17을 사용하고 크로스 플랫폼이 필요하지 않은 경우 전체 .net 프레임워크를 대상으로 하는 핵심 웹 앱 템플릿을 사용하고 구식 방식으로 system.directoryservices.accountmanagement dll을 참조하여 원하는 것에 조금 더 가까워질 수 있습니다. 그 동안 미들웨어를 실행하십시오. 내가 본 바로는 너겟 패키지를 사용하고 ref를 삭제하는 것을 제외하고 동일한 코드가 .net 코어를 대상으로 하는 것으로 이월되어야 합니다. 이 정보가 프로젝트를 순조롭게 진행하는 데 도움이 되기를 바랍니다.

@los93sol 그 제안에 감사드립니다. 초기 논의는 해당 제안과 유사하게 빌드하고 나중에 Nuget에 있는 모든 항목으로 "컷오버"할 수 있는 미들웨어 모듈로 만드는 것입니다. 무리 감사!

나는 이 제안에 대해 논평하고 당신을 칭찬해야 합니다. 나는 처음에 이러한 코어 변경에 대해 회의적이었습니다. 그러나 이 커뮤니티 접근 방식을 사용하면 이와 같은 토론이 빛을 발하고 이러한 주요 변경 사항이 진행되는 동안 우리 모두가 문제를 해결하는 데 도움이 됩니다.

감사 해요.

현재 누락된 테스트를 추가하거나 System.DirectoryServices.Protocols를 Linux/Mac으로 이식하는 작업을 하는 사람이 있습니까?

@pasikarkkainen AFAIK 현재 Microsoft 팀의 적극적인 노력은 없습니다(가까운 장래에 변경되거나 변경되지 않을 수 있음). 커뮤니티에서 작업을 시작하는 사람도 본 적이 없습니다.
기여에 관심이 있습니까, 아니면 상태가 궁금하십니까?

@karelz 올 여름 .NET Core 2.0 릴리스용 DirectoryServices를 대상으로 하는 것 같습니다.

@shanselman 의 인용문

AD – 완전히, 이것은 LDAP를 직접 호출하려는 경우 공백입니다. Windows Auth NOW에 대해 확실히 인증할 수 있습니다. 우리는 여름 기간 동안 Core 2.0을 위한 DirectoryServices 네임스페이스를 특별히 가질 계획입니다.

=> 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

이것이 코어 2.0에 포함될 것입니까? 상태가 좀 헷갈립니다.

아니요, .NET Core 2.0의 일부가 아니지만 Build 컨퍼런스에서 여름 동안 패키지를 사용할 수 있다고 약속했습니다. (Windows) 패키지는 .NET Core 2.0이 출시될 즈음에 .NET Core 2.0 위에서 사용할 수 있어야 합니다.
현재 마스터 브랜치(#18090)에서 패키지를 미리보기로 사용할 수 있도록 하고 테스트 자산을 병렬로(#20669) 작업하고 있습니다.

공유 런타임 또는 비 Windows 런타임을 대상으로 할 때 컴파일 오류가 발생합니까? 아니면 PlatformNotSupported -trap으로 끝날까요?

Windows 이외의 자산이 없는 독립 실행형 패키지가 됩니다. 컴파일이 중단되어야 합니다. @ericstj 가 확인할 수 있습니다.

컴파일 오류는 발생하지 않으며 런타임 "PlatformNotSupported" 예외가 됩니다.

예, 오래된 것입니다. .NET Standard 라이브러리에서 사용하는 사람들을 차단합니까, 아니면 컴파일 타임 오류를 PlatformNotSupported 예외로 전환합니까? ... 운 좋게도 중간 지점이 있습니다. ApiCompat 도구는 어디에나 있지 않은 것을 사용하고 있음을 미리 알려줍니다.

netstandard 1.6 프로젝트에서 System.DirectoryServices 패키지를 시도할 때 다음 오류가 발생합니다.

Install-Package : 패키지 System.DirectoryServices 4.0.0은 netstandard1.6(.NETStandard,Version=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 현재 Windows를 제외하고 DirectoryServices에 대한 CoreFX의 구현이 없습니다. @karelz 는 계획/열망에 대해 이야기해야 합니다.

System.DirectoryServices.Protocol 만 잠재적으로 x-plat으로 수행할 수 있습니다(아직 구현되지 않음). 위의 일부 답변과 맨 위 게시물에서 자세한 내용을 참조하세요.

System.DirectoryServices.Protocols 플랫폼 간 작동(Linux/Mac에서도 가능)을 얻는 것이 중요합니다. 현재 주요 문제는 System.DirectoryServices(Windows에서)에서 사용하는 LDAP 라이브러리가 오픈 소스가 아니므로 Windows에서 작동합니까?

내가 올바르게 이해했다면 System.DirectoryServices는 Windows에서만 사용할 수 있는 ADSI COM 인터페이스에 대한 많은 종속성으로 인해 xplat을 만들기 어려울 것입니다.

System.DirectoryServices.Protocols는 여전히 xplat을 실행할 수 있어야 합니다.

앞에서 언급한 것과 동일한 코드 실행:
```c#
(var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla")) 사용
````

.NET Core 2.0이 포함된 Win7 x64에서 다음을 생성합니다.

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에 의한 고정 호출 스택 및 xml/C# 코드 구문 강조 표시

@bruno-garcia는 별도의 문제를 제출하십시오. 이것은 특정 버그/차이가 아닌 전체 포트 노력을 추적합니다. 감사 해요!

https://github.com/dotnet/corefx/issues/23605 에서 추적하는 @bruno-garcia

다음 단계는 데스크톱을 통해 디버그하고 동작이 분기되는 위치를 확인하는 것입니다. 나는 그것을 볼 수 있도록 개발자를 확보하려고 노력할 것입니다.

Windows 서버에서 동일한 문제 :( (Version="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 --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

@papamamadoii 소스로 https://dotnet.myget.org/F/dotnet-core/api/v3/index.json 이 누락되었고 분명히 Install-Package가 종속성을 찾기 위해 지정된 피드를 사용하지 않았기 때문입니다. 특정 재현 단계를 사용하여 http://github.com/nuget/home 에 버그를 신고할 수 있습니다.

@karelz 내가 주석을 올바르게 이해하고 있다면 이것은 Linux 기반 배포에서 작동하지 않습니까?

@euclid47 System.DirectoryServices.*는 현재 Linux에서 지원되지 않습니다. 위에서 논의한 바와 같이, 그것의 일부는 충분한 커뮤니티 관심/참여가 주어진다면 잠재적으로 이식될 수 있습니다.

@danmosemsft 2015년 10월 이후 열린 전체 스레드를 커뮤니티의 충분한 관심으로 볼 수 없다는 것이 이해가 되지 않습니다. LDAP 통신 계층처럼 복잡한 것을 작성하는 데 필요한 기술을 보유하고 있었다면 AD가 엔터프라이즈 환경의 핵심 인증 메커니즘 중 하나였기 때문에 이미 작업하고 있었을 것입니다. 저는 대부분의 대기업의 경우 Linux에서 이러한 종류의 상호 작용을 수행할 수 없다는 사실이 말 그대로 Core의 목적을 무효화하고 dotnet의 코어 이전 빌드를 고수하도록 하여 소중한 커뮤니티 상호 작용을 제한한다는 점을 지적합니다.

@danmosemsft 또한 말 그대로 이 작업을 할 계획이 아닌 경우 커뮤니티에 확실히 알려서 다른 개발자가 부분을 선택할 수 있도록 하세요.

@shairozan 지금까지 Linux의 DirectoryServices를 Windows보다 더 높은 우선 순위로 고려하는 54명 중 7명의 투표를 확인했습니다. https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217 참조
개발자가 .NET Core에서 x-platform보다 얻는 다른 이점도 있습니다(x-plat이 가장 큰 이유 중 하나라는 점에는 동의하지만).

먼저 Windows 전용 패키지의 릴리스를 완료한 다음 새 문제를 열어 Linux 포트에 대한 관심을 보다 정확하게 추적할 수 있습니다.

우리는 이미 커뮤니티에 도움을 구하고 있으며 문제가 해결 가능한 것으로 표시되어 있다고 말했습니다. https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168을 참조하세요. 그리고 @hughbe 는 DirectoryServices에 대한 첫 번째 테스트 라운드를 도왔습니다. 여기 , 여기 및 여기 에서 기록을 참조하십시오.

@karelz 이러한 구성 요소에 대한 투표는 어디에서 관리됩니까? SELF / POSSCON 이후에 관심이 상당히 급격하게 증가할 것이라고 장담할 수 있습니다.

@karelz 이 기능에 대한 투표는 어디에 있습니까? 나는 @shairozan 의 필요성에 절대적으로 동의합니다. 이번 호에는 개발 및 프로덕션 환경을 설명하는 설명 이 있습니다. .Net Core 전도사들이 플랫폼에 구애받지 않는다고 설교한 이후로 구현에 대한 어떠한 움직임도 없었다는 것은 매우 충격적입니다.

이 문제의 중간에 있는 댓글보다 더 쉬운 투표를 위해 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 아직 모르는 경우 LDAP를 프로젝트에 통합하는 데 사용할 수 있는 Novell.Directory.Ldap.NETStandard Nuget 패키지가 있습니다. 우리는 고급 LDAP 사용자가 아니며 자격 증명을 확인하고 사용자 정보를 가져오는 데 사용하지만 dotnet 코어 런타임 도커 이미지에서 실행되는 1.0과 2.0 모두에서 제대로 작동합니다. 공식적인 방법은 아니지만 System.DirectoryServices 크로스 플랫폼 포트가 있을 때까지 작업을 완료합니다.

@OskarKlintrot 감사합니다. 그러나 이 라이브러리는 도메인 없이 로그인을 지원하지 않습니다.
나는 이슈를 생성한다 https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
이 문제를 해결하는 데 도움을 줄 수 있습니까?

저는 그 프로젝트의 일부나 고급 사용자는 아니지만 한 번 살펴보겠습니다. 거기서 뵙겠습니다!

(우리는 도메인으로 로그인하지 않습니다)

@karelz 가 Unix에 대한 문제를 발생시켰기 때문에 명확성을 위해 이 문제의 제목을 변경했습니다.

@danmosemsft 하지만 문제에는 계획이 있습니다
Linux/Mac 포트.

@balkarov 다른 추적 문제에 연결하도록 계획을 업데이트하고 별도로 추적(

System.DS 포트가 RODC 서버(읽기 전용 도메인 컨트롤러)와 호환됩니까?

@PKGeorgiev 전체 프레임워크에서 제공하는 것과 동일한 System.DirectoryServices 지원을 받아야 합니다.

Windows용 DirectoryServices 작업이 완료되어 문제가 종료됩니다.
메모:

• 최종 패키지 게시는 dotnet/corefx#24909에서 추적합니다.
• Linux/Mac 포트는 dotnet/corefx#24843에서 별도로 추적합니다.

안녕하세요, UWP에서 작동합니까?

안녕하세요, UWP에서 작동합니까?

아니요, Windows 및 전체 프레임워크에서 실행되는 넷 코어 앱에만 지원됩니다. UWP 또는 Linux에서 사용하는 경우 PlatformNotSupported 예외가 발생합니다.

백그라운드에서 Linux에서 실행되는 AWS의 람다 함수에서 이 코드를 사용하고 있는데 이 오류가 발생합니다. "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에서는 아직 지원되지 않습니다. Windows에서만 지원됩니다.

@sscoleman 문제가 생성되었습니다( https://github.com/dotnet/corefx/issues/24843). 이 질문이 항상 나오는 것을 제외하고는 이에 대한 커뮤니티의 관심이 충분하지 않다고 합니다. 그래서 지금 당신은 쓰레기 같은 위치에 있습니다. 디렉토리 서비스를 구현하는 데 시간을 보낸 후 Linux가 지원되는지 확인했습니다. 이제 Windows 전용 기능이 있는 경우 이것이 플랫폼에 구애받지 않는 것으로 선전되는 이유가 무엇인지 자문해 보십시오.

더 큰 Microsoft 전략을 보면 매우 분명합니다. Microsoft는 Active Directory를 포함한 모든 개발 리소스를 Azure에 투입하고 있습니다. "2016년의 새로운 기능"을 확인하세요. 대부분 AzureAD/하이브리드 투자입니다. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft는 모두가 대신 Azure AD로 이동하기를 원하기 때문에 Linux용 라이브러리에 투자하지 않습니다. 그것은 이해가 됩니다. 왜 고객이 멀어지게 하려는 무언가에 투자하겠습니까?

당신은 비교적 간단한 일을 하고 있습니다. 새로운 LDAP 라이브러리를 사용할 수 있으며 AD 및 Linux용 .NET Core에서 작동합니다. 프로토콜 작업을 직접 수행해야 하지만 지나치게 복잡하지 않고 많은 샘플이 있습니다. 단점은 사용자 DN과 암호가 필요한 바인딩을 직접 관리해야 한다는 것입니다.

System.DirectoryServices 는 현재 Windows 전용 API이며 .NET Core용 Windows 호환성 팩 의 일부입니다. 원칙적으로 System.DirectoryServices 의 일부를 Linux에서 작동하도록 만들 수 있지만 아직 그렇게 할 수 있는 리소스가 없습니다. dotnet/corefx#24843이 이 작업 항목을 추적 중입니다.

Linux에서 작동하지 않는 패키지를 설치하도록 허용하는 이유는 무엇입니까? 대안은 API 표면을 분기하는 것이지만 모든 경우에 잘 작동하지 않으며 전체 시스템을 코딩하기 더 어렵게 만듭니다. 물론 우리의 선택에도 문제가 없는 것은 아닙니다. 코드가 플랫폼 간에 작동할지 여부를 예측하기가 더 어려워질 수 있기 때문입니다. 코딩할 때 실시간 피드백을 제공하는 호환성 분석기의 미리 보기가 있습니다.

Windows 호환성 팩과 플랫폼 간 분석기가 함께 작동하는 방식에 대한 자세한 내용은 이 비디오를 참조하십시오.

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

@thedevopsmachine

Microsoft는 모두가 대신 Azure AD로 이동하기를 원하기 때문에 Linux용 라이브러리에 투자하지 않습니다.

제가 보기에는 그렇지 않습니다. 당신이 지적했듯이 우리는 Azure를 통해 돈을 벌려고 합니다. 그리고 Azure는 다양한 기술과 운영 체제를 제공하는 클라우드 플랫폼입니다. 우리는 클라우드의 Linux보다 클라우드의 Windows를 홍보하는 데 비즈니스 관심이 없습니다. 하지만 물론 .NET은 15년 동안 Windows에서 강력한 존재감을 과시했습니다. 모든 운영 체제에서 모든 기능을 완벽하게 작동시키는 데는 시간이 걸리지만 솔직히 말해서 우리의 오픈 소스 노력을 따르는 대부분의 사람들은 우리가 의도적으로 Linux를 햄스트링하지 않는다는 것을 알 수 있을 것이라고 생각합니다. 시간이 걸릴 뿐입니다.

나는 일관된 api x-plat 및 x-framework를 갖는 접근 방식에 동의하지만 그 두려운 오류가 발생할 때마다 영혼이 파괴됩니다 .. 나는 @scoleman 에 대해 느낍니다 ...

이 DirectoryServices 패키지는 CentOS 7에서 작동합니까?

이 DirectoryServices 패키지는 CentOS 7에서 작동합니까?

패키지를 설치할 수 있지만 작동하지 않습니다. 그것을 사용할 때 플랫폼이 지원되지 않는 예외가 발생합니다. Linux에서 일반적으로 디렉토리 서비스를 지원할 수 있는 방법을 찾고 있습니다. 이것은 우리의 레이더에 있습니다.

이것은 정말 지원 리눅스가 필요합니다

CC @joperezr

@niemyjski dotnet /corefx#24843 참조

이것은 정말 지원 리눅스가 필요합니다

.. 플러스 도커 컨테이너에서 실행할 수 있습니다. Imho Linux에서 .NET Core 2+를 사용하려는 경우 이전 Novell 디렉토리 구현으로 대체해야 하는 것은 골치 아픈 일입니다.
어쨌든 작업해 주셔서 감사합니다!

이 문제를 닫는 이유는 무엇입니까? System.DirectoryServices.AccountManagement는 여전히 Windows 외부의 .NET Core에 없습니다.

# 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 시나리오를 활성화했습니다.

CC @joperezr

@tarekgh
System.DirectoryServices.Protocols가 이식되었다는 사실을 몰랐지만 여전히 security.principal.windows에 종속되어 있는 것 같습니다. 기본 인증 등을 통해 Linux에서도 작동합니까 아니면 누락될 것입니다. 조립 오류?

목표는 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]);
                }
        }

`

오늘 이미 지원되는 것이 무엇인지 전혀 단서가 없습니다. 내가 마지막으로 확인한 것은 2월이었습니다.
고마워요, 요아킴

@jol64 프로토콜을 사용하여 동일한 결과를 얻을 수 없습니까?

@jol64 프로토콜을 사용하여 동일한 결과를 얻을 수 없습니까?

아마도 내가 할 수 있습니다. Novell 라이브러리를 사용하기 위해 몇 가지 항목을 다시 작성했습니다. 그러나 기존 .NET 프레임워크 코드에 대한 재작성 및 중복 코드가 필요합니다. 나는 확실히 모든 코드의 코드 분할을 피하는 것을 선호하며 다른 사람들도 그 아이디어를 싫어할 것이라고 확신합니다.
또한 인증이 어떻게 작동하는지 궁금합니다. Novell(내가 시도한 이전 버전)에서는 자격 증명을 지정해야 하지만 기존 코드에서는 그럴 필요가 없습니다.
고마워요, 요아킴