@vibronet

有这方面的更新吗？

我也想对此进行更新。 我的公司正在让我构建一个新应用程序，该应用程序需要能够通过 LDAP 查询 Active Directory，但目前看来这是不可能的。 是否有计划支持它，它是否被放弃以支持其他东西，或者它是否已经在工作，只是没有在任何地方记录？

在 .NET CoreFX 中实现 LDAP 和 Active Directory 支持的全新视角非常棒。

我们确实需要一个可以在 .NET Core 中利用的 Active Directory/LDAP 解决方案。 无论是干净的工作表实现还是 System.DirectoryServices 的移植，对我来说都无关紧要。 有很多以业务为中心的 Windows 应用程序绝对需要 AD 身份验证，而 LDAP 身份验证对于跨平台开发人员来说将是一个很棒的功能要点。

同意上面的向后兼容说明 - 我觉得不需要直接端口，我们只需要一种针对 Active Directory 或任何 LDAP 提供程序访问身份验证（并执行其他操作：搜索、解锁、删除等）的方法.

@尼克克拉弗

我觉得不需要直接端口，我们只需要一种方法来访问针对 Active Directory 的身份验证 [...]

很高兴知道。 不要过多地阅读我刚刚应用的端口到核心标签。 这只是我跟踪 .NET Core 产品差距的一种方式，它阻止了像您这样的客户将他们的应用程序移植到 .NET Core。

@terrajobst 明白了。 我不一定认为这必须是 1.0 项目，因为它是模块化的（而且它_听起来_就像它被安排在 RTM 后一样），但我确实期待它。 它将成为我移植 Opserver 的障碍，如果我们可以使用的话，很高兴参与 API 讨论。 我们在系统管理员方面有广泛的用例可能会有所帮助，如果我能提供帮助，请联系。

只是为了把另一顶帽子扔进戒指。 目前，这也是留给我的最大障碍。 现在仅仅能够进行身份验证将是一个巨大的帮助。

我们能否从开发团队的某个人那里获得对此计划的官方回应，如果有任何计划来支持这一点吗？

我觉得真的不需要直接端口

为什么？ 对不起，我很困惑。 对于每个人来说，这不是最简单的解决方案，并且符合 DRY 原则吗？
尽管如此，如果有理由从头开始编写整个 API，那么与旧 API 的一些一致性（相同的方法签名）对消费者来说不会那么混乱。

@jasonwilliams200OK让我澄清一下，我的真正意思是DirectoryServices.ActiveDirectory 。 我认为身份验证以及它周围的东西：例如组成员身份是命名空间的 95-99% 用例。 我认为 _that_ 的直接签名端口非常有用。 如果由于某种原因其余的保证发生变化，那么我会很好，如果它稍后出现也可以......授权会尽快走出门，因为这对许多人来说是一个障碍。

使用 ASP.NET 5 至少集成搜索 Active Directory 用户并将其映射到自定义角色的基本功能将简化 Windows 身份验证在 ASP.NET Web 应用程序中的实施。 我们的 Intranet 站点需要此功能。

这对我们来说也是一个障碍。 我们需要能够针对 ldap 服务器进行身份验证、查询用户和组、创建新用户和组等。

这对我来说也是一个障碍——我需要查询和验证用户。

我想出了一个在 .NET Core rc1 Web 应用程序中针对 Active Directory 进行身份验证的解决方案。 您只需覆盖 UserManager 类中的 CheckPasswordAsync 方法。 让我知道你的想法。

首先，您需要制作一个自定义注册页面，允许用户输入 AD 用户名而不是电子邮件地址和密码。 当您选择个人用户帐户身份验证时，该用户名进入由 ASP.NET 5 模板生成的 ApplicationUser 类的 UserName 属性。 此外，您必须将 Password 属性默认为通过 IdentityUser 类中的内部验证的内容。

我的注册页面控制器调用 Web API 2 方法，该方法在 AD 中查找用户名并返回包含该用户的 AD 信息的 JSON。 我在 ApplicationUser 类中添加了一些自定义属性来保存 AD 信息。 我将在下周发布我项目中的代码。

然后在 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我必须在这里插话——因为将用户的密码再次通过网络以纯文本形式传递给另一个应用程序是一个_really_ 坏主意。 请不要使用这种方法。 这是一个安全漏洞。

@terrajobst这将成为移植我的大型应用程序（如 Opserver）的障碍 - 我们可以优先考虑吗？

@NickCraver我从不建议将凭据作为明文传递。 作为一项规则，我对所有 Web 应用程序/服务都使用 SSL，因为它们通常返回只有授权用户才能看到的数据。 我没想到要指定这一点，可能是因为很明显您不想以明文形式发送凭据。

我会支持至少提供System.DirectoryServices.Protocols的端口。 我们最近将与 LDAP 相关的代码切换到此代码以支持更大范围的 LDAP 服务器，因为System.DirectoryServices.ActiveDirectory命名空间只喜欢与 AD 服务器通信。

我想，第 3 方库有可能提供这种支持，但由于它已经存在于框架中，我想一个端口会更简单。

WTF asp 团队不提供此基本功能
这是一个真正的障碍问题:(

CoreCLR 中的 LDAP 支持有什么更新吗？

我也想对此进行更新。 我将使用 ASP.NET Core 开发一个企业应用程序，该应用程序需要针对 AD 服务器对用户进行身份验证。

我将研究将 System.DirectoryServices 移植到 v1.1.0 的 .NET Core (https://github.com/dotnet/corefx/milestones)

@joshfree
我还必须对 ADLDS 的用户进行身份验证，还请考虑 System.DirectoryServices.AccountManagement

几年前，我工作的公司采用了 Novell (Mono) LDAP 库源代码，以便我们的应用程序可以与 Active Directory、OpenLDAP 和 Oracle 系统通信，我们添加了对分页控件的支持并更新了一些 TLS 修复程序。 我们这样做是因为我们想在 Linux 上运行。 包含我们更改的 PR 已发送给所有者。 因为我们现在想要进入 CoreCLR，所以该库需要转换为 RC2。 工作从这里开始https://github.com/VQComms/CsharpLDAP/pull/1 ，还有 17 个编译器错误需要解决。 它们主要是Thread.Abort ， ThreadInterruptedException ，将 TLS 流从 Mono 替换为 CoreCLR SslStream如果有人感兴趣并需要对 CoreCLR 的 LDAP 支持，请随时提供帮助。

我已确认ASP.NET Core Web 应用程序 (.NET Framework) RC2项目可以引用使用 System.DirectoryServices.AccountManagement 的类库。 只有当 Web 应用程序和类库都是使用 VS 2015 Update 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 上使用 Angular Web 应用程序时，登录到 AD，在 aspnet core RC2 中调用 WebAPI 控制器方法（无需用户在 Web 浏览器中输入密码）。 可能的？ 很快可能吗？

为此，您只需在来自客户端的 http 请求中使用 withCredentials。 然后，您可以使用 User.Identity 在您的控制器中获取用户信息和声明。
这适用于 ie 和 chrome，但使用 Firefox 会自动显示一个弹出窗口，让用户输入他们的 windows 用户名和密码

大约两个月前，我们遇到了同样的问题（例如，尝试使用 LDAP 服务器作为用户存储）。 除了将 Novell LDAP 库 (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) 移植到 .net 核心之外，我们找不到任何解决方案（请参见此处 https://github.com/dsbenghe/Novell。 Directory.Ldap.NET 标准）。 发布了一个 nuget 包。 我们正在使用带有 OpenDJ LDAP 服务器的库（应该与任何 LDAP 服务器一起使用）——使用 1.5 个月没有问题。

@dsbenghe我们刚刚在 netstandard 上编译了 Novell LDAP 库，我们的也包含分页。 这是由@igorshmukler完成的。 您想比较和合作吗？ 我们的在制品在这里https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe感谢您在 .NET Core 实现方面所做的工作。
拿到nuget包后，我创建了以下代码来测试用户的ActiveDirectory密码是否正确

using Novell.Directory.Ldap;

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

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

它调用 AuthenticateWithActiveDirectory：

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

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

    return string.Empty;
}

并使用一个简单的帮助类来让 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 ，他将致力于 System.DirectoryServices 对 .NET Core 的支持。

等不及了！ 预计到达时间？ 设计规范？

当它最终移植过来时，我们是否可以访问：

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

我知道该名称空间中有一些小缺陷，但仍然很有帮助。

@GArrigotti在测试中，使用 LdapDirectoryIdentifier通常比 PrincipalContext

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

有预计到达时间吗？ 我可以在本月底完成的系统中使用它...

@johnkwaters是否有理由不能将 AD 代码放入类库中？ 有些人（包括我）在引用 ASP.NET Core 应用程序中的遗留类库时遇到了问题。 但是，如果您在 VS 2015 Update 3 中创建 Web 应用程序和类库并在 Web 应用程序和类库中以 .NET Framework 4.61 为目标，则没有问题。

是否有理由不能将 AD 代码放入类库中？

您的意思是 PCL 后跟"imports": "portable-net45+win8"在 project.json 中用于 .NET Core TxM？ 这将要求在 Unix 上存在 Mono PCL 参考程序集，而不是在 Unix 上实现自给自足的“纯 donet-core”解决方案。 使编译器静音是一个很好的技巧，但只有在 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 个不同的人放在 nuget 上的库。 它的
所有的OSS。 如果你不喜欢这个包，请发送 PR

2016 年 9 月 8 日 12:19，Mikhail Orlov [email protected]
写道：

伙计们，你们都可以在主帖中添加反应吗？

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 @jchannon Novell LDAP。 它使我们向前迈进，几乎没有对我们的 LDAP 实现进行任何更改。 我的意思是你正确地抽象了；）

是的，我最终也使用了@jchannon Novell LDAP，它运行良好。

如果我之前没有这么说，这里是https://github.com/VQComms/CsharpLDAP/commits/coreclrPort上的所有分支

目前非常适合我们的要求...

@h3smith @johnkwaters 如有任何问题，请随时提出问题😄

我决定尝试使用 Novell，样本看起来足够好，但我不知道如何使用 Novell LDAP 将用户成员踢出（删除）组。
我无法在 MSAD LDAP 上更改我的密码，因为我看不到 userPassword 并且它没有在 LDAP 服务器上设置。

真的需要这个！

@joshfree或其他任何知情的人......
我们正在寻找一个需要访问 ActiveDirectoryServices.AccountManagement 的新项目。问题，端口是针对 1.1 还是 1.2？

它不是 1.1 的一部分（即将完成）。 @tquerec ，你能在这里评论你的计划吗？

抄送：@danmosemsft

所以，如果不是 1.1 的一部分，有人有计划吗？ 没有这种支持似乎是一个主要问题。 显然，微软最需要这种集成。

只是另一个投票。 当 .NET Core 缺乏基本的企业功能时，很难投资构建企业级系统。 小说项目有效，但还达不到标准。

又是一票。 我将重复同样的声明，即这对于创建任何企业应用程序都是不可或缺的。

@nevcoBpalacio我认为他们正试图推动我们使用 azure 活动目录

这对于那些与要求服务留在内部的公司协议一起使用的人永远不起作用。

我一直在为联邦政府机构和现在的地方县政府机构工作，无论哪种方式，您仍然需要一些接口或能力来集成到某些目录服务，无论是基于云的还是本地的。 我共同开发了管理数十亿美元的应用程序，并且总是会出现对目录服务的一些需求。 我认为这不仅仅是另一次投票，而是您还在等什么的声明？ 我同意之前的一篇文章，即这最初是以前 .NET 版本中的开箱即用解决方案。 我知道 CORE 更开放的结构应该会获得社区的动力，如果这是微软选择等待的，也许他们已经说过，我错过了，他们应该这样说，这样有人可能会主动投入时间完成它。

是的，请将 System.DirectoryServices 添加到 .NET Core！

我们计划在明年移植 System.DirectoryServices.Protocols。 在这一点上，我无法提供更确定的日期。 我们还没有移植 System.DirectoryServices 或 System.DirectoryServices.AccountManagement 的计划，但我有兴趣衡量兴趣。 人们正在使用的那些命名空间中是否有协议无法解决的特性？

@tquerec我不熟悉协议。 我们有一个项目来做 Active Directory 自助服务来做帐户解锁和帐户密码重置。 我们在项目中使用 UserPrincipal 并调用 FindByIdentity、UnlockAccount、SetPassword、ExpirePasswordNow 等方法。
我不确定这些是否可以在协议上完成，但看起来协议是较低级别的实现，而 AccountManagement 是使用 ActiveDirectory 的更好抽象。
谢谢
摇滚大师

@nevcoBpalacio绝对应该不仅仅是我同意的投票。 我认为这确实需要更多优先级。

@CalebMacdonaldBlack如果您能回答@tquerec关于使用模式以及为什么需要的问题，那将会很有帮助。 没有场景的更多赞成或“我同意/这很重要”将无助于提高此时的优先级......谢谢！

我们的用途是扫描/搜索 LDAP、执行 BIND 以验证凭据、添加/删除 LDAP 对象（用户、组）、修改组中的成员资格等。

@tquerec我真的需要 System.DirectoryServices.AccountManagement 以便我可以针对活动目录对我们的用户进行身份验证，并在他们有权访问的组中授权他们。

绝对同意 h3smith .. 我们在 v1 中需要这个，而不是被迫走新路径，我们已经把它放在一起（尤其是复制位），并且让我们对维护等开销感到悲痛。这使得 .NETCore看起来很糟糕的副作用..

@液体男孩

我们需要这个 v1

你的意思是 .NET Core v1 吗？ - 完成并发货。 我们现在正在开发 1.2。 还是你的意思是别的？

而是被迫走小说之路

这是什么意思？ （抱歉，我在 DirectoryServices 上的上下文为零，但我很想从场景的角度了解我们缺少什么）

@karelz只需在此线程中搜索“小说”一词，您就会明白我的意思。 我团队的另一位开发人员（dsbenge）（与其他人一起）评论了导致我们使用小说的差距。 [这里是上面评论的链接https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

是的，我的意思是已经发布的 .NET Core v1，我们已经研究了一年多的解决方案，当时我们需要一个好的 DirectoryServices 解决方案。我们碰壁了，因此别无选择，只能使用小说.

@liquidboy感谢您的链接——如果它在 Mono 中，我们应该能够在 .NET Core AFAIK 中重用源代码。 @tquerec有兴趣，您的团队会考虑吗？

@tquerec ：我们需要以下内容：
System.DirectoryServices、System.DirectoryServices.AccountManagement、System.DirectoryServices.ActiveDirectory 和 System.DirectoryServices.Protocols。

这些是连接和管理 Active Directory（和其他 LDAP 服务器）用户、组、属性所必需的，就像上面的回复中描述的一样。 在 .Net Core 中拥有这些功能很重要！

我同意其他人的观点。 我需要它来将我们任何针对 ActiveDirectory 进行身份验证的应用程序移植到 .NET Core。 这是非常基本的，它绝对应该在尽可能快的版本中。 这是阻断移植到这么多东西。

.NET Core 路线图页面 (https://github.com/dotnet/core/blob/master/roadmap.md) 对 .NET Core 1.2 有以下计划：“将 .NET Core 与 .NET Framework 和 Mono 相提并论大量的基本类型。”

我认为移植 System.DirectoryServices 非常适合该计划，并且确实应该成为 1.2 版本的一部分。 只是我的 5（欧元）美分 :)

澄清一下：在 1.2 中移植的 API 是根据使用数据（很少是复杂性）挑选出来的 - @weshaggard @danmosemsft你能详细说明一下，为什么我们不包括 System.DirectoryServices？

我们选择匹配的程序集列表在这里。 @weshaggard将不得不提醒我他是如何选择该列表的。 （单声道有 S.DirectoryServices）

我相信您将能够使用 System.DirectoryServices.Protocols 完成与 ActiveDirectory（和其他 ldap 服务器）对话所需的一切，但是很多人将不得不重写他们的代码以使用 S.DS.Protocols。

就我个人而言，我更喜欢 MS 移植 S.DS.Protocols 和 MS 或社区，以便在此之上创建一个易于使用的用户/组管理库。

我们选择匹配的程序集列表在这里。 @weshaggard将不得不提醒我他是如何选择该列表的。 （单声道有 S.DirectoryServices）

最初的播种是通过将 Xamarin 配置文件与 .NET Framework 相交来完成的。 Xamarain 配置文件（它是 mono 的一个子集）不支持 DirectoryServices，这就是为什么它不在交叉点中的原因。

我们能做些什么来争论这应该是什么？ 无法在 Microsoft 应用程序中使用最常见的身份验证方案有点阻碍，不是吗？ 这里的重点是 Azure 而不是 AAD？ 或者说跨平台移植是一个更大的协议未知数？

有没有办法在这里增加优先级？ 2.0 离我们还有很长的路要走，如果 _everything_ else 都可以，那真的很不幸，但我们无法对用户进行身份验证。 这是许多应用程序的虚拟前门。 IMO，就优先级而言，它有点不同，因为它不是部分阻止者，而是本质上通常是完全阻止者。

我不认为我们希望在 .NET Core 中支持这一点存在任何分歧，这与成为 .NET Standard 的一部分不同，这只是时间问题。 @tquerec拥有该地区，并将成为与之交谈的人。

.NET Foundation 有人问，但我们专门使用的命名空间是：
System.DirectoryServices、System.DirectoryServices.Protocols、System.DirectoryServices.AccountManagement

那么， @tquerec ，我们如何将 System.DirectoryServices 标记为 .NET Core 1.2 ？ 至少 System.DirectoryServices.Protocols。 那可能吗？

非常感谢！

[更新了来自@tquerec 的更多信息]
星期一我会见了@tquerec 。 我欠每个人一个记录。 简而言之：

• 系统。 DirectoryServices仅在 Windows 上可行（它调用所有实现所在的 Windows DLL），对于 Linux/Mac 完全未知
• System.DirectoryServices。 AccountManagement位于其之上，因此仅适用于 Windows，对于 Linux/Mac 未知
• System.DirectoryServices。 ActiveDirectory仅适用于 Windows（它调用许多 Windows 特定的 API）
• System.DirectoryServices。 对于 Windows，协议应该相当简单，而对于 Linux，协议应该相当简单（我们需要找到要使用的 LDAP 库）。
  我们正试图与@tquerec一起弄清楚如何为这项工作提供资金——最好是 1.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 的目标背道而驰

我们不久前从使用System.DirectoryServices切换到使用System.DirectoryServices.Protocols ，以便我们可以支持非 AD LDAP 服务器。 访问 Protocols 命名空间将更接近允许我们将代码移植到 .NET 核心。

但是，如果这将是特定于平台的，那么对我们的使用就更少了。 想要迁移到 .NET 核心的一个要点是平台可移植性。 我们可能还需要等待。

对我们来说，使用 .NET Core 是能够利用 Docker 并完全与平台无关。 因此，只支持 Windows 的 LDAP 支持将无济于事。

感谢内部讨论。

我的投票是独立于平台的路线🦃

我必须同意与平台无关的评论，尽管在完成之前我不能使用核心，这很伤人。 我确实认为这是必须在更高级别进行审查的事情。 我不明白的是这个概念的复杂性？ 有几种目录解决方案，AD、Novell 等...这需要一个跨平台（不可知）界面解决方案...节日快乐！

虽然我个人可以在纯 Windows 范围内生活得很好，但在我看来，这打破了 .NET Core 的想法及其可移植性。
独立于平台的解决方案应该是重点关注的途径。

是的，同意，.NET Core 应该是跨平台的，并且特性/API 应该在所有支持的平台上工作！
因此，如果要首先移植/实现 System.DirectoryServices.Protocols，它应该也可以在 Linux 上运行。

我同意理想情况下独立于平台的解决方案应该是目标。 尽管对于许多只想在公司 (AD) 环境中试验该平台的开发人员（例如我自己）来说，仍然没有在 Windows 上安装它是一个障碍。 这就是为什么我暂时欢迎仅 Windows 的解决方案。

我只是想插话并说我对仅限 Windows 的解决方案很好，直到可以将跨平台的东西放在一起。

我想 99.9% 需要连接到 Active Directory 的开发人员是在他们在 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 的实现开始（欢迎贡献）。 此时我们不会对实现或 API 表面进行任何功能更改，除非它们对于移植到 .NET Core 是必要的。
下一个（可能是并行的）步骤将是添加测试。 如果有任何我们可以利用的东西，或者我们必须从头开始，我们应该与@tquerec就现有（闭源 .NET 框架）测试设计展开讨论。
稍后，我们可以专注于 Linux/Mac 端口。

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte，以及任何其他感兴趣的人，一旦@ianhays开始努力，我们将很乐意接受您的贡献（ETA：我认为是下周中旬）。 如果您有任何问题或建议，请告诉我们。

这项工作是否还允许 SqlClient 等库在 Linux 上运行但连接到需要 Windows 身份验证的 SQL Server 时执行 Windows 身份验证？

这是我能够将东西移植到在 Linux 上运行的 .NET Core 的障碍之一。 我们所有的企业 Microsoft SQL 服务器只允许通过 AD 中的服务 ID（非交互式）进行连接。

blgmboy。 您的问题是为什么需要“审查”以确保与新建议模型的真正跨平台兼容性的一个主要例子。 如果你有更多的场景，我认为你的环境是一个很好的例子，说明事情需要如何跨越，你应该列出你在 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有一个 PR 在这里https://github.com/dotnet/corefx/pull/15324添加进一步的支持和建立协议/帐户管理。

对于它的价值，我最近一直在试验 System.DirectoryServices.Protocols，发现许多简单的 System.DirectoryServices 场景并不难用 System.DirecotryServices.Protocols 模拟。 基于此，我认为让 S.DS 和 S.DS.AM 跨平台工作可能是一个较低的优先级，因为跨平台 System.DirectoryServices.Protocols 对于许多用户来说可能是一种可行的解决方法。

当然，这意味着让 System.DirectoryServices.Protocols 作为跨平台 LDAP 解决方案工作仍然是重中之重。

我在阅读拉取请求吗？ 看起来这在几天前被接受了，所以如果我们从源代码构建，我们应该能够尝试一下吗？

是的，我认为我们已经构建了所有 DirectoryServices，但是我们没有任何测试 - 这会阻止我们将包作为稳定的包发布并改进代码库（错误修复、增强等）。
如果您可以尝试从源代码构建，那就太好了。 如果您（或其他任何人）想帮助我们添加测试或启动 Linux 端口，那就更好了 :)

大家好，

我们正准备开始一个需要 Active Directory 支持的企业项目，因为我们 100% 位于我们的域内部。 有人可以提供此问题的状态以及对下一个核心版本的期望吗？ 抱歉，我是 GitHub 社区的新手，还不了解所有各种术语和状态信息。

将 Active Directory 用于成员资格而不是完全独立的身份模型会非常好，该身份模型必须单独管理并且也会导致数据不匹配。

提前致谢！

@karelz回答这个问题，但我认为答案是目前在 2.0 版本中预计不会出现这种情况，因为我们没有为它安排开发人员。 欢迎社区贡献。 它不需要 _in_ 发布 2.0 版本，它可以随时在 NuGet 上发布。

完美的！ 你回答了我的问题。

谢谢。

@nevcoBpalacio有兴趣投稿吗？

我确实有兴趣，尤其是这个主题，因为我知道它阻碍了许多企业解决方案的核心。 但是，我们有一个解决方法，我似乎无法在一天中（晚上和孩子们）找到时间。 我将尝试在家里重新构建我的系统以使用 GitHub。 我很感激你问！ 谢谢。

Nevcobpalacio，如果您使用 vs17 并且不需要跨平台，则可以通过使用针对完整 .net 框架的核心 Web 应用程序模板并以老式方式引用 system.directoryservices.accountmanagement dll 来更接近您想要的内容同时滚动你自己的中间件来完成它。 从我所看到的情况来看，一旦可用，相同的代码应该会延续到目标 .net 核心，除非您将使用 nuget 包并删除 ref。 希望这些信息能帮助您的项目走上正轨。

@los93sol感谢您的建议。 我们最初的讨论是构建它类似于那个建议，并使其成为一个中间件模块，我们可以“切入”到以后在 Nuget 中的任何地方。 非常感谢！

我必须评论和赞扬你的这个建议。 起初我对核心的这种变化持怀疑态度。 然而，通过这种社区方法，像这样的讨论会曝光，并帮助我们在这些重大变化期间解决问题。

谢谢。

目前是否有人正在努力添加缺失的测试，或将 System.DirectoryServices.Protocols 移植到 Linux/Mac？

@pasikarkkainen AFAIK 目前微软团队没有这样的积极努力（在不久的将来可能会或可能不会改变）。 我也没有看到社区中的任何人开始研究它。
您是有兴趣贡献，还是只是对状态感到好奇？

@karelz看起来他们正在针对今年夏天发布的 .NET Core 2.0 的 DirectoryServices。

引用@shanselman

AD – 完全是，如果您想直接调用 LDAP，这是一个差距。 您现在当然可以针对 Windows Auth 进行身份验证。 我们计划在夏季时间框架内专门为 Core 2.0 提供 DirectoryServices 命名空间

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

是的，这与我听到的走廊讨论一致。 我只是不确定它是否是公共信息以及有多少（以及谁）承诺了它。 我认为可以肯定地说，这是在非常认真的考虑之中，并且很可能会发生。 我让@shanselman和 DirectoryServices 所有者对时间表发表评论。

@karelz ：感谢您的更新！ 我主要是对状态感到好奇。当它可用时，我绝对可以帮助测试至少。

@pasikarkkainen如果您也愿意帮助编写一些测试用例，我们将不胜感激。
如果您“只是”想在您的应用程序/代码上测试包，那么今天应该是可行的。 我们只需要开始在 myget 上将包作为预览发布（我认为今天发布已禁用）。

@karelz我不介意专门帮助 Mac 实施。 我的知识很少，所以我不确定我能做出多大的贡献。 我已经围绕它进行了研究，人们似乎建议使用一个 Novell 图书馆。 在这里找到了其他人围绕该 Novell 库的实现： 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 发布的时候。
我们目前正致力于在 master 分支 (#18090) 中将包作为预览版提供，并并行处理测试资产 (#20669)。

当我们以共享运行时或非 Windows 运行时为目标时，会出现编译错误吗？ 或者我们最终会遇到PlatformNotSupported -trap 吗？

它将是没有任何非 Windows 资产的独立包。 编译应该中断。 @ericstj可以确认。

您不会收到编译错误，它们将是运行时“PlatformNotSupported”异常。

是的，它是旧的 - 我们是否阻止人们从 .NET 标准库中使用它，或者我们是否将编译时错误转换为 PlatformNotSupported 异常？ ... 幸运的是，有一个中间立场： ApiCompat工具会提前告诉您您正在使用并非无处不在的东西。

当我尝试在 netstandard 1.6 项目中使用 System.DirectoryServices 包时出现以下错误：

安装包：包 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 目前在 CoreFX 中没有针对 DirectoryServices 的实现，但在 Windows 上除外。 如果有的话， @karelz将不得不谈论计划/愿望。

只有System.DirectoryServices.Protocol可能是 x-plat 可行的（尚未实施） - 请参阅我上面的一些答案和顶部帖子中的详细信息。

让 System.DirectoryServices.Protocols 跨平台工作（也在 Linux/Mac 上）很重要。我是否理解正确目前的主要问题是 System.DirectoryServices （在 Windows 上）使用的 LDAP 库不是开源的，因此只有在 Windows 上工作？

如果我理解正确的话，System.DirectoryServices 将很难制作 xplat，因为它对 ADSI COM 接口有很多依赖，只能在 Windows 上使用。

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 请提交单独的问题。 这是跟踪整个端口工作，而不是特定的错误/差异。 谢谢！

@bruno-garcia 由https://github.com/dotnet/corefx/issues/23605跟踪

下一步可能是通过桌面进行调试并查看行为分歧的地方。 我将尝试释放开发人员来查看它。

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 --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作为来源，并且显然 Install-Package 没有使用您指定的提要来查找依赖项。 您可能想在http://github.com/nuget/home上提交一个带有特定重现步骤的错误。

@karelz如果我正确理解评论，这不适用于基于 Linux 的部署？

@euclid47 System.DirectoryServices.* 目前在 Linux 上不受支持。 如上所述，如果社区有足够的兴趣/参与，它的一部分可能会被移植。

@danmosemsft我不明白你怎么看不到自 2015 年 10 月以来整个线程的开放，因为社区的兴趣足够大。 如果我具备编写像 LDAP 通信层这样复杂的东西所需的技能，我早就开始研究它了，因为 AD 是企业环境中的核心身份验证机制之一。 我要指出，对于大多数大型企业而言，无法在 Linux 上执行此类交互实际上违背了 Core 的目的，并将导致他们坚持使用 dotnet 的预内核构建，从而限制了您宝贵的社区交互。

@danmosemsft另外，如果您真的不打算为此工作，请明确告知社区，以便其他开发人员可以接手。

@shairozan到目前为止，我们注意到 54 人中有 7 人认为 Linux 上的 DirectoryServices 比 Windows 具有更高的优先级——请参阅https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
除了 x-platform 之外，开发人员还从 .NET Core 中获得了其他优势（尽管我同意 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如果您不知道已经有Novell.Directory.Ldap.NETStandard Nuget 包，您可以使用它来将 LDAP 集成到您的项目中。 我们不是高级 LDAP 用户，我们只是使用它来验证凭据并获取用户信息，但它对我们来说工作正常，无论是在 dotnet 核心运行时 docker 映像上运行的 1.0 还是 2.0 上。 这不是官方方式，但它可以完成工作，直到有一个跨平台端口System.DirectoryServices 。

@OskarKlintrot谢谢。 但是这个库不支持无域登录。
我创建问题https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
你能帮我解决这个问题吗？

我不是该项目的一部分，也不是高级用户，但我会看看，在那里见！

（我们没有使用域登录）

鉴于@karelz 引发了 Unix 的一个问题，为了清楚起见，我重新命名了这个问题。

@danmosemsft但问题有计划
Linux/Mac 端口。

@balkarov我已更新计划以链接到其他跟踪问题，并删除了单独跟踪（中断工作）或不阻止 Windows 工作的项目的复选框。

System.DS 端口是否与 RODC 服务器（只读域控制器）兼容？

@PKGeorgiev您应该获得与我们在完整框架中相同的 System.DirectoryServices 支持。

针对 Windows 的 DirectoryServices 的工作已完成，关闭问题。
笔记：

• 最终包发布由 dotnet/corefx#24909 跟踪
• Linux/Mac 端口由 dotnet/corefx#24843 单独跟踪

嗨，这可以在 UWP 中使用吗？

嗨，这可以在 UWP 中使用吗？

不，它仅支持在 Windows 和完整框架上运行的网络核心应用程序。 如果你在 UWP 或 Linux 上使用它，你会得到一个 PlatformNotSupported 异常。

我在 AWS 的 lambda 函数中使用此代码，该函数在后台在 Linux 上运行，我收到此错误。 “此平台不支持 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 战略，这一点相当明显。 微软正在将他们所有的开发资源投入 Azure，其中包括 Active Directory。 查看“2016 年新增功能”，主要是 AzureAD/Hybrid 投资。 https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services。

微软没有投资这个 Linux 库，因为他们希望每个人都迁移到 Azure AD。 这是有道理的，你为什么要投资于你试图让客户远离的东西？

不过，您正在做一些相对简单的事情。 您可以使用 Novel 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

微软没有投资这个 Linux 库，因为他们希望每个人都迁移到 Azure AD。

我不是这么看的。 正如您所指出的，我们打算通过 Azure 赚钱。 Azure 是一个提供多种技术和操作系统的云平台。 我们没有商业利益来推广云中的 Windows 而不是云中的 Linux。 当然，.NET 在 Windows 上的影响力已经有 15 年之久。 让所有操作系统的功能完全发挥作用需要时间，但老实说，我认为大多数关注我们开源工作的人都可以看到，我们并不是故意限制 Linux。 只是需要时间。

我同意使用一致的 api x-plat 和 x-framework 的方法，但是每当我遇到那个可怕的错误时，它都会摧毁灵魂……我对@sscoleman有感觉……

这个 DirectoryServices 软件包可以在 CentOS 7 上运行吗？

这个 DirectoryServices 软件包可以在 CentOS 7 上运行吗？

该软件包可以安装，但无法正常工作。 使用它时，您将获得平台不支持的异常。 我们正在研究如何在 Linux 上支持一般的目录服务。 这是我们的雷达。

这个真的需要支持linux

抄送@joperezr

@niemyjski见 dotnet/corefx#24843

这个真的需要支持linux

.. 加上能够在 docker 容器中运行。 恕我直言，当人们想在 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。

抄送@joperezr

@tarekgh
我不知道 System.DirectoryServices.Protocols 已被移植，但看起来它仍然依赖于 security.principal.windows，它是否可以在 linux 中工作（通过基本身份验证等），还是会丢失组装错误？

目标是将诸如 ActiveDirectory Powershell 模块之类的东西重新实现为 xplat，如果至少没有可用的基本交互支持，我正在考虑使用 novell ldap 模块或 ldap4net 模块。

实施 ActiveDirectory Powershell 可能是一个非常大的用例。 让我分享我的两个用例：

1）我从 UserPrincipal 派生，因为我需要开箱即用不支持的属性。 我关注了https://stackoverflow.com/questions/24798037/extend-userprincipal-class ，我想这是旧 .NET 框架中的一种标准，让这种方法发挥作用可能会帮助更多的开发人员。

2）我也有如下代码：

`

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

`

不知道今天已经支持什么，我上次检查是在二月份。
谢谢，约阿希姆

@jol64你不能使用协议实现同样的目标吗？

@jol64你不能使用协议实现同样的目标吗？

可能我可以。 我重写了一些东西来使用 Novell 库。 但它需要对我现有的 .NET 框架代码进行重写，因此是冗余代码。 我肯定更喜欢避免所有代码的代码拆分，我相信其他人也不喜欢这个想法。
我也想知道身份验证是如何工作的。 使用 Novell（我尝试过的旧版本）我必须指定凭据，而使用我现有的代码我不需要。
谢谢，约阿希姆