@vibronet

Apakah ada pembaruan tentang ini?

Saya juga ingin pembaruan tentang ini. Perusahaan saya meminta saya membangun aplikasi baru yang memerlukan kemampuan untuk menanyakan Active Directory melalui LDAP tetapi tampaknya saat ini tidak memungkinkan. Apakah ada dukungan yang direncanakan untuk itu, apakah itu dibatalkan demi sesuatu yang lain, atau sudah berfungsi tetapi tidak didokumentasikan di mana pun?

Tampilan baru dan segar dalam menerapkan dukungan LDAP dan Active Directory akan sangat bagus untuk dimiliki di .NET CoreFX.

Kami sangat membutuhkan solusi Active Directory/LDAP yang dapat kami manfaatkan di .NET Core. Baik itu implementasi clean sheet atau port System.DirectoryServices tidak terlalu penting bagi saya. Ada banyak aplikasi Windows yang berfokus pada bisnis yang benar-benar membutuhkan autentikasi AD, dan autentikasi LDAP akan menjadi poin fitur hebat untuk pengembang lintas platform.

Setuju dengan catatan yang kompatibel di atas - Saya tidak merasa port langsung benar-benar diperlukan, kami hanya perlu cara untuk mengakses auth (dan melakukan tindakan lain: mencari, membuka kunci, menghapus, dll.) terhadap Active Directory atau penyedia LDAP mana pun .

@NickCraver

Saya tidak merasa port langsung sangat diperlukan, kami hanya perlu cara untuk mengakses auth [...] melawan Active Directory

Senang mendengarnya. Jangan terlalu banyak membaca label port-to-core saya yang baru saja saya terapkan. Ini hanya cara saya melacak celah dalam penawaran .NET Core yang mencegah pelanggan seperti Anda untuk mem-porting aplikasi mereka ke .NET Core.

@terrajobst Gotcha. Saya tidak selalu berpikir ini harus menjadi item 1.0 karena modularitasnya (dan itu _sounds_ seperti itu dijadwalkan untuk pasca-RTM), tetapi saya sangat menantikannya. Ini akan menjadi pemblokir porting Opserver bagi saya, sangat senang untuk berpartisipasi dalam diskusi API jika kami dapat berguna. Kami memiliki berbagai kasus penggunaan di sisi sysadmin yang mungkin bisa membantu, ping jika saya bisa membantu.

Hanya untuk melemparkan topi lain ke dalam ring. Saat ini, ini adalah pemblokir terbesar yang tersisa untuk saya juga. Cukup mampu mengautentikasi akan sangat membantu untuk saat ini.

Bisakah kami mendapatkan tanggapan resmi dari seseorang di tim pengembang tentang rencana ini, jika ada rencana untuk mendukung ini?

Saya tidak merasa port langsung sangat dibutuhkan

Mengapa? Maaf saya bingung. Bukankah itu solusi yang paling mudah untuk semua orang dan sesuai dengan prinsip KERING?
Namun demikian, jika ada alasan untuk menulis seluruh API dari awal, beberapa konsistensi dengan API lama (tanda tangan metode yang sama) tidak akan terlalu membingungkan konsumen.

@jasonwilliams200OK izinkan saya mengklarifikasi, maksud saya DirectoryServices.ActiveDirectory secara khusus. Saya pikir otentikasi, dan hal-hal di sekitarnya: misalnya keanggotaan grup adalah 95-99% kasus penggunaan namespace. Saya pikir port tanda tangan langsung dari _that_ cukup berguna. Jika sisanya menjamin perubahan untuk beberapa alasan maka saya akan cukup baik-baik saja dengan itu, dan oke jika itu datang nanti ... autentikasi akan baik untuk keluar dari pintu ASAP karena itu adalah penghalang bagi banyak orang.

Mengintegrasikan setidaknya fungsi dasar pencarian pengguna Active Directory dan memetakannya dengan peran khusus dengan ASP.NET 5 akan memudahkan implementasi Otentikasi Windows ke dalam aplikasi web ASP.NET. Kami membutuhkan fungsi ini di situs intranet kami.

Ini juga menjadi penghambat bagi kami. Kita harus dapat mengautentikasi, meminta pengguna dan grup, membuat pengguna dan grup baru, dll. terhadap server ldap.

Ini juga merupakan pemblokir bagi saya - saya memerlukan permintaan dan otentikasi pengguna.

Saya menemukan solusi untuk mengautentikasi terhadap Active Directory dalam aplikasi web .NET Core rc1. Anda hanya perlu mengganti metode CheckPasswordAsync di kelas UserManager. Biarkan aku tahu apa yang kamu pikirkan.

Pertama, Anda perlu membuat halaman register khusus yang memungkinkan pengguna memasukkan nama pengguna AD alih-alih alamat email dan kata sandi. Nama pengguna tersebut masuk ke properti UserName dari kelas ApplicationUser yang dihasilkan oleh template ASP.NET 5 saat Anda memilih otentikasi Akun Pengguna Individual. Selain itu, Anda harus menetapkan properti Kata Sandi secara default ke sesuatu yang lolos validasi internal di kelas IdentityUser.

Pengontrol halaman register saya memanggil metode Web API 2 yang menemukan nama pengguna di AD dan mengembalikan JSON yang menyimpan informasi AD untuk pengguna itu. Saya telah menambahkan beberapa properti khusus ke kelas ApplicationUser untuk menyimpan informasi AD. Saya akan memposting kode dari proyek saya minggu depan.

Kemudian tambahkan file kelas di folder Layanan. Saya menamai saya ApplicationUserManager.cs. Tambahkan kode di bawah ini ke file kelas itu.

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

Kemudian buka file Startup.cs. Tambahkan .AddUserManager() ke panggilan AddIdentity dalam metode ConfigureServices seperti yang ditunjukkan di bawah ini.

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

Ini setidaknya memungkinkan saya untuk mengatur otorisasi berbasis kebijakan/klaim sambil menunggu dukungan DirectoryServices.

Saya mengandalkan perpustakaan ini. Sayang saya tidak bisa port sekarang.

@ClintBailiff Saya harus berpadu di sini - karena menyampaikan kata sandi pengguna melalui kabel lagi ke aplikasi lain dalam plaintext adalah _benar-benar_ ide yang buruk. Tolong, jangan gunakan pendekatan ini. Ini adalah lubang keamanan.

@terrajobst ini akan menjadi penghalang dalam mem-porting aplikasi saya yang lebih besar seperti Opserver - dapatkah kami memprioritaskan ini?

@NickCraver Saya tidak pernah menyarankan untuk meneruskan kredensial sebagai teks biasa. Sebagai aturan, saya menggunakan SSL untuk semua aplikasi/layanan web saya karena mereka biasanya mengembalikan data yang hanya boleh dilihat oleh pengguna yang berwenang. Saya tidak berpikir untuk menentukan itu mungkin karena sangat jelas bahwa Anda tidak ingin mengirim kredensial dalam teks biasa.

Saya akan mendukung setidaknya menyediakan port System.DirectoryServices.Protocols . Kami baru-baru ini mengalihkan kode terkait LDAP ke kode ini untuk mendukung jangkauan server LDAP yang lebih besar, karena ruang nama System.DirectoryServices.ActiveDirectory hanya suka berbicara dengan server AD.

Saya kira, adalah mungkin bagi perpustakaan pihak ke-3 untuk meningkatkan dukungan semacam ini, tetapi karena sudah ada dalam kerangka kerja saya akan membayangkan bahwa port akan lebih sederhana.

Tim asp WTF tidak menyediakan fungsionalitas dasar ini
Ini benar-benar masalah pemblokir :(

Adakah pembaruan tentang dukungan LDAP di CoreCLR?

Saya juga ingin pembaruan tentang ini. Saya akan mengembangkan aplikasi perusahaan dengan ASP.NET Core yang perlu mengautentikasi pengguna terhadap server AD.

Saya akan melihat porting System.DirectoryServices ke .NET Core untuk v1.1.0 (https://github.com/dotnet/corefx/milestones)

@joshfree
Saya juga harus mengautentikasi pengguna dari ADLDS, harap pertimbangkan juga System.DirectoryServices.AccountManagement

Beberapa tahun yang lalu perusahaan tempat saya bekerja mengambil kode sumber perpustakaan Novell (Mono) LDAP sehingga aplikasi kami dapat berbicara dengan sistem Active Directory, OpenLDAP, dan Oracle, dan kami menambahkan dukungan untuk kontrol halaman dan memperbarui beberapa perbaikan TLS. Kami melakukan ini karena kami ingin berjalan di Linux. PR dengan perubahan kami dikirim ke pemilik. Karena kita sekarang ingin masuk ke CoreCLR, perpustakaan itu perlu dikonversi ke RC2. Pekerjaan telah dimulai di sini https://github.com/VQComms/CsharpLDAP/pull/1 , ada 17 kesalahan kompiler yang perlu ditangani. Mereka terutama Thread.Abort , ThreadInterruptedException , menggantikan aliran TLS dari Mono ke CoreCLR SslStream Jika ada yang tertarik dan membutuhkan dukungan LDAP untuk CoreCLR, jangan ragu untuk membantu.

Saya telah mengkonfirmasi bahwa proyek RC2 Aplikasi Web Inti ASP.NET (.NET Framework) dapat mereferensikan perpustakaan kelas yang menggunakan System.DirectoryServices.AccountManagement. Saya hanya bisa membuatnya bekerja ketika aplikasi web dan perpustakaan kelas dibuat dengan VS 2015 Update 2 dan keduanya menggunakan .NET Framework 4.6.1.

Hanya untuk menggemakan sentimen orang lain, kita mati di port air tanpa bisa menanyakan LDAP dan sejenisnya.

@h3smith
Lihat postingan saya sebelumnya. Dengan rilis RC2 Anda sekarang dapat mereferensikan perpustakaan kelas yang menggunakan System.DirectoryServices.AccountManagement .

Tidak di Netstandard.

Namun seperti yang saya katakan, kami sedang berupaya agar ini berfungsi. Semoga memiliki
sesuatu dalam waktu sekitar 2-3 minggu

Pada hari Jumat, 17 Juni 2016, Clinton Bailiff [email protected] menulis:

@h3smith https://github.com/h3smith
Lihat postingan saya sebelumnya. Dengan rilis RC2, Anda sekarang dapat mereferensikan
perpustakaan kelas yang menggunakan _System.DirectoryServices.AccountManagement_.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679, atau bisukan
benang
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

Ada pembaruan tentang ini? Saya perlu mengautentikasi pengguna panggilan, ketika pengguna menggunakan aplikasi web sudut di LAN, masuk ke AD, memanggil metode pengontrol WebAPI (tanpa pengguna memasukkan kata sandi ke browser web) di aspnet core RC2. Mungkin? Segera mungkin?

Untuk melakukan ini, Anda hanya perlu menggunakan withCredentials dalam permintaan http Anda dari klien. Kemudian Anda bisa mendapatkan informasi dan klaim pengguna di pengontrol Anda menggunakan User.Identity.
Ini berfungsi di ie dan chrome tetapi dengan Firefox, sebuah popup akan secara otomatis ditampilkan ke Le ketik pengguna di pengguna dan kata sandi windows mereka

Kami mengalami masalah yang sama (misalnya mencoba menggunakan server LDAP sebagai penyimpanan pengguna) sekitar dua bulan yang lalu. Kami tidak dapat menemukan solusi apa pun selain mem-porting perpustakaan Novell LDAP (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) ke .net core (lihat di sini https://github.com/dsbenghe/Novell. Directory.Ldap.NETStandard). Ada paket nuget yang diterbitkan. Kami menggunakan perpustakaan dengan server OpenDJ LDAP (harus bekerja dengan server LDAP apa pun) - tidak ada masalah dalam 1,5 bulan penggunaan.

@dsbenghe kami baru saja mendapatkan kompilasi lib Novell LDAP kami di netstandard, milik kami juga berisi paging. Ini dilakukan oleh @igorshmukler . Apakah Anda ingin membandingkan dan berkolaborasi? Milik kami adalah WIP di sini https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Terima kasih atas pekerjaan Anda pada implementasi .NET Core itu.
Setelah mendapatkan paket nuget, saya telah membuat kode berikut untuk menguji apakah kata sandi ActiveDirectory pengguna benar

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

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

Dan menggunakan kelas pembantu sederhana untuk memberi tahu aplikasi sudut apa yang sedang terjadi

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

Untuk UWP, ada permintaan untuk fitur ini di UserVoice kami: https://wpdev.uservoice.com/forums/110705/suggestions/1256779

cc @tquerec @jimuphaus yang akan mengerjakan dukungan System.DirectoryServices untuk .NET Core.

Tidak sabar! ETA? Spesifikasi desain?

Ketika akhirnya porting selesai, apakah kita akan memiliki akses ke:

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

Saya tahu ada beberapa cacat kecil dalam namespace itu, tetapi masih cukup membantu.

@GArrigotti dalam pengujian, menggunakan LdapDirectoryIdentifier biasanya lebih cepat dari 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;  
}

Apakah ada ETAnya? Saya bisa menggunakan ini dalam sistem karena akan selesai pada akhir bulan ini ...

@johnkwaters apakah ada alasan mengapa Anda tidak dapat meletakkan kode AD di perpustakaan kelas? Beberapa orang (termasuk saya) mengalami masalah dalam mereferensikan perpustakaan kelas lama dalam aplikasi ASP.NET Core. Tetapi tidak ada masalah jika Anda membuat aplikasi web dan perpustakaan kelas di VS 2015 Update 3 dan menargetkan .NET Framework 4.61 di aplikasi web dan perpustakaan kelas.

apakah ada alasan mengapa Anda tidak dapat meletakkan kode AD di perpustakaan kelas?

Apakah maksud Anda PCL diikuti oleh "imports": "portable-net45+win8" di project.json untuk .NET Core TxM? Itu akan membutuhkan Majelis Referensi Mono PCL untuk hadir di Unix dan bukan solusi "core donet murni", yang memberikan swasembada di Unix. Ini adalah peretasan yang baik untuk membungkam kompiler, tetapi hanya bekerja terus menerus jika CoreFX BCL memiliki implementasi yang sesuai. Sebagai aturan, project.json tanpa "imports" untuk netcoreapp/netstandard1.x selalu lebih baik. misalnya https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Ada update tentang ETA? Di mana saya bisa pergi ke layanan mandiri pertanyaan berulang itu?

_Benar-benar_ menantikan fitur ini!

Sangat menantikan fitur ini juga!!

Sangat menantikan fitur ini juga!!

Saya juga sangat membutuhkan fitur ini!

Guys, bisakah Anda menambahkan reaksi ke posting utama?

Atau gunakan library yang sudah di nuget oleh 2 orang terpisah. Nya
semua OSS. Jika Anda tidak menyukai paketnya, kirimkan PR

Pada 8 September 2016 pukul 12:19, Mikhail Orlov [email protected]
menulis:

Guys, bisakah Anda menambahkan reaksi ke posting utama?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328, atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 untuk @jchannon Novell LDAP. Itu membuat kami bergerak maju dan hampir tidak ada perubahan pada implementasi LDAP kami. Maksud saya, Anda mengabstraksi dengan benar;)

Ya, saya akhirnya menggunakan @jchannon Novell LDAP juga, itu bekerja dengan baik.

Jika saya belum pernah mengatakannya sebelumnya, inilah cabangnya di https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Berfungsi dengan baik untuk kebutuhan kami saat ini...

@h3smith @johnkwaters setiap masalah jangan ragu untuk mengangkat masalah

Saya memutuskan untuk mencoba dengan Novell, sampelnya terlihat cukup bagus tetapi saya tidak tahu bagaimana cara mengeluarkan (menghapus) anggota pengguna dari grup dengan Novell LDAP.
Saya tidak dapat mengubah kata sandi saya di MSAD LDAP karena saya tidak dapat melihat kata sandi pengguna dan Kata sandi tidak disetel di Server LDAP.

Sangat membutuhkan ini!

@joshfree atau siapa pun yang tahu...
Kami sedang mencari untuk memulai proyek baru yang membutuhkan akses ke ActiveDirectoryServices.AccountManagement Pertanyaan, Apakah port ditargetkan untuk 1.1 atau 1.2?

Ini bukan bagian dari 1.1 (yang akan diselesaikan). @tquerec , bisakah Anda mengomentari rencana Anda di sini?

cc: @danmosemsft

JADI, jika bukan bagian dari 1.1, adakah yang punya rencana? Sepertinya masalah besar untuk tidak memiliki dukungan ini. Jelas, Microsoft tentu menginginkan integrasi ini.

Hanya satu suara untuk. Sulit untuk membuat investasi untuk membangun sistem kelas perusahaan di .NET Core ketika tidak memiliki fungsionalitas perusahaan yang mendasar. Proyek Novel bekerja, tetapi tidak sampai padam.

Namun suara lain. Saya akan menggemakan pernyataan yang sama bahwa ini merupakan bagian integral untuk membuat aplikasi perusahaan apa pun.

@nevcoBpalacio Saya pikir mereka mencoba mendorong kami untuk menggunakan direktori aktif Azure

Itu tidak akan pernah berhasil bagi mereka yang digunakan dengan perjanjian perusahaan yang membutuhkan layanan untuk tetap berada di rumah.

Saya telah bekerja untuk lembaga Pemerintah, baik Federal dan sekarang Kabupaten Lokal dan bagaimanapun Anda masih memerlukan beberapa antarmuka atau kemampuan untuk berintegrasi ke beberapa Layanan Direktori, baik berbasis cloud atau di lokasi. Saya telah mengembangkan aplikasi bersama yang mengelola miliaran dolar dan selalu muncul kebutuhan akan layanan direktori. Saya pikir ini lebih dari satu suara, melainkan pernyataan apa yang Anda tunggu? Saya setuju dengan posting sebelumnya bahwa ini awalnya merupakan solusi di luar kotak dalam rilis .NET sebelumnya. Saya mengerti bahwa struktur CORE yang lebih terbuka harus mendapatkan momentum komunitas dan jika ini yang dipilih Microsoft untuk ditunggu, mungkin mereka telah mengatakan ini dan saya melewatkannya, mereka harus mengatakannya sehingga seseorang mungkin mengambil inisiatif untuk menginvestasikan waktu untuk menyelesaikannya.

Ya, tambahkan System.DirectoryServices ke .NET Core!

Kami memiliki rencana untuk port System.DirectoryServices.Protocols dalam tahun depan. Pada titik ini saya tidak dapat memberikan tanggal yang lebih pasti. Kami belum memiliki rencana untuk mem-port System.DirectoryServices atau System.DirectoryServices.AccountManagement tetapi saya tertarik untuk mengukur minat. Apakah ada fitur dari ruang nama yang digunakan orang yang tidak dapat diselesaikan dengan Protokol?

@tquerec Saya tidak terbiasa dengan Protokol. Kami memiliki proyek untuk melakukan layanan mandiri Direktori Aktif untuk melakukan Buka Kunci Akun dan reset kata sandi Akun. Kami menggunakan UserPrincipal dalam proyek dan memanggil metode seperti FindByIdentity, UnlockAccount, SetPassword,, ExpirePasswordNow,.
Saya tidak yakin apakah ini dapat dilakukan pada Protokol tetapi sepertinya Protokol adalah implementasi tingkat yang lebih rendah versus Manajemen Akun adalah abstraksi yang lebih baik untuk bekerja dengan ActiveDirectory.
Terima kasih
Rockmeister

@nevcoBpalacio pasti harus lebih dari satu suara saya setuju. Saya pikir ini benar-benar perlu lebih diprioritaskan.

@CalebMacdonaldBlack akan sangat membantu jika Anda dapat menjawab pertanyaan @tquerec tentang pola penggunaan dan mengapa diperlukan. Lebih banyak upvotes atau "Saya setuju/ itu penting" tanpa skenario tidak akan membantu meningkatkan prioritas saat ini ... Terima kasih!

Penggunaan kami adalah memindai/mencari LDAP, melakukan BIND untuk memverifikasi kredensial, menambah/menghapus objek LDAP (pengguna, grup), memodifikasi keanggotaan dalam grup, dll.

@tquerec Saya sangat membutuhkan System.DirectoryServices.AccountManagement sehingga saya dapat mengotentikasi pengguna kami terhadap direktori aktif dan mengotorisasi mereka pada grup yang mereka akses.

pasti setuju dengan h3smith .. kami membutuhkan ini untuk v1 dan sebagai gantinya dipaksa untuk pergi ke jalur Novel , yang telah kami pijak bersama (terutama bit replikasi) dan menyebabkan kami sedih dengan biaya pemeliharaan dll. Ini membuat .NETCore terlihat buruk sebagai efek samping..

@liquidboy

kami membutuhkan ini untuk v1

Apakah yang Anda maksud: .NET Core v1 - yang dilakukan dan dikirim. Kami sedang mengerjakan 1.2 sekarang. Atau apakah Anda bermaksud sesuatu yang lain?

alih-alih dipaksa untuk menempuh jalur Novel

Apa artinya? (Maaf saya tidak memiliki konteks nol pada DirectoryServices, tetapi saya ingin memahami apa yang kami lewatkan dari sudut pandang skenario)

@karelz lakukan pencarian di utas ini untuk kata "novel" dan Anda akan melihat apa yang saya maksud. Pengembang lain (dsbenge) di tim saya berkomentar tentang (bersama dengan yang lain) tentang celah yang membuat kami menggunakan novel. [ini tautan ke komentar di atas https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

Dan ya maksud saya .NET Core v1 yang telah dikirimkan, kami telah mengerjakan solusi kami selama lebih dari setahun dan kami membutuhkan solusi DirectoryServices yang baik saat itu .. Kami menabrak tembok dan karenanya tidak punya pilihan selain menggunakan novel .

@liquidboy terima kasih atas tautannya -- jika dalam Mono, kami seharusnya dapat menggunakan kembali kode sumber di .NET Core AFAIK. @tquerec mengingat minatnya, apakah itu sesuatu yang akan dipertimbangkan oleh tim Anda?

@tquerec : Kami membutuhkan yang berikut ini:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory, dan System.DirectoryServices.Protocols.

Itu diperlukan untuk terhubung ke dan mengelola pengguna, grup, atribut Active Directory (dan server LDAP lainnya), seperti yang dijelaskan di atas juga. Penting untuk memiliki fitur ini di .Net Core!

Saya setuju dengan orang lain. Saya memerlukan ini untuk mem-port salah satu aplikasi kami yang diautentikasi terhadap ActiveDirectory ke .NET Core. Ini cukup mendasar, pasti harus dalam rilis secepat mungkin. Ini adalah penghalang untuk porting begitu banyak hal.

Halaman peta jalan .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) memiliki rencana ini untuk .NET Core 1.2: "membawa .NET Core ke paritas dengan .NET Framework dan Mono untuk koleksi besar tipe dasar."

Saya pikir port System.DirectoryServices sangat cocok dengan rencana itu, dan memang harus menjadi bagian dari rilis 1.2. Hanya 5 (euro) sen saya :)

Hanya untuk memperjelas: API yang di-porting di 1.2 dipilih berdasarkan data penggunaan (dan jarang rumit) - @weshaggard @danmosemsft dapatkah Anda memberi tahu detailnya, mengapa kami tidak menyertakan System.DirectoryServices?

Daftar rakitan yang kami pilih untuk dicocokkan ada di sini . @weshaggard harus mengingatkan saya bagaimana dia memilih daftar itu. (Mono memiliki S.DirectoryServices)

Saya yakin Anda akan dapat melakukan hampir semua yang diperlukan untuk berbicara dengan ActiveDirectory (dan server ldap lainnya) menggunakan System.DirectoryServices.Protocols, tetapi banyak orang harus menulis ulang kode mereka untuk menggunakan S.DS.Protocols.

Secara pribadi saya lebih suka MS untuk port S.DS.Protocols dan MS atau Komunitas untuk membuat perpustakaan yang mudah digunakan untuk manajemen pengguna/grup di atas ini.

Daftar rakitan yang kami pilih untuk dicocokkan ada di sini. @weshaggard harus mengingatkan saya bagaimana dia memilih daftar itu. (Mono memiliki S.DirectoryServices)

Penyemaian awal dilakukan dari persilangan profil Xamarin dengan .NET Framework. Profil Xamarain (yang merupakan bagian dari mono) tidak mendukung DirectoryServices, itulah sebabnya mengapa ini tidak ada di persimpangan.

Apa yang bisa kita lakukan untuk memperdebatkan hal ini? Ketidakmampuan untuk menggunakan skema otentikasi yang paling umum di aplikasi Microsoft sedikit menghalangi, bukan? Apakah fokus pada Azure di sini dan AAD saja? Atau apakah pemblokir yang mem-porting ini melintasi platform adalah protokol yang tidak diketahui yang lebih besar?

Apakah ada cara kita dapat meningkatkan prioritas di sini? 2.0 masih jauh, dan sangat disayangkan jika _semuanya_ berfungsi, tetapi kami tidak dapat mengautentikasi pengguna. Ini adalah pintu depan virtual untuk begitu banyak aplikasi. IMO, dalam hal prioritas itu sedikit berbeda karena itu bukan pemblokir sebagian, tetapi sering pemblokiran penuh secara alami.

Saya tidak berpikir ada perbedaan pendapat bahwa kami ingin mendukung ini di .NET Core, yang berbeda dengan menjadi bagian dari .NET Standard, hanya masalah kapan. @tquerec memiliki area tersebut dan akan menjadi orang yang berbicara tentang itu.

Seseorang dari .NET Foundation bertanya, tetapi ruang nama yang kami gunakan secara khusus adalah:
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

Jadi, @tquerec , bagaimana kita membuat System.DirectoryServices ditandai untuk .NET Core 1.2? Setidaknya System.DirectoryServices.Protocols. Apakah itu mungkin?

Terima kasih banyak!

[diperbarui dengan info lebih lanjut dari @tquerec]
Saya bertemu dengan @tquerec pada hari Senin. Saya berutang surat kepada semua orang. Singkatnya:

• Sistem. DirectoryServices dapat dilakukan hanya pada Windows (memanggil ke Windows DLL di mana semua implementasinya hidup), sama sekali tidak dikenal untuk Linux/Mac
• Sistem.Layanan Direktori. AccountManagement berada di atasnya, jadi juga hanya dapat dilakukan untuk Windows, dan tidak dikenal untuk Linux/Mac
• Sistem.Layanan Direktori. ActiveDirectory dapat dilakukan hanya pada Windows (memanggil ke banyak API khusus Windows)
• Sistem.Layanan Direktori. Protokol harus cukup sederhana untuk Windows dan lebih berfungsi untuk Linux (kita perlu menemukan perpustakaan LDAP untuk digunakan).
  Kami mencoba mencari tahu dengan @tquerec cara mendanai pekerjaan - idealnya untuk 1.2, tetapi belum ada janji. Saya berharap keputusan akan memakan waktu setidaknya beberapa minggu.

Pertanyaan untuk semua orang :

• Apakah pelingkupan khusus Windows di atas dapat diterima untuk kasus penggunaan utama? (Sys.DirSer dan Sys.DirSer.AccountManagement dan Sys.DirSer.ActiveDirectory)
• Jika Sys.DirSer.Protocols Linux hadir setelah 1.2 atau bergantung pada kontribusi komunitas, apakah itu akan menjadi pemblokir utama?

@karelz System.DirectoryServices.ActiveDirectory didasarkan pada sejumlah besar API khusus Windows sehingga masuk ke dalam wadah yang sama dengan S.DS dan S.DS.AM.

@karelz Saya tidak yakin apa yang Anda maksud dengan solusi hanya windows untuk 1.2. Kami sudah memiliki solusi hanya windows yang berfungsi.

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

@rock-meister maksud saya .NET Core. Yang Anda sebutkan menargetkan "penuh" .NET 4.5.2+.

Ya, dukungan khusus Windows adalah pemblokiran besar bagi kami. Kami dapat melakukan semua pekerjaan untuk porting .NET Core dan memperluas dukungan platform "gratis" nanti, ketika bit yang mendasarinya melakukannya. Benar bukan pemblokir bahkan _starting_ ke port sangat besar. Bahwa pergi adalah kemenangan besar.

Menjadi toko Windows, ini juga akan menjadi kemenangan besar di sini. Begitu banyak perusahaan besar akan menganggap ini sebagai kemenangan besar! Terima kasih untuk tetap up to date dengan informasi Anda. Jaga agar kami tetap diposting. Terima kasih.

@karelz Terima kasih atas klarifikasinya. Ya, pelingkupan khusus Windows untuk 1.2 bekerja untuk kami.
Rockmeister

System.DirectoryServices.Protocol dengan dukungan Linux /LDAP adalah prioritas tertinggi untuk pekerjaan yang kami lakukan..

ps pelingkupan hanya windows tampaknya bertentangan dengan tujuan .netcore / .netstandard

Kami beralih dari menggunakan System.DirectoryServices menjadi menggunakan System.DirectoryServices.Protocols beberapa waktu lalu sehingga kami dapat mendukung server LDAP non-AD. Memiliki akses ke ruang nama Protokol akan menjadi satu langkah lebih dekat untuk memungkinkan kita mem-porting kode kita ke inti .NET.

Namun, jika ini akan menjadi spesifik platform maka ada sedikit gunanya bagi kami. Salah satu poin utama keinginan untuk pindah ke .NET core adalah portabilitas platform. Kami mungkin masih harus menunggu untuk itu.

Bagi kami, masuk ke .NET Core adalah kemampuan untuk memanfaatkan Docker dan sepenuhnya menjadi platform agnostik. Jadi terjebak dengan dukungan LDAP Windows saja tidak akan bermanfaat.

Terima kasih telah berdiskusi secara internal.

Suara saya pergi dengan rute independen platform

Saya harus setuju dengan komentar agnostik platform, meskipun menyakitkan karena saya tidak dapat menggunakan inti sampai ini tercapai. Saya pikir ini adalah sesuatu yang harus ditinjau di tingkat yang lebih tinggi. Hal yang tidak saya mengerti adalah kerumitan konsepnya? Ada beberapa solusi direktori, AD, Novell, dll... Ini membutuhkan solusi antarmuka lintas platform (agnostik)... Selamat Berlibur!

Sementara secara pribadi saya bisa hidup baik-baik saja dengan lingkup hanya windows, menurut pendapat saya ini mematahkan gagasan .NET Core dan portabilitasnya.
Solusi independen platform harus menjadi rute untuk fokus.

Ya, setuju, .NET Core harus lintas platform dan fitur/API harus bekerja di semua platform yang didukung!
Jadi jika System.DirectoryServices.Protocols akan di-porting/diimplementasikan terlebih dahulu, itu harus bekerja juga di Linux.

Saya setuju bahwa idealnya solusi platform independen harus menjadi tujuannya. Meskipun masih belum memilikinya di Windows, ini adalah pemblokiran bagi banyak pengembang yang hanya ingin bereksperimen dengan platform di Lingkungan korporat (AD), seperti saya. Itu sebabnya saya akan menyambut solusi Windows saja untuk saat ini.

Saya hanya ingin berpadu dan mengatakan bahwa saya baik-baik saja dengan solusi khusus Windows sampai sesuatu lintas platform dapat disatukan.

Saya akan membayangkan bahwa 99,9% pengembang yang perlu terhubung ke Active Directory melakukannya di lingkungan perusahaan tempat mereka mengembangkan kotak Windows.

Kami sedang mendiskusikan pendanaan di pihak kami (mengharapkan pembaruan dalam ~2 minggu), saat ini merupakan prioritas utama dari API yang belum menjadi bagian dari .NET Standard 2.0.

Apakah ada orang-orang di sekitar yang bersedia membantu/berkontribusi dengan implementasi Windows dan/atau implementasi Linux? (kita bisa memasukkan kode dari Desktop dan itu akan membutuhkan pemijatan lebih lanjut untuk membangun + beberapa pengujian)

@karelz Saya ingin berkontribusi untuk sisi Linux. Kami membutuhkan dukungan ini untuk Otentikasi Windows dan non-Windows (on-prem). Ini adalah pemblokir bagi kami, dan kami menargetkan inti .NET untuk proyek lintas platform kami (sebelumnya Mono di sisi Linux dan .NET di sisi Windows).

Ingin membantu di mana kita bisa, tanpa ragu.

Saya ingin membantu tetapi saya yakin kalian jauh lebih berpengalaman daripada saya dan saya tidak akan berguna.

@karelz @tquerec Saya akan dengan senang hati membantu pengujian di Windows dan, di masa mendatang, Linux. Saya berlangganan utas, jadi balas saja di sini atau sebutkan saya untuk menghubungi saat Anda membutuhkan saya untuk terlibat. Terima kasih atas pekerjaan Anda dalam hal ini. Sudah lama ditunggu dan, bahkan jika bertahap, ini akan menjadi langkah yang baik untuk adopsi lebih lanjut dari .NET Core.

Saya pikir "Windows yang diperluas" adalah target yang baik pada awalnya, "diperpanjang" artinya ia bekerja di NanoServer dan di Wadah (yaitu mesin yang tidak bergabung dengan domain yang tidak dapat menjalankan .NET CLR penuh). Ini akan memberi Anda kemenangan cepat, dan titik awal untuk bekerja mundur untuk mengimplementasikannya di server lain.

Kami bekerja dengan @tquerec dan rantai manajemen kami untuk menemukan cara terbaik untuk membuka blokir pekerjaan ini secepatnya. Sayangnya kami tidak memiliki siapa pun yang gratis sebelum akhir Januari, jadi kami akan mencoba melakukan yang terbaik sementara itu untuk membuka blokir kontribusi komunitas dengan sumber daya yang terbatas dan beberapa pekerjaan sukarela dari pihak kami ( @ianhays @tquerec dan @karelz).

Inilah yang kami rencanakan untuk dilakukan:
@ianhays akan membantu kami memulai proyek di repo CoreFX (menambahkan beberapa kode sumber, menunjukkan contoh bagaimana melakukannya, menyarankan dengan menyiapkan build, mengemas, menyiapkan proyek untuk port Linux/Mac mendatang, dll.).
Kami akan mulai dengan implementasi khusus Windows (kontribusi dipersilakan). Kami tidak akan mengambil perubahan fungsional apa pun pada implementasi atau permukaan API pada saat ini kecuali jika diperlukan untuk port ke .NET Core.
Langkah berikutnya (berpotensi paralel) adalah menambahkan tes. Kita harus memulai diskusi dengan @tquerec tentang desain pengujian yang ada (sumber tertutup .NET Framework) jika ada sesuatu yang dapat kita manfaatkan, atau jika kita harus memulai dari awal.
Nantinya, kita bisa fokus pada port Linux/Mac.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte, dan siapa pun yang tertarik, kami akan dengan senang hati menerima kontribusi Anda begitu @ianhays memulai upaya (ETA: pertengahan minggu depan saya kira). Jika Anda memiliki pertanyaan, atau saran, beri tahu kami.

Apakah pekerjaan ini juga memungkinkan perpustakaan seperti SqlClient untuk melakukan Otentikasi Windows saat berjalan di Linux tetapi terhubung ke SQL Server yang memerlukan Otentikasi Windows?

Itu adalah salah satu penghalang saya untuk dapat mem-porting sesuatu ke .NET Core yang berjalan di Linux. Semua server Microsoft SQL perusahaan kami hanya mengizinkan koneksi melalui ID Layanan (non-interaktif) yang ada di AD.

blgboy. Masalah Anda adalah contoh utama mengapa hal-hal perlu "diperiksa" untuk memastikan kompatibilitas lintas platform yang sebenarnya dengan model baru yang disarankan. Jika Anda memiliki lebih banyak skenario, saya pikir lingkungan Anda adalah contoh yang baik tentang bagaimana hal-hal perlu dilintasi dan Anda harus membuat daftar masalah lain yang Anda alami dengan bagian AD dari Core.

Ya, saya pasti akan mengingat utas ini dan membagikan apa pun yang saya temukan. Hanya ingin memberi tahu semua orang bahwa ini adalah penghenti acara yang cukup besar untuk Perusahaan dengan pertanian SQL yang memiliki keamanan ketat seperti yang dijelaskan.

Ini juga merupakan penghenti acara untuk menggunakan sesuatu seperti EF Core yang pada akhirnya akan memiliki masalah yang sama.

System.DirectoryServices sekarang digabungkan ke CoreFX. Langkah selanjutnya adalah membangunnya untuk .NET Core - Windows dan menambahkan tes.

Terima kasih Ian. Adalah baik untuk melihat beberapa daya tarik pada masalah ini!

Terima kasih Ian!

Rencana eksekusi yang diperbarui: EDIT: Dipindahkan ke pos teratas dalam edisi ini agar lebih mudah ditemukan

Jika ada yang mengerjakan langkah apa pun, harap sebutkan & koordinasikan di sini untuk menghindari upaya duplikat. Saya juga akan menugaskan masalah ini kepada Anda.

Ruang nama System.DirectoryServices berisi fungsionalitas penting seperti itu untuk aplikasi Windows perusahaan lokal, sangat bagus untuk melihat beberapa kemajuan dalam masalah ini. Pertahankan pekerjaan yang baik.

Saya telah memperbaiki sumber dan System.DirectoryServices sekarang sedang membangun. Saya harus segera mengirimkan PR.

Terima kasih @tquerec telah berkontribusi pada putaran kedua!
Apakah ada sukarelawan untuk membantu dengan 2 ruang nama atau tes yang tersisa? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 memiliki PR di sini https://github.com/dotnet/corefx/pull/15324 untuk menambahkan dukungan lebih lanjut dan mendapatkan pembuatan Protokol/AccountManagement.

Untuk apa nilainya, saya telah bereksperimen dengan System.DirectoryServices.Protocols baru-baru ini dan menemukan bahwa banyak skenario System.DirectoryServices sederhana tidak sulit untuk ditiru dengan System.DirecotryServices.Protocols. Berdasarkan itu, saya pikir membuat S.DS dan S.DS.AM bekerja lintas platform dapat menjadi prioritas yang lebih rendah karena System.DirectoryServices.Protocols lintas platform dapat menjadi solusi yang dapat digunakan untuk banyak pengguna.

Tentu saja, itu berarti membuat System.DirectoryServices.Protocols berfungsi sebagai solusi LDAP lintas platform tetap menjadi prioritas utama.

Apakah saya membaca permintaan tarik dengan benar? Sepertinya ini diterima beberapa hari yang lalu jadi jika kita membangun dari sumber kita harus bisa mencobanya?

Ya, saya pikir kami memiliki semua bangunan DirectoryServices, namun kami tidak memiliki tes apa pun - yang mencegah kami mengirimkan paket sebagai stabil dan dari peningkatan basis kode (perbaikan bug, peningkatan, dll.).
Jika Anda dapat mencobanya di build dari sumber, itu akan sangat bagus. Jika Anda (atau siapa pun) ingin membantu kami menambahkan tes, atau memulai port Linux, itu akan lebih baik :)

Halo semuanya,

Kami bersiap untuk memulai proyek perusahaan yang memerlukan dukungan Active Directory karena kami 100% internal ke domain kami. Bisakah seseorang memberikan status untuk masalah ini dan harapan untuk rilis inti berikutnya? Saya minta maaf, tetapi saya baru mengenal komunitas GitHub dan belum memahami semua istilah dan informasi status yang berbeda.

Akan lebih baik menggunakan Active Directory untuk keanggotaan daripada model identitas yang sepenuhnya terpisah yang harus dikelola secara terpisah dan hanya menyebabkan ketidakcocokan data juga.

Terima kasih sebelumnya!

@karelz untuk pertanyaan itu, tapi saya pikir jawabannya adalah saat ini tidak diharapkan dalam rilis 2.0, karena kami tidak memiliki pengembang yang dijadwalkan untuk itu. Kontribusi komunitas dipersilakan. itu tidak perlu mengirimkan _in_ rilis 2.0, itu bisa keluar di NuGet kapan saja itu siap dikirim.

Sempurna! Anda menjawab pertanyaan saya.

Terima kasih.

@nevcoBpalacio ada minat untuk mencoba kontribusi?

Saya memiliki minat, terutama dengan topik ini karena saya tahu topik ini menahan banyak orang untuk beralih ke solusi perusahaan inti. Namun, kami memiliki pekerjaan di sekitar dan sepertinya saya tidak dapat menemukan waktu di siang hari (malam dengan anak-anak) untuk itu. Saya akan mencoba untuk memperlengkapi kembali sistem saya di rumah untuk bekerja dengan GitHub. Saya menghargai Anda bertanya! Terima kasih.

Nevcobpalacio, jika Anda menggunakan vs17 dan tidak memerlukan lintas plat, Anda bisa mendapatkan sedikit lebih dekat dengan apa yang Anda inginkan dengan menggunakan templat aplikasi web inti yang menargetkan kerangka .net lengkap dan merujuk ke system.directoryservices.accountmanagement dll dengan cara lama dan gulung middleware Anda sendiri untuk melakukannya sementara itu. Dari apa yang saya lihat kode yang sama harus dibawa ke penargetan .net core setelah ini tersedia kecuali Anda akan menggunakan paket nuget dan menjatuhkan referensi. Semoga info ini membantu proyek Anda berjalan sesuai rencana.

@los93sol terima kasih atas sarannya. Diskusi awal kami adalah untuk membangunnya mirip dengan saran itu dan menjadikannya modul perangkat tengah yang dapat kami "potong" ke tanah apa pun di Nuget nanti. Terima kasih banyak!

Saya harus berkomentar dan memuji Anda atas saran ini. Awalnya saya skeptis tentang perubahan ke inti ini. Namun, dengan pendekatan komunitas ini, diskusi seperti ini terungkap dan membantu kita semua menyelesaikan masalah selama perubahan besar ini.

Terima kasih.

Adakah yang sedang mengerjakan penambahan tes yang hilang, atau porting System.DirectoryServices.Protocols ke Linux/Mac ?

@pasikarkkainen AFAIK tidak ada upaya aktif saat ini dari tim Microsoft (yang mungkin, atau mungkin tidak berubah dalam waktu dekat). Saya juga belum melihat ada orang dari komunitas yang mulai mengerjakannya.
Apakah Anda tertarik untuk berkontribusi, atau hanya ingin tahu statusnya?

@karelz Sepertinya mereka menargetkan DirectoryServices untuk rilis .NET Core 2.0 musim panas ini.

Kutipan dari @shanselman

AD – Benar-benar, ini adalah celah JIKA Anda ingin memanggil LDAP secara langsung. Anda pasti dapat mengautentikasi terhadap Windows Auth SEKARANG. Kami berencana untuk secara khusus memiliki namespace DirectoryServices untuk Core 2.0 sekitar jangka waktu musim panas

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

Yap, itu sejalan dengan diskusi lorong yang pernah saya dengar. Saya hanya tidak yakin apakah itu info publik dan seberapa banyak (dan siapa) yang berkomitmen untuk itu. Saya pikir aman untuk mengatakan, itu sedang dalam pertimbangan yang sangat kuat dan kemungkinan akan terjadi. Saya membiarkan pemilik @shanselman & DirectoryServices mengomentari timeline.

@karelz : Terima kasih atas pembaruannya! Saya sangat ingin tahu tentang statusnya.. Saya pasti dapat membantu dengan pengujian setidaknya, ketika ini tersedia.

@pasikarkkainen jika Anda juga bersedia membantu menulis beberapa kasus uji, itu akan sangat dihargai.
Jika Anda "hanya" ingin menguji paket pada aplikasi/kode Anda, itu seharusnya bisa dilakukan hari ini. Kami hanya perlu mulai menerbitkan paket sebagai pratinjau di myget (saya pikir penerbitan dinonaktifkan hari ini).

@karelz Saya tidak keberatan membantu implementasi Mac secara khusus. Saya memiliki sedikit pengetahuan, jadi saya tidak yakin seberapa baik saya dapat berkontribusi. Saya telah melakukan penelitian di sekitarnya dan ada perpustakaan baru yang sepertinya disarankan orang. Menemukan implementasi orang lain di sekitar perpustakaan novel itu di sini: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt Penulis paket sudah menyebutkannya di sini.
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

Jadi apakah ini sesuatu yang akan ada di core 2.0? Saya agak bingung dengan statusnya.

Tidak, itu tidak akan menjadi bagian dari .NET Core 2.0, namun, pada konferensi Build kami menjanjikan ketersediaan paket selama Musim Panas. Paket (Windows) harus tersedia di atas .NET Core 2.0, sekitar waktu .NET Core 2.0 dikirimkan.
Saat ini kami sedang berupaya membuat paket tersedia sebagai pratinjau di cabang master (#18090) dan mengerjakan aset uji secara paralel (#20669).

Apakah kita akan mendapatkan kesalahan kompilasi ketika kita menargetkan runtime bersama atau runtime non-Windows? Atau akankah kita berakhir dengan PlatformNotSupported -trap?

Ini akan menjadi paket mandiri tanpa aset non-Windows. Kompilasi harus pecah. @ericstj dapat mengkonfirmasi.

Anda tidak akan mendapatkan kesalahan kompilasi, itu akan menjadi pengecualian runtime "PlatformNotSupported".

Ya, ini yang lama - apakah kita memblokir orang yang menggunakannya dari perpustakaan .NET Standard, atau apakah kita mengubah kesalahan waktu kompilasi menjadi pengecualian PlatformNotSupported? ... Untungnya ada jalan tengah: Alat ApiCompat akan memberi tahu Anda sebelumnya bahwa Anda menggunakan sesuatu yang tidak ada di mana-mana.

Saya mendapatkan kesalahan berikut ketika saya mencoba paket System.DirectoryServices di proyek netstandard 1.6:

Install-Package : Package System.DirectoryServices 4.0.0 tidak kompatibel dengan netstandard1.6 (.NETStandard,Version=v1.6). Package System.DirectoryServices 4.0.0 mendukung: net (.NETFramework,Version=v0.0)

Apakah ada solusi atau solusi untuk ini?
Salam,
Varun

@vrn11 paket ini dari vendor lain dan hanya mendukung kerangka kerja bersih penuh

Lagi pula ingin bertanya apakah ada pembaruan tentang ini. Mungkin paket preview yang bisa kita ambil dari myget? Akan luar biasa untuk menguji ini

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

Seperti yang disebutkan @MarcusKohnert, Anda dapat mengambilnya dari https://dotnet.myget.org/F/dotnet-core/api/v3/index.json . Ada System.DirectoryServices, System.DirectoryServices.AccountManagement, dan System.DirectoryServices.Protocols.

Luar biasa! terima kasih kepada @MarcusKohnert dan @ericstj untuk tautannya!

Saya mencoba paket dari myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
Saat berjalan di MacOS 10.12.6, dan saat menjalankan:

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

Saya mendapatkan:

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

Apakah PrincipalContext diharapkan berfungsi di Mac?

@bruno-garcia tidak ada implementasi di CoreFX sekarang untuk DirectoryServices kecuali pada Windows. @karelz harus berbicara dengan rencana/aspirasi jika ada.

Hanya System.DirectoryServices.Protocol yang berpotensi dapat dilakukan x-plat (belum diterapkan) - lihat detail di beberapa jawaban saya di atas dan di posting teratas.

Membuat System.DirectoryServices.Protocols bekerja lintas platform (juga di Linux/Mac) adalah penting .. apakah saya mengerti dengan benar masalah utama saat ini adalah bahwa perpustakaan LDAP yang digunakan oleh System.DirectoryServices (di Windows) bukan opensource, dan dengan demikian hanya bekerja di Windows?

Jika saya telah memahaminya dengan benar, System.DirectoryServices akan sulit untuk membuat xplat karena banyak ketergantungan pada Antarmuka COM ADSI, yang hanya tersedia di windows.

System.DirectoryServices.Protocols seharusnya masih memungkinkan untuk menjalankan xplat.

Menjalankan kode yang sama yang saya sebutkan sebelumnya:
```c#
menggunakan (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

Pada Win7 x64 dengan .NET Core 2.0 menghasilkan:

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)

Paket yang digunakan:

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

[EDIT] Memperbaiki panggilan sintaks & sintaks kode xml/C# oleh @karelz

@bruno-garcia tolong ajukan masalah terpisah. Yang ini melacak keseluruhan upaya port, bukan bug/perbedaan tertentu. Terima kasih!

@bruno-garcia yang dilacak oleh https://github.com/dotnet/corefx/issues/23605

Langkah selanjutnya mungkin untuk men-debug melalui desktop dan melihat di mana perilaku menyimpang. Saya akan mencoba membebaskan dev untuk melihatnya.

Masalah yang sama di server 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)

Bagaimana menurut Anda, kapan itu akan berhasil?

memiliki masalah saat mencoba menginstal paket

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

=================================================
Jika ada yang memiliki masalah yang sama dengan saya, gunakan .NET CLI sebagai gantinya

dotnet tambahkan paket System.DirectoryServices --version 4.5.0-preview2-25707-02 --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

@papamamadoii itu karena Anda kehilangan https://dotnet.myget.org/F/dotnet-core/api/v3/index.json sebagai sumber dan ternyata Install-Package tidak menggunakan umpan yang Anda tentukan untuk menemukan dependensi. Anda mungkin ingin mengajukan bug di http://github.com/nuget/home dengan langkah-langkah repro tertentu.

@karelz Jika saya memahami komentar dengan benar, ini tidak berfungsi pada penyebaran berbasis Linux?

@euclid47 System.DirectoryServices.* saat ini tidak didukung di Linux. Seperti yang telah dibahas di atas, bagian-bagiannya berpotensi untuk diangkut karena minat/partisipasi masyarakat yang cukup.

@danmosemsft Saya tidak mengerti bagaimana Anda tidak dapat melihat seluruh utas ini dibuka sejak Oktober 2015 sebagai minat komunitas yang memadai. Jika saya memiliki keahlian yang diperlukan untuk menulis sesuatu yang rumit seperti lapisan komunikasi LDAP, saya pasti sudah mengerjakannya, karena AD adalah salah satu mekanisme otentikasi inti di lingkungan perusahaan. Saya akan menunjukkan bahwa untuk sebagian besar perusahaan besar, ketidakmampuan untuk melakukan interaksi semacam ini di Linux secara harfiah mengalahkan tujuan Core dan akan menyebabkan mereka tetap berpegang pada build dotnet pra-inti, sehingga membatasi interaksi komunitas Anda yang berharga.

@danmosemsft Juga, jika Anda benar-benar tidak berencana untuk mengerjakan ini, beri tahu komunitas secara definitif sehingga pengembang lain dapat mengambil bagiannya.

@shairozan sejauh ini kami telah mencatat 7 suara dari 54 yang menganggap Layanan Direktori di Linux sebagai prioritas yang lebih tinggi daripada Windows -- lihat https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
Ada juga keuntungan lain yang didapat pengembang dari .NET Core daripada hanya x-platform (walaupun saya setuju bahwa x-plat adalah salah satu alasan utama).

Saya akan merekomendasikan untuk menyelesaikan rilis paket Windows-only terlebih dahulu, kemudian kita dapat membuka edisi baru untuk melacak minat untuk port Linux dengan lebih tepat.

Kami telah memberi tahu komunitas bahwa kami sedang mencari bantuan dan masalah ini ditandai untuk diambil -- lihat https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. Dan @hughbe membantu dengan tes putaran pertama untuk DirectoryServices - lihat sejarah di sini , di sini dan di sini .

@karelz Di mana pemungutan suara dikelola untuk komponen ini? Saya jamin setelah SELF / POSSCON Anda akan melihat peningkatan minat yang cukup drastis.

@karelz Dimana voting untuk fitur ini? Saya sangat setuju dengan @shairozan dengan kebutuhan. Ada komentar dalam edisi ini yang menjelaskan lingkungan pengembangan dan produksi kami. Cukup mengejutkan tidak ada gerakan dalam implementasinya sejak penginjil .Net Core memberitakannya adalah platform agnostik.

Saya membuat masalah baru untuk melacak port Linux/Mac dotnet/corefx#24843 untuk pemungutan suara yang lebih mudah daripada pada komentar di tengah masalah ini (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

Saya menambahkan tautan juga ke posting teratas masalah ini.

@euclid47 pemungutan suara sejauh ini dalam masalah ini - lihat tautan di atas. Itulah yang menghasilkan 7 suara (+1 untuk pengirim edisi asli).

Tim kami membutuhkan dukungan LDAP di Linux.
Karena sebagian besar klien kami menggunakan auth melalui LDAP.

@balkarov Jika Anda bisa, berikan suara positif pada masalah yang baru saja dibuat @karelz ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 Jika Anda belum mengetahuinya, ada paket Novell.Directory.Ldap.NETStandard Nuget yang dapat Anda gunakan untuk mengintegrasikan LDAP ke dalam proyek Anda. Kami bukan pengguna LDAP tingkat lanjut, kami hanya menggunakannya untuk memvalidasi kredensial dan mendapatkan informasi pengguna, tetapi ini berfungsi dengan baik untuk kami, baik pada 1.0 maupun 2.0 yang berjalan pada image dotnet runtime core dotnet. Ini bukan cara resmi tetapi menyelesaikan pekerjaan sampai ada port lintas platform System.DirectoryServices .

@OskarKlintrot terima kasih. Namun library ini tidak mendukung login tanpa domain.
Saya membuat masalah https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
Bisakah Anda membantu saya menyelesaikan masalah ini?

Saya bukan bagian dari proyek itu atau pengguna tingkat lanjut, tetapi saya akan melihatnya, sampai jumpa di sana!

(Kami tidak login dengan domain)

Mengingat @karelz memecahkan masalah untuk Unix, saya memberi judul ulang yang ini untuk kejelasan.

@danmosemsft tetapi masalah memiliki rencana
Port Linux/Mac.

@balkarov Saya telah memperbarui rencana untuk menautkan ke masalah pelacakan lain dan menghapus kotak centang untuk item yang dilacak secara terpisah (rusak bekerja) atau tidak memblokir pekerjaan Windows.

Apakah port System.DS akan kompatibel dengan server RODC (Read-Only Domain Controllers)?

@PKGeorgiev Anda harus mendapatkan dukungan System.DirectoryServices yang sama dengan yang kami miliki dalam kerangka kerja penuh.

Pekerjaan pada DirectoryServices untuk Windows selesai, menutup masalah.
Catatan:

• Penerbitan paket akhir dilacak oleh dotnet/corefx#24909
• Port Linux/Mac dilacak secara terpisah oleh dotnet/corefx#24843

Hai, apakah ini akan berfungsi di UWP?

Hai, apakah ini akan berfungsi di UWP?

Tidak, ini hanya didukung untuk aplikasi inti bersih yang berjalan di Windows dan kerangka kerja penuh. jika Anda menggunakannya di UWP atau di Linux, Anda akan mendapatkan pengecualian PlatformNotSupported.

Saya menggunakan kode ini dalam fungsi lambda di AWS yang berjalan di Linux di latar belakang dan saya mendapatkan kesalahan ini. "System.DirectoryServices.AccountManagement tidak didukung pada platform ini."
Saya menggunakan inti 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 Ya, ini belum didukung di Linux. Ini hanya didukung di Windows.

@sscoleman ada masalah yang dibuat di atasnya, https://github.com/dotnet/corefx/issues/24843. Dikatakan tidak ada cukup minat masyarakat di dalamnya kecuali pertanyaan ini muncul sepanjang waktu. Jadi sekarang Anda berada di tempat sampah. Anda menghabiskan waktu mengimplementasikan layanan direktori dan kemudian mengetahui bahwa Linux didukung. Sekarang Anda bertanya pada diri sendiri mengapa ini disebut-sebut sebagai platform agnostik jika hanya ada fitur Windows.

Ini cukup jelas jika Anda melihat strategi Microsoft yang lebih besar. Microsoft membuang SEMUA sumber daya pengembangan mereka ke Azure, dan itu termasuk Active Directory. Lihat "Yang baru di 2016", sebagian besar adalah investasi AzureAD/Hybrid. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft tidak berinvestasi di perpustakaan ini untuk Linux karena mereka ingin semua orang pindah ke Azure AD sebagai gantinya. Masuk akal, mengapa Anda berinvestasi dalam sesuatu yang Anda coba untuk membuat pelanggan menjauh?

Anda melakukan sesuatu yang relatif sederhana. Anda dapat menggunakan perpustakaan Novel LDAP, mereka bekerja dengan AD dan di .NET Core untuk Linux. Anda perlu melakukan protokol sendiri, tetapi tidak terlalu rumit, dan ada banyak sampel di luar sana. Kelemahannya adalah Anda perlu mengelola pengikatan sendiri, yang memerlukan DN pengguna dan kata sandi.

System.DirectoryServices saat ini merupakan API khusus Windows dan merupakan bagian dari Paket Kompatibilitas Windows untuk .NET Core . Pada prinsipnya, kami dapat membuat bagian dari System.DirectoryServices berfungsi di Linux tetapi kami belum memiliki sumber daya untuk melakukannya. dotnet/corefx#24843 melacak item pekerjaan ini.

Mengapa kami mengizinkan untuk menginstal paket yang tidak berfungsi di Linux? Alternatifnya adalah dengan memotong permukaan API tetapi itu juga tidak berfungsi dengan baik untuk semua kasus dan membuat sistem keseluruhan lebih sulit untuk dikodekan. Tentu saja, pilihan kami juga bukan tanpa masalah, karena dapat mempersulit untuk memprediksi apakah kode akan bekerja lintas platform atau. Kami memiliki pratinjau penganalisis kompatibilitas yang memberi Anda umpan balik langsung saat Anda membuat kode.

Lihat video ini untuk konteks lebih lanjut tentang bagaimana kami melihat Paket Kompatibilitas Windows dan penganalisis lintas platform bekerja bersama-sama:

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

@thedevopsmachine

Microsoft tidak berinvestasi di perpustakaan ini untuk Linux karena mereka ingin semua orang pindah ke Azure AD sebagai gantinya.

Bukan seperti itu yang saya lihat. Seperti yang Anda tunjukkan, kami bermaksud menghasilkan uang melalui Azure. Dan Azure adalah platform cloud yang menawarkan berbagai macam teknologi dan sistem operasi. Kami tidak memiliki kepentingan bisnis untuk mempromosikan Windows di cloud melalui Linux di cloud. Tapi tentu saja, .NET telah hadir di Windows selama 15 tahun. Membuat semuanya berfungsi penuh di semua sistem operasi membutuhkan waktu, tapi sejujurnya saya pikir kebanyakan orang yang mengikuti upaya open source kami dapat melihat bahwa kami tidak sengaja melumpuhkan Linux. Ini hanya membutuhkan waktu.

saya setuju dengan pendekatan dengan memiliki api x-plat dan x-framework yang konsisten, tetapi itu menghancurkan jiwa setiap kali saya menemukan kesalahan yang ditakuti itu .. saya merasa untuk @sscoleman ...

Bisakah paket DirectoryServices ini bekerja pada CentOS 7?

Bisakah paket DirectoryServices ini bekerja pada CentOS 7?

Paket dapat diinstal tetapi tidak akan berfungsi. saat menggunakannya, Anda akan mendapatkan pengecualian platform yang tidak didukung. kami sedang mencari bagaimana kami dapat mendukung layanan direktori secara umum di Linux. ini ada di radar kami.

Ini sangat membutuhkan dukungan linux

CC @joperezr

@niemyjski lihat dotnet/corefx#24843

Ini sangat membutuhkan dukungan linux

.. plus dapat dijalankan dalam wadah buruh pelabuhan. Imho itu menyebalkan bahwa seseorang harus kembali ke implementasi direktori Novell lama ketika seseorang ingin menggunakan .NET Core 2+ di linux.
Terima kasih pula untuk bekerja di atasnya!

Mengapa menutup masalah ini? System.DirectoryServices.AccountManagement masih belum ada di .NET Core di luar Windows:

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

buka kembali 14734

@tarekgh masih di radar?

buka kembali 14734

@JustinGrote apa fungsi sebenarnya yang Anda inginkan untuk skenario? DirectoryServices sangat besar dan saya ragu seluruh fungsionalitas dapat didukung hanya dalam satu rilis. Memiliki permintaan khusus dapat membantu lebih baik daripada hanya meminta seluruh pustaka DS untuk didukung. Di .NET 5.0 kami telah mengaktifkan skenario https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
Saya tidak menyadari System.DirectoryServices.Protocols telah di-porting tetapi sepertinya masih memiliki ketergantungan pada security.principal.windows, apakah itu berfungsi di linux bahkan dengan itu (melalui auth dasar dll.) atau akankah hilang kesalahan perakitan?

Tujuannya adalah untuk mengimplementasikan kembali sesuatu seperti modul ActiveDirectory Powershell menjadi xplat, saya sedang mempertimbangkan modul novell ldap atau ldap4net untuk tujuan itu jika tidak ada setidaknya dukungan interaksi dasar yang tersedia.

Menerapkan ActiveDirectory Powershell kemungkinan merupakan kasus penggunaan yang sangat besar. Izinkan saya membagikan dua kasus penggunaan saya:

1) Saya berasal dari UserPrincipal karena saya membutuhkan atribut yang tidak didukung di luar kotak. Saya mengikuti https://stackoverflow.com/questions/24798037/extend-userprincipal-class dan saya kira ini adalah semacam standar dalam kerangka .NET lama, dan membuat pendekatan itu berfungsi mungkin akan membantu lebih banyak pengembang.

2) Saya juga memiliki kode seperti berikut:

`

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

`

Tidak tahu apa yang sudah didukung hari ini, terakhir kali saya memeriksa adalah pada bulan Februari.
Terima kasih, Joachim

@ jol64 tidak bisakah Anda mencapai hal yang sama menggunakan Protokol?

@ jol64 tidak bisakah Anda mencapai hal yang sama menggunakan Protokol?

Mungkin saya bisa. Saya menulis ulang beberapa hal untuk menggunakan perpustakaan Novell. Tapi itu membutuhkan penulisan ulang dan dengan demikian kode yang berlebihan ke kode kerangka .NET saya yang sudah ada. Saya pasti lebih suka menghindari pemecahan kode dari semua kode, dan saya yakin orang lain juga tidak menyukai ide itu.
Saya juga bertanya-tanya bagaimana cara kerja otentikasi. Dengan Novell (versi lama yang saya coba) saya harus menentukan kredensial, sedangkan dengan kode saya yang sudah ada, saya tidak perlu melakukannya.
Terima kasih, Joachim