@vibronet

Existe alguma atualização sobre isso?

Eu também gostaria de uma atualização sobre isso. Minha empresa está me pedindo para criar um novo aplicativo que requer a capacidade de consultar o Active Directory via LDAP, mas parece que isso não é possível no momento. Existe suporte planejado para isso, está sendo descartado em favor de outra coisa ou já está funcionando, mas não está documentado em nenhum lugar?

Seria ótimo ter um novo olhar sobre a implementação do suporte LDAP e Active Directory no .NET CoreFX.

Realmente precisamos de uma solução Active Directory/LDAP que possamos aproveitar no .NET Core. Seja uma implementação de planilha limpa ou uma porta de System.DirectoryServices não importa tanto para mim. Há muitos aplicativos Windows focados em negócios que precisam absolutamente de autenticação de AD, e a autenticação de LDAP seria um ótimo ponto de referência de recurso para desenvolvedores de plataforma cruzada.

Concordo com as notas de compatibilidade com versões anteriores acima - não acho que uma porta direta seja realmente necessária, só precisamos de uma maneira de acessar a autenticação (e executar outras ações: pesquisar, desbloquear, excluir etc.) no Active Directory ou em qualquer provedor LDAP .

@NickCraver

Não acho que uma porta direta seja realmente necessária, só precisamos de uma maneira de acessar a autenticação [...] no Active Directory

Isso é bom saber. Não leia muito no meu rótulo de porta para núcleo que acabei de aplicar. É apenas minha maneira de rastrear lacunas na oferta do .NET Core que impede clientes como você de portar seus aplicativos para o .NET Core.

@terrajobst Peguei . Eu não acho necessariamente que isso tenha que ser um item 1.0 por causa de sua modularidade (e parece que está programado para pós-RTM de qualquer maneira), mas estou ansioso por isso. Será um bloqueador na portabilidade do Opserver para mim, tão feliz em participar das discussões da API, se pudermos ser úteis. Temos uma ampla gama de casos de uso no lado sysadmin de coisas que podem ser úteis, ping se eu puder ajudar.

Só para jogar outro chapéu no ringue. No momento, este é o maior bloqueador que resta para mim também. Simplesmente ser capaz de autenticar seria uma grande ajuda por enquanto.

Podemos obter uma resposta oficial de alguém da equipe de desenvolvimento sobre os planos para isso, se houver algum plano para apoiar isso?

Eu não sinto que uma porta direta seja realmente necessária

Por quê? Desculpe estou confuso. Não seria a solução mais fácil para todos e de acordo com o princípio DRY?
No entanto, se houver uma razão para escrever toda a API do zero, alguma consistência com a API antiga (mesmas assinaturas de método) seria menos confusa para o consumidor.

@jasonwilliams200OK , deixe-me esclarecer, eu realmente quis dizer DirectoryServices.ActiveDirectory especificamente. Acho que a autenticação e as coisas em torno dela: por exemplo, a associação ao grupo é o caso de uso de 95-99% do namespace. Eu acho que uma porta direta de assinaturas de _that_ é bastante útil. Se o resto exigir mudança por algum motivo, então eu ficaria bem com isso, e tudo bem se viesse mais tarde ... a autenticação seria boa para sair pela porta o mais rápido possível, pois isso é um bloqueador para muitos.

Integrar pelo menos uma funcionalidade básica de pesquisar usuários do Active Directory e mapeá-los com funções personalizadas com o ASP.NET 5 facilitará a implementação da Autenticação do Windows em aplicativos Web ASP.NET. Precisamos dessa funcionalidade em nosso site de intranet.

Este é um bloqueador para nós também. Precisamos ser capazes de autenticar, consultar usuários e grupos, criar novos usuários e grupos etc. em um servidor ldap.

Também é um bloqueador para mim - preciso consultar e autenticar usuários.

Eu criei uma solução para autenticação no Active Directory em um aplicativo Web .NET Core rc1. Você só precisa substituir o método CheckPasswordAsync na classe UserManager. Diz-me o que pensas.

Primeiro, você precisa criar uma página de registro personalizada que permita ao usuário inserir um nome de usuário do AD em vez de um endereço de e-mail e senha. Esse nome de usuário vai na propriedade UserName da classe ApplicationUser que é gerada pelo modelo ASP.NET 5 quando você escolhe a autenticação de contas de usuário individuais. Além disso, você terá que padronizar a propriedade Password para algo que passe na validação interna na classe IdentityUser.

Meu controlador de página de registro chama um método Web API 2 que encontra o nome de usuário no AD e retorna o JSON que contém as informações do AD para esse usuário. Adicionei algumas propriedades personalizadas à classe ApplicationUser para armazenar as informações do AD. Vou postar o código do meu projeto na próxima semana.

Em seguida, adicione um arquivo de classe na pasta Serviços. Eu nomeei meu ApplicationUserManager.cs. Adicione o código abaixo a esse arquivo de classe.

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

Em seguida, abra o arquivo Startup.cs. Adicionar .AddUserManager() para a chamada AddIdentity no método ConfigureServices conforme mostrado abaixo.

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

Isso pelo menos me permite configurar a autorização baseada em políticas/declarações enquanto aguardo o suporte do DirectoryServices.

Eu confio nesta biblioteca. É uma pena que não posso portar agora.

@ClintBailiff Eu tenho que entrar aqui - porque retransmitir a senha do usuário pela rede novamente para outro aplicativo em texto simples é uma ideia _realmente_ ruim. Por favor, não use essa abordagem. É uma falha de segurança.

@terrajobst este será o bloqueador na portabilidade de meus aplicativos maiores, como o Opserver - podemos priorizar isso?

@NickCraver Eu nunca sugeri passar as credenciais como texto simples. Como regra, eu uso SSL para todos os meus aplicativos/serviços da web porque eles normalmente retornam dados que apenas usuários autorizados devem ver. Eu não pensei em especificar isso provavelmente porque é tão óbvio que você não gostaria de enviar credenciais em texto simples.

Eu apoiaria pelo menos fornecer uma porta de System.DirectoryServices.Protocols . Recentemente, mudamos nosso código relacionado ao LDAP para oferecer suporte a uma variedade maior de servidores LDAP, pois o namespace System.DirectoryServices.ActiveDirectory só gosta de se comunicar com servidores AD.

Suponho que seria possível para uma biblioteca de terceiros criar esse tipo de suporte, mas como já existe no framework, imagino que uma porta seja mais simples.

A equipe WTF asp não fornece essa funcionalidade básica
Este é realmente um problema de bloqueador :(

Qualquer atualização no suporte LDAP no CoreCLR?

Também gostaria de uma atualização sobre isso. Estarei desenvolvendo um aplicativo corporativo com ASP.NET Core que precisa autenticar usuários em um servidor AD.

Estarei analisando a portabilidade de System.DirectoryServices para .NET Core para v1.1.0 (https://github.com/dotnet/corefx/milestones)

@joshfree
Eu também tenho que autenticar usuários do ADLDS, considere também System.DirectoryServices.AccountManagement

Alguns anos atrás, a empresa em que trabalhei pegou o código-fonte da biblioteca LDAP Novell (Mono) para que nosso aplicativo pudesse se comunicar com os sistemas Active Directory, OpenLDAP e Oracle, e adicionamos suporte para controles paginados e atualizamos algumas correções de TLS. Fizemos isso porque queríamos rodar no Linux. Um PR com nossas alterações foi enviado aos proprietários. Como agora queremos entrar no CoreCLR, essa biblioteca precisava ser convertida para RC2. O trabalho começou aqui https://github.com/VQComms/CsharpLDAP/pull/1 , restam 17 erros de compilador que precisam ser endereçados. Eles são principalmente Thread.Abort , ThreadInterruptedException , substituindo fluxos TLS do Mono para o CoreCLR SslStream Se alguém estiver interessado e precisar de suporte LDAP para CoreCLR, sinta-se à vontade para ajudar.

Confirmei que um projeto RC2 de aplicativo Web ASP.NET Core (.NET Framework) pode fazer referência a uma biblioteca de classes que usa System.DirectoryServices.AccountManagement. Só consegui fazê-lo funcionar quando o aplicativo Web e a biblioteca de classes são criados com o VS 2015 Update 2 e ambos usam o .NET Framework 4.6.1.

Apenas para ecoar os sentimentos dos outros, estamos mortos na porta da água sem poder consultar o LDAP e similares.

@h3smith
Veja meu post anterior. Com o lançamento do RC2, agora você pode fazer referência a uma biblioteca de classes que usa System.DirectoryServices.AccountManagement .

Não no Netstandard.

No entanto, como eu disse, estamos trabalhando para que isso funcione. Espero ter
algo em cerca de 2-3 semanas

Na sexta-feira, 17 de junho de 2016, Clinton Bailiff [email protected] escreveu:

@h3smith https://github.com/h3smith
Veja meu post anterior. Com o lançamento do RC2, agora você pode fazer referência a um
biblioteca de classes que usa _System.DirectoryServices.AccountManagement_.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679, ou mudo
o segmento
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

Alguma atualização sobre isso? Eu preciso autenticar o usuário chamador, quando o usuário estiver usando um aplicativo web angular na LAN, logado no AD, chamando um método de controlador WebAPI (sem que o usuário digite a senha no navegador da web) no aspnet core RC2. Possível? Em breve possível?

Para fazer isso, você só precisa usar withCredentials em suas solicitações http do cliente. Em seguida, você pode obter informações e declarações do usuário em seus controladores usando User.Identity.
Isto funciona no ie e no chrome mas com o Firefox serámostrado automaticamente um popup para o utilizador escrever o seu utilizador e palavra-passe do Windows

Encontramos o mesmo problema (por exemplo, tentar usar um servidor LDAP como repositório de usuários) cerca de dois meses atrás. Não encontramos nenhuma solução além de portar a biblioteca LDAP da Novell (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) para o núcleo .net (veja aqui https://github.com/dsbenghe/Novell. Directory.Ldap.NETStandard). Há um pacote nuget publicado. Estamos usando a biblioteca com o servidor OpenDJ LDAP (deve funcionar com qualquer servidor LDAP) - sem problemas em 1,5 meses de uso.

@dsbenghe , acabamos de compilar nossa biblioteca LDAP da Novell no netstandard, a nossa também contém paginação. Isso foi feito por @igorshmukler . Gostaria de comparar e colaborar? O nosso é WIP aqui https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Obrigado por seu trabalho na implementação do .NET Core.
Depois de obter o pacote nuget, criei o seguinte código para testar se a senha do ActiveDirectory do usuário está correta

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

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

E usa uma classe auxiliar simples para permitir que o aplicativo angular saiba o que está acontecendo

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

Para UWP, há uma solicitação para esse recurso em nosso UserVoice: https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cc @tquerec @jimuphaus que trabalhará no suporte do System.DirectoryServices para .NET Core.

Mal posso esperar! ETA? Especificações do projeto?

Quando finalmente for portado, teremos acesso a:

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

Eu sei que existem alguns pequenos defeitos nesse namespace, mas ainda é bastante útil.

@GARrigotti em testes, usando LdapDirectoryIdentifier geralmente é mais rápido que o 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;  
}

Existe um ETA? Eu poderia usar isso em um sistema que deve ser concluído no final deste mês ...

@johnkwaters existe alguma razão pela qual você não pode colocar o código AD em uma biblioteca de classes? Algumas pessoas (inclusive eu) tiveram problemas ao referenciar bibliotecas de classes herdadas em um aplicativo ASP.NET Core. Mas não há problemas se você criar o aplicativo Web e a biblioteca de classes no VS 2015 Update 3 e direcionar o .NET Framework 4.61 no aplicativo Web e na biblioteca de classes.

existe alguma razão pela qual você não pode colocar o código AD em uma biblioteca de classes?

Você quer dizer PCL seguido por "imports": "portable-net45+win8" em project.json para .NET Core TxM? Isso exigirá que Mono PCL Reference Assemblies esteja presente no Unix e não uma solução "pure donet-core", que concede autossuficiência no Unix. É um bom truque para silenciar o compilador, mas só funciona se o CoreFX BCL tiver a implementação correspondente. Como regra, o project.json sem "imports" para netcoreapp/netstandard1.x é sempre melhor. por exemplo https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Alguma atualização sobre um ETA? Onde posso ir para o autoatendimento dessa dúvida recorrente?

_Realmente_ ansioso por esse recurso!

Realmente ansioso para esse recurso também !!

Realmente ansioso para esse recurso também !!

Eu também estou precisando desesperadamente desse recurso!

Pessoal, vocês poderiam adicionar reações ao post principal?

Ou use as bibliotecas que foram colocadas no nuget por 2 pessoas separadas. Seu
todos OS. Se você não gostar do pacote, envie um PR

Em 8 de setembro de 2016 às 12h19, Mikhail Orlov [email protected]
escreveu:

Pessoal, vocês poderiam adicionar reações ao post principal?

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328, ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 para @jchannon Novell LDAP. Isso nos fez avançar e praticamente não fez alterações em nossa implementação do LDAP. Quero dizer que você está abstraindo corretamente certo ;)

Sim, acabei usando @jchannon Novell LDAP também, funcionou bem.

Se eu não disse isso antes, aqui está o ramo em https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Funciona bem para as nossas necessidades no momento...

@h3smith @johnkwaters qualquer problema sinta-se à vontade para levantar um problema 😄

Eu decidi tentar com a Novell, as amostras parecem boas o suficiente, mas não sei como expulsar (remover) o membro do usuário de um grupo com o Novell LDAP.
Não consigo alterar minha senha no MSAD LDAP porque não consigo ver userPassword e não foi definido no servidor LDAP.

Realmente preciso disso!

@joshfree ou qualquer outra pessoa que saiba...
Estamos procurando iniciar um novo projeto que precisa de acesso a ActiveDirectoryServices.AccountManagement Pergunta, A porta é direcionada para 1.1 ou 1.2?

Não faz parte do 1.1 (que está prestes a ser finalizado). @tquerec , você pode comentar sobre seus planos aqui?

cc: @danmosemsft

ASSIM, se não faz parte do 1.1 alguém tem um plano? Parece ser um grande problema não ter esse suporte. Claramente, a Microsoft iria querer essa integração.

Só mais um voto. Difícil fazer o investimento para construir sistemas de classe empresarial no .NET Core quando falta a funcionalidade empresarial fundamental. O projeto Novel funciona, mas não funciona.

Mais um voto. Vou repetir a mesma afirmação de que isso é essencial para a criação de qualquer aplicativo corporativo.

@nevcoBpalacio Acho que eles estão tentando nos empurrar para usar o diretório ativo do

Isso nunca funcionará para aqueles de uso com acordos corporativos que exigem que os serviços permaneçam em casa.

Eu tenho trabalhado para agências governamentais, tanto federais quanto agora em condados locais e, de qualquer forma, você ainda precisaria de alguma interface ou habilidades para integrar a algum serviço de diretório, seja baseado em nuvem ou no local. Eu co-desenvolvi aplicativos gerenciando bilhões de dólares e sempre surge alguma necessidade de serviços de diretório. Acho que isso é mais do que outra votação, mas sim uma declaração do que você está esperando? Concordo com uma postagem anterior que esta era originalmente uma solução pronta para uso em versões anteriores do .NET. Eu entendo que a estrutura mais aberta do CORE deve ganhar o impulso da comunidade e se é isso que a Microsoft escolhe esperar, talvez eles tenham falado isso e eu perdi, eles deveriam dizer para que alguém tome a iniciativa de investir tempo para fazê-lo.

Sim, adicione System.DirectoryServices ao .NET Core!

Temos planos de portar System.DirectoryServices.Protocols no próximo ano. Neste ponto, não posso fornecer uma data mais firme. Ainda não temos planos de portar System.DirectoryServices ou System.DirectoryServices.AccountManagement, mas estou interessado em avaliar o interesse. Existem recursos desses namespaces que as pessoas estão usando que não podem ser resolvidos com protocolos?

@tquerec Não estou familiarizado com protocolos. Temos um projeto para fazer o autoatendimento do Active Directory para fazer o desbloqueio de conta e redefinição de senha da conta. Usamos UserPrincipal no projeto e invocamos os métodos como FindByIdentity, UnlockAccount, SetPassword, ExpirePasswordNow,.
Não tenho certeza se isso pode ser feito em protocolos, mas parece que Protocols é uma implementação de nível inferior versus AccountManagement é uma abstração melhor para trabalhar com o ActiveDirectory.
Obrigado
Rockmeister

@nevcoBpalacio definitivamente deveria ser mais do que um voto que eu concordo. Eu acho que isso realmente precisa de mais prioridade.

@CalebMacdonaldBlack seria útil se você pudesse responder à pergunta @tquerec sobre padrões de uso e por que é necessário. Mais votos positivos ou "Concordo/é importante" sem cenários não ajudarão a aumentar a prioridade neste momento... Obrigado!

Nosso uso é escanear/pesquisar LDAP, fazer BIND para verificar credenciais, adicionar/remover objetos LDAP (usuários, grupos), modificar membros em grupos, etc.

@tquerec Eu realmente preciso de System.DirectoryServices.AccountManagement para poder autenticar nossos usuários no diretório ativo e autorizá-los em grupos aos quais eles têm acesso.

definitivamente concordo com h3smith .. nós precisávamos disso para v1 e em vez disso somos forçados a seguir o caminho Novel , que nós montamos juntos (especialmente os bits de replicação) e está nos causando sofrimento com a sobrecarga de manutenção etc. Isso está tornando o .NETCore fica ruim como efeito colateral ..

@liquidboy

precisávamos disso para v1

Você quer dizer .NET Core v1? -- isso é feito e enviado. Estamos trabalhando em 1.2 agora. Ou você quis dizer algo diferente?

em vez disso, são forçados a seguir o caminho do romance

O que isso significa? (Desculpe, não tenho contexto nenhum no DirectoryServices, mas adoraria entender o que estamos perdendo do ponto de vista dos cenários)

@karelz basta fazer uma pesquisa neste tópico pela palavra "romance" e você verá o que quero dizer. Outro dev (dsbenge) da minha equipe comentou (junto com outros) sobre a lacuna que nos levou a usar o novel. [aqui está o link para o comentário acima https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

E sim, eu quis dizer .NET Core v1 que já foi lançado, estamos trabalhando em nossa solução há mais de um ano e precisávamos de uma boa solução DirectoryServices naquela época. .

@liquidboy obrigado pelo link - se estiver em Mono, devemos poder reutilizar o código-fonte no .NET Core AFAIK. @tquerec dado o interesse, é algo que sua equipe consideraria?

@tquerec : Precisamos do seguinte:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory e System.DirectoryServices.Protocols.

Eles são necessários para conectar e gerenciar usuários, grupos e atributos do Active Directory (e outros servidores LDAP), como descrito nas respostas acima. É importante ter esses recursos no .Net Core!

Eu concordo com os outros. Eu preciso disso para portar qualquer um de nossos aplicativos que são autenticados no ActiveDirectory para o .NET Core. Isso é bastante fundamental, definitivamente deve ser lançado o mais rápido possível. É o bloqueador para portar tantas coisas.

A página de roteiro do .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) tem este plano para o .NET Core 1.2: "trazer o .NET Core à paridade com o .NET Framework e o Mono para um grande coleção de tipos básicos."

Eu acho que a portabilidade de System.DirectoryServices se encaixa muito bem nesse plano, e deve realmente fazer parte da versão 1.2. Apenas os meus 5 (euro) cêntimos :)

Apenas para esclarecer: as APIs portadas em 1.2 foram escolhidas com base em dados de uso (e raramente complexidade) - @weshaggard @danmosemsft você pode entrar em contato com detalhes, por que não incluímos System.DirectoryServices?

A lista de assemblies que escolhemos para corresponder está aqui . @weshaggard terá que me lembrar como ele escolheu essa lista. (Mono tem S.DirectoryServices)

Acredito que você será capaz de fazer praticamente tudo o que for necessário para falar com o ActiveDirectory (e outros servidores ldap) usando System.DirectoryServices.Protocols, mas muitas pessoas terão que reescrever seu código para usar S.DS.Protocols.

Pessoalmente, prefiro MS para portar S.DS.Protocols e MS ou a Comunidade para criar uma biblioteca fácil de usar para gerenciamento de usuários/grupos em cima disso.

A lista de assemblies que escolhemos para combinar está aqui. @weshaggard terá que me lembrar como ele escolheu essa lista. (Mono tem S.DirectoryServices)

A propagação inicial foi feita a partir da interseção de perfis do Xamarin com o .NET Framework. Perfis Xamarain (que é um subconjunto de mono) não suportam DirectoryServices e é por isso que isso não estava na interseção.

O que podemos fazer para argumentar que isso deveria estar? A incapacidade de usar o esquema de autenticação mais comum em aplicativos da Microsoft é um pouco bloqueador, não? O foco está no Azure aqui e no AAD? Ou o bloqueador que portar isso entre plataformas é uma grande incógnita dos protocolos?

Existe uma maneira de aumentar a prioridade aqui? 2.0 está muito longe, e isso é realmente lamentável se _tudo_ mais funcionar, mas não podemos autenticar usuários. Esta é a porta de entrada virtual para muitos aplicativos. IMO, em termos de prioridade é um pouco diferente porque não é um bloqueador parcial, mas muitas vezes um bloqueador completo por natureza.

Não acho que haja discordância de que queremos oferecer suporte a isso no .NET Core, que é diferente de fazer parte do .NET Standard, é apenas uma questão de quando. @tquerec é dono da área e seria o único a falar sobre isso.

Alguém da .NET Foundation perguntou, mas os namespaces que estamos usando especificamente são:
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

Então, @tquerec , como obtemos System.DirectoryServices sinalizados para .NET Core 1.2 ? Pelo menos System.DirectoryServices.Protocols. Isso é possível?

Muito obrigado!

[atualizado com mais informações de @tquerec]
Eu me encontrei com @tquerec na segunda-feira. Devo a todos uma redação. Em poucas palavras:

• Sistema. DirectoryServices é viável apenas no Windows (ele chama a DLL do Windows onde toda a implementação reside), totalmente desconhecida para Linux/Mac
• System.DirectoryServices. AccountManagement fica em cima dele, então também é viável apenas para Windows e desconhecido para Linux/Mac
• System.DirectoryServices. O ActiveDirectory é viável apenas no Windows (ele chama muitas APIs específicas do Windows)
• System.DirectoryServices. Os protocolos devem ser razoavelmente simples para Windows e mais trabalhosos para Linux (precisamos encontrar uma biblioteca LDAP para usar).
  Estamos tentando descobrir com @tquerec como financiar o trabalho - idealmente para 1.2, mas ainda sem promessa. Espero que a decisão leve pelo menos duas semanas.

Perguntas a todos :

• O escopo somente do Windows acima é aceitável para os principais casos de uso? (Sys.DirSer e Sys.DirSer.AccountManagement e Sys.DirSer.ActiveDirectory)
• Se o Sys.DirSer.Protocols Linux vier pós-1.2 ou depender de contribuições da comunidade, isso seria um grande bloqueador?

@karelz System.DirectoryServices.ActiveDirectory é baseado em um grande número de APIs específicas do Windows, portanto, cai no mesmo bucket que S.DS e S.DS.AM.

@karelz Não tenho certeza do que você quer dizer com uma solução apenas do Windows para 1.2. Já temos uma solução apenas para Windows que funciona.

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

@rock-meister quero dizer .NET Core. O que você mencionou tem como alvo o .NET 4.5.2+ "completo".

Sim, o suporte somente para Windows é um grande desbloqueador para nós. Podemos fazer todo o trabalho para a portabilidade do .NET Core e expandir os suportes de plataforma "de graça" posteriormente, quando os bits subjacentes o fizerem. Direito não o bloqueador mesmo _starting_ a porta é enorme. Que se foi é uma grande vitória.

Sendo uma loja do Windows, isso seria uma grande vitória aqui também. Tantas grandes empresas considerariam isso uma grande vitória! Obrigado por manter-se atualizado com suas informações. Mantenha-nos informados. Obrigado.

@karelz Obrigado pelo esclarecimento. Sim, o escopo somente do Windows para 1.2 funciona para nós.
Rockmeister

System.DirectoryServices.Protocols com suporte a Linux/LDAP é a maior prioridade para o trabalho que fazemos.

ps o escopo somente do Windows parece contrário aos objetivos de .netcore / .netstandard

Passamos de System.DirectoryServices para System.DirectoryServices.Protocols um tempo atrás para que pudéssemos oferecer suporte a servidores LDAP não AD. Ter acesso ao namespace Protocols seria um passo mais próximo de nos permitir portar nosso código para o .NET core.

No entanto, se isso for específico da plataforma, haverá menos uso para nós. Um ponto principal de querer migrar para o .NET core é a portabilidade da plataforma. Provavelmente ainda teremos que esperar por isso.

Para nós, chegar ao .NET Core foi a capacidade de aproveitar o Docker e ser totalmente independente de plataforma. Portanto, ficar preso apenas ao suporte LDAP do Windows não seria benéfico.

Obrigado por discutir internamente.

Meu voto vai com rota independente de plataforma 🦃

Eu tenho que concordar com o comentário agnóstico da plataforma, por mais que doa que eu não possa usar o core até que isso seja realizado. Eu acho que isso é algo que precisa ser revisto em um nível mais alto. A coisa que eu não entendo é a complexidade do conceito? Existem várias soluções de diretório, AD, Novell, etc... Isso exige uma solução de interface multiplataforma (agnóstica)... Boas Festas!

Embora pessoalmente eu pudesse viver perfeitamente bem com um escopo somente do Windows, na minha opinião isso quebra a ideia do .NET Core e sua portabilidade.
Uma solução independente de plataforma deve ser o caminho a ser focado.

Sim, de acordo, o .NET Core deve ser multiplataforma e os recursos/APIs devem funcionar em todas as plataformas suportadas!
Portanto, se System.DirectoryServices.Protocols for portado/implementado primeiro, ele deve funcionar também no Linux.

Concordo que idealmente uma solução independente de plataforma deve ser o objetivo. Embora ainda não tê-lo no Windows seja um bloqueador para muitos desenvolvedores que querem apenas experimentar a plataforma em um ambiente corporativo (AD), como eu. É por isso que eu gostaria de uma solução apenas para Windows por enquanto.

Eu gostaria apenas de entrar na conversa e dizer que estou bem com uma solução somente para Windows até que algo multiplataforma possa ser montado.

Eu imagino que 99,9% dos desenvolvedores que precisam se conectar ao Active Directory estão fazendo isso em um ambiente corporativo onde estão desenvolvendo em caixas Windows.

Estamos discutindo o financiamento do nosso lado (esperamos atualização em ~ 2 semanas), isso é atualmente a principal prioridade das APIs que ainda não fazem parte do .NET Standard 2.0.

Existem pessoas ao redor que estariam dispostas a ajudar/contribuir com a implementação do Windows e/ou implementação do Linux? (podemos inserir o código do Desktop e exigiria mais massagens para construir + alguns testes)

@karelz Eu adoraria contribuir para o lado Linux das coisas. Precisamos desse suporte para autenticação Windows e não Windows (on-prem). Este é um bloqueador para nós, e estamos visando o .NET core para nosso projeto de plataforma cruzada (anteriormente era Mono no lado Linux e .NET no lado Windows).

Gostaria de ajudar onde pudermos, sem dúvida.

Eu adoraria ajudar, mas tenho certeza que vocês são muito mais experientes do que eu e eu não seria de alguma utilidade.

@karelz @tquerec Ficarei feliz em ajudar nos testes no Windows e, no futuro, no Linux. Eu me inscrevi no tópico, então responda aqui ou me mencione para entrar em contato quando precisar que eu me envolva. Obrigado por seu trabalho sobre isso. Ele é esperado há muito tempo e, mesmo que seja incremental, será um bom passo para uma maior adoção do .NET Core.

Eu acho que "Windows estendido" é um bom alvo inicialmente, "estendido" significando que ele funciona em NanoServer e em Containers (ou seja, máquinas não ingressadas no domínio que não podem executar o .NET CLR completo). Isso lhe dará uma vitória rápida e um ponto de partida para trabalhar de trás para frente para implementá-lo em outros servidores.

Trabalhamos com @tquerec e nossas cadeias de gestão para descobrir a melhor maneira de desbloquear esse trabalho o mais rápido possível. Infelizmente, não temos ninguém livre antes do final de janeiro, então tentaremos fazer o nosso melhor enquanto isso para desbloquear as contribuições da comunidade com recursos limitados e algum trabalho voluntário do nosso lado ( @ianhays @tquerec e @karelz).

Aqui está o que planejamos fazer:
@ianhays nos ajudará a iniciar o projeto no repositório CoreFX (adicionar algum código-fonte, mostrando exemplos de como fazê-lo, aconselhar sobre a configuração de compilação, empacotamento, preparar o projeto para futuras portas Linux/Mac, etc.).
Começaremos com a implementação somente do Windows (contribuições são bem-vindas). Não faremos nenhuma alteração funcional na implementação ou na superfície da API neste momento, a menos que sejam necessárias para a porta para o .NET Core.
A próxima etapa (potencialmente paralela) será adicionar testes. Devemos iniciar a discussão com @tquerec sobre o design de teste existente (.NET Framework de código fechado) se houver algo que possamos aproveitar ou se tivermos que começar do zero.
Mais tarde, podemos nos concentrar nas portas Linux/Mac.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte, e qualquer outra pessoa interessada, ficaremos felizes em receber suas contribuições assim que @ianhays começar o esforço (ETA: meados da próxima semana, eu acho). Se você tiver alguma dúvida, ou sugestão, por favor nos avise.

Este trabalho também permite que bibliotecas como SqlClient executem a autenticação do Windows ao serem executadas no Linux, mas se conectando a um SQL Server que requer autenticação do Windows?

Esse é um dos meus obstáculos para poder portar coisas para o .NET Core rodando no Linux. Todos os nossos servidores Microsoft SQL corporativos permitem apenas a conexão por meio de um Service ID (não interativo) que está no AD.

blgmboy. Seu problema é um excelente exemplo de por que as coisas precisam ser "examinadas" para garantir a verdadeira compatibilidade entre plataformas com os novos modelos sugeridos. Se você tiver mais cenários, acho que seu ambiente é um bom exemplo de como as coisas precisam se cruzar e você deve listar quaisquer outros problemas que esteja tendo com a parte AD do Core.

Sim, eu definitivamente manterei este tópico em mente e compartilharei qualquer coisa que eu encontrar. Só queria que todos soubessem que este é um grande obstáculo para empresas com farms SQL que possuem segurança estrita, conforme descrito.

Também é um impedimento para usar algo como o EF Core que, em última análise, teria o mesmo problema.

System.DirectoryServices agora está mesclado no CoreFX. A próxima etapa é compilar para .NET Core - Windows e adicionar testes.

Obrigado Ian. É bom ver alguma tração nesta questão!

Obrigado Ian!

Plano de execução atualizado: EDIT: movido para a postagem mais importante nesta edição para melhor descoberta

Se alguém estiver trabalhando em alguma etapa, mencione-a e coordene aqui para evitar esforços duplicados. Vou co-atribuir o problema a você também.

Os namespaces System.DirectoryServices contêm uma funcionalidade tão importante para aplicativos corporativos do Windows no local, tão bom ver algum progresso nesse problema. Mantenha o bom trabalho.

Eu consertei as fontes e o System.DirectoryServices agora está sendo construído. Devo enviar um PR em breve.

Obrigado @tquerec por contribuir com a segunda rodada!
Existem voluntários para ajudar com os 2 namespaces ou testes restantes? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 tem um PR aqui https://github.com/dotnet/corefx/pull/15324 para adicionar mais suporte e obter a construção de Protocols/AccountManagement.

Para o que vale a pena, eu tenho experimentado com System.DirectoryServices.Protocols recentemente e descobri que muitos cenários simples de System.DirectoryServices não são difíceis de imitar com System.DirecotryServices.Protocols. Com base nisso, acho que fazer com que o S.DS e o S.DS.AM funcionem em plataforma cruzada pode ser uma prioridade mais baixa, pois um System.DirectoryServices.Protocols de plataforma cruzada pode ser uma solução alternativa útil para muitos usuários.

Obviamente, isso significa que fazer com que System.DirectoryServices.Protocols funcione como uma solução LDAP de plataforma cruzada continua sendo uma alta prioridade.

Estou lendo o pull request certo? Parece que isso foi aceito há alguns dias, então, se construirmos a partir do código-fonte, poderemos experimentá-lo?

Sim, acho que temos toda a construção do DirectoryServices, porém não temos nenhum teste - o que nos impede de enviar o pacote como estável e de melhorias no código base (correções de bugs, aprimoramentos, etc.).
Se você puder tentar compilar a partir da fonte, isso seria ótimo. Se você (ou qualquer outra pessoa) quiser nos ajudar a adicionar testes ou iniciar a porta do Linux, seria ainda melhor :)

Olá a todos,

Estamos nos preparando para iniciar um projeto corporativo que requer suporte ao Active Directory, pois somos 100% internos ao nosso domínio. Alguém pode fornecer o status desse problema e as expectativas para a próxima versão principal? Peço desculpas, mas sou novo na comunidade do GitHub e ainda não entendo todas as várias terminologias e informações de status.

Seria ótimo usar o Active Directory para associação em vez de um modelo de identidade totalmente separado que precisaria ser gerenciado separadamente e também causar incompatibilidade de dados.

Desde já, obrigado!

@karelz para essa pergunta, mas acho que a resposta é que isso não é esperado atualmente na versão 2.0, pois não temos um desenvolvedor agendado para isso. Contribuições da comunidade são bem-vindas. ele não precisa enviar _in_ a versão 2.0, ele pode sair no NuGet a qualquer momento em que estiver pronto para envio.

Perfeito! Você respondeu minha pergunta.

Obrigado.

@nevcoBpalacio algum interesse em

Eu tenho interesse, especialmente com esse tópico, pois sei que ele impede muitos de irem para o núcleo com soluções corporativas. No entanto, temos um trabalho em torno e não consigo encontrar o tempo do dia (noite com crianças) para isso. Vou tentar reorganizar meu sistema em casa para trabalhar com o GitHub. Eu aprecio você perguntar embora! Obrigado.

Nevcobpalacio, se você usa o vs17 e não requer cross plat, você pode se aproximar um pouco do que deseja usando o modelo principal do aplicativo da Web direcionado à estrutura .net completa e ref a dll system.directoryservices.accountmanagement à moda antiga e role seu próprio middleware para fazê-lo nesse meio tempo. Pelo que vi, o mesmo código deve ser transferido para direcionar o .net core assim que estiver disponível, exceto que você usará o pacote nuget e descartará a ref. Espero que esta informação ajude a colocar seu projeto nos trilhos.

@los93sol obrigado por essa sugestão. Nossas discussões iniciais são para construí-lo de forma semelhante a essa sugestão e torná-lo um módulo de software intermediário que podemos "cortar" para qualquer coisa que pousar no Nuget mais tarde. Muitíssimo obrigado!

Tenho que comentar e elogiar esta sugestão. Eu estava cético no início sobre essa mudança para o núcleo. No entanto, com essa abordagem da comunidade, discussões como essa vêm à tona e nos ajudam a resolver as coisas durante essas grandes mudanças.

Obrigado.

Alguém está trabalhando atualmente na adição dos testes ausentes ou na portabilidade de System.DirectoryServices.Protocols para Linux/Mac?

@pasikarkkainen AFAIK não há um esforço ativo no momento das equipes da Microsoft (que pode ou não mudar no futuro próximo). Também não vi ninguém da comunidade começando a trabalhar nisso.
Você está interessado em contribuir, ou apenas curioso sobre o status?

@karelz Parece que eles estão direcionando os DirectoryServices para a versão .NET Core 2.0 neste verão.

Citação de @shanselman

AD – Totalmente, esta é uma lacuna SE você quiser chamar o LDAP diretamente. Você certamente pode autenticar no Windows Auth AGORA. Planejamos ter especificamente o namespace DirectoryServices para Core 2.0 no período de verão

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

Sim, isso está de acordo com as discussões de corredor que ouvi. Eu só não tinha certeza se é informação pública e quanto (e quem) se comprometeu com isso. Eu acho que é seguro dizer, está sob forte consideração e é provável que aconteça. Deixei os proprietários @shanselman e DirectoryServices comentarem sobre as linhas do tempo.

@karelz : Obrigado pela atualização! Eu estava mais curioso sobre o status .. Eu definitivamente posso ajudar com os testes, pelo menos, quando isso estiver disponível.

@pasikarkkainen se você também estiver disposto a ajudar a escrever alguns casos de teste, isso seria muito apreciado.
Se você "apenas" quiser testar o pacote em seu aplicativo/código, isso deve ser possível hoje. Só precisamos começar a publicar o pacote como preview no myget (acho que a publicação está desabilitada hoje).

@karelz Eu não me importaria de ajudar especificamente na implementação do Mac. Tenho pouco conhecimento, então não tenho certeza de quão bem posso contribuir. Eu fiz pesquisas sobre isso e há uma biblioteca de romances que as pessoas parecem sugerir. Encontrei a implementação de outra pessoa em torno dessa biblioteca novell aqui: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt O autor do pacote já o mencionou aqui.
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

Então, isso é algo que estará no núcleo 2.0? Estou um pouco confuso quanto ao status dele.

Não, ele não fará parte do .NET Core 2.0, no entanto, na conferência Build, prometemos a disponibilidade do pacote durante o verão. O pacote (Windows) deve estar disponível em cima do .NET Core 2.0, na época em que o .NET Core 2.0 for lançado.
No momento, estamos trabalhando para disponibilizar os pacotes como visualização no branch master (#18090) e trabalhando em ativos de teste em paralelo (#20669).

Receberemos erros de compilação quando direcionarmos o tempo de execução compartilhado ou um tempo de execução não Windows? Ou vamos acabar com a armadilha PlatformNotSupported ?

Será um pacote autônomo sem nenhum ativo que não seja do Windows. A compilação deve quebrar. @ericstj pode confirmar.

Você não receberá erros de compilação, eles serão exceções "PlatformNotSupported" de tempo de execução.

Sim, é o antigo - bloqueamos as pessoas que o usam nas bibliotecas .NET Standard ou transformamos erros de tempo de compilação em exceções PlatformNotSupported? ... Felizmente, existe um meio-termo: as ferramentas ApiCompat lhe dirão com antecedência que você está usando algo que não está em todos os lugares.

Estou recebendo o seguinte erro ao tentar o pacote System.DirectoryServices no projeto netstandard 1.6:

Pacote de instalação : O pacote System.DirectoryServices 4.0.0 não é compatível com o netstandard1.6 (.NETStandard,Version=v1.6). O pacote System.DirectoryServices 4.0.0 suporta: net (.NETFramework,Version=v0.0)

Existe alguma solução ou solução para isso?
Cumprimentos,
Varun

@vrn11 este pacote é de outro fornecedor e só suporta full net framework

De qualquer forma queria perguntar se há uma atualização sobre isso. Talvez um pacote de pré-visualização que possamos pegar no myget? Seria incrível testar isso

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

Como @MarcusKohnert mencionou, você pode pegá-los em https://dotnet.myget.org/F/dotnet-core/api/v3/index.json. Há System.DirectoryServices, System.DirectoryServices.AccountManagement e System.DirectoryServices.Protocols.

Impressionante! obrigado a @MarcusKohnert e @ericstj pelos links!

Estou tentando os pacotes do myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
Ao executar em um MacOS 10.12.6 e ao executar:

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

Estou entendendo:

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

Espera-se que o PrincipalContext funcione em um Mac?

@bruno-garcia não há implementação no CoreFX no momento para DirectoryServices, exceto no Windows. @karelz teria que falar sobre planos/aspirações, se houver.

Apenas System.DirectoryServices.Protocol é potencialmente viável para x-plat (ainda não implementado) - veja detalhes em algumas das minhas respostas acima e no post principal.

Fazer com que o System.DirectoryServices.Protocols funcione em várias plataformas (também no Linux/Mac) é importante. funciona no Windows?

Se eu entendi corretamente, System.DirectoryServices será difícil de fazer xplat devido a muitas dependências nas interfaces ADSI COM, que estão disponíveis apenas no Windows.

System.DirectoryServices.Protocols ainda deve ser possível fazer o xplat executar.

Executando o mesmo código que mencionei antes:
``` c#
using (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

Em um Win7 x64 com .NET Core 2.0 produz:

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)

Usei os pacotes:

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

[EDIT] Corrigido destaque de sintaxe de código xml/C# e pilha de chamadas por @karelz

@bruno-garcia, arquive o problema separado. Este está rastreando o esforço geral da porta, não bugs/diferenças particulares. Obrigado!

@bruno-garcia que é rastreado por https://github.com/dotnet/corefx/issues/23605

O próximo passo pode ser depurar por meio da área de trabalho e ver onde o comportamento diverge. Vou tentar liberar um dev para dar uma olhada.

Mesmo problema no servidor 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)

O que você acha, quando vai funcionar?

tem um problema ao tentar instalar um pacote

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

===============================================
Se alguém tiver o mesmo problema que eu, use o .NET CLI

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

@papamamadoii é porque você está perdendo https://dotnet.myget.org/F/dotnet-core/api/v3/index.json como fonte e aparentemente o Install-Package não usou seu feed especificado para encontrar dependências. Você pode querer registrar um bug em http://github.com/nuget/home com etapas de reprodução específicas.

@karelz Se estou entendendo os comentários corretamente, isso não está funcionando em implantações baseadas em Linux?

@euclid47 System.DirectoryServices.* não é suportado atualmente no Linux. Conforme discutido acima, partes dele poderiam ser portadas se houver interesse/participação suficiente da comunidade.

@danmosemsft Não entendo como você não consegue ver este tópico inteiro aberto desde outubro de 2015 como interesse suficiente da comunidade. Se eu possuísse o conjunto de habilidades necessário para escrever algo tão complicado quanto uma camada de comunicação LDAP, já estaria trabalhando nisso, pois o AD era um dos principais mecanismos de autenticação em um ambiente corporativo. Ressaltarei que, para a maioria das grandes empresas, a incapacidade de realizar esses tipos de interações no Linux literalmente anula o propósito do Core e fará com que elas se atenham às compilações pré-core do dotnet, limitando assim sua preciosa interação com a comunidade.

@danmosemsft Além disso, se você literalmente não planeja trabalhar nisso, apenas informe a comunidade definitivamente para que outros desenvolvedores possam pegar as peças.

@shairozan até agora, notamos 7 votos de 54 que consideram DirectoryServices no Linux como prioridade mais alta que o Windows - consulte https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
Há também outras vantagens que os desenvolvedores obtêm do .NET Core além do x-platform (embora eu concorde que o x-plat seja um dos principais motivos).

Eu recomendaria primeiro terminar o lançamento do pacote apenas para Windows, então podemos abrir um novo problema para rastrear o interesse pela porta Linux com mais precisão.

Já dissemos à comunidade que estamos procurando ajuda e o problema está marcado para ser obtido - consulte https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. E @hughbe ajudou com a primeira rodada de testes para DirectoryServices - veja o histórico aqui , aqui e aqui .

@karelz Onde a votação é gerenciada para esses componentes? Posso garantir que após o SELF / POSSCON você verá um aumento bastante drástico no interesse.

@karelz Onde está a votação para esse recurso? Concordo absolutamente com @shairozan com a necessidade. Há um comentário nesta edição que descreve nosso ambiente de desenvolvimento e produção. É bastante chocante que não tenha havido nenhum movimento na implementação desde que os evangelistas do .Net Core pregam que é agnóstico de plataforma.

Criei um novo problema para rastrear a porta Linux/Mac dotnet/corefx#24843 para facilitar a votação do que no comentário no meio deste problema (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

Eu adicionei o link também no post principal desta edição.

@euclid47 a votação até agora foi nesta questão - veja os links acima. Foi isso que resultou nos 7 votos (+1 para o remetente original da edição).

Nossa equipe precisa de suporte a LDAP no Linux.
Porque a maioria de nossos clientes usa autenticação via LDAP.

@balkarov Se puder, vote no problema que o @karelz acabou de criar ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 Se você ainda não sabe, existe o pacote Nuget Novell.Directory.Ldap.NETStandard que você pode usar para integrar o LDAP em seus projetos. Não somos usuários LDAP avançados, apenas o usamos para validar credenciais e obter informações do usuário, mas funciona bem para nós, tanto na versão 1.0 quanto na 2.0 em execução na imagem docker runtime dotnet core. Não é uma maneira oficial, mas faz o trabalho até que haja uma porta multiplataforma de System.DirectoryServices .

@OskarKlintrot obrigado. Mas esta biblioteca não suporta login sem domínio.
Eu crio um problema https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
Você pode me ajudar a resolver esse problema?

Não faço parte desse projeto nem sou usuário avançado, mas vou dar uma olhada, nos vemos lá!

(Não estamos logando com um domínio)

Dado que @karelz apresentou um problema para o Unix, renomei este para maior clareza.

@danmosemsft mas o problema tem plano
Portas Linux/Mac.

@balkarov Atualizei o plano para vincular a outros problemas de rastreamento e removi as caixas de seleção para itens que são rastreados separadamente (trabalho interrompido) ou não bloqueiam o trabalho do Windows.

A porta System.DS será compatível com servidores RODC (controladores de domínio somente leitura)?

@PKGeorgiev você deve obter o mesmo suporte System.DirectoryServices que temos na estrutura completa.

O trabalho no DirectoryServices for Windows está concluído, encerrando o problema.
Observação:

• A publicação final do pacote é rastreada por dotnet/corefx#24909
• A porta Linux/Mac é rastreada separadamente por dotnet/corefx#24843

Oi, isso funciona em UWP?

Oi, isso funciona em UWP?

Não, há suporte apenas para aplicativos net core executados no Windows e na estrutura completa. se você usá-lo em UWP ou no Linux, receberá uma exceção PlatformNotSupported.

Estou usando este código em uma função lambda na AWS que roda no Linux em segundo plano e estou recebendo este erro. "System.DirectoryServices.AccountManagement não é compatível com esta plataforma."
Estou usando o core 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 Sim, isso ainda não é suportado no Linux. É suportado apenas no Windows.

@sscoleman existe um problema criado nele, https://github.com/dotnet/corefx/issues/24843. Foi dito que não havia interesse suficiente da comunidade, com a exceção de que essa pergunta surge o tempo todo. Então agora você está em um lugar de merda. Você gastou tempo implementando serviços de diretório e então descobriu que o Linux é suportado. Agora você se pergunta por que isso está sendo apresentado como agnóstico de plataforma se existem recursos apenas do Windows.

É bastante óbvio se você olhar para a estratégia maior da Microsoft. A Microsoft está lançando TODOS os seus recursos de desenvolvimento no Azure, e isso inclui o Active Directory. Confira "O que há de novo em 2016", é principalmente investimentos AzureAD/Hybrid. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

A Microsoft não está investindo nessa biblioteca para Linux porque deseja que todos migrem para o Azure AD. Faz sentido, por que você investiria em algo que você está tentando fazer com que os clientes se afastem?

Você está fazendo algo relativamente simples embora. Você pode usar as bibliotecas Novel LDAP, elas funcionam com AD e no .NET Core para Linux. Você precisa fazer o protocolo funcionar sozinho, mas não é muito complexo, e há muitas amostras por aí. A desvantagem é que você precisa gerenciar a vinculação, o que requer um DN de usuário e uma senha.

System.DirectoryServices é atualmente uma API somente do Windows e faz parte do Windows Compatibility-Pack for .NET Core . Em princípio, podemos fazer com que partes de System.DirectoryServices funcionem no Linux, mas ainda não temos recursos para fazer isso. dotnet/corefx#24843 está rastreando este item de trabalho.

Por que estamos permitindo a instalação de pacotes que não funcionarão no Linux? A alternativa seria bifurcar a superfície da API, mas isso também não funciona bem para todos os casos e torna o sistema geral mais difícil de codificar. Obviamente, nossa escolha também não é isenta de problemas, pois pode dificultar a previsão se o código funcionará em várias plataformas ou. Temos uma prévia de um analisador de compatibilidade que fornece feedback ao vivo à medida que você codifica.

Veja este vídeo para obter mais contexto sobre como vemos o Pacote de Compatibilidade do Windows e o analisador de plataforma cruzada trabalhando lado a lado:

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

@thedevopsmachine

A Microsoft não está investindo nessa biblioteca para Linux porque deseja que todos migrem para o Azure AD.

Não é assim que eu vejo. Como você apontou, pretendemos ganhar dinheiro via Azure. E o Azure é uma plataforma em nuvem que oferece uma ampla variedade de tecnologias e sistemas operacionais. Não temos interesse comercial em promover o Windows na nuvem em vez do Linux na nuvem. Mas é claro que o .NET tem uma forte presença no Windows há 15 anos. Tornar as coisas totalmente funcionais em todos os sistemas operacionais leva tempo, mas honestamente acho que a maioria das pessoas que seguem nossos esforços de código aberto pode ver que não estamos limitando o Linux de propósito. Só leva tempo.

eu concordo com a abordagem de ter uma api x-plat e x-framework consistente, mas é destruidor de almas sempre que encontro esse temido erro .. eu sinto por @sscoleman ...

Este pacote DirectoryServices pode funcionar no CentOS 7?

Este pacote DirectoryServices pode funcionar no CentOS 7?

O pacote pode ser instalado, mas não funcionará. ao usá-lo, você obterá uma exceção de plataforma não suportada. estamos procurando como podemos oferecer suporte a serviços de diretório em geral no Linux. isso está no nosso radar.

Isso realmente precisa de suporte linux

CC @joperezr

@niemyjski veja dotnet/corefx#24843

Isso realmente precisa de suporte linux

.. além de poder rodar em um container docker. Imho é uma dor de cabeça que é preciso voltar para a antiga implementação do diretório Novell quando se quer usar .NET Core 2+ no linux.
Obrigado de qualquer maneira por trabalhar nisso!

Por que encerrar este assunto? System.DirectoryServices.AccountManagement ainda não está no .NET Core fora do 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]

reabrir 14734

@tarekgh ainda no radar?

reabrir 14734

@JustinGrote qual é a funcionalidade exata que você deseja para o cenário? DirectoryServices é enorme e duvido que toda a funcionalidade possa ser suportada em apenas uma versão. Ter solicitações específicas pode ajudar melhor do que apenas solicitar que todas as bibliotecas do DS sejam suportadas. No .NET 5.0, habilitamos um cenário https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
Eu não sabia que o System.DirectoryServices.Protocols havia sido portado, mas parece que ainda tem uma dependência do security.principal.windows, funciona no linux mesmo com isso (via autenticação básica etc.) erro de montagem?

O objetivo é reimplementar algo como o módulo ActiveDirectory Powershell para ser xplat, eu estava considerando o novo módulo ldap ou ldap4net para esse propósito se não houvesse pelo menos suporte básico de interação disponível.

A implementação do ActiveDirectory Powershell é provavelmente um caso de uso muito grande. Deixe-me compartilhar meus dois casos de uso:

1) Estou derivando do UserPrincipal, pois preciso de atributos que não são suportados imediatamente. Eu segui https://stackoverflow.com/questions/24798037/extend-userprincipal-class e acho que isso é uma espécie de padrão na antiga estrutura .NET, e fazer essa abordagem funcionar provavelmente ajudará mais desenvolvedores.

2) Eu também tenho um código como o seguinte:

`

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

`

Não faço ideia do que já é suportado hoje, a última vez que verifiquei foi em fevereiro.
Obrigado, Joaquim

@ jol64 você não pode conseguir o mesmo usando os protocolos?

@ jol64 você não pode conseguir o mesmo usando os protocolos?

Provavelmente eu posso. Reescrevi algumas coisas para usar a biblioteca Novell. Mas requer uma reescrita e, portanto, um código redundante para meu código de estrutura .NET existente. Definitivamente, prefiro evitar uma divisão de código de todo o código, e tenho certeza de que outros também não gostam da ideia.
Também estou querendo saber como funciona a autenticação. Com Novell (a versão antiga que eu tentei) eu tenho que especificar credenciais, enquanto que com meu código existente eu não preciso.
Obrigado, Joaquim