@vibronet

¿Hay alguna actualización sobre esto?

Yo también quisiera una actualización sobre esto. Mi empresa me pide que cree una nueva aplicación que requiere la capacidad de consultar Active Directory a través de LDAP, pero parece que esto no es posible actualmente. ¿Hay soporte planificado para él, se está descartando a favor de otra cosa, o ya está funcionando pero no está documentado en ninguna parte?

Sería genial tener una nueva mirada a la implementación de la compatibilidad con LDAP y Active Directory en .NET CoreFX.

Realmente necesitamos una solución de Active Directory/LDAP que podamos aprovechar en .NET Core. Ya sea una implementación de hoja limpia o un puerto de System.DirectoryServices no me importa tanto. Hay muchas aplicaciones de Windows centradas en los negocios que necesitan absolutamente la autenticación AD, y la autenticación LDAP sería una excelente característica para los desarrolladores multiplataforma.

Estoy de acuerdo con las notas anteriores compatibles con versiones anteriores: realmente no creo que se necesite un puerto directo, solo necesitamos una forma de acceder a la autenticación (y realizar otras acciones: buscar, desbloquear, eliminar, etc.) contra Active Directory o cualquier proveedor LDAP .

@NickCraver

Realmente no creo que se necesite un puerto directo, solo necesitamos una forma de acceder a la autenticación [...] contra Active Directory

Es bueno saberlo. No lea demasiado en mi etiqueta de puerto a núcleo que acabo de aplicar. Es solo mi forma de rastrear las brechas en la oferta de .NET Core que impide que los clientes como usted transfieran su aplicación a .NET Core.

@terrajobst Lo tengo . No creo necesariamente que este tenga que ser un elemento 1.0 debido a su modularidad (y _suena_ como si estuviera programado para después de RTM de todos modos), pero lo espero con ansias. Será un obstáculo para la migración de Opserver para mí, así que feliz de participar en las discusiones de API si podemos ser de utilidad. Tenemos una amplia gama de casos de uso en el lado del administrador de sistemas que pueden ser útiles, ping si puedo ayudar.

Solo para lanzar otro sombrero al ring. Por el momento, este es el mayor bloqueador que me queda también. Simplemente ser capaz de autenticar sería de gran ayuda por ahora.

¿Podemos obtener una respuesta oficial de alguien del equipo de desarrollo sobre los planes para esto, si es que hay algún plan para apoyar esto?

Realmente no siento que se necesite un puerto directo

¿Por qué? Lo siento, estoy confundido. ¿No sería esa la solución más fácil para todos y de acuerdo con el principio DRY?
Sin embargo, si hay una razón para escribir toda la API desde cero, cierta coherencia con la API antigua (firmas del mismo método) sería menos confusa para el consumidor.

@ jasonwilliams200OK déjame aclarar, realmente quise decir DirectoryServices.ActiveDirectory específicamente. Creo que la autenticación y todo lo que la rodea: por ejemplo, la pertenencia a un grupo es el caso de uso del 95-99% del espacio de nombres. Creo que un puerto directo de firmas de _eso_ es bastante útil. Si el resto justifica el cambio por alguna razón, estaría bastante bien con eso, y está bien si llegara más tarde... la autenticación sería buena para salir lo antes posible, ya que es un bloqueo para muchos.

La integración de al menos una funcionalidad básica de búsqueda de usuarios de Active Directory y la asignación de roles personalizados con ASP.NET 5 facilitará la implementación de la autenticación de Windows en las aplicaciones web de ASP.NET. Necesitamos esta funcionalidad en nuestro sitio de intranet.

Este es un bloqueador para nosotros también. Necesitamos poder autenticar, consultar usuarios y grupos, crear nuevos usuarios y grupos, etc. contra un servidor ldap.

También es un bloqueador para mí: necesito consultar y autenticar a los usuarios.

Se me ocurrió una solución para la autenticación en Active Directory en una aplicación web .NET Core rc1. Solo tiene que anular el método CheckPasswordAsync en la clase UserManager. Déjame saber lo que piensas.

Primero, debe crear una página de registro personalizada que permita al usuario ingresar un nombre de usuario de AD en lugar de una dirección de correo electrónico y una contraseña. Ese nombre de usuario va en la propiedad UserName de la clase ApplicationUser que genera la plantilla ASP.NET 5 cuando elige la autenticación de cuentas de usuario individuales. Además, tendrá que establecer de forma predeterminada la propiedad Contraseña en algo que pase la validación interna en la clase IdentityUser.

Mi controlador de página de registro llama a un método Web API 2 que encuentra el nombre de usuario en AD y devuelve JSON que contiene la información de AD para ese usuario. He agregado algunas propiedades personalizadas a la clase ApplicationUser para contener la información de AD. Publicaré el código de mi proyecto la próxima semana.

Luego agregue un archivo de clase en la carpeta Servicios. Llamé al mío ApplicationUserManager.cs. Agregue el siguiente código a ese archivo de clase.

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

Luego abra el archivo Startup.cs. Añadir .AddUserManager() a la llamada AddIdentity en el método ConfigureServices como se muestra a continuación.

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

Esto al menos me permite configurar la autorización basada en políticas/reclamaciones mientras espero el soporte de DirectoryServices.

Confío en esta biblioteca. Es una pena que no pueda portar ahora.

@ClintBailiff Tengo que intervenir aquí, porque transmitir la contraseña del usuario a través del cable nuevamente a otra aplicación en texto sin formato es una _realmente_ mala idea. Por favor, no utilice este enfoque. Es un agujero de seguridad.

@terrajobst , este será el obstáculo para transferir mis aplicaciones más grandes como Opserver. ¿Podemos priorizar esto?

@NickCraver Nunca sugerí pasar las credenciales como texto sin formato. Como regla general, uso SSL para todas mis aplicaciones/servicios web porque generalmente devuelven datos que solo los usuarios autorizados deberían ver. No pensé en especificar eso probablemente porque es tan obvio que no querrás enviar credenciales en texto sin formato.

Apoyaría al menos proporcionar un puerto de System.DirectoryServices.Protocols . Recientemente cambiamos nuestro código relacionado con LDAP a este para admitir una gama más amplia de servidores LDAP, ya que al espacio de nombres System.DirectoryServices.ActiveDirectory solo le gusta hablar con servidores AD.

Supongo que sería posible que una biblioteca de terceros active este tipo de soporte, pero dado que ya existe en el marco, me imagino que un puerto sería más simple.

El equipo WTF asp no proporciona esta funcionalidad básica
Este es un problema realmente bloqueador :(

¿Alguna actualización sobre la compatibilidad con LDAP en CoreCLR?

También me gustaría una actualización sobre esto. Desarrollaré una aplicación empresarial con ASP.NET Core que necesita autenticar a los usuarios en un servidor AD.

Buscaré portar System.DirectoryServices a .NET Core para v1.1.0 (https://github.com/dotnet/corefx/milestones)

@joshfree
También tengo que autenticar a los usuarios de ADLDS. Considere también System.DirectoryServices.AccountManagement

Hace un par de años, la empresa para la que trabajé tomó el código fuente de la biblioteca LDAP de Novell (Mono) para que nuestra aplicación pudiera comunicarse con los sistemas Active Directory, OpenLDAP y Oracle, y agregamos soporte para controles paginados y actualizamos algunas correcciones de TLS. Hicimos esto porque queríamos ejecutarlo en Linux. Se envió un PR con nuestros cambios a los propietarios. Como ahora queremos acceder a CoreCLR, esa biblioteca necesitaba convertirse a RC2. El trabajo ha comenzado aquí https://github.com/VQComms/CsharpLDAP/pull/1 , quedan 17 errores del compilador que deben corregirse. Son principalmente Thread.Abort , ThreadInterruptedException , que reemplazan los flujos TLS de Mono a CoreCLR SslStream Si alguien está interesado y necesita soporte LDAP para CoreCLR, no dude en ayudar.

He confirmado que un proyecto RC2 de ASP.NET Core Web Application (.NET Framework) puede hacer referencia a una biblioteca de clases que usa System.DirectoryServices.AccountManagement. Solo pude hacer que funcionara cuando tanto la aplicación web como la biblioteca de clases se crean con VS 2015 Update 2 y ambos usan .NET Framework 4.6.1.

Solo para hacernos eco de los sentimientos de los demás, estamos muertos en el agua portando sin poder consultar LDAP y similares.

@h3smith
Ver mi publicación anterior. Con el lanzamiento de RC2, ahora puede hacer referencia a una biblioteca de clases que usa System.DirectoryServices.AccountManagement .

No en Netstandard.

Sin embargo, como digo, estamos trabajando para que esto funcione. Ojalá tenga
algo en alrededor de 2-3 semanas

El viernes, 17 de junio de 2016, Clinton Bailiff [email protected] escribió:

@h3smith https://github.com/h3smith
Ver mi publicación anterior. Con el lanzamiento de RC2, ahora puede hacer referencia a un
biblioteca de clases que utiliza _System.DirectoryServices.AccountManagement_.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679, o silenciar
la amenaza
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

¿Alguna actualización sobre esto? Necesito autenticar al usuario que llama, cuando el usuario usa una aplicación web angular en la LAN, inicia sesión en AD, llama a un método de controlador WebAPI (sin que el usuario ingrese la contraseña en el navegador web) en aspnet core RC2. ¿Posible? ¿Posiblemente, pronto?

Para hacer esto, solo necesita usar withCredentials en sus solicitudes http del cliente. Luego puede obtener información de usuario y reclamos en sus controladores usando User.Identity.
Esto funciona en ie y Chrome, pero con Firefox se mostrará automáticamente una ventana emergente para que el usuario escriba su usuario y contraseña de Windows.

Nos encontramos con el mismo problema (por ejemplo, tratando de usar un servidor LDAP como almacén de usuarios) hace unos dos meses. No pudimos encontrar ninguna solución además de migrar la biblioteca LDAP de Novell (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) a .net core (consulte aquí https://github.com/dsbenghe/Novell. Directorio.Ldap.NETStandard). Hay un paquete nuget publicado. Estamos utilizando la biblioteca con el servidor OpenDJ LDAP (debería funcionar con cualquier servidor LDAP), sin problemas en 1,5 meses de uso.

@dsbenghe acabamos de compilar nuestra biblioteca LDAP de Novell en netstandard, la nuestra también contiene paginación. Esto fue hecho por @igorshmukler . ¿Te gustaría comparar y colaborar? El nuestro es WIP aquí https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Gracias por su trabajo en la implementación de .NET Core.
Después de obtener el paquete nuget, he creado el siguiente código para probar si la contraseña de ActiveDirectory del usuario es correcta

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

Llama a 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;
}

Y usa una clase de ayuda simple para que la aplicación angular sepa lo que está pasando

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

Para UWP, hay una solicitud para esta función en nuestro UserVoice: https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cc @tquerec @jimuphaus que trabajará en la compatibilidad de System.DirectoryServices para .NET Core.

¡No puedo esperar! ETA? ¿Especificaciones de diseño?

Cuando finalmente se transfiera, tendremos acceso a:

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

Sé que hay algunos defectos menores dentro de ese espacio de nombres, pero sigue siendo bastante útil.

@GArrigotti en las pruebas, usar LdapDirectoryIdentifier suele ser más rápido que 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;  
}

¿Hay una ETA? Podría usar esto en un sistema que se completará a fines de este mes...

@johnkwaters , ¿hay alguna razón por la que no pueda poner el código AD en una biblioteca de clases? Algunas personas (incluyéndome a mí) han tenido problemas para hacer referencia a bibliotecas de clases heredadas en una aplicación ASP.NET Core. Pero no hay problemas si crea la aplicación web y la biblioteca de clases en VS 2015 Update 3 y tiene como destino .NET Framework 4.61 en la aplicación web y la biblioteca de clases.

¿Hay alguna razón por la que no pueda poner el código AD en una biblioteca de clases?

¿Quiere decir PCL seguido de "imports": "portable-net45+win8" en project.json para .NET Core TxM? Eso requerirá que los ensamblajes de referencia Mono PCL estén presentes en Unix y no una solución de "donet-core puro", que garantiza la autosuficiencia en Unix. Es un buen truco para silenciar el compilador, pero solo funciona de principio a fin si CoreFX BCL tiene la implementación correspondiente. Como regla general, el proyecto.json sin "imports" para netcoreapp/netstandard1.x siempre es mejor. por ejemplo , https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

¿Alguna actualización sobre una ETA? ¿Dónde puedo ir al autoservicio que pregunta recurrente?

_Realmente_ ¡espero con ansias esta función!

¡Realmente espero con ansias esta característica también!

¡Realmente espero con ansias esta característica también!

¡También necesito desesperadamente esta característica!

Chicos, ¿podrían agregar reacciones a la publicación principal?

O use las bibliotecas que 2 personas separadas han puesto en nuget. Su
todo el S.O. Si no te gusta el paquete, envía un PR

El 8 de septiembre de 2016 a las 12:19, Mikhail Orlov [email protected]
escribió:

Chicos, ¿podrían agregar reacciones a la publicación principal?

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 para @jchannon Novell LDAP. Nos hizo avanzar y prácticamente no tuvo cambios en nuestra implementación de LDAP. Quiero decir que estás abstrayendo correctamente, ¿verdad?

Sí, terminé usando @jchannon Novell LDAP también, ha funcionado bien.

Si no lo he dicho antes, aquí está la sucursal, todo está en https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Funciona bien para nuestros requisitos en este momento...

@h3smith @johnkwaters cualquier problema siéntase libre de plantear un problema 😄

Decidí probar con Novell, las muestras se ven lo suficientemente bien, pero no sé cómo expulsar (eliminar) a un usuario de un grupo con Novell LDAP.
No puedo cambiar mi contraseña en MSAD LDAP porque no puedo ver la contraseña de usuario y no se configuró en el servidor LDAP.

¡Realmente necesito esto!

@joshfree o cualquier otra persona que sepa...
Buscamos iniciar un nuevo proyecto que necesita acceso a ActiveDirectoryServices.AccountManagement Pregunta: ¿El puerto está destinado a 1.1 o 1.2?

No es parte de 1.1 (que está a punto de ser finalizado). @tquerec , ¿puedes comentar tus planes aquí?

cc: @danmosemsft

Entonces, si no es parte de 1.1, ¿alguien tiene un plan? Parece un problema importante no tener este soporte. Claramente, Microsoft de todos querría esta integración.

Sólo otro voto a favor. Es difícil hacer la inversión para construir sistemas de clase empresarial en .NET Core cuando carece de la funcionalidad empresarial fundamental. El proyecto Novel funciona, pero no está a la altura.

Otro voto más. Me haré eco de la misma declaración de que esto es parte integral de la creación de cualquier aplicación empresarial.

@nevcoBpalacio Creo que están tratando de presionarnos para que usemos el directorio activo de Azure

Eso nunca funcionará para aquellos de uso con acuerdos corporativos que requieren que los servicios permanezcan en casa.

He estado trabajando para agencias gubernamentales, tanto federales como ahora del condado local y, de cualquier manera, aún necesitaría alguna interfaz o capacidades para integrarse a algún servicio de directorio, ya sea basado en la nube o en las instalaciones. He co-desarrollado aplicaciones que manejan miles de millones de dólares y siempre surge alguna necesidad de servicios de directorio. Creo que esto es más que otro voto, sino más bien una declaración de ¿qué estás esperando? Estoy de acuerdo con una publicación anterior de que esta era originalmente una solución lista para usar en versiones anteriores de .NET. Entiendo que la estructura más abierta de CORE debería ganar el impulso de la comunidad y si esto es lo que Microsoft elige esperar, tal vez lo hayan dicho y me lo perdí, deberían decirlo para que alguien pueda tomar la iniciativa de invertir tiempo. para hacerlo

Sí, agregue System.DirectoryServices a .NET Core.

Tenemos planes para portar System.DirectoryServices.Protocols dentro del próximo año. En este momento no puedo proporcionar una fecha más firme. Todavía no tenemos planes para migrar System.DirectoryServices o System.DirectoryServices.AccountManagement, pero me interesa medir el interés. ¿Hay características de esos espacios de nombres que la gente usa que no se pueden resolver con los Protocolos?

@tquerec No estoy familiarizado con los Protocolos. Tenemos un proyecto para hacer el autoservicio de Active Directory para desbloquear la cuenta y restablecer la contraseña de la cuenta. Usamos UserPrincipal en el proyecto e invocamos métodos como FindByIdentity, UnlockAccount, SetPassword, ExpirePasswordNow.
No estoy seguro de si esto se puede hacer en los protocolos, pero parece que los protocolos son una implementación de nivel inferior en comparación con AccountManagement, es una mejor abstracción para trabajar con ActiveDirectory.
Gracias
Maestro de rocas

@nevcoBpalacio definitivamente debería ser más que un voto, estoy de acuerdo. Creo que esto realmente necesita más prioridad.

@CalebMacdonaldBlack , sería útil si pudiera responder la pregunta de @tquerec sobre los patrones de uso y por qué es lo que se necesita. Más votos a favor o "Estoy de acuerdo/es importante" sin escenarios no ayudarán a aumentar la prioridad en este momento... ¡Gracias!

Nuestro uso es escanear/buscar LDAP, hacer BIND para verificar credenciales, agregar/eliminar objetos LDAP (usuarios, grupos), modificar membresía en grupos, etc.

@tquerec Realmente necesito System.DirectoryServices.AccountManagement para poder autenticar a nuestros usuarios en el directorio activo y autorizarlos en los grupos a los que tienen acceso.

Definitivamente estoy de acuerdo con h3smith... necesitábamos esto para v1 y, en cambio, nos vemos obligados a seguir el camino de Novel, que hemos juntado (especialmente los bits de replicación) y nos está causando problemas con los gastos generales de mantenimiento, etc. Esto está haciendo .NETCore quedar mal como efecto secundario..

@liquidboy

necesitábamos esto para v1

¿Te refieres a .NET Core v1? -- eso está hecho y enviado. Estamos trabajando en 1.2 ahora. ¿O quisiste decir algo más?

en cambio, se ven obligados a seguir el camino Novel

Qué significa eso? (Lo siento, no tengo contexto en DirectoryServices, pero me encantaría entender lo que nos falta desde el punto de vista de los escenarios)

@karelz simplemente busque en este hilo la palabra "novela" y verá lo que quiero decir. Otro desarrollador (dsbenge) de mi equipo comentó (junto con otros) sobre la brecha que nos llevó a usar novel. [aquí está el enlace al comentario anterior https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

Y sí, quise decir .NET Core v1 que ya se envió, hemos estado trabajando en nuestra solución durante más de un año y necesitábamos una buena solución de DirectoryServices en ese entonces. .

@liquidboy gracias por el enlace: si está en Mono, deberíamos poder reutilizar el código fuente en .NET Core AFAIK. @tquerec dado el interés, ¿es algo que su equipo consideraría?

@tquerec : Necesitamos lo siguiente:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory y System.DirectoryServices.Protocols.

Esos son necesarios para conectarse y administrar usuarios, grupos y atributos de Active Directory (y otros servidores LDAP), tal como se describe en las respuestas anteriores. ¡Es importante tener estas funciones en .Net Core!

Estoy de acuerdo con los demás. Necesito esto para portar cualquiera de nuestras aplicaciones que se autentican contra ActiveDirectory a .NET Core. Esto es bastante fundamental, definitivamente debería estar en el lanzamiento lo antes posible. Es el bloqueador para portar tantas cosas.

La página de hoja de ruta de .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) tiene este plan para .NET Core 1.2: "llevar .NET Core a la paridad con .NET Framework y Mono para un gran colección de tipos básicos".

Creo que la migración de System.DirectoryServices se ajusta muy bien a ese plan y, de hecho, debería ser parte de la versión 1.2. Solo mis 5 céntimos de euro :)

Solo para aclarar: las API portadas en 1.2 se eligieron en función de los datos de uso (y rara vez de la complejidad): @weshaggard @danmosemsft , ¿puede aportar detalles? ¿Por qué no incluimos System.DirectoryServices?

La lista de ensamblajes que elegimos para hacer coincidir está aquí . @weshaggard tendrá que recordarme cómo eligió esa lista. (Mono tiene S.DirectoryServices)

Creo que podrá hacer casi todo lo necesario con respecto a hablar con ActiveDirectory (y otros servidores ldap) usando System.DirectoryServices.Protocols, pero mucha gente tendrá que volver a escribir su código para usar S.DS.Protocols.

Personalmente, preferiría que MS adaptara S.DS.Protocols y MS o la Comunidad para crear una biblioteca fácil de usar para la administración de usuarios/grupos además de esto.

La lista de ensamblajes que elegimos para hacer coincidir está aquí. @weshaggard tendrá que recordarme cómo eligió esa lista. (Mono tiene S.DirectoryServices)

La propagación inicial se realizó a partir de la intersección de perfiles de Xamarin con .NET Framework. Los perfiles de Xamarain (que es un subconjunto de mono) no son compatibles con DirectoryServices, por lo que esto no estaba en la intersección.

¿Qué podemos hacer para argumentar que esto debería estar de moda? La incapacidad de usar el esquema de autenticación más común en las aplicaciones de Microsoft es un poco bloqueador, ¿no? ¿El enfoque es Azure aquí y AAD en su lugar? ¿O es el bloqueador que portar esto a través de plataformas es una gran incógnita de los protocolos?

¿Hay alguna manera de que podamos aumentar la prioridad aquí? 2.0 está muy lejos, y eso es realmente desafortunado si _todo_ funciona, pero no podemos autenticar a los usuarios. Esta es la puerta de entrada virtual para tantas aplicaciones. En mi opinión, en términos de prioridad, es un poco diferente porque no es un bloqueador parcial, sino un bloqueador completo por naturaleza.

No creo que haya ningún desacuerdo en que queremos admitir esto en .NET Core, que es diferente a ser parte de .NET Standard, solo es cuestión de cuándo. @tquerec es dueño del área y sería quien hablaría de eso.

Alguien de .NET Foundation preguntó, pero los espacios de nombres que estamos usando específicamente son:
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

Entonces, @tquerec , ¿cómo marcamos System.DirectoryServices para .NET Core 1.2? Al menos System.DirectoryServices.Protocols. ¿Es eso posible?

¡Muchas gracias!

[actualizado con más información de @tquerec]
Me reuní con @tquerec el lunes. Les debo a todos un escrito. En pocas palabras:

• Sistema. DirectoryServices es factible solo en Windows (llama a Windows DLL donde vive toda la implementación), totalmente desconocido para Linux/Mac
• System.DirectoryServices. AccountManagement se encuentra encima, por lo que también es factible solo para Windows y desconocido para Linux/Mac
• System.DirectoryServices. ActiveDirectory es factible solo en Windows (llama a muchas API específicas de Windows)
• System.DirectoryServices. Los protocolos deberían ser razonablemente simples para Windows y más trabajo para Linux (necesitamos encontrar una biblioteca LDAP para usar).
  Estamos tratando de averiguar con @tquerec cómo financiar el trabajo, idealmente para 1.2, pero aún no lo prometemos. Espero que la decisión tome al menos un par de semanas.

Preguntas para todos :

• ¿El alcance solo de Windows anterior es aceptable para los principales casos de uso? (Sys.DirSer y Sys.DirSer.AccountManagement y Sys.DirSer.ActiveDirectory)
• Si Sys.DirSer.Protocols Linux viene después de 1.2 o depende de las contribuciones de la comunidad, ¿sería eso un gran obstáculo?

@karelz System.DirectoryServices.ActiveDirectory se basa en una gran cantidad de API específicas de Windows, por lo que cae en el mismo grupo que S.DS y S.DS.AM.

@karelz No estoy seguro de lo que quiere decir con una solución solo de Windows para 1.2. Ya tenemos una solución solo para Windows que funciona.

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

@rock-meister Me refiero a .NET Core. El que mencionó apunta a .NET 4.5.2+ "completo".

Sí, el soporte solo para Windows es un gran desbloqueador para nosotros. Podemos hacer todo el trabajo para la migración de .NET Core y expandir la compatibilidad de la plataforma "gratis" más tarde, cuando lo hagan los bits subyacentes. Justo no, el bloqueador incluso para _comenzar_ al puerto es enorme. Que se haya ido es una gran victoria.

Al ser una tienda de Windows, esto también sería una gran victoria aquí. ¡Tantas empresas grandes considerarían esto como una gran victoria! Gracias por mantenerte al día con tu información. Que nos mantengais. Gracias.

@karelz Gracias por la aclaración. Sí, el alcance solo de Windows para 1.2 funciona para nosotros.
Maestro de rocas

System.DirectoryServices.Protocols con soporte Linux/LDAP es la máxima prioridad para el trabajo que hacemos.

ps el alcance solo de Windows parece contrario a los objetivos de .netcore / .netstandard

Pasamos de usar System.DirectoryServices a usar System.DirectoryServices.Protocols hace un tiempo para poder admitir servidores LDAP que no sean de AD. Tener acceso al espacio de nombres de Protocolos estaría un paso más cerca de permitirnos migrar nuestro código a .NET core.

Sin embargo, si esto va a ser específico de la plataforma, entonces hay menos uso para nosotros. Un punto principal de querer pasar a .NET Core es la portabilidad de la plataforma. Probablemente todavía tengamos que esperar para eso.

Para nosotros, llegar a .NET Core fue la capacidad de aprovechar Docker y ser totalmente independientes de la plataforma. Por lo tanto, quedarse con el soporte LDAP solo de Windows no sería beneficioso.

Gracias por discutir internamente.

Mi voto va con ruta independiente de plataforma 🦃

Tengo que estar de acuerdo con el comentario agnóstico de la plataforma, por mucho que me duela que no pueda usar el núcleo hasta que esto se logre. Creo que esto es algo que debe revisarse a un nivel superior. Lo que no entiendo es la complejidad del concepto. Hay varias soluciones de directorio, AD, Novell, etc... Esto requiere una solución de interfaz multiplataforma (agnóstica)... ¡Felices fiestas!

Si bien personalmente podría vivir perfectamente bien con un alcance solo de Windows, en mi opinión, esto rompe la idea de .NET Core y su portabilidad.
Una solución independiente de la plataforma debería ser la ruta en la que centrarse.

Sí, de acuerdo, .NET Core debe ser multiplataforma y las características/API deben funcionar en todas las plataformas compatibles.
Entonces, si System.DirectoryServices.Protocols se va a portar/implementar primero, también debería funcionar en Linux.

Estoy de acuerdo en que, idealmente, el objetivo debería ser una solución independiente de la plataforma. Aunque todavía no tenerlo en Windows es un obstáculo para muchos desarrolladores que solo quieren experimentar con la plataforma en un entorno corporativo (AD), como yo. Es por eso que agradecería una solución solo para Windows por el momento.

Solo me gustaría participar y decir que estoy bien con una solución solo para Windows hasta que se pueda armar algo multiplataforma.

Me imagino que el 99,9 % de los desarrolladores que necesitan conectarse a Active Directory lo hacen en un entorno empresarial en el que desarrollan en cajas de Windows.

Estamos discutiendo la financiación de nuestro lado (se espera una actualización en aproximadamente 2 semanas), esta es actualmente la máxima prioridad de las API que aún no forman parte de .NET Standard 2.0.

¿Hay personas alrededor que estarían dispuestas a ayudar/contribuir con la implementación de Windows y/o la implementación de Linux? (podríamos colocar el código desde el escritorio y requeriría más masaje para construir + algunas pruebas)

@karelz Me encantaría contribuir con el lado de Linux. Necesitamos esta compatibilidad tanto para la autenticación de Windows como para la que no es de Windows (en las instalaciones). Esto es un obstáculo para nosotros y apuntamos a .NET core para nuestro proyecto multiplataforma (anteriormente era Mono en el lado de Linux y .NET en el lado de Windows).

Me gustaría ayudar en lo que podamos, sin duda.

Me encantaría ayudar, pero estoy seguro de que ustedes tienen mucha más experiencia que yo y yo no sería de ninguna utilidad.

@karelz @tquerec Me encantaría ayudar con las pruebas en Windows y, en el futuro, en Linux. Me suscribí al hilo, así que solo responda aquí o mencione para ponerse en contacto cuando necesite que me involucre. Gracias por tu trabajo en esto. Ha sido esperado durante mucho tiempo y, aunque sea incremental, será un buen paso para una mayor adopción de .NET Core.

Creo que "Windows extendido" es un buen objetivo inicialmente, "extendido" significa que funciona en NanoServer y en Contenedores (es decir, máquinas no unidas a un dominio que no pueden ejecutar .NET CLR completo). Esto le dará una ganancia rápida y un punto de partida para trabajar hacia atrás para implementarlo en otros servidores.

Trabajamos con @tquerec y nuestras cadenas de gestión para encontrar la mejor manera de desbloquear este trabajo lo antes posible. Desafortunadamente, no tenemos a nadie libre antes de finales de enero, así que intentaremos hacer todo lo posible mientras tanto para desbloquear las contribuciones de la comunidad con recursos limitados y algo de trabajo voluntario de nuestra parte ( @ianhays @tquerec y @karelz).

Esto es lo que planeamos hacer:
@ianhays nos ayudará a poner en marcha el proyecto en el repositorio de CoreFX (agregue código fuente, muestre ejemplos de cómo hacerlo, aconseje con la configuración de compilación, empaquetado, prepare el proyecto para futuras versiones de Linux/Mac, etc.).
Comenzaremos con la implementación solo para Windows (las contribuciones son bienvenidas). No realizaremos ningún cambio funcional en la implementación o la superficie de la API en este momento, a menos que sean necesarios para la migración a .NET Core.
El siguiente paso (potencialmente paralelo) será agregar pruebas. Deberíamos iniciar la discusión con @tquerec sobre el diseño de prueba existente (.NET Framework de código cerrado) si hay algo que podamos aprovechar, o si tenemos que empezar desde cero.
Más adelante, podemos centrarnos en los puertos Linux/Mac.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte, y cualquier otra persona interesada, estaremos encantados de recibir sus contribuciones una vez que @ianhays comience el esfuerzo (ETA: a mediados de la próxima semana, creo). Si tiene alguna pregunta o sugerencia, por favor háganoslo saber.

¿Este trabajo también permite que las bibliotecas como SqlClient realicen la autenticación de Windows cuando se ejecutan en Linux pero se conectan a un servidor SQL que requiere la autenticación de Windows?

Ese es uno de mis obstáculos para poder portar cosas a .NET Core ejecutándose en Linux. Todos nuestros servidores empresariales de Microsoft SQL solo permiten la conexión a través de un ID de servicio (no interactivo) que está en AD.

blgmboy Su problema es un excelente ejemplo de por qué las cosas deben ser "examinadas" para garantizar una verdadera compatibilidad multiplataforma con los nuevos modelos sugeridos. Si tiene más escenarios, creo que su entorno es un buen ejemplo de cómo las cosas deben cruzarse y debe enumerar cualquier otro problema que tenga con la parte AD de Core.

Sí, definitivamente tendré en cuenta este hilo y compartiré todo lo que encuentre. Solo quería que todos supieran que este es un gran obstáculo para las empresas con granjas SQL que tienen una seguridad estricta como se describe.

También es un impedimento para el uso de algo como EF Core que, en última instancia, tendría el mismo problema.

System.DirectoryServices ahora se fusiona con CoreFX. El siguiente paso es construirlo para .NET Core - Windows y agregar pruebas.

gracias ¡Es bueno ver algo de tracción en este tema!

¡Gracias Ian!

Plan de ejecución actualizado: EDITAR: Movido a la publicación más alta en este problema para una mejor visibilidad

Si alguien está trabajando en algún paso, menciónelo y coordine aquí para evitar la duplicación de esfuerzos. También te co-asignaré el problema.

Los espacios de nombres System.DirectoryServices contienen una funcionalidad tan importante para las aplicaciones empresariales de Windows en las instalaciones que es genial ver algún progreso en este problema. Sigan con el buen trabajo.

He arreglado las fuentes y System.DirectoryServices ahora se está construyendo. Debería estar enviando un PR pronto.

¡Gracias @tquerec por contribuir con la segunda ronda!
¿Hay voluntarios para ayudar con los 2 espacios de nombres o pruebas restantes? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 tiene un PR aquí https://github.com/dotnet/corefx/pull/15324 para agregar más soporte y obtener protocolos/construcción de gestión de cuentas.

Por lo que vale, he estado experimentando con System.DirectoryServices.Protocols recientemente y descubrí que muchos escenarios simples de System.DirectoryServices no son difíciles de imitar con System.DirectoryServices.Protocols. En base a eso, creo que hacer que S.DS y S.DS.AM funcionen en varias plataformas puede ser una prioridad menor, ya que un System.DirectoryServices.Protocols multiplataforma podría ser una solución útil para muchos usuarios.

Por supuesto, eso significa que lograr que System.DirectoryServices.Protocols funcione como una solución LDAP multiplataforma sigue siendo una alta prioridad.

¿Estoy leyendo bien la solicitud de extracción? Parece que esto se aceptó hace unos días, por lo que si construimos desde la fuente, ¿podríamos probarlo?

Sí, creo que tenemos todo el desarrollo de DirectoryServices, sin embargo, no tenemos ninguna prueba, lo que nos impide enviar el paquete como estable y realizar mejoras en la base del código (corrección de errores, mejoras, etc.).
Si puede probarlo en la compilación desde la fuente, sería genial. Si usted (o cualquier otra persona) quiere ayudarnos a agregar pruebas o iniciar el puerto de Linux, eso sería aún mejor :)

Hola a todos,

Nos estamos preparando para iniciar un proyecto empresarial que requiere soporte de Active Directory ya que somos 100% internos a nuestro dominio. ¿Puede alguien proporcionar el estado de este problema y las expectativas para la próxima versión principal? Pido disculpas, pero soy nuevo en la comunidad de GitHub y aún no entiendo toda la terminología y la información de estado.

Sería genial usar Active Directory para la membresía en lugar de un modelo de identidad completamente separado que tendría que administrarse por separado y solo causaría una falta de coincidencia de datos también.

¡Gracias por adelantado!

@karelz para esa pregunta, pero creo que la respuesta es que esto no se espera actualmente en la versión 2.0, ya que no tenemos un desarrollador programado para ello. Las contribuciones de la comunidad son bienvenidas. no necesita enviarse _en_ ​​la versión 2.0, puede publicarse en NuGet en cualquier momento en que esté listo para el envío.

¡Perfecto! Respondiste mi pregunta.

Gracias.

@nevcoBpalacio ¿ algún interés en intentar una contribución?

Tengo interés, especialmente con este tema, ya que sé que impide que muchos vayan al centro de las soluciones empresariales. Sin embargo, tenemos un trabajo y parece que no puedo encontrar el tiempo en el día (tarde con niños) para hacerlo. Intentaré reequipar mi sistema en casa para que funcione con GitHub. Aunque aprecio que preguntes! Gracias.

Nevcobpalacio, si usa vs17 y no requiere multiplataforma, puede acercarse un poco más a lo que desea utilizando la plantilla de la aplicación web principal dirigida al marco completo de .net y ref the system.directoryservices.accountmanagement dll a la antigua usanza y implemente su propio middleware para hacerlo mientras tanto. Por lo que he visto, el mismo código debería transferirse a .net core como objetivo una vez que esté disponible, excepto que usará el paquete nuget y soltará la referencia. Espero que esta información ayude a poner en marcha su proyecto.

@los93sol gracias por esa sugerencia. Nuestras discusiones iniciales son construirlo de manera similar a esa sugerencia y convertirlo en un módulo de software intermedio que podamos "cortar" a lo que sea que llegue a Nuget más adelante. ¡Gracias un montón!

Tengo que comentar y felicitarte por esta sugerencia. Al principio era escéptico acerca de este cambio en el núcleo. Sin embargo, con este enfoque comunitario, discusiones como esta salen a la luz y nos ayudan a todos a resolver las cosas durante estos cambios importantes.

Gracias.

¿Alguien está trabajando actualmente para agregar las pruebas que faltan o para migrar System.DirectoryServices.Protocols a Linux/Mac?

@pasikarkkainen AFAIK no hay tal esfuerzo activo en este momento por parte de los equipos de Microsoft (lo que podría o no cambiar en un futuro cercano). Tampoco he visto a nadie de la comunidad que empiece a trabajar en ello.
¿Está interesado en contribuir, o simplemente tiene curiosidad sobre el estado?

@karelz Parece que apuntan a DirectoryServices para el lanzamiento de .NET Core 2.0 este verano.

Cita de @shanselman

AD – Totalmente, esta es una brecha SI desea llamar a LDAP directamente. Ciertamente puede autenticarse contra Windows Auth AHORA. Planeamos tener específicamente el espacio de nombres DirectoryServices para Core 2.0 alrededor del período de verano.

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

Sí, eso está en línea con las discusiones de pasillo que he escuchado. Simplemente no estaba seguro de si se trata de información pública y cuánto (y quién) se comprometió con ella. Creo que es seguro decir que está bajo una consideración muy fuerte y es probable que suceda. Dejo que los propietarios de @shanselman y DirectoryServices comenten las líneas de tiempo.

@karelz : ¡Gracias por la actualización! Tenía curiosidad sobre el estado. Definitivamente puedo ayudar con las pruebas al menos, cuando esté disponible.

@pasikarkkainen si también está dispuesto a ayudar a escribir algunos casos de prueba, sería muy apreciado.
Si "solo" desea probar el paquete en su aplicación/código, debería ser factible hoy. Solo necesitamos comenzar a publicar el paquete como vista previa en myget (creo que la publicación está deshabilitada hoy).

@karelz No me importaría ayudar específicamente con la implementación de Mac. Tengo poco conocimiento, así que no estoy seguro de qué tan bien puedo contribuir. Investigué al respecto y hay una biblioteca de novelas que la gente parece sugerir. Encontré la implementación de otra persona en torno a esa biblioteca de Novell aquí: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt El autor del paquete ya lo mencionó aquí.
https://github.com/dotnet/corefx/issues/2089#issuecomment-228043297

Entonces, ¿es esto algo que estará en el núcleo 2.0? Estoy un poco confundido en cuanto al estado de la misma.

No, no será parte de .NET Core 2.0, sin embargo, en la conferencia Build prometimos la disponibilidad del paquete durante el verano. El paquete (de Windows) debería estar disponible además de .NET Core 2.0, más o menos cuando se envíe .NET Core 2.0.
Actualmente estamos trabajando para que los paquetes estén disponibles como vista previa en la rama maestra (n.º 18090) y trabajando en activos de prueba en paralelo (n.º 20669).

¿Obtendremos errores de compilación cuando apuntemos al tiempo de ejecución compartido o un tiempo de ejecución que no sea de Windows? ¿O terminaremos con la trampa de PlatformNotSupported ?

Será un paquete independiente sin activos que no sean de Windows. La compilación debería interrumpirse. @ericstj puede confirmar.

No obtendrá errores de compilación, serán excepciones "PlatformNotSupported" en tiempo de ejecución.

Sí, es el antiguo: ¿bloqueamos a las personas que lo usan desde las bibliotecas de .NET Standard o convertimos los errores en tiempo de compilación en excepciones PlatformNotSupported? ... Afortunadamente, hay un término medio: las herramientas de ApiCompat le dirán con anticipación que está usando algo que no está en todas partes.

Recibo el siguiente error cuando intento usar el paquete System.DirectoryServices en el proyecto netstandard 1.6:

Install-Package: Package System.DirectoryServices 4.0.0 no es compatible con netstandard1.6 (.NETStandard,Version=v1.6). Paquete System.DirectoryServices 4.0.0 admite: net (.NETFramework,Version=v0.0)

¿Hay algún trabajo o solución para esto?
Saludos,
varun

@vrn11 este paquete es de otro proveedor y solo es compatible con el marco de red completo

De todos modos quería preguntar si hay una actualización sobre esto. ¿Tal vez un paquete de vista previa que podamos obtener de myget? Sería increíble probar esto

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

Como mencionó @MarcusKohnert , puede obtenerlos de https://dotnet.myget.org/F/dotnet-core/api/v3/index.json. Hay System.DirectoryServices, System.DirectoryServices.AccountManagement y System.DirectoryServices.Protocols.

¡Impresionante! ¡gracias a @MarcusKohnert y @ericstj por los enlaces!

Estoy probando los paquetes de myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
Mientras se ejecuta en MacOS 10.12.6 y cuando se ejecuta:

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

Me estoy poniendo:

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

¿Se espera que PrincipalContext funcione en una Mac?

@bruno-garcia no hay implementación en CoreFX en este momento para DirectoryServices, excepto en Windows. @karelz tendría que hablar sobre planes/aspiraciones, si las hubiera.

Solo System.DirectoryServices.Protocol es potencialmente factible en x-plat (aún no implementado); vea los detalles en algunas de mis respuestas anteriores y en la publicación superior.

Es importante lograr que System.DirectoryServices.Protocols funcione entre plataformas (también en Linux/Mac). ¿Entendí correctamente que el problema principal actualmente es que la biblioteca LDAP utilizada por System.DirectoryServices (en Windows) no es de código abierto y, por lo tanto, solo funciona en Windows?

Si lo he entendido correctamente, System.DirectoryServices será difícil de hacer xplat debido a muchas dependencias en las interfaces ADSI COM, que solo están disponibles en Windows.

System.DirectoryServices.Protocols aún debería ser posible ejecutar xplat.

Ejecutando el mismo código que mencioné antes:
```c#
usando (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

En un Win7 x64 con .NET Core 2.0 produce:

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)

Usé los paquetes:

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

[EDITAR] Resaltado de sintaxis de código fijo de callstack y xml/C# por @karelz

@bruno-garcia, presente un problema por separado. Este está rastreando el esfuerzo general del puerto, no errores/diferencias particulares. ¡Gracias!

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

El siguiente paso puede ser depurar a través del escritorio y ver dónde diverge el comportamiento. Intentaré liberar a un desarrollador para que lo mire.

Mismo problema en el servidor de 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)

¿Qué os parece, cuándo funcionará?

tiene un problema al intentar instalar un paquete

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

===============================================
Si alguien tiene el mismo problema que yo, use .NET CLI en su lugar

dotnet agregar paquete System.DirectoryServices --versión 4.5.0-preview2-25707-02 --fuente https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

@papamamadoii eso se debe a que te falta https://dotnet.myget.org/F/dotnet-core/api/v3/index.json como fuente y aparentemente Install-Package no usó tu fuente especificada para encontrar dependencias. Es posible que desee presentar un error en http://github.com/nuget/home con pasos de reproducción específicos.

@karelz Si entiendo los comentarios correctamente, ¿esto no funciona en implementaciones basadas en Linux?

@euclid47 System.DirectoryServices.* actualmente no es compatible con Linux. Como se discutió anteriormente, partes de él podrían potencialmente ser portadas dado el suficiente interés/participación de la comunidad.

@danmosemsft No entiendo cómo no puedes ver todo este hilo abierto desde octubre de 2015 como suficiente interés de la comunidad. Si poseyera el conjunto de habilidades necesario para escribir algo tan complicado como una capa de comunicación LDAP, ya habría estado trabajando en ello, ya que AD era uno de los mecanismos de autenticación centrales en un entorno empresarial. Señalaré que para la mayoría de las grandes empresas, la incapacidad de realizar este tipo de interacciones en Linux literalmente anula el propósito de Core y hará que se apeguen a las compilaciones pre-core de dotnet, lo que limita su valiosa interacción con la comunidad.

@danmosemsft Además, si literalmente no planea trabajar en esto, dígaselo definitivamente a la comunidad para que otros desarrolladores puedan recoger las piezas.

@shairozan hasta ahora hemos notado 7 votos de 54 que consideran DirectoryServices en Linux como una prioridad más alta que Windows; consulte https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
También hay otras ventajas que los desarrolladores obtienen de .NET Core además de la plataforma x (aunque estoy de acuerdo en que x-plat es una de las principales razones).

Recomendaría terminar primero el lanzamiento del paquete solo para Windows, luego podemos abrir un nuevo problema para rastrear el interés por el puerto de Linux con mayor precisión.

Ya le dijimos a la comunidad que estamos buscando ayuda y que el problema está marcado como disponible; consulte https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. Y @hughbe ayudó con la primera ronda de pruebas para DirectoryServices; vea el historial aquí , aquí y aquí .

@karelz ¿Dónde se gestiona la votación de estos componentes? Puedo garantizar que después de SELF/POSSCON verás un aumento bastante drástico en el interés.

@karelz ¿Dónde está la votación para esta función? Estoy absolutamente de acuerdo con @shairozan con la necesidad. Hay un comentario en este número que describe nuestro entorno de desarrollo y producción. Es bastante impactante que no haya habido ningún movimiento en la implementación desde que los evangelistas de .Net Core predican que es independiente de la plataforma.

Creé un nuevo problema para rastrear el puerto Linux/Mac dotnet/corefx#24843 para facilitar la votación que en el comentario en medio de este problema (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

Agregué el enlace también en la publicación superior de este número.

@euclid47 la votación hasta ahora fue en este tema; consulte los enlaces anteriores. Eso es lo que resultó en los 7 votos (+1 para el remitente del problema original).

Nuestro equipo necesita soporte LDAP en Linux.
Porque la mayoría de nuestros clientes utilizan la autenticación a través de LDAP.

@balkarov Si puede, vote a favor del problema que acaba de crear @karelz ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 Si aún no lo sabe, existe el paquete Novell.Directory.Ldap.NETStandard Nuget que puede usar para integrar LDAP en sus proyectos. No somos usuarios avanzados de LDAP, solo lo usamos para validar credenciales y obtener información del usuario, pero funciona bien para nosotros, tanto en 1.0 como en 2.0 ejecutándose en la imagen docker dotnet core runtime. No es una forma oficial, pero hace el trabajo hasta que hay un puerto multiplataforma de System.DirectoryServices .

@OskarKlintrot gracias. Pero esta biblioteca no admite el inicio de sesión sin dominio.
Creo el problema https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
¿Me pueden ayudar a resolver este problema?

No soy parte de ese proyecto ni soy un usuario avanzado, pero le echaré un vistazo, ¡nos vemos allí!

(No iniciamos sesión con un dominio)

Dado que @karelz estalló un problema para Unix, cambié el título de este para mayor claridad.

@danmosemsft pero el problema tiene un plan
Puertos Linux/Mac.

@balkarov Actualicé el plan para vincularlo con otros problemas de seguimiento y eliminé las casillas de verificación de los elementos que se rastrean por separado (trabajo interrumpido) o que no bloquean el trabajo de Windows.

¿El puerto System.DS será compatible con los servidores RODC (controladores de dominio de solo lectura)?

@PKGeorgiev debería obtener el mismo soporte de System.DirectoryServices que tenemos en el marco completo.

El trabajo en DirectoryServices para Windows está terminado, cerrando el problema.
Nota:

• La publicación del paquete final es rastreada por dotnet/corefx#24909
• El puerto Linux/Mac se rastrea por separado mediante dotnet/corefx#24843

Hola, ¿funcionará esto en UWP?

Hola, ¿funcionará esto en UWP?

No, solo es compatible con las aplicaciones principales de red que se ejecutan en Windows y el marco completo. si lo usa en UWP o en Linux, obtendrá una excepción PlatformNotSupported.

Estoy usando este código en una función lambda en AWS que se ejecuta en Linux en segundo plano y recibo este error. "System.DirectoryServices.AccountManagement no es compatible con esta plataforma".
Estoy usando el núcleo 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 Sí, esto aún no es compatible con Linux. Solo es compatible con Windows.

@sscoleman se creó un problema, https://github.com/dotnet/corefx/issues/24843. Se dijo que no había suficiente interés de la comunidad con la excepción de que esta pregunta surge todo el tiempo. Así que ahora estás en un lugar de mierda. Dedicó tiempo a implementar servicios de directorio y luego descubrió que Linux es compatible. Ahora te preguntas por qué se promociona esto como independiente de la plataforma si solo hay funciones de Windows.

Es bastante obvio si nos fijamos en la gran estrategia de Microsoft. Microsoft está lanzando TODOS sus recursos de desarrollo a Azure, y eso incluye Active Directory. Consulte "Novedades de 2016", se trata principalmente de inversiones AzureAD/Hybrid. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft no está invirtiendo en esta biblioteca para Linux porque quiere que todos se trasladen a Azure AD. Tiene sentido, ¿por qué invertirías en algo de lo que intentas que los clientes se alejen?

Sin embargo, estás haciendo algo relativamente simple. Puede usar las bibliotecas Novel LDAP, funcionan con AD y en .NET Core para Linux. Debe hacer el trabajo del protocolo usted mismo, pero no es demasiado complejo y hay muchas muestras disponibles. La desventaja es que debe administrar la vinculación usted mismo, lo que requiere un DN de usuario y una contraseña.

System.DirectoryServices es actualmente una API solo para Windows y es parte del paquete de compatibilidad de Windows para .NET Core . En principio, podemos hacer que partes de System.DirectoryServices funcionen en Linux, pero aún no tenemos los recursos para hacerlo. dotnet/corefx#24843 está rastreando este elemento de trabajo.

¿Por qué permitimos instalar paquetes que no funcionarán en Linux? La alternativa sería bifurcar la superficie de la API, pero eso tampoco funciona bien en todos los casos y hace que el sistema en general sea más difícil de codificar. Por supuesto, nuestra elección tampoco está exenta de problemas, ya que puede hacer que sea más difícil predecir si el código funcionará multiplataforma o. Tenemos una vista previa de un analizador de compatibilidad que le brinda comentarios en vivo mientras codifica.

Vea este video para obtener más contexto sobre cómo vemos que el paquete de compatibilidad de Windows y el analizador multiplataforma funcionan de la mano:

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

@thedevopsmachine

Microsoft no está invirtiendo en esta biblioteca para Linux porque quiere que todos se trasladen a Azure AD.

Yo no lo veo así. Como ha señalado, tenemos la intención de ganar dinero a través de Azure. Y Azure es una plataforma en la nube que ofrece una amplia variedad de tecnologías y sistemas operativos. No tenemos ningún interés comercial en promocionar Windows en la nube sobre Linux en la nube. Pero, por supuesto, .NET ha tenido una fuerte presencia en Windows durante 15 años. Hacer que las cosas sean totalmente funcionales en todos los sistemas operativos lleva tiempo, pero sinceramente, creo que la mayoría de las personas que siguen nuestros esfuerzos de código abierto pueden ver que no estamos paralizando Linux a propósito. Solo toma tiempo.

estoy de acuerdo con el enfoque de tener una api x-plat y x-framework consistente, pero es devastador cada vez que me encuentro con ese temido error... lo siento por @sscoleman ...

¿Puede este paquete DirectoryServices funcionar en CentOS 7?

¿Puede este paquete DirectoryServices funcionar en CentOS 7?

El paquete se puede instalar pero no funcionará. al usarlo, obtendrá una excepción de plataforma no compatible. estamos buscando cómo podemos soportar los servicios de directorio en general en Linux. esto está en nuestro radar.

Esto realmente necesita soporte Linux

CC @joperezr

@niemyjski ver

Esto realmente necesita soporte Linux

.. además de poder ejecutarse en un contenedor docker. En mi humilde opinión, es un fastidio que uno tenga que recurrir a la antigua implementación del directorio de Novell cuando quiere usar .NET Core 2+ en Linux.
¡Gracias de todos modos por trabajar en ello!

¿Por qué cerrar este tema? System.DirectoryServices.AccountManagement todavía no está en .NET Core fuera de 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 todavía en el radar?

reabrir 14734

@JustinGrote, ¿cuál es la funcionalidad exacta que desea para el escenario? DirectoryServices es enorme y dudo que toda la funcionalidad pueda admitirse en una sola versión. Tener solicitudes específicas puede ayudar mejor que simplemente solicitar la compatibilidad con todas las bibliotecas de DS. En .NET 5.0 hemos habilitado un escenario https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
No sabía que System.DirectoryServices.Protocols había sido portado, pero parece que todavía depende de security.principal.windows, ¿funciona en Linux incluso con eso (a través de autenticación básica, etc.) o arrojará una falta? error de montaje?

El objetivo es volver a implementar algo como el módulo ActiveDirectory Powershell para que sea xplat, estaba considerando el módulo ldap de novell o ldap4net para ese propósito si no iba a haber al menos soporte de interacción básico disponible.

La implementación de ActiveDirectory Powershell es probablemente un caso de uso muy importante. Permítanme compartir mis dos casos de uso:

1) Estoy derivando de UserPrincipal ya que necesito atributos que no son compatibles de fábrica. Seguí https://stackoverflow.com/questions/24798037/extend-userprincipal-class y supongo que esto es una especie de estándar en el antiguo marco .NET, y hacer que ese enfoque funcione probablemente ayudará a más desarrolladores.

2) También tengo un código como el siguiente:

`

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

`

No tengo idea de lo que ya es compatible hoy, la última vez que lo comprobé fue en febrero.
Gracias, Joachim

@ jol64 ¿no puedes lograr lo mismo usando los Protocolos?

@ jol64 ¿no puedes lograr lo mismo usando los Protocolos?

Probablemente pueda. Reescribí algunas cosas para usar la biblioteca de Novell. Pero requiere una reescritura y, por lo tanto, un código redundante para mi código de marco .NET existente. Definitivamente prefiero evitar una división de código de todo el código, y estoy seguro de que a otros tampoco les gusta la idea.
También me pregunto cómo funciona la autenticación. Con Novell (la versión anterior que probé) tengo que especificar las credenciales, mientras que con mi código existente no necesito hacerlo.
Gracias, Joachim