@vibronet

これに関する更新はありますか？

私もこれについての最新情報をお願いします。 私の会社では、LDAPを介してActive Directoryにクエリを実行する機能を必要とする新しいアプリを作成してもらいましたが、現在これは不可能のようです。 それに対する計画されたサポートはありますか、それは何か他のもののために落とされますか、それともどこにも文書化されていないだけですでに機能していますか？

LDAPとActiveDirectoryのサポートを実装するための新しい、新鮮な見方は、.NETCoreFXにあると素晴らしいでしょう。

.NETCoreで活用できるActiveDirectory / LDAPソリューションが本当に必要です。 それがクリーンシートの実装であるか、System.DirectoryServicesの移植であるかは、私にとってそれほど重要ではありません。 AD認証を絶対に必要とするビジネスに焦点を合わせたWindowsアプリケーションはたくさんあり、LDAP認証はクロスプラットフォーム開発者にとって優れた機能の箇条書きになります。

上記の下位互換性に関する注意事項に同意しました-直接ポートが本当に必要だとは思いません。ActiveDirectoryまたは任意のLDAPプロバイダーに対して認証にアクセスする（および他のアクション（検索、ロック解除、削除など）を実行する）方法が必要です。 。

@NickCraver

直接ポートが本当に必要だとは思いません。ActiveDirectoryに対してauth [...]にアクセスする方法が必要です。

それを知っておくのは良いことです。 適用したばかりのport-to-coreラベルを読みすぎないでください。 これは、.NET Coreオファリングのギャップを追跡するための私の方法であり、あなたのような顧客がアプリを.NETCoreに移植することを妨げています。

@terrajobstガッチャ。 モジュール性があるため、必ずしも1.0アイテムである必要はないと思いますが（とにかくRTM後の予定のように聞こえます）、楽しみにしています。 Opserverの移植を妨げるものになるので、役立つことがあればAPIのディスカッションに参加してください。 sysadmin側には、役立つ可能性のあるさまざまなユースケースがあります。サポートできる場合はpingを実行してください。

別の帽子をリングに投げ込むだけです。 現時点では、これは私にも残された最大のブロッカーです。 単に認証できることは、今のところ大きな助けになるでしょう。

これをサポートする計画がある場合でも、開発チームの誰かからこの計画について公式の回答を得ることができますか？

直接ポートが本当に必要だとは思わない

どうして？ 混乱してすみません。 それは誰にとっても最も簡単な解決策であり、DRYの原則に一致しているのではないでしょうか？
それでも、API全体を最初から作成する理由がある場合は、古いAPI（同じメソッドシグネチャ）との一貫性が消費者にとって混乱しにくくなります。

@ jasonwilliams200OKはっきりさせておきますが、具体的にはDirectoryServices.ActiveDirectoryを意味します。 認証とその周辺のものだと思います。たとえば、グループメンバーシップは、名前空間の95〜99％のユースケースです。 _that_の署名の直接ポートは非​​常に便利だと思います。 残りの令状が何らかの理由で変更された場合、私はそれでかなり大丈夫です、そしてそれが後で来た場合は大丈夫です...それは多くの人にとってブロッカーなので、認証はできるだけ早くドアから出るのが良いでしょう。

Active Directoryユーザーを検索し、それらをASP.NET 5でカスタムロールにマッピングするという少なくとも基本的な機能を統合すると、ASP.NETWebアプリケーションへのWindows認証の実装が容易になります。 イントラネットサイトでこの機能が必要です。

これは私たちにとってもブロッカーです。 LDAPサーバーに対して、認証、ユーザーとグループのクエリ、新しいユーザーとグループの作成などができる必要があります。

それは私にとってもブロッカーです-私はユーザーを検索して認証する必要があります。

.NET Core rc1WebアプリケーションでActiveDirectoryに対して認証するためのソリューションを思いつきました。 UserManagerクラスのCheckPasswordAsyncメソッドをオーバーライドする必要があります。 どう考えているか教えてください。

まず、ユーザーがメールアドレスとパスワードの代わりにADユーザー名を入力できるカスタム登録ページを作成する必要があります。 そのユーザー名は、個別のユーザーアカウント認証を選択したときにASP.NET5テンプレートによって生成されるApplicationUserクラスのUserNameプロパティに含まれます。 また、Passwordプロパティを、IdentityUserクラスの内部検証に合格するものにデフォルト設定する必要があります。

私の登録ページコントローラーは、ADでユーザー名を検索し、そのユーザーのAD情報を保持するJSONを返すWeb API2メソッドを呼び出します。 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クレデンシャルをプレーンテキストとして渡すことを提案したことはありません。 原則として、すべてのWebアプリケーション/サービスにSSLを使用します。これは、通常、許可されたユーザーのみが表示する必要があるデータを返すためです。 おそらく、クレデンシャルをプレーンテキストで送信したくないほど明白であるため、これを指定することは考えていませんでした。

私は少なくともSystem.DirectoryServices.Protocolsのポートを提供することをサポートします。 System.DirectoryServices.ActiveDirectory名前空間はADサーバーとの通信のみを好むため、最近、LDAP関連のコードをこれに切り替えてより広範囲のLDAPサーバーをサポートしました。

サードパーティのライブラリがこの種のサポートをスピンアップすることは可能だと思いますが、フレームワークにすでに存在しているので、ポートはもっと単純になると思います。

WTFaspチームはこの基本機能を提供していません
これは本当にブロッカーの問題です:(

CoreCLRでのLDAPサポートに関する更新はありますか？

これについても更新をお願いします。 ADサーバーに対してユーザーを認証する必要があるASP.NETCoreを使用してエンタープライズアプリケーションを開発します。

System.DirectoryServicesを.NETCore for v1.1.0（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 、MonoからCoreCLRへのTLSストリームを置き換えますSslStream興味があり、CoreCLRのLDAPサポートが必要な場合は、遠慮なく支援してください。

ASP.NET Core Webアプリケーション（.NET Framework）RC2プロジェクトが、System.DirectoryServices.AccountManagementを使用するクラスライブラリを参照できることを確認しました。 Webアプリケーションとクラスライブラリの両方がVS2015 Update 2で作成され、両方が.NET Framework 4.6.1を使用している場合にのみ、これを機能させることができました。

他の人の感情を反映するためだけに、LDAPなどを照会することができずにウォーターポーティングで死んでいます。

@ h3smith
私の以前の投稿を参照してください。 RC2のリリースにより、 System.DirectoryServices.AccountManagementを使用するクラスライブラリを参照できるようになりました。

Netstandardにはありません。

しかし、私が言うように、私たちはこれを機能させるために取り組んでいます。 うまくいけば
約2〜3週間で何か

2016年6月17日金曜日、ClintonBailiffの[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上でAngularWebアプリを使用し、ADにログインし、aspnet Core RC2で（ユーザーがWebブラウザーにパスワードを入力せずに）WebAPIコントローラーメソッドを呼び出している場合、呼び出し元のユーザーを認証する必要があります。 可能？ すぐに可能ですか？

これを行うには、クライアントからのhttpリクエストでwithCredentialsを使用する必要があります。 次に、User.Identityを使用して、コントローラーでユーザー情報とクレームを取得できます。
これはieとchromeで機能しますが、Firefoxでは、Windowsのユーザーとパスワードを入力したユーザーにポップアップが自動的に表示されます。

約2か月前に、同じ問題が発生しました（たとえば、LDAPサーバーをユーザーストアとして使用しようとしています）。 Novell LDAPライブラリ（https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html）を.netコア（https://github.com/dsbenghe/Novellを参照）に移植する以外に解決策は見つかりませんでした。 Directory.Ldap.NETStandard）。 nugetパッケージが公開されています。 ライブラリをOpenDJLDAPサーバーで使用しています（任意のLDAPサーバーで動作するはずです）。1.5か月の使用で問題はありません。

@dsbengheノベルのLDAPライブラリをnetstandardでコンパイルしました。ページングも含まれています。 これは@igorshmuklerによって行われました。 比較してコラボレーションしませんか？ 私たちのものはここで仕掛品ですhttps://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe .NETCoreの実装にご協力いただきありがとうございます。
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

.NETCoreのSystem.DirectoryServicesサポートに取り組むcc @ tquerec @ jimuphaus 。

待てない！ ETA？ 設計仕様？

それが最終的に移植されたとき、私たちは以下にアクセスできますか？

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.NETCoreアプリケーションでレガシークラスライブラリを参照する際に問題が発生しました。 ただし、VS 2015 Update 3でWebアプリとクラスライブラリを作成し、Webアプリとクラスライブラリで.NET Framework 4.61をターゲットにする場合は、問題はありません。

ADコードをクラスライブラリに入れられない理由はありますか？

.NET Core TxMのproject.jsonでPCLの後に"imports": "portable-net45+win8"が続くという意味ですか？ そのためには、Mono PCLリファレンスアセンブリがUnixに存在する必要があり、Unixでの自給自足を可能にする「純粋なドネットコア」ソリューションではありません。 コンパイラをサイレントにするのは良いハックですが、CoreFXBCLに対応する実装がある場合にのみ機能します。 原則として、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 [email protected]
書きました：

皆さん、メインの投稿にリアクションを追加していただけませんか？

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
。

@jchannon NovellLDAPの場合は+1。 それは私たちを前進させ、LDAP実装に実質的に変更を加えることはありませんでした。 私はあなたが正しく抽象化していることを意味します;）

はい、 @ jchannon NovellLDAPも使用することになりました。うまく機能しました。

これまでにそう言ったことがない場合は、 https：//github.com/VQComms/CsharpLDAP/commits/coreclrPortにあるブランチをご覧ください。

現時点での要件に対応しています...

@ h3smith @ johnkwaters問題があればお気軽に問題を提起してください😄

Novellを試してみることにしました。サンプルは十分に見栄えがしますが、Novell LDAPを使用してユーザーメンバーをグループから追い出す（削除する）方法がわかりません。
userPasswordが表示されず、LDAPサーバーに設定されていないため、MSADLDAPでパスワードを変更できません。

本当にこれが必要です！

@joshfreeまたは知っている他の誰か...
ActiveDirectoryServices.AccountManagementへのアクセスが必要な新しいプロジェクトを開始しようとしています。質問、ポートは1.1または1.2のどちらを対象としていますか？

これは1.1の一部ではありません（これはまもなく完成します）。 @tquerec 、ここであなたの計画についてコメントしていただけますか？

cc：@danmosemsft

それで、1.1の一部でない場合、誰かが計画を持っていますか？ このサポートがないことは大きな問題のようです。 明らかに、Microsoftはすべてこの統合を望んでいます。

ちょうど別の投票。 基本的なエンタープライズ機能が不足している場合、.NETCore上にエンタープライズクラスのシステムを構築するための投資を行うのは困難です。 小説プロジェクトは機能しますが、嗅ぎタバコではありません。

さらに別の投票。 これは、エンタープライズアプリケーションの作成に不可欠であるという同じ声明を繰り返します。

@nevcoBpalacio彼らは私たちに紺碧の促そうとしていると思います

これは、サービスを社内に残すことを要求する企業契約で使用する場合には機能しません。

私は連邦政府と現在は地方自治体の両方の政府機関で働いていますが、どちらの方法でも、クラウドベースまたはオンプレミスのいずれかのディレクトリサービスに統合するには、いくつかのインターフェイスまたは機能が必要です。 私は数十億ドルを管理するアプリケーションを共同開発してきましたが、常にディレクトリサービスの必要性が生じています。 これは別の投票ではなく、何を待っているのかという声明だと思います。 以前の.NETリリースでは、これは元々すぐに使用できるソリューションであったという以前の投稿に同意します。 COREのよりオープンな構造がコミュニティの勢いを増すはずだと理解しています。これがマイクロソフトが待つことを選択した場合、おそらく彼らはこれを言っていて、私はそれを見逃しました。誰かが主導権を握って時間を投資できるように、彼らはそれを言うべきです。それを成し遂げるために。

はい、System.DirectoryServicesを.NETCoreに追加してください。

来年中にSystem.DirectoryServices.Protocolsを移植する予定です。 現時点では、より確定した日付を提供することはできません。 System.DirectoryServicesまたはSystem.DirectoryServices.AccountManagementを移植する計画はまだありませんが、関心を測定することに興味があります。 プロトコルでは解決できない、人々が使用している名前空間の機能はありますか？

@tquerec私はプロトコルに精通していません。 アカウントのロック解除とアカウントのパスワードのリセットを行うActiveDirectoryセルフサービスを実行するプロジェクトがあります。 プロジェクトでUserPrincipalを使用し、FindByIdentity、UnlockAccount、SetPassword 、、 ExpirePasswordNow、などのメソッドを呼び出します。
これらがプロトコルで実行できるかどうかはわかりませんが、プロトコルは低レベルの実装であるのに対し、AccountManagementはActiveDirectoryを操作するためのより優れた抽象化であるように見えます。
ありがとう
ロックマイスター

@nevcoBpalacioは間違いなく私が同意する投票以上のものでなければなりません。 これにはもっと優先順位が必要だと思います。

@CalebMacdonaldBlack使用パターンとその理由についての@tquerecの質問に答えることができれば、役に立ちます。 シナリオなしでより多くの賛成票または「同意する/重要である」は、現時点で優先順位を上げるのに役立ちません...ありがとう！

私たちの使用法は、LDAPのスキャン/検索、資格情報の検証のためのBINDの実行、LDAPオブジェクト（ユーザー、グループ）の追加/削除、グループのメンバーシップの変更などです。

@tquerec Active Directoryに対してユーザーを認証し、アクセスできるグループでユーザーを承認できるように、System.DirectoryServices.AccountManagementが本当に必要です。

h3smithに明確に同意します..v1にこれが必要でしたが、代わりに、一緒にホベルした新しいパス（特にレプリケーションビット）に移動することを余儀なくされ、メンテナンスなどのオーバーヘッドで悲しみを引き起こしています。これにより、.NETCoreが作成されます。副作用として見栄えが悪い..

@liquidboy

v1にはこれが必要でした

.NET Core v1のことですか？ -完了して出荷されます。 現在1.2に取り組んでいます。 それとも何か他の意味ですか？

代わりに、小説の道を進むことを余儀なくされています

どういう意味ですか？ （申し訳ありませんが、DirectoryServicesのコンテキストはありませんが、シナリオの観点から何が欠けているのかを理解したいと思います）

@karelzは、このスレッドで「小説」という単語を検索するだけで、私が何を意味するのかがわかります。 私のチームの別の開発者（dsbenge）が、小説を使用することになったギャップについて（他の人たちと一緒に）コメントしました。 [上記のコメントへのリンクはこちらhttps://github.com/dotnet/corefx/issues/2089#issuecomment-228043297 ]

ええ、私はすでに出荷されている.NET Core v1を意味しました。私たちは、1年以上ソリューションに取り組んでおり、当時は優れたDirectoryServicesソリューションが必要でした。 。

@liquidboyリンクに感謝します-Monoの場合、.NET CoreAFAIKでソースコードを再利用できるはずです。 @tquerecは興味を持っていますが、それはあなたのチームが検討するものですか？

@tquerec ：次のものが必要です：
System.DirectoryServices、System.DirectoryServices.AccountManagement、System.DirectoryServices.ActiveDirectory、およびSystem.DirectoryServices.Protocols。

これらは、上記の返信で説明したように、Active Directory（およびその他のLDAPサーバー）のユーザー、グループ、属性に接続して管理するために必要です。 これらの機能を.NetCoreに含めることが重要です。

私は他の人に同意します。 ActiveDirectoryに対して認証を行うアプリを.NETCoreに移植するには、これが必要です。 これはかなり基本的なことであり、間違いなく可能な限り早いリリースになるはずです。 それは非常に多くのものを移植することへのブロッカーです。

.NET Coreロードマップページ（https://github.com/dotnet/core/blob/master/roadmap.md）には、.NET Core1.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プロファイルを.NETFrameworkと交差させることで行われました。 Xamarainプロファイル（monoのサブセット）はDirectoryServicesをサポートしていないため、これは交差点にありませんでした。

これが含まれるべきであると主張するために私たちは何ができるでしょうか？ Microsoftアプリケーションで最も一般的な認証スキームを使用できないことは、少しブロッカーですよね？ ここではAzureに焦点を当て、代わりにAADに焦点を当てていますか？ それとも、これをプラットフォーム間で移植することは、プロトコルのより大きな未知数であるというブロッカーですか？

ここで優先度を上げる方法はありますか？ 2.0は遠い道のりであり、他のすべてが機能する場合は本当に残念ですが、ユーザーを認証することはできません。 これは、非常に多くのアプリケーションの仮想フロントドアです。 IMOは、部分的なブロッカーではなく、本質的に完全なブロッカーであることが多いため、優先度の点で少し異なります。

.NETCoreでこれをサポートしたいという意見の相違はないと思います。これは.NETStandardの一部であるのとは異なり、いつの問題かということです。 @tquerecがその地域を所有しており、それについて話す人になるでしょう。

.NET Foundationの誰かが質問しましたが、私たちが具体的に使用している名前空間は次のとおりです。
System.DirectoryServices、System.DirectoryServices.Protocols、System.DirectoryServices.AccountManagement

では、 @ tquerec 、.NET Core 1.2のSystem.DirectoryServicesにフラグを付けるにはどうすればよいですか？ 少なくとも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と同じバケットに分類されます。

@ karelz1.2のWindows専用ソリューションの意味がわかりません。 すでに動作するWindowsのみのソリューションがあります。

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

@ rock-meisterつまり.NETCoreです。 あなたが言及したものは、「完全な」.NET4.5.2 +を対象としています。

はい、Windowsのみのサポートは私たちにとって大きな阻害要因です。 .NET Coreの移植に関するすべての作業を実行し、プラットフォームのサポートを後で「無料」で拡張できます。 ポートへの_開始_さえも巨大なブロッカーではありません。 それがなくなったことは大きな勝利です。

Windowsショップなので、これはここでも大きな勝利になります。 非常に多くの大企業がこれを大きな勝利と見なすでしょう！ あなたの情報を最新に保つためにありがとう。 投稿してください。 ありがとう。

@karelz説明してくれてありがとう。 はい、Windowsのみの1.2のスコープが機能します。
ロックマイスター

Linux / LDAPをサポートするSystem.DirectoryServices.Protocolsは、私たちが行う作業の最優先事項です。

pswindows-スコープのみが.netcore / .netstandardの目標に反しているようです

AD以外のLDAPサーバーをサポートできるように、しばらく前にSystem.DirectoryServicesの使用からSystem.DirectoryServices.Protocolsの使用に切り替えました。 Protocols名前空間にアクセスできることは、コードを.NETCoreに移植できるようにすることに一歩近づきます。

ただし、これがプラットフォーム固有になる場合は、使用量が少なくなります。 .NET Coreに移行する主なポイントの1つは、プラットフォームの移植性です。 おそらくまだそれを待つ必要があるでしょう。

私たちにとって.NETCoreに到達したのは、Dockerを活用し、プラットフォームに完全に依存しない機能でした。 したがって、WindowsのみのLDAPサポートに固執することは有益ではありません。

社内で話し合ってくれてありがとう。

私の投票はプラットフォームに依存しないルートで行われます🦃

プラットフォームにとらわれないコメントに同意する必要があります。これが達成されるまでコアを使用できないことが痛いのです。 これは、より高いレベルで見直さなければならないことだと思います。 私が得られないのは、概念の複雑さですか？ AD、Novellなど、いくつかのディレクトリソリューションがあります...これには、クロスプラットフォーム（不可知論者）のインターフェイスソリューションが必要です...ハッピーホリデー！

個人的には、Windowsのみのスコープで完全に問題なく動作することができましたが、私の意見では、これは.NETCoreとその移植性の概念を壊します。
プラットフォームに依存しないソリューションは、焦点を当てるルートである必要があります。

はい、同意しました。.NETCoreはクロスプラットフォームであり、機能/ APIはサポートされているすべてのプラットフォームで機能する必要があります。
したがって、System.DirectoryServices.Protocolsを最初に移植/実装する場合は、Linuxでも機能するはずです。

理想的には、プラットフォームに依存しないソリューションが目標であるべきだということに同意します。 まだWindowsにインストールされていないのは、私のような企業（AD）環境でプラットフォームを試してみたいだけの多くの開発者にとってはブロッカーです。 そのため、当面はWindowsのみのソリューションを歓迎します。

チャイムを鳴らして、クロスプラットフォームを組み合わせることができるようになるまでは、Windowsのみのソリューションで問題ないと言いたいです。

Active Directoryに接続する必要がある開発者の99.9％は、Windowsボックスで開発しているエンタープライズ環境で接続していると思います。

私たちの側で資金調達について話し合っています（約2週間で更新される予定です）。これは現在、.NET Standard2.0の一部ではないAPIからの最優先事項です。

Windowsの実装やLinuxの実装を支援/貢献してくれる人はいますか？ （デスクトップからコードをドロップする可能性があり、ビルドするためにさらにマッサージする必要があります+いくつかのテスト）

@karelzLinux側に貢献したいと思います。 Windows認証とWindows以外の認証（オンプレミス）の両方でこのサポートが必要です。 これは私たちにとってブロッカーであり、クロスプラットフォームプロジェクトの.NETコアをターゲットにしています（以前はLinux側でMono、Windows側で.NETでした）。

間違いなく、私たちができるところを手伝いたいと思います。

私は手伝いたいのですが、皆さんは私よりもはるかに経験豊富であり、私は何の役にも立たないと確信しています。

@karelz @tquerec Windows、そして将来的にはLinuxでのテストを喜んでお手伝いさせていただきます。 私はスレッドを購読しているので、ここに返信するか、私が参加する必要があるときに連絡を取るように言ってください。 これにご協力いただきありがとうございます。 これは待望のことであり、たとえ段階的であっても、.NETCoreをさらに採用するための良いステップになるでしょう。

「拡張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：来週半ばだと思います）。 ご不明な点やご提案がございましたら、お気軽にお問い合わせください。

これは、Linuxで実行しているがWindows認証を必要とするSQL Serverに接続しているときに、SqlClientなどのライブラリがWindows認証を実行することも可能にしますか？

これは、Linux上で実行されている.NETCoreに移植できるようにするための私の障害の1つです。 すべてのエンタープライズMicrosoftSQLサーバーは、ADにあるサービスID（非対話型）を介した接続のみを許可します。

blgmboy。 あなたの問題は、新しい提案されたモデルとの真のクロスプラットフォーム互換性を確保するために物事を「精査」する必要がある理由の典型的な例です。 より多くのシナリオがある場合は、環境がどのように交差する必要があるかを示す良い例だと思います。コアのAD部分で発生している他の問題をリストする必要があります。

はい、私は間違いなくこのスレッドを念頭に置き、見つけたものはすべて共有します。 説明したように、これは厳格なセキュリティを備えたSQLファームを持つ企業にとって非常に大きなショーストッパーであることをみんなに知らせたかっただけです。

また、最終的に同じ問題が発生するEFCoreのようなものを使用することへのショーストッパーでもあります。

System.DirectoryServicesがCoreFXにマージされました。 次のステップは、.NET Core-Windows用にビルドし、テストを追加することです。

ありがとうイアン。 この問題に関するいくつかの牽引力を見るのは良いことです！

ありがとうイアン！

更新された実行プラン：編集：発見しやすさを向上させるために、この号の一番上の投稿に移動しました

誰かがいずれかのステップに取り組んでいる場合は、重複した作業を避けるために、ここでそれについて言及し、調整してください。 私もあなたに問題を共同で割り当てます。

System.DirectoryServices名前空間には、オンプレミスのエンタープライズWindowsアプリにとって重要な機能が含まれているため、この問題の進捗状況を確認できます。 良い仕事を続けてください。

ソースを修正し、System.DirectoryServicesを構築しています。 すぐにPRを送る予定です。

第2ラウンドに貢献してくれた@tquerecに感謝します！
残りの2つの名前空間またはテストを支援するボランティアはいますか？ （ @gortok @ h3smith @CalebMacdonaldBlack @ SOM-fermonte）

@ jay98014には、 https：//github.com/dotnet/corefx/pull/15324にPRがあり、さらにサポートを追加して、プロトコル/アカウント管理を構築できます。

価値のあることとして、私は最近System.DirectoryServices.Protocolsを実験してきましたが、多くの単純なSystem.DirectoryServicesシナリオをSystem.DirecotryServices.Protocolsで模倣するのは難しくないことがわかりました。 それに基づいて、クロスプラットフォームのSystem.DirectoryServices.Protocolsは多くのユーザーにとって有用な回避策になる可能性があるため、S.DSとS.DS.AMをクロスプラットフォームで機能させることは優先度が低くなる可能性があると思います。

もちろん、これは、System.DirectoryServices.ProtocolsをクロスプラットフォームのLDAPソリューションとして機能させることの優先度が高いことを意味します。

プルリクエストを正しく読んでいますか？ これは数日前に受け入れられたようですので、ソースからビルドした場合、試してみることができるはずですか？

はい、すべてのDirectoryServicesを構築していると思いますが、テストはありません。これにより、パッケージを安定して出荷したり、コードベースを改善したり（バグ修正、機能拡張など）することができなくなります。
ソースからのビルドを試してみることができれば、それは素晴らしいことです。 あなた（または他の誰か）が私たちがテストを追加したり、Linuxポートを起動したりするのを手伝いたいのなら、それはさらに良いでしょう:)

皆さんこんにちは、

ドメインの100％内部にあるため、ActiveDirectoryのサポートを必要とするエンタープライズプロジェクトを開始する準備をしています。 誰かがこの問題のステータスと次のコアリリースへの期待を教えてもらえますか？ 申し訳ありませんが、GitHubコミュニティは初めてであり、さまざまな用語やステータス情報のすべてをまだ理解していません。

個別に管理する必要があり、データの不一致も発生させる完全に個別のIDモデルではなく、メンバーシップにActiveDirectoryを使用することをお勧めします。

前もって感謝します！

その質問については@karelzですが、答えは、開発者が予定されていないため、2.0リリースでは現在予想されていないということだと思います。 コミュニティの貢献は大歓迎です。 2.0リリースを出荷する必要はありません。出荷準備が整ったらいつでもNuGetで出荷できます。

完全！ あなたは私の質問に答えました。

ありがとう。

@nevcoBpalacio貢献を狙うことに興味はありますか？

特にこのトピックについては、多くの人がエンタープライズソリューションのコアになるのを妨げていることを知っているので、私は興味を持っています。 しかし、回避策があり、その日の時間（子供との夜）が見つからないようです。 自宅でシステムを再構築して、GitHubで動作するようにします。 よろしくお願いします！ ありがとう。

Nevcobpalacio、vs17を使用し、クロスプラットを必要としない場合は、完全な.netフレームワークを対象とするコアWebアプリテンプレートを使用して、system.directoryservices.accountmanagement dllを昔ながらの方法で参照することで、必要なものに少し近づけることができます。その間にそれを行うためにあなた自身のミドルウェアを転がしてください。 私が見たところ、nugetパッケージを使用して参照を削除することを除いて、これが利用可能になると、同じコードが.netCoreをターゲットにするように引き継がれるはずです。 この情報がプロジェクトを軌道に乗せるのに役立つことを願っています。

@ los93solその提案に感謝します。 最初の議論は、その提案と同様にそれを構築し、後でNugetにあるものに「カットオーバー」できるミドルウェアモジュールにすることです。 本当にありがとう！

私はこの提案についてコメントし、あなたを称賛しなければなりません。 私は最初、このコアへの変更について懐疑的でした。 ただし、このコミュニティアプローチでは、このような議論が明らかになり、これらの大きな変化の中で私たち全員が問題を解決するのに役立ちます。

ありがとう。

不足しているテストの追加、またはSystem.DirectoryServices.ProtocolsのLinux / Macへの移植に現在取り組んでいる人はいますか？

@pasikarkkainen AFAIK現時点では、Microsoftチームによるそのような積極的な取り組みはありません（近い将来変更される可能性があるか、変更されない可能性があります）。 コミュニティの誰もがそれに取り組み始めているのを見たことがありません。
貢献することに興味がありますか、それともステータスに興味がありますか？

@karelzこの夏の.NETCore2.0リリースのDirectoryServicesをターゲットにしているようです。

@shanselmanからの引用

AD –全体として、LDAPを直接呼び出したい場合、これはギャップです。 あなたは確かに今すぐWindows認証に対して認証することができます。 特に夏の時間枠の前後にCore2.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 Core2.0上で利用可能になるはずです。
現在、マスターブランチでプレビューとしてパッケージを利用できるようにする作業（＃18090）と、並行してテストアセットで作業しています（＃20669）。

共有ランタイムまたはWindows以外のランタイムをターゲットにすると、コンパイルエラーが発生しますか？ それとも、 PlatformNotSupportedトラップで終わるのでしょうか？

これは、Windows以外のアセットを含まないスタンドアロンパッケージになります。 コンパイルが壊れるはずです。 @ericstjが確認できます。

コンパイルエラーは発生せず、実行時の「PlatformNotSupported」例外になります。

ええ、それは古いです-.NET標準ライブラリからそれを使用する人々をブロックしますか、それともコンパイル時エラーをPlatformNotSupported例外に変えますか？ ...幸いなことに、妥協点があります知らせてくれます。

netstandard 1.6プロジェクトでSystem.DirectoryServicesパッケージを実行しようとすると、次のエラーが発生します。

Install-Package：パッケージSystem.DirectoryServices 4.0.0はnetstandard1.6（.NETStandard、Version = v1.6）と互換性がありません。 パッケージSystem.DirectoryServices4.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＃
using（var context = new PrincipalContext（ContextType.Domain、domain、$ "OU = someou、DC = somedomain、DC = bla"））
`` ``

.NET Core2.0を搭載したWin7x64では、次のようになります。

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によるcallstackとxml / C＃コード構文の強調表示を修正しました

@ bruno-garcia別の問題を提出してください。 これは、特定のバグ/違いではなく、全体的な移植作業を追跡しています。 ありがとう！

@ bruno- https：//github.com/dotnet/corefx/issues/23605によって追跡されている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

===============================================
誰かが私と同じ問題を抱えている場合は、代わりに.NETCLIを使用してください

dotnet add package 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はエンタープライズ環境のコア認証メカニズムの1つであったため、すでに取り組んでいました。 ほとんどの大企業にとって、Linuxでこの種の対話を実行できないと、文字通りCoreの目的が損なわれ、ドットネットのプレコアビルドに固執することになり、貴重なコミュニティの対話が制限されることを指摘します。

@danmosemsftまた、文字通りこれに取り組む予定がない場合は、他の開発者が作品を入手できるように、コミュニティに明確に知らせてください。

@shairozanこれまでのところ、Linux上のDirectoryServicesをWindowsよりも優先度が高いと考えている54人中7票に注目しています。https： //github.com/dotnet/corefx/issues/2089#issuecomment-261093217を参照してください。
開発者が.NETCoreから得られる利点は、xプラットフォームだけではありません（ただし、x-platが最大の理由の1つであることに同意します）。

最初に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.NETStandardNugetパッケージがあります。 私たちは高度なLDAPユーザーではなく、資格情報を検証してユーザー情報を取得するために使用しますが、ドットネットコアランタイム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サポートを取得する必要があります。

DirectoryServices for Windowsでの作業が終了し、問題が解決しました。
ノート：

• 最終的なパッケージの公開は、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は、すべての開発リソースをAzureに投入しています。これには、ActiveDirectoryが含まれます。 「2016年の新機能」をご覧ください。ほとんどがAzureAD / Hybridへの投資です。 https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services。

Microsoftは、Linux用のこのライブラリに投資していません。代わりに、全員がAzureADに移行することを望んでいるからです。 それは理にかなっています、なぜあなたは顧客を遠ざけようとしている何かに投資するのですか？

しかし、あなたは比較的単純なことをしています。 新規LDAPライブラリを使用できます。これらはADおよび.NETCore forLinuxで動作します。 プロトコルの動作は自分で行う必要がありますが、それほど複雑ではなく、サンプルがたくさんあります。 欠点は、バインディングを自分で管理する必要があることです。これには、ユーザーDNとパスワードが必要です。

System.DirectoryServicesは現在Windows専用のAPIであり、 .NETCore用のWindowsCompatibility-Packの一部です。 原則として、 System.DirectoryServicesの一部をLinuxで動作させることはできますが、それを実行するためのリソースはまだありません。 dotnet / corefx＃24843はこの作業項目を追跡しています。

Linuxで動作しないパッケージのインストールを許可するのはなぜですか？ 別の方法はAPIサーフェスをフォークすることですが、これもすべての場合にうまく機能するわけではなく、システム全体のコーディングが難しくなります。 もちろん、コードがクロスプラットフォームで機能するかどうかを予測するのが難しくなる可能性があるため、私たちの選択にも問題がないわけではありません。 コーディング時にライブフィードバックを提供する互換性アナライザーのプレビューがあります。

Windows互換性パックとクロスプラットフォームアナライザーが連携して機能する方法の詳細については、このビデオを参照してください。

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

@thedevopsmachine

Microsoftは、Linux用のこのライブラリに投資していません。代わりに、全員がAzureADに移行することを望んでいるからです。

それは私がそれを見る方法ではありません。 ご指摘のとおり、Azureで収益を上げるつもりです。 また、Azureは、さまざまなテクノロジーとオペレーティングシステムを提供するクラウドプラットフォームです。 クラウド内のLinuxよりもクラウド内のWindowsを宣伝することにビジネス上の関心はありません。 しかしもちろん、.NETは15年間Windows上で強力な存在感を示してきました。 すべてのオペレーティングシステムで物事を完全に機能させるには時間がかかりますが、私たちのオープンソースの取り組みをフォローしているほとんどの人は、私たちが意図的にLinuxを妨害していないことを理解できると正直に思います。 時間がかかるだけです。

私は一貫したapix-platとx-frameworkを持つというアプローチに同意しますが、iveがその恐ろしいエラーに遭遇したときはいつでも魂を破壊します..私は@sscolemanを感じます...

このDirectoryServicesパッケージはCentOS7で動作しますか？

このDirectoryServicesパッケージはCentOS7で動作しますか？

パッケージはインストールできますが、機能しません。 それを使用すると、プラットフォームがサポートされていない例外が発生します。 Linuxで一般的なディレクトリサービスをサポートする方法を検討しています。 これは私たちのレーダーです。

これは本当にLinuxのサポートが必要です

CC @joperezr

@niemyjski dotnet / corefx＃24843を参照

これは本当にLinuxのサポートが必要です

..さらに、Dockerコンテナで実行できます。 Linuxで.NETCore 2+を使用したい場合、古いNovellディレクトリの実装にフォールバックする必要があるのはお尻の痛みです。
とにかくそれに取り組んでくれてありがとう！

なぜこの問題を閉じるのですか？ System.DirectoryServices.AccountManagementは、Windows以外の.NETCoreにはまだありません。

# 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は巨大であり、1つのリリースですべての機能をサポートできるとは思えません。 特定の要求があると、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の実装は、おそらく非常に大きなユースケースです。 私の2つのユースケースを共有しましょう：

1）そのままではサポートされていない属性が必要なため、UserPrincipalから派生しています。 私はhttps://stackoverflow.com/questions/24798037/extend-userprincipal-classをフォローしましたが、これは古い.NET Frameworkの一種の標準であり、そのアプローチを機能させることで、より多くの開発者が役立つと思います。

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 Frameworkコードを書き直す必要があるため、冗長なコードが必要になります。 私は間違いなくすべてのコードのコード分割を避けることを好みます、そして他の人もその考えを嫌うと確信しています。
また、認証がどのように機能するのか疑問に思っています。 Novell（私が試した古いバージョン）では、資格情報を指定する必要がありますが、既存のコードでは指定する必要はありません。
ありがとう、ヨアキム