@вибронет

Есть ли какие-либо обновления по этому поводу?

Я тоже хотел бы получить обновление по этому поводу. Моя компания заставляет меня создать новое приложение, для которого требуется возможность запрашивать Active Directory через LDAP, но, похоже, в настоящее время это невозможно. Планируется ли его поддержка, от него отказываются в пользу чего-то другого или он уже работает, просто нигде не задокументирован?

Новый, свежий взгляд на реализацию поддержки LDAP и Active Directory было бы здорово иметь в .NET CoreFX.

Нам действительно нужно решение Active Directory/LDAP, которое мы можем использовать в .NET Core. Будь то реализация с чистого листа или порт System.DirectoryServices, для меня не имеет большого значения. Существует множество бизнес-приложений Windows, которым абсолютно необходима аутентификация AD, и аутентификация LDAP была бы отличной возможностью для кроссплатформенных разработчиков.

Согласен с примечаниями об обратной совместимости выше - я не чувствую, что прямой порт действительно нужен, нам просто нужен способ доступа к аутентификации (и выполнения других действий: поиск, разблокировка, удаление и т. д.) для Active Directory или любого провайдера LDAP. .

@НикКравер

Я не чувствую, что на самом деле нужен прямой порт, нам просто нужен способ доступа [...] к аутентификации в Active Directory

Это хорошо знать. Не читайте слишком много о моей маркировке порта-ядра, которую я только что применил. Это просто мой способ отслеживать пробелы в предложении .NET Core, которые не позволяют таким клиентам, как вы, переносить свои приложения на .NET Core.

@terrajobst Попался. Я не думаю, что это обязательно должен быть элемент 1.0 из-за его модульности (и в любом случае это звучит так, как будто он намечен для пост-RTM), но я с нетерпением жду этого. Для меня это будет препятствием для переноса Opserver, так что буду рад участвовать в обсуждениях API, если мы можем быть полезны. У нас есть широкий спектр вариантов использования со стороны системного администратора, которые могут быть полезны, пингуйте, если я могу помочь.

Просто чтобы бросить еще одну шляпу на ринг. На данный момент это самый большой блокиратор, оставшийся и для меня. Просто возможность авторизации была бы огромной помощью на данный момент.

Можем ли мы получить официальный ответ от кого-то из команды разработчиков о планах на это, если вообще есть какие-либо планы по поддержке этого?

Я не чувствую, что прямой порт действительно нужен

Почему? Извините, я в замешательстве. Разве это не было бы самым простым решением для всех и в соответствии с принципом DRY?
Тем не менее, если есть причина написать весь API с нуля, некоторая согласованность со старым API (те же сигнатуры методов) будет менее запутанной для потребителя.

@jasonwilliams200ОК, позвольте мне уточнить, я действительно имел в виду конкретно DirectoryServices.ActiveDirectory . Я думаю, что аутентификация и все, что с ней связано: например, членство в группе — это 95-99% случаев использования пространства имен. Я думаю, что прямой порт сигнатур _that_ очень полезен. Если остальные ордера изменятся по какой-то причине, то я буду вполне согласен с этим, и хорошо, если это произойдет позже ... авторизация была бы хороша, чтобы выйти за дверь как можно скорее, поскольку это блокирует многих.

Интеграция по крайней мере базовых функций поиска пользователей Active Directory и сопоставления их с настраиваемыми ролями с помощью ASP.NET 5 упростит реализацию проверки подлинности Windows в веб-приложениях ASP.NET. Нам нужна эта функциональность на нашем интранет-сайте.

Это блокировщик и для нас. Нам нужно иметь возможность авторизоваться, запрашивать пользователей и группы, создавать новых пользователей и группы и т. д. на сервере ldap.

Это также блокировщик для меня - я требую запроса и аутентификации пользователей.

Я придумал решение для аутентификации в Active Directory в веб-приложении .NET Core rc1. Вам просто нужно переопределить метод CheckPasswordAsync в классе UserManager. Дайте мне знать, что вы думаете.

Сначала вам нужно создать пользовательскую страницу регистрации, которая позволяет пользователю вводить имя пользователя AD вместо адреса электронной почты и пароля. Это имя пользователя входит в свойство UserName класса ApplicationUser, который создается шаблоном ASP.NET 5, когда вы выбираете проверку подлинности отдельных учетных записей пользователей. Кроме того, вам придется установить свойство Password по умолчанию на то, что проходит внутреннюю проверку в классе IdentityUser.

Мой контроллер страницы регистрации вызывает метод Web API 2, который находит имя пользователя в AD и возвращает JSON, содержащий информацию AD для этого пользователя. Я добавил несколько настраиваемых свойств в класс ApplicationUser для хранения информации AD. Я опубликую код из моего проекта на следующей неделе.

Затем добавьте файл класса в папку Services. Я назвал свой ApplicationUserManager.cs. Добавьте приведенный ниже код в этот файл класса.

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNet.Http;
using Microsoft.AspNet.Identity;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.OptionsModel;
using [YourApp].Models;

namespace [YourApp].Services
{
    public class ApplicationUserManager : UserManager<ApplicationUser>
    {
        public ApplicationUserManager(IUserStore<ApplicationUser> store, IOptions<IdentityOptions> optionsAccessor, IPasswordHasher<ApplicationUser> passwordHasher,
                                      IEnumerable<IUserValidator<ApplicationUser>> userValidators, IEnumerable<IPasswordValidator<ApplicationUser>> passwordValidators,
                                      ILookupNormalizer keyNormalizer, IdentityErrorDescriber errors, IServiceProvider services, ILogger<UserManager<ApplicationUser>> logger,
                                      IHttpContextAccessor contextAccessor)
        : base(store, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer, errors, services, logger, contextAccessor)
        {

        }

        public override async Task<bool> CheckPasswordAsync(ApplicationUser user, string password)
        {
            //Pass user.UserName and password to an ASP.NET Web API 2 method that 
            //does the Active Directory authentication and returns a bool.
        }
    }
}

Затем откройте файл Startup.cs. Добавить .AddUserManager() к вызову AddIdentity в методе ConfigureServices, как показано ниже.

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

Это, по крайней мере, позволяет мне настроить авторизацию на основе политик/утверждений в ожидании поддержки DirectoryServices.

Я полагаюсь на эту библиотеку. Жалко, что сейчас нельзя портировать.

@ClintBailiff Я должен вмешаться здесь, потому что передача пароля пользователя по сети снова в другое приложение в виде открытого текста - _действительно_ плохая идея. Пожалуйста, не используйте этот подход. Это дыра в безопасности.

@terrajobst это будет препятствием при переносе моих более крупных приложений, таких как Opserver, — можем ли мы сделать это приоритетным?

@NickCraver Я никогда не предлагал передавать учетные данные в виде открытого текста. Как правило, я использую SSL для всех своих веб-приложений/служб, потому что они обычно возвращают данные, которые должны видеть только авторизованные пользователи. Я не подумал указать это, вероятно, потому, что это настолько очевидно, что вы не захотите отправлять учетные данные в виде открытого текста.

Я бы поддержал хотя бы предоставление порта System.DirectoryServices.Protocols . Недавно мы переключили наш код, связанный с LDAP, на этот, чтобы поддерживать более широкий диапазон серверов LDAP, поскольку пространство имен System.DirectoryServices.ActiveDirectory любит взаимодействовать только с серверами AD.

Я полагаю, что сторонняя библиотека могла бы развернуть такую ​​поддержку, но, поскольку она уже существует в фреймворке, я полагаю, что порт будет проще.

Команда WTF asp не предоставляет эту базовую функциональность
Это действительно проблема блокировщика :(

Какие-нибудь новости о поддержке LDAP в CoreCLR?

Я также хотел бы получить обновленную информацию об этом. Я буду разрабатывать корпоративное приложение с ASP.NET Core, которое должно аутентифицировать пользователей на AD-сервере.

Я буду изучать перенос System.DirectoryServices на .NET Core для версии 1.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 , заменяющие потоки TLS с Mono на CoreCLR SslStream Если кто-то заинтересован и нуждается в поддержке LDAP для CoreCLR, не стесняйтесь помочь.

Я подтвердил, что проект RC2 веб-приложения ASP.NET Core (.NET Framework) может ссылаться на библиотеку классов, которая использует System.DirectoryServices.AccountManagement. Я смог заставить его работать только тогда, когда и веб-приложение, и библиотека классов созданы с помощью VS 2015 Update 2 и оба используют .NET Framework 4.6.1.

Просто чтобы повторить чувства других, мы мертвы в переносе воды, не имея возможности запрашивать LDAP и тому подобное.

@h3smith
Смотрите мой предыдущий пост. С выпуском RC2 теперь вы можете ссылаться на библиотеку классов, которая использует System.DirectoryServices.AccountManagement .

Не на Нетстандарте.

Однако, как я уже сказал, мы работаем над тем, чтобы это заработало. Надеюсь, есть
что-то через 2-3 недели

В пятницу, 17 июня 2016 г., судебный пристав-исполнитель Клинтона, [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
.

Есть новости по этому поводу? Мне нужно аутентифицировать вызывающего пользователя, когда пользователь использует угловое веб-приложение в локальной сети, вошел в AD, вызывая метод контроллера WebAPI (без ввода пользователем пароля в веб-браузере) в ядре aspnet RC2. Возможный? Скоро можно?

Для этого вам просто нужно использовать withCredentials в ваших http-запросах от клиента. Затем вы можете получить информацию о пользователе и утверждения в своих контроллерах, используя User.Identity.
Это работает в ie и chrome, но с Firefox всплывающее окно будет автоматически отображаться для пользователя, который введет в своих окнах пользователя и пароль.

Мы столкнулись с той же проблемой (например, пытались использовать сервер LDAP в качестве хранилища пользователей) около двух месяцев назад. Нам не удалось найти никакого решения, кроме переноса библиотеки Novell LDAP (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) на ядро ​​.net (см. здесь https://github.com/dsbenghe/Novell. Каталог.Ldap.NETStandard). Опубликован пакет nuget. Мы используем библиотеку с LDAP-сервером OpenDJ (должно работать с любым LDAP-сервером) — никаких проблем за 1,5 месяца использования.

@dsbenghe , мы только что получили нашу библиотеку Novell LDAP, скомпилированную на netstandard, наша также содержит пейджинг. Это сделал @igorshmukler . Хотите сравнить и сотрудничать? Наш WIP тут https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Спасибо за вашу работу над реализацией .NET Core.
После получения пакета nuget я создал следующий код, чтобы проверить правильность пароля ActiveDirectory пользователя.

using Novell.Directory.Ldap;

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

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

Он вызывает AuthenticateWithActiveDirectory:

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

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

    return string.Empty;
}

И использует простой вспомогательный класс, чтобы приложение angular знало, что происходит.

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

Для UWP есть запрос на эту функцию в нашем UserVoice: https://wpdev.uservoice.com/forums/110705/suggestions/12556779 .

cc @tquerec @jimuphaus , который будет работать над поддержкой System.DirectoryServices для .NET Core.

Не могу дождаться! Расчетное время прибытия? Характеристики дизайна?

Когда он будет наконец перенесен, у нас будет доступ к:

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

Я знаю, что в этом пространстве имен есть некоторые незначительные дефекты, но все же это довольно полезно.

@GArrigotti при тестировании, использование LdapDirectoryIdentifier обычно быстрее , чем PrincipalContext.

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

Есть ли расчетное время прибытия? Я мог бы использовать это в системе, которая должна быть завершена в конце этого месяца...

@johnkwaters есть ли причина, по которой вы не можете поместить код AD в библиотеку классов? У некоторых людей (включая меня) были проблемы со ссылками на устаревшие библиотеки классов в приложении ASP.NET Core. Но проблем не возникает, если вы создаете веб-приложение и библиотеку классов в VS 2015 с обновлением 3 и ориентируетесь на .NET Framework 4.61 в веб-приложении и библиотеке классов.

есть ли причина, по которой вы не можете поместить код AD в библиотеку классов?

Вы имеете в виду PCL, за которым следует "imports": "portable-net45+win8" в project.json для .NET Core TxM? Это потребует присутствия в Unix эталонных сборок Mono PCL, а не решения «чистого ядра donet», которое обеспечивает самодостаточность в Unix. Это хороший способ заставить компилятор замолчать, но работает только в том случае, если CoreFX BCL имеет соответствующую реализацию. Как правило, проект.json без "imports" для netcoreapp/netstandard1.x всегда лучше. например https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Есть какие-нибудь новости о ETA? Где я могу обратиться к самообслуживанию, чтобы ответить на повторяющийся вопрос?

_Очень_ с нетерпением жду этой функции!

Очень жду эту функцию!

Очень жду эту функцию!

Мне тоже очень нужна эта функция!

Ребята, не могли бы вы просто добавить реакции на основной пост?

Или используйте библиотеки, которые поставили на nuget два разных человека. Его
все ОСС. Если вам не нравится пакет, отправьте PR

8 сентября 2016 г., 12:19, Михаил Орлов, [email protected]
написал:

Ребята, не могли бы вы просто добавить реакции на основной пост?

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 для @jchannon Novell LDAP. Это заставило нас двигаться вперед и практически не вносило изменений в нашу реализацию LDAP. Я имею в виду, что вы правильно абстрагируете;)

Да, в итоге я тоже использовал @jchannon Novell LDAP, это сработало хорошо.

Если я не говорил об этом раньше, вот вся ветка на https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

На данный момент соответствует нашим требованиям...

@h3smith @johnkwaters любые проблемы, не стесняйтесь поднимать их 😄

Я решил попробовать с Novell, примеры выглядят достаточно хорошо, но я не знаю, как выкинуть (удалить) пользователя из группы с помощью Novell LDAP.
Я не могу изменить свой пароль на MSAD LDAP, так как не вижу userPassword, и он не установлен на сервере LDAP.

Это действительно нужно!

@joshfree или кто-нибудь еще в курсе...
Мы собираемся начать новый проект, которому требуется доступ к ActiveDirectoryServices.AccountManagement. Вопрос. Предназначен ли порт для версии 1.1 или 1.2?

Это не часть 1.1 (которая вот-вот будет доработана). @tquerec , не могли бы вы прокомментировать здесь свои планы?

копия: @danmosemsft

Итак, если не часть 1.1, у кого-нибудь есть план? Похоже, что отсутствие этой поддержки является серьезной проблемой. Ясно, что Microsoft больше всех хотела бы этой интеграции.

Просто еще один голос за. Трудно инвестировать в создание систем корпоративного класса на .NET Core, если в нем отсутствуют основные корпоративные функции. Проект Novel работает, но не на высоте.

Еще голосование. Я повторю то же утверждение, что это неотъемлемая часть создания любого корпоративного приложения.

@nevcoBpalacio Я думаю, они пытаются подтолкнуть нас к использованию активного каталога azure.

Это никогда не сработает для тех, кто использует корпоративные соглашения, требующие, чтобы услуги оставались в доме.

Я работал в государственных учреждениях, как федеральных, так и местных округов, и в любом случае вам все равно понадобится какой-то интерфейс или возможности для интеграции с какой-либо службой каталогов, будь то облачная или локальная. Я совместно разрабатывал приложения, управляющие миллиардами долларов, и всегда возникает потребность в службах каталогов. Я думаю, что это больше, чем очередное голосование, а скорее заявление о том, чего вы ждете? Я согласен с более ранним сообщением о том, что изначально это было готовое решение в предыдущих выпусках .NET. Я понимаю, что более открытая структура CORE должна получить импульс сообщества, и если это то, чего Microsoft хочет ждать, может быть, они сказали это, а я пропустил это, они должны сказать это, чтобы кто-то мог взять на себя инициативу и потратить время. чтобы сделать это.

Да, добавьте System.DirectoryServices в .NET Core!

У нас есть планы портировать System.DirectoryServices.Protocols в течение следующего года. На данный момент я не могу назвать более точную дату. У нас пока нет планов портировать System.DirectoryServices или System.DirectoryServices.AccountManagement, но я заинтересован в оценке интереса. Существуют ли особенности тех пространств имен, которые люди используют, которые нельзя решить с помощью протоколов?

@tquerec Я не знаком с протоколами. У нас есть проект по самообслуживанию Active Directory для разблокировки учетной записи и сброса пароля учетной записи. Мы используем UserPrincipal в проекте и вызываем такие методы, как FindByIdentity, UnlockAccount, SetPassword, ExpirePasswordNow,.
Я не уверен, можно ли это сделать в протоколах, но похоже, что протоколы — это реализация более низкого уровня, а AccountManagement — лучшая абстракция для работы с ActiveDirectory.
Спасибо
Рокмайстер

@nevcoBpalacio определенно должен быть больше, чем голосование, я согласен. Я думаю, что это действительно требует большего приоритета.

@CalebMacdonaldBlack было бы полезно, если бы вы могли ответить на вопрос @tquerec о шаблонах использования и о том, почему это необходимо. Больше лайков или "согласен/это важно" без сценариев сейчас не помогут поднять приоритет... Спасибо!

Мы используем сканирование/поиск LDAP, выполнение BIND для проверки учетных данных, добавление/удаление объектов LDAP (пользователей, групп), изменение членства в группах и т. д.

@tquerec Мне действительно нужен System.DirectoryServices.AccountManagement, чтобы я мог аутентифицировать наших пользователей в Active Directory и авторизовать их в группах, к которым у них есть доступ.

определенно согласен с h3smith .. нам это было нужно для v1, и вместо этого мы вынуждены идти по пути Novel, который мы объединили вместе (особенно биты репликации), и это вызывает у нас проблемы с накладными расходами на обслуживание и т. д. Это делает .NETCore плохо выглядеть как побочный эффект..

@liquidboy

нам нужно это для v1

Вы имеете в виду .NET Core v1? -- это сделано и отправлено. Сейчас работаем над 1.2. Или вы имели в виду что-то другое?

вместо этого вынуждены идти по пути Романа

Что это означает? (Извините, у меня нет контекста DirectoryServices, но я хотел бы понять, чего нам не хватает с точки зрения сценариев)

@karelz просто выполните поиск в этой теме по слову «роман», и вы поймете, что я имею в виду. Другой разработчик (dsbenge) в моей команде прокомментировал (вместе с другими) пробел, который привел к тому, что мы использовали роман. [вот ссылка на комментарий выше https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

И да, я имел в виду .NET Core v1, который уже выпущен, мы работали над нашим решением больше года, и тогда нам нужно было хорошее решение DirectoryServices. Мы уперлись в стену, и поэтому у нас не было выбора, кроме как использовать новый .

@liquidboy спасибо за ссылку - если она в Mono, мы должны иметь возможность повторно использовать исходный код в .NET Core AFAIK. @tquerec , учитывая интерес, рассмотрит ли это ваша команда?

@tquerec Нам нужно следующее:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory и System.DirectoryServices.Protocols.

Они необходимы для подключения и управления пользователями, группами и атрибутами Active Directory (и других серверов LDAP), как описано в приведенных выше ответах. Важно иметь эти функции в .Net Core!

Я согласен с другими. Мне нужно это, чтобы перенести любое из наших приложений, которые аутентифицируются в ActiveDirectory, на .NET Core. Это довольно фундаментально, это определенно должно быть в скорейшем выпуске. Это блокатор переноса многих вещей.

На странице дорожной карты .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) есть этот план для .NET Core 1.2: «приведение .NET Core к паритету с .NET Framework и Mono для большая коллекция базовых типов».

Я думаю, что портирование System.DirectoryServices очень хорошо соответствует этому плану и действительно должно быть частью выпуска 1.2. Просто мои 5 (евро) центов :)

Просто для уточнения: API, перенесенные в 1.2, были выбраны на основе данных об использовании (и редко сложности) — @weshaggard @danmosemsft, не могли бы вы рассказать подробности, почему мы не включили System.DirectoryServices?

Список сборок, которые мы выбрали для соответствия, находится здесь . @weshaggard придется напомнить мне, как он выбрал этот список. (У Mono есть S.DirectoryServices)

Я полагаю, что вы сможете делать почти все, что необходимо для взаимодействия с ActiveDirectory (и другими серверами ldap) с помощью System.DirectoryServices.Protocols, но многим людям придется переписать свой код, чтобы использовать S.DS.Protocols.

Лично я бы предпочел, чтобы MS перенесла S.DS.Protocols и MS или Community, чтобы создать простую в использовании библиотеку для управления пользователями/группами поверх этого.

Список сборок, которые мы выбрали для соответствия, находится здесь. @weshaggard придется напомнить мне, как он выбрал этот список. (У Mono есть S.DirectoryServices)

Первоначальное заполнение было выполнено из пересекающихся профилей Xamarin с .NET Framework. Профили Xamarain (которые являются подмножеством моно) не поддерживают DirectoryServices, поэтому это не было на пересечении.

Что мы можем сделать, чтобы утверждать, что это должно быть в? Невозможность использовать наиболее распространенную схему аутентификации в приложениях Microsoft немного мешает, не так ли? Находится ли здесь акцент на Azure, а не на AAD? Или блокировщик, который портирует это через платформы, является большим неизвестным протоколом?

Есть ли способ повысить приоритет здесь? До версии 2.0 еще далеко, и очень жаль, если все остальное работает, но мы не можем аутентифицировать пользователей. Это виртуальная входная дверь для многих приложений. ИМО, с точки зрения приоритета это немного отличается, потому что это не частичный блокировщик, а часто полный блокировщик по своей природе.

Я не думаю, что есть какие-либо разногласия по поводу того, что мы хотим поддерживать это в .NET Core, что отличается от того, чтобы быть частью .NET Standard, это просто вопрос времени. @tquerec владеет этой территорией и будет говорить об этом.

Кто-то из .NET Foundation спросил, но конкретно мы используем следующие пространства имен:
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

Итак, @tquerec , как нам пометить System.DirectoryServices для .NET Core 1.2? По крайней мере System.DirectoryServices.Protocols. Это возможно?

Большое спасибо!

[обновлено дополнительной информацией от @tquerec]
Я встретился с @tquerec в понедельник. Я должен всем написать. В двух словах:

• Система. DirectoryServices выполним только для Windows (он вызывает Windows DLL, где живет вся реализация), совершенно неизвестен для Linux/Mac.
• Система.DirectoryServices. AccountManagement находится поверх него, поэтому также выполним только для Windows и неизвестен для Linux/Mac.
• Система.DirectoryServices. ActiveDirectory выполним только для Windows (он вызывает множество специфичных для Windows API)
• Система.DirectoryServices. Протоколы должны быть достаточно простыми для Windows и более сложными для Linux (нам нужно найти библиотеку LDAP для использования).
  Мы пытаемся выяснить с @tquerec , как финансировать работу — в идеале для 1.2, но пока ничего не обещаем. Я ожидаю, что решение займет по крайней мере пару недель.

Вопросы ко всем :

• Приемлема ли указанная выше область видимости только для Windows для основных вариантов использования? (Sys.DirSer и Sys.DirSer.AccountManagement и Sys.DirSer.ActiveDirectory)
• Если Sys.DirSer.Protocols Linux выйдет после версии 1.2 или будет полагаться на вклад сообщества, станет ли это серьезным препятствием?

@karelz System.DirectoryServices.ActiveDirectory основан на большом количестве специфичных для Windows API, поэтому он относится к тому же сегменту, что и S.DS и S.DS.AM.

@karelz Я не уверен, что вы подразумеваете под решением только для Windows для 1.2. У нас уже есть работающее решение только для Windows.

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

@rock-meister Я имею в виду .NET Core. Тот, который вы упомянули, нацелен на «полный» .NET 4.5.2+.

Да, поддержка только для Windows — это огромный разблокировщик для нас. Мы можем сделать всю работу по переносу .NET Core и расширить поддержку платформы «бесплатно» позже, когда будут готовы базовые компоненты. Право не блокировать даже _starting_ в порт огромен. То, что он ушел, — большая победа.

Будучи магазином Windows, это также было бы большой победой. Так много крупных предприятий сочли бы это огромной победой! Спасибо, что следите за своей информацией. Держать нас в курсе. Спасибо.

@karelz Спасибо за разъяснение. Да, область видимости только для Windows для версии 1.2 у нас работает.
Рокмайстер

System.DirectoryServices.Protocols с поддержкой Linux/LDAP является наивысшим приоритетом для нашей работы.

ps область видимости только для окон кажется противоречащей целям .netcore/.netstandard

Некоторое время назад мы перешли с использования System.DirectoryServices на использование System.DirectoryServices.Protocols , чтобы иметь возможность поддерживать серверы LDAP без AD. Доступ к пространству имен Protocols был бы на один шаг ближе к тому, чтобы мы могли перенести наш код в ядро ​​.NET.

Однако, если это будет зависеть от платформы, от нас будет меньше пользы. Одной из основных причин перехода на ядро ​​.NET является переносимость платформы. Вероятно, нам все еще придется ждать этого.

Для нас переход на .NET Core был возможностью использовать Docker и быть полностью независимым от платформы. Таким образом, зацикливание на поддержке LDAP только для Windows не принесет пользы.

Спасибо за внутреннее обсуждение.

Мой голос идет по независимому от платформы маршруту 🦃

Я должен согласиться с комментарием, не зависящим от платформы, как бы ни было больно, что я не могу использовать ядро, пока это не будет выполнено. Я думаю, что это то, что должно быть рассмотрено на более высоком уровне. Чего я не понимаю, так это сложности концепции? Существует несколько решений для каталогов, AD, Novell и т. д. Это требует межплатформенного (независимого) интерфейса... Счастливых праздников!

Хотя лично я мог бы прекрасно жить с областью действия только для Windows, на мой взгляд, это ломает идею .NET Core и его переносимости.
Независимое от платформы решение должно быть направлением, на котором следует сосредоточиться.

Да, согласен, .NET Core должен быть кроссплатформенным, а функции/API должны работать на всех поддерживаемых платформах!
Поэтому, если System.DirectoryServices.Protocols будет портирован/реализован в первую очередь, он должен работать и в Linux.

Я согласен с тем, что в идеале целью должно быть независимое от платформы решение. Хотя его отсутствие в Windows по-прежнему мешает многим разработчикам, которые просто хотят поэкспериментировать с платформой в корпоративной (AD) среде, как я. Вот почему я бы приветствовал решение только для Windows на данный момент.

Я просто хотел бы вмешаться и сказать, что меня устраивает решение только для Windows, пока не удастся собрать что-то кроссплатформенное.

Я полагаю, что 99,9% разработчиков, которым необходимо подключиться к Active Directory, делают это в корпоративной среде, где они работают на компьютерах с Windows.

Мы обсуждаем финансирование с нашей стороны (ожидайте обновление примерно через 2 недели), в настоящее время это является главным приоритетом для API, которые еще не являются частью .NET Standard 2.0.

Есть ли вокруг люди, которые хотели бы помочь/внести свой вклад в реализацию Windows и/или реализацию Linux? (мы могли бы добавить код с рабочего стола, и для сборки потребовалось бы дальнейшее массирование + некоторое тестирование)

@karelz Я бы хотел внести свой вклад в Linux. Нам нужна эта поддержка как для проверки подлинности Windows, так и для проверки подлинности не Windows (локально). Это блокировщик для нас, и мы нацеливаемся на ядро ​​.NET для нашего кросс-платформенного проекта (ранее было Mono на стороне Linux и .NET на стороне Windows).

Хотел бы помочь, где мы можем, без сомнения.

Я был бы рад помочь, но я уверен, что вы, ребята, намного опытнее меня, и я не был бы вам полезен.

@karelz @tquerec Буду рад помочь с тестированием на Windows, а в будущем и на Linux. Я подписался на ветку, так что просто ответьте здесь или упомяните меня, чтобы связаться со мной, когда вам понадобится мое участие. Спасибо за вашу работу над этим. Этого давно ждали, и даже если оно будет инкрементальным, это будет хороший шаг к дальнейшему внедрению .NET Core.

Я думаю, что «расширенная Windows» изначально является хорошей целью, «расширенная» означает, что она работает на NanoServer и в контейнерах (т.е. машины, не присоединенные к домену, которые не могут запускать полную .NET CLR). Это даст вам быстрый выигрыш и отправную точку для работы в обратном направлении, чтобы реализовать его на других серверах.

Мы работали с @tquerec и нашими цепочками управления, чтобы найти лучший способ разблокировать эту работу как можно скорее. К сожалению, до конца января у нас нет свободных людей, поэтому тем временем мы постараемся сделать все возможное, чтобы разблокировать вклады сообщества, используя лишь ограниченные ресурсы и некоторую волонтерскую работу с нашей стороны ( @ianhays @tquerec и @karelz).

Вот что мы планируем сделать:
@ianhays поможет нам запустить проект в репозитории CoreFX (добавьте исходный код, покажите примеры, как это сделать, посоветуйте с настройкой сборки, упаковки, подготовьте проект для будущих портов Linux/Mac и т. д.).
Мы начнем с реализации только для Windows (вклад приветствуется). На данном этапе мы не будем вносить какие-либо функциональные изменения в реализацию или поверхность API, если только они не необходимы для переноса на .NET Core.
Следующим (потенциально параллельным) шагом будет добавление тестов. Мы должны начать обсуждение с @tquerec существующего дизайна тестов (с закрытым исходным кодом .NET Framework), если есть что-то, что мы можем использовать, или если нам нужно начинать с нуля.
Позже мы можем сосредоточиться на портах Linux/Mac.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte и все, кто заинтересован, мы будем рады принять ваш вклад, как только @ianhays начнет работу ( прибытия : думаю, в середине следующей недели). Если у вас есть какие-либо вопросы или предложения, пожалуйста, сообщите нам об этом.

Позволяет ли эта работа также библиотекам, таким как SqlClient, выполнять проверку подлинности Windows при работе в Linux, но при подключении к SQL Server, для которого требуется проверка подлинности Windows?

Это одно из моих препятствий на пути к возможности переноса вещей в .NET Core, работающий в Linux. Все наши корпоративные серверы Microsoft SQL разрешают подключение только через идентификатор службы (неинтерактивный), который находится в AD.

блгмбой. Ваша проблема является ярким примером того, почему необходимо «проверять» вещи, чтобы обеспечить истинную кросс-платформенную совместимость с новыми предлагаемыми моделями. Если у вас есть другие сценарии, я думаю, что ваша среда является хорошим примером того, как вещи должны пересекаться, и вы должны перечислить любые другие проблемы, которые у вас возникают с AD-частью Core.

Да, я обязательно запомню эту тему и поделюсь всем, что найду. Просто хотел, чтобы все знали, что это довольно большая проблема для предприятий с фермами SQL, которые имеют строгую безопасность, как описано.

Это также мешает использовать что-то вроде EF Core, которое в конечном итоге будет иметь ту же проблему.

System.DirectoryServices теперь объединен с CoreFX. Следующий шаг — собрать его для .NET Core — Windows и добавить тесты.

Спасибо Ян. Приятно видеть хоть какое-то движение в этом вопросе!

Спасибо Ян!

Обновленный план выполнения: РЕДАКТИРОВАТЬ: перемещен в самый верхний пост в этом выпуске для лучшей видимости.

Если кто-то работает над каким-либо шагом, пожалуйста, укажите это и скоординируйте здесь, чтобы избежать дублирования усилий. Я также поручу вам этот вопрос.

Пространства имен System.DirectoryServices содержат такие важные функции для локальных корпоративных приложений Windows, что приятно видеть прогресс в решении этой проблемы. Продолжайте хорошую работу.

Я исправил исходники, и System.DirectoryServices теперь собирается. Я должен отправить PR в ближайшее время.

Спасибо @tquerec за участие во втором туре!
Есть ли добровольцы, которые помогут с оставшимися двумя пространствами имен или тестами? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

У @jay98014 есть PR здесь https://github.com/dotnet/corefx/pull/15324 , чтобы добавить дополнительную поддержку и получить сборку Protocols/AccountManagement.

Что бы это ни стоило, я недавно экспериментировал с System.DirectoryServices.Protocols и обнаружил, что многие простые сценарии System.DirectoryServices нетрудно имитировать с помощью System.DirecotryServices.Protocols. Исходя из этого, я думаю, что обеспечение кросс-платформенной работы S.DS и S.DS.AM может быть менее приоритетным, поскольку кросс-платформенный System.DirectoryServices.Protocols может быть полезным обходным путем для многих пользователей.

Конечно, это означает, что обеспечение работы System.DirectoryServices.Protocols в качестве кросс-платформенного решения LDAP остается первоочередной задачей.

Я правильно читаю пулреквест? Похоже, это было принято несколько дней назад, поэтому, если мы будем строить из исходного кода, мы сможем попробовать его?

Да, я думаю, что у нас есть вся сборка DirectoryServices, однако у нас нет никаких тестов, что мешает нам поставлять пакет как стабильный и вносить улучшения в кодовую базу (исправления ошибок, улучшения и т. д.).
Если вы можете попробовать собрать его из исходников, это будет здорово. Если вы (или кто-то еще) хотите помочь нам добавить тесты или запустить порт Linux, это будет еще лучше :)

Всем привет,

Мы готовимся к запуску корпоративного проекта, для которого требуется поддержка Active Directory, поскольку мы на 100% находимся внутри нашего домена. Может ли кто-нибудь сообщить статус этой проблемы и ожидания для следующего основного выпуска? Прошу прощения, но я новичок в сообществе GitHub и еще не понимаю всей разнообразной терминологии и информации о статусе.

Было бы здорово использовать Active Directory для членства вместо полностью отдельной модели удостоверений, которой нужно было бы управлять отдельно и которая также вызывала бы несоответствие данных.

Заранее спасибо!

@karelz за этот вопрос, но я думаю, что ответ заключается в том, что в настоящее время этого не ожидается в выпуске 2.0, поскольку у нас нет запланированного разработчика для этого. Вклад сообщества приветствуется. его не нужно поставлять _в_ выпуске 2.0, он может выйти в NuGet в любое время, когда он будет готов к отправке.

Идеально! Вы ответили на мой вопрос.

Спасибо.

@nevcoBpalacio есть желание попробовать внести свой вклад?

У меня есть интерес, особенно к этой теме, поскольку я знаю, что она удерживает многих от перехода к основным корпоративным решениям. Тем не менее, у нас есть работа, и я не могу найти время днем ​​(вечером с детьми) для этого. Я попытаюсь перенастроить свою систему дома для работы с GitHub. Я ценю, что вы спросили, хотя! Спасибо.

Nevcobpalacio, если вы используете vs17 и вам не требуется кросс-плата, вы можете немного приблизиться к тому, что хотите, используя основной шаблон веб-приложения, ориентированный на полную платформу .net, и сослаться на dll system.directoryservices.accountmanagement по старинке и сверните свое собственное промежуточное программное обеспечение, чтобы сделать это тем временем. Из того, что я видел, тот же код должен быть перенесен на ядро ​​​​.net, как только он станет доступен, за исключением того, что вы будете использовать пакет nuget и удалить ссылку. Надеемся, что эта информация поможет вам в реализации вашего проекта.

@ los93sol спасибо за это предложение. Наши первоначальные обсуждения заключались в том, чтобы создать его, аналогичный этому предложению, и сделать его промежуточным программным модулем, который мы можем «перерезать» на все, что попадет в Nuget позже. Огромное спасибо!

Я должен прокомментировать и поблагодарить вас за это предложение. Сначала я скептически отнесся к этому изменению ядра. Тем не менее, с таким подходом сообщества, подобные обсуждения выходят на свет и помогают нам всем разобраться во время этих серьезных изменений.

Спасибо.

Кто-нибудь в настоящее время работает над добавлением недостающих тестов или над переносом System.DirectoryServices.Protocols на Linux/Mac?

@pasikarkkainen AFAIK , на данный момент команды Microsoft не предпринимают таких активных усилий (которые могут измениться или не измениться в ближайшем будущем). Я также не видел, чтобы кто-то из сообщества начал над этим работать.
Вы заинтересованы в том, чтобы внести свой вклад, или просто интересуетесь статусом?

@karelz Похоже, они нацелены на DirectoryServices для выпуска .NET Core 2.0 этим летом.

Цитата сообщения @shanselman

AD. В общем, это пробел, ЕСЛИ вы хотите вызывать LDAP напрямую. Вы, безусловно, можете авторизоваться с Windows Auth СЕЙЧАС. Мы планируем создать специальное пространство имен DirectoryServices для Core 2.0 в летнее время.

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

Да, это соответствует обсуждениям в коридоре, которые я слышал. Я просто не был уверен, является ли это общедоступной информацией и насколько (и кто) привержен этому. Я думаю, можно с уверенностью сказать, что это очень серьезно рассматривается, и это, вероятно, произойдет. Я позволяю владельцам @shanselman и DirectoryServices комментировать сроки.

@karelz : Спасибо за обновление! В основном меня интересовал статус. Я определенно могу помочь с тестированием, по крайней мере, когда это станет доступно.

@pasikarkkainen , если вы также готовы помочь написать несколько тестовых примеров, это будет очень признательно.
Если вы «просто» хотите протестировать пакет в своем приложении/коде, это должно быть выполнимо сегодня. Нам просто нужно начать публикацию пакета в качестве предварительного просмотра на myget (я думаю, что публикация отключена сегодня).

@karelz Я был бы не против помочь конкретно с реализацией Mac. У меня мало знаний, поэтому я не уверен, насколько хорошо я могу внести свой вклад. Я провел исследование вокруг этого, и есть библиотека новелл, которую, кажется, предлагают люди. Нашел чужую реализацию этой библиотеки новелл здесь: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt Автор пакета уже упоминал об этом здесь.
https://github.com/dotnet/corefx/issues/2089#issuecomment-228043297

Так это то, что будет в ядре 2.0? Я немного смущен относительно его статуса.

Нет, он не будет частью .NET Core 2.0, однако на конференции Build мы обещали доступность пакета летом. Пакет (Windows) должен быть доступен поверх .NET Core 2.0 примерно во время выпуска .NET Core 2.0.
В настоящее время мы работаем над тем, чтобы сделать пакеты доступными для предварительного просмотра в основной ветке (#18090) и параллельно работаем над тестовыми активами (#20669).

Получим ли мы ошибки компиляции, если нацелимся на общую среду выполнения или среду выполнения, отличную от Windows? Или мы окажемся в ловушке PlatformNotSupported ?

Это будет автономный пакет без каких-либо ресурсов, отличных от Windows. Компиляция должна сломаться. @ericstj может подтвердить.

Вы не получите ошибок компиляции, они будут исключениями "PlatformNotSupported" во время выполнения.

Да, это старое — блокируем ли мы людей, использующих его в библиотеках .NET Standard, или превращаем ошибки времени компиляции в исключения PlatformNotSupported? ... К счастью, есть золотая середина: инструментарий ApiCompat заранее скажет вам, что вы используете что-то, чего нет везде.

Я получаю следующую ошибку, когда пытаюсь использовать пакет System.DirectoryServices в проекте netstandard 1.6:

Install-Package: пакет System.DirectoryServices 4.0.0 несовместим с netstandard1.6 (.NETStandard, версия = v1.6). Пакет System.DirectoryServices 4.0.0 поддерживает: сеть (.NETFramework, версия = 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 и @ericsstj за ссылки!

Пробую пакеты от myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
При работе на MacOS 10.12.6 и при работе:

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

Я получаю:

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

Ожидается ли, что PrincipalContext будет работать на Mac?

@ bruno-garcia в CoreFX сейчас нет реализации DirectoryServices, кроме как для Windows. @karelz должен был бы поговорить о планах/стремлениях, если таковые имеются.

Только System.DirectoryServices.Protocol потенциально выполнимо для x-plat (пока не реализовано) — подробности см. в некоторых моих ответах выше и в верхнем посте.

Важно, чтобы System.DirectoryServices.Protocols работал на разных платформах (также на Linux/Mac). Правильно ли я понял, что основная проблема в настоящее время заключается в том, что библиотека LDAP, используемая System.DirectoryServices (в Windows), не имеет открытого исходного кода и, следовательно, только работает на винде?

Если я правильно понял, System.DirectoryServices будет сложно сделать xplat из-за большого количества зависимостей от COM-интерфейсов ADSI, которые доступны только в Windows.

System.DirectoryServices.Protocols по-прежнему должен иметь возможность запускать xplat.

Запуск того же кода, который я упоминал ранее:
```С#
используя (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

На Win7 x64 с .NET Core 2.0 выдает:

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

Использовал пакеты:

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

[EDIT] Исправлена ​​подсветка стека вызовов и кода xml/C# от @karelz.

@bruno-garcia, пожалуйста, создайте отдельную проблему. Этот отслеживает общие усилия по переносу, а не конкретные ошибки/различия. Спасибо!

@bruno-garcia, который отслеживается https://github.com/dotnet/corefx/issues/23605 .

Следующим шагом может быть отладка через рабочий стол и поиск отклонений в поведении. Я постараюсь освободить разработчика, чтобы посмотреть на это.

Та же проблема на сервере Windows :( (Version="4.5.0-preview2-25701-02")

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

Как вы думаете, когда это сработает?

возникла проблема при попытке установить пакет

Install-Package : Unable to find package System.IO.FileSystem.AccessControl with version (>= 4.5.0-preview2-25707-02)
  - Found 15 version(s) in nuget.org [ Nearest version: 4.4.0 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages
  - Found 0 version(s) in Package source
At line:1 char:2
+  Install-Package System.DirectoryServices -Version 4.4.0-preview2-257 ...
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

===============================================
Если у кого-то такая же проблема, как у меня, используйте вместо этого .NET CLI

dotnet добавить пакет System.DirectoryServices --version 4.5.0-preview2-25707-02 --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

@papamamadoii это потому, что вы пропустили https://dotnet.myget.org/F/dotnet-core/api/v3/index.json в качестве источника и, очевидно, Install-Package не использовал указанный вами канал для поиска зависимостей. Возможно, вы захотите сообщить об ошибке на http://github.com/nuget/home с конкретными шагами воспроизведения.

@karelz Если я правильно понимаю комментарии, это не работает в развертываниях на базе Linux?

@euclid47 System.DirectoryServices.* в настоящее время не поддерживается в Linux. Как обсуждалось выше, некоторые его части потенциально могут быть перенесены при достаточном интересе/участии сообщества.

@danmosemsft Я не понимаю, как вы не можете видеть, что вся эта ветка открыта с октября 2015 года как достаточный интерес сообщества. Если бы у меня был набор навыков, необходимый для написания чего-то столь сложного, как коммуникационный уровень LDAP, я бы уже работал над этим, поскольку AD был одним из основных механизмов аутентификации в корпоративной среде. Я укажу, что для большинства крупных предприятий невозможность выполнять такие взаимодействия в Linux буквально сводит на нет цель Core и заставит их придерживаться предварительных сборок dotnet, тем самым ограничивая ваше драгоценное взаимодействие с сообществом.

@danmosemsft Кроме того, если вы буквально не планируете работать над этим, просто сообщите об этом сообществу окончательно, чтобы другие разработчики могли собрать все по кусочкам.

На данный момент @shairozan мы отметили 7 голосов из 54, которые считают службы каталогов в Linux более приоритетными, чем в Windows — см. https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217.
Есть и другие преимущества, которые разработчики получают от .NET Core, помимо x-платформы (хотя я согласен, что x-plat — одна из главных причин).

Я бы порекомендовал сначала закончить выпуск пакета только для Windows, а затем мы сможем открыть новый выпуск, чтобы более точно отслеживать интерес к порту Linux.

Мы уже сообщили сообществу, что ищем помощи, и проблема помечена для получения — см. https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. И @hughbe помог с первым раундом тестов для DirectoryServices — см. историю здесь , здесь и здесь .

@karelz Где осуществляется голосование за эти компоненты? Я могу гарантировать, что после SELF / POSSCON вы увидите довольно резкое увеличение интереса.

@karelz Где голосование за эту функцию? Я абсолютно согласен с @shairozan в необходимости. В этом выпуске есть комментарий , описывающий нашу среду разработки и производства. Это довольно шокирует, что не было никакого движения по реализации, так как евангелисты .Net Core проповедуют, что она независима от платформы.

Я создал новую задачу, чтобы отслеживать порт dotnet/corefx#24843 для Linux/Mac, чтобы голосование было проще , чем в комментарии в середине этой задачи (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217). ).

Я также добавил ссылку в верхний пост этого выпуска.

@ euclid47 голосование до сих пор было в этом выпуске - см. ссылки выше. Вот что привело к 7 голосам (+1 за отправителя оригинального выпуска).

Нашей команде нужна поддержка LDAP в Linux.
Потому что большинство наших клиентов используют авторизацию через LDAP.

@balkarov Если можете, проголосуйте за вопрос, который только что создал @karelz ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 Если вы еще не знаете, существует пакет Novell.Directory.Ldap.NETStandard Nuget, который вы можете использовать для интеграции LDAP в свои проекты. Мы не являемся продвинутыми пользователями LDAP, мы просто используем его для проверки учетных данных и получения информации о пользователе, но он отлично работает для нас, как в версии 1.0, так и в версии 2.0, работающей на образе докера dotnet core runtime. Это не официальный способ, но он выполняет свою работу до тех пор, пока не появится кросс-платформенный порт 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 для Windows завершена, вопрос закрыт.
Примечание:

• Публикация окончательного пакета отслеживается dotnet/corefx#24909.
• Порт Linux/Mac отслеживается отдельно с помощью dotnet/corefx#24843.

Привет, это будет работать в UWP?

Привет, это будет работать в UWP?

Нет, он поддерживается только для сетевых основных приложений, работающих в Windows и полной инфраструктуре. если вы используете его в UWP или в Linux, вы получите исключение PlatformNotSupported.

Я использую этот код в лямбда-функции в AWS, которая работает в Linux в фоновом режиме, и я получаю эту ошибку. «System.DirectoryServices.AccountManagement не поддерживается на этой платформе».
Я использую ядро ​​​​2.0

 public static List<string> GetGroups(string userName, string domainString)
        {
            List<string> result = new List<string>();
            List<GroupPrincipal> gprList = new List<GroupPrincipal>();
            // establish domain context
            PrincipalContext yourDomain = new PrincipalContext(ContextType.Domain, null, domainString);

            // find your user
            UserPrincipal user = UserPrincipal.FindByIdentity(yourDomain, userName);

            // if found - grab its groups
            if (user != null)
            {
                PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups();

                // iterate over all groups
                foreach (Principal p in groups)
                {
                    // make sure to add only group principals
                    if (p is GroupPrincipal)
                    {
                        gprList.Add((GroupPrincipal)p);
                    }
                }
            }

            foreach (var gp in gprList)
            {
                result.Add(gp.Name);
            }

            return result;
        }

@sscoleman Да, это еще не поддерживается в Linux. Он поддерживается только в Windows.

@sscoleman на нем создана проблема, https://github.com/dotnet/corefx/issues/24843. Было сказано, что интерес сообщества к нему недостаточен, за исключением того, что этот вопрос возникает постоянно. Так что теперь ты в дерьмовом месте. Вы потратили время на внедрение служб каталогов, а затем узнали, что Linux поддерживается. Теперь вы спрашиваете себя, почему это рекламируется как не зависящее от платформы, если есть функции только для Windows.

Это довольно очевидно, если вы посмотрите на большую стратегию Microsoft. Microsoft бросает ВСЕ свои ресурсы для разработки в Azure, включая Active Directory. Ознакомьтесь с разделом «Что нового в 2016 году». В основном это инвестиции в AzureAD/гибрид. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft не инвестирует в эту библиотеку для Linux, потому что вместо этого они хотят, чтобы все перешли на Azure AD. Имеет смысл, зачем вам вкладывать средства в то, от чего вы пытаетесь оттолкнуть клиентов?

Однако вы делаете что-то относительно простое. Вы можете использовать библиотеки Novel LDAP, они работают с AD и на .NET Core для Linux. Вам нужно самому составить протокол, но это не слишком сложно, и есть много образцов. Недостатком является то, что вам нужно самостоятельно управлять привязкой, для чего требуются DN пользователя и пароль.

System.DirectoryServices в настоящее время является API только для Windows и является частью пакета обеспечения совместимости Windows для .NET Core . В принципе, мы можем заставить части System.DirectoryServices работать на Linux, но у нас пока нет для этого ресурсов. dotnet/corefx#24843 отслеживает этот рабочий элемент.

Почему мы разрешаем устанавливать пакеты, которые не будут работать в Linux? Альтернативой может быть разветвление поверхности API, но это также не работает во всех случаях и затрудняет кодирование всей системы. Конечно, наш выбор тоже не без проблем, так как может быть сложнее предсказать, будет ли код работать кросс-платформенно или. У нас есть предварительная версия анализатора совместимости, который дает вам живую обратную связь по мере написания кода.

Посмотрите это видео, чтобы узнать больше о том, как пакет обеспечения совместимости Windows и кросс-платформенный анализатор работают рука об руку:

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

@thedevopsmachine

Microsoft не инвестирует в эту библиотеку для Linux, потому что вместо этого они хотят, чтобы все перешли на Azure AD.

Это не то, как я это вижу. Как вы указали, мы намерены зарабатывать деньги с помощью Azure. А Azure — это облачная платформа, предлагающая широкий спектр технологий и операционных систем. У нас нет деловых интересов в продвижении Windows в облаке вместо Linux в облаке. Но, конечно же, .NET уже 15 лет широко используется в Windows. Обеспечение полной функциональности во всех операционных системах требует времени, но я искренне думаю, что большинство людей, следящих за нашими усилиями с открытым исходным кодом, видят, что мы не намеренно ограничиваем возможности Linux. Это просто требует времени.

Я согласен с подходом, заключающимся в наличии согласованной API x-plat и x-framework, но это разрушает душу всякий раз, когда я сталкиваюсь с этой ужасной ошибкой ... я сочувствую @sscoleman ...

Может ли этот пакет DirectoryServices работать на CentOS 7?

Может ли этот пакет DirectoryServices работать на CentOS 7?

Пакет может быть установлен, но не будет работать. при его использовании вы получите исключение, не поддерживаемое платформой. мы ищем, как мы можем поддерживать службы каталогов в целом в Linux. это на нашем радаре.

Это действительно нуждается в поддержке Linux

CC @joperezr

@niemyjski см. dotnet/corefx#24843

Это действительно нуждается в поддержке Linux

.. плюс иметь возможность работать в контейнере докеров. Имхо, это боль в заднице, что нужно вернуться к старой реализации каталога Novell, когда вы хотите использовать .NET Core 2+ в Linux.
Все равно спасибо за работу!

Зачем закрывать эту тему? System.DirectoryServices.AccountManagement по-прежнему отсутствует в .NET Core вне 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]

открыть заново 14734

@tarekgh все еще на радаре?

открыть заново 14734

@JustinGrote , какую именно функциональность вы хотите использовать для сценария? DirectoryServices огромен, и я сомневаюсь, что вся функциональность может поддерживаться только в одном выпуске. Наличие конкретных запросов может помочь лучше, чем просто запрос на поддержку целых библиотек DS. В .NET 5.0 мы включили сценарий https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
Я не знал, что System.DirectoryServices.Protocols был перенесен, но похоже, что он все еще зависит от security.principal.windows, работает ли он в Linux даже с этим (через базовую аутентификацию и т. д.) или он выдаст отсутствующий ошибка сборки?

Цель состоит в том, чтобы повторно реализовать что-то вроде модуля ActiveDirectory Powershell, чтобы он был xplat, я рассматривал для этой цели либо новый модуль ldap, либо ldap4net, если не будет по крайней мере базовой поддержки взаимодействия.

Внедрение ActiveDirectory Powershell, вероятно, является очень большим вариантом использования. Позвольте мне поделиться двумя моими вариантами использования:

1) Я получаю от UserPrincipal, так как мне нужны атрибуты, которые не поддерживаются из коробки. Я следил за https://stackoverflow.com/questions/24798037/extend-userprincipal-class , и я думаю, что это своего рода стандарт в старой среде .NET, и такой подход к работе, вероятно, поможет большему количеству разработчиков.

2) У меня также есть код, подобный следующему:

`

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

`

Не знаю, что уже поддерживается сегодня, последний раз я проверял это в феврале.
Спасибо, Йоахим.

@ jol64 разве ты не можешь добиться того же с помощью протоколов?

@ jol64 разве ты не можешь добиться того же с помощью протоколов?

Скорее всего смогу. Я переписал некоторые вещи, чтобы использовать библиотеку Novell. Но это требует перезаписи и, следовательно, избыточного кода для моего существующего кода .NET framework. Я определенно предпочитаю избегать разделения всего кода, и я уверен, что другим эта идея тоже не нравится.
Мне также интересно, как работает аутентификация. С Novell (старая версия, которую я пробовал) мне нужно указать учетные данные, тогда как с моим существующим кодом мне это не нужно.
Спасибо, Йоахим.