@vibronet

Y a-t-il une mise à jour à ce sujet ?

Moi aussi j'aimerais une mise à jour à ce sujet. Mon entreprise me demande de créer une nouvelle application qui nécessite la possibilité d'interroger Active Directory via LDAP, mais il semble que cela ne soit actuellement pas possible. Y a-t-il un support prévu pour cela, est-il abandonné au profit d'autre chose, ou fonctionne-t-il déjà mais n'est documenté nulle part?

Un nouveau regard sur l'implémentation de la prise en charge LDAP et Active Directory serait formidable dans .NET CoreFX.

Nous avons vraiment besoin d'une solution Active Directory/LDAP que nous pouvons exploiter dans .NET Core. Qu'il s'agisse d'une implémentation de feuille blanche ou d'un port de System.DirectoryServices n'a pas autant d'importance pour moi. Il existe de nombreuses applications Windows axées sur les entreprises qui ont absolument besoin de l'authentification AD, et l'authentification LDAP serait une excellente fonctionnalité pour les développeurs multiplateformes.

D'accord sur les notes rétrocompatibles ci-dessus - je ne pense pas qu'un port direct soit vraiment nécessaire, nous avons juste besoin d'un moyen d'accéder à l'authentification (et d'effectuer d'autres actions : rechercher, déverrouiller, supprimer, etc.) contre Active Directory ou tout fournisseur LDAP .

@NickCraver

Je ne pense pas qu'un port direct soit vraiment nécessaire, nous avons juste besoin d'un moyen d'accéder à l'authentification [...] contre Active Directory

C'est bon à savoir. Ne lisez pas trop dans mon étiquette port-à-cœur que je viens d'appliquer. C'est juste ma façon de suivre les lacunes de l'offre .NET Core qui empêche les clients comme vous de porter leur application sur .NET Core.

@terrajobst Gotcha. Je ne pense pas nécessairement que cela doive être un élément 1.0 en raison de sa modularité (et il semble de toute façon qu'il soit prévu pour le post-RTM), mais je l'attends avec impatience. Ce sera un obstacle au portage d'Opserver pour moi, donc heureux de participer aux discussions sur l'API si nous pouvons être utiles. Nous avons un large éventail de cas d'utilisation du côté de l'administrateur système qui peuvent être utiles, ping si je peux aider.

Juste pour jeter un autre chapeau dans le ring. Pour le moment, c'est aussi le plus gros bloqueur qui me reste. Le simple fait de pouvoir auth serait d'une grande aide pour l'instant.

Pouvons-nous obtenir une réponse officielle de quelqu'un de l'équipe de développement sur les plans pour cela, s'il y a même des plans pour le soutenir ?

Je ne pense pas qu'un port direct soit vraiment nécessaire

Pourquoi? Désolé je suis confus. Ne serait-ce pas la solution la plus simple pour tout le monde et en accord avec le principe DRY ?
Néanmoins, s'il y a une raison d'écrire l'intégralité de l'API à partir de zéro, une certaine cohérence avec l'ancienne API (mêmes signatures de méthode) serait moins déroutante pour le consommateur.

@ jasonwilliams200OK laissez-moi clarifier, je voulais vraiment dire DirectoryServices.ActiveDirectory spécifiquement. Je pense à l'authentification et à tout ce qui l'entoure : par exemple, l'appartenance à un groupe est le cas d'utilisation à 95-99 % de l'espace de noms. Je pense qu'un portage direct des signatures de _that_ est assez utile. Si le reste justifie un changement pour une raison quelconque, je serais plutôt d'accord avec cela, et d'accord si cela venait plus tard ... l'autorisation serait bonne de sortir dès que possible car c'est un blocage pour beaucoup.

L'intégration d'au moins une fonctionnalité de base de recherche d'utilisateurs Active Directory et de leur mappage avec des rôles personnalisés avec ASP.NET 5 facilitera la mise en œuvre de l'authentification Windows dans les applications Web ASP.NET. Nous avons besoin de cette fonctionnalité sur notre site intranet.

C'est un blocage pour nous aussi. Nous devons pouvoir authentifier, interroger les utilisateurs et les groupes, créer de nouveaux utilisateurs et groupes, etc. sur un serveur LDAP.

C'est aussi un bloqueur pour moi - j'ai besoin d'interroger et d'authentifier les utilisateurs.

J'ai trouvé une solution pour s'authentifier auprès d'Active Directory dans une application Web .NET Core rc1. Il vous suffit de remplacer la méthode CheckPasswordAsync dans la classe UserManager. Laissez-moi savoir ce que vous pensez.

Vous devez d'abord créer une page d'inscription personnalisée qui permet à l'utilisateur de saisir un nom d'utilisateur AD au lieu d'une adresse e-mail et d'un mot de passe. Ce nom d'utilisateur va dans la propriété UserName de la classe ApplicationUser qui est générée par le modèle ASP.NET 5 lorsque vous avez choisi l'authentification des comptes d'utilisateurs individuels. En outre, vous devrez définir par défaut la propriété Password sur quelque chose qui passe la validation interne dans la classe IdentityUser.

Mon contrôleur de page de registre appelle une méthode Web API 2 qui trouve le nom d'utilisateur dans AD et renvoie JSON qui contient les informations AD pour cet utilisateur. J'ai ajouté des propriétés personnalisées à la classe ApplicationUser pour contenir les informations AD. Je posterai le code de mon projet la semaine prochaine.

Ajoutez ensuite un fichier de classe dans le dossier Services. J'ai nommé le mien ApplicationUserManager.cs. Ajoutez le code ci-dessous à ce fichier 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.
        }
    }
}

Ouvrez ensuite le fichier Startup.cs. Ajouter .AddUserManager() à l'appel AddIdentity dans la méthode ConfigureServices, comme indiqué ci-dessous.

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

Cela me permet au moins de configurer une autorisation basée sur les politiques/revendications en attendant le support de DirectoryServices.

Je compte sur cette bibliothèque. C'est dommage que je ne puisse pas porter maintenant.

@ClintBailiff Je dois intervenir ici - car relayer à nouveau le mot de passe de l'utilisateur sur le fil vers une autre application en clair est une _vraiment_ mauvaise idée. S'il vous plaît, n'utilisez pas cette approche. C'est une faille de sécurité.

@terrajobst , ce sera le bloqueur du portage de mes applications plus volumineuses comme Opserver - pouvons-nous, s'il vous plaît, donner la priorité à cela ?

@NickCraver Je n'ai jamais suggéré de transmettre les informations d'identification en clair. En règle générale, j'utilise SSL pour toutes mes applications/services Web car ils renvoient généralement des données que seuls les utilisateurs autorisés devraient voir. Je n'ai pas pensé à le préciser probablement parce que c'est tellement évident que vous ne voudriez pas envoyer les informations d'identification en clair.

Je serais favorable à au moins fournir un port de System.DirectoryServices.Protocols . Nous avons récemment changé notre code lié à LDAP pour prendre en charge une plus grande gamme de serveurs LDAP, car l'espace de noms System.DirectoryServices.ActiveDirectory n'aime parler qu'aux serveurs AD.

Je suppose qu'il serait possible pour une bibliothèque tierce de créer ce type de support, mais comme il existe déjà dans le framework, j'imagine qu'un port serait plus simple.

L'équipe WTF asp ne fournit pas cette fonctionnalité de base
C'est vraiment un problème de blocage :(

Une mise à jour sur le support LDAP dans CoreCLR ?

J'aimerais aussi une mise à jour à ce sujet. Je développerai une application d'entreprise avec ASP.NET Core qui doit authentifier les utilisateurs par rapport à un serveur AD.

Je vais étudier le portage de System.DirectoryServices vers .NET Core pour la v1.1.0 (https://github.com/dotnet/corefx/milestones)

@joshfree
Je dois également authentifier les utilisateurs d'ADLDS, veuillez également considérer System.DirectoryServices.AccountManagement

Il y a quelques années, la société pour laquelle je travaillais a pris le code source de la bibliothèque LDAP Novell (Mono) afin que notre application puisse communiquer avec les systèmes Active Directory, OpenLDAP et Oracle, et nous avons ajouté la prise en charge des contrôles paginés et mis à jour certains correctifs TLS. Nous l'avons fait car nous voulions fonctionner sous Linux. Un PR avec nos changements a été envoyé aux propriétaires. Comme nous voulons maintenant accéder à CoreCLR, cette bibliothèque devait être convertie en RC2. Le travail a commencé ici https://github.com/VQComms/CsharpLDAP/pull/1 , il reste 17 erreurs de compilateur qui doivent être corrigées. Ils sont principalement Thread.Abort , ThreadInterruptedException , remplaçant les flux TLS de Mono au CoreCLR SslStream Si quelqu'un est intéressé et a besoin d'un support LDAP pour CoreCLR, n'hésitez pas à aider.

J'ai confirmé qu'un projet RC2 d'application Web ASP.NET Core (.NET Framework) peut faire référence à une bibliothèque de classes qui utilise System.DirectoryServices.AccountManagement. Je ne pouvais le faire fonctionner que lorsque l'application Web et la bibliothèque de classes étaient créées avec VS 2015 Update 2 et qu'elles utilisaient toutes deux .NET Framework 4.6.1.

Juste pour faire écho aux sentiments des autres, nous sommes morts dans le portage de l'eau sans pouvoir interroger LDAP et autres.

@h3smith
Voir mon post précédent. Avec la version de RC2, vous pouvez désormais référencer une bibliothèque de classes qui utilise System.DirectoryServices.AccountManagement .

Pas sur Netstandard.

Cependant, comme je l'ai dit, nous travaillons pour que cela fonctionne. J'espère avoir
quelque chose dans environ 2-3 semaines

Le vendredi 17 juin 2016, Clinton Bailiff [email protected] a écrit :

@h3smith https://github.com/h3smith
Voir mon post précédent. Avec la sortie de RC2, vous pouvez désormais référencer un
bibliothèque de classes qui utilise _System.DirectoryServices.AccountManagement_.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679, ou muet
le fil
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

Des mises à jour à ce sujet ? Je dois authentifier l'utilisateur appelant, lorsque l'utilisateur utilise une application Web angulaire sur le réseau local, connecté à AD, appelant une méthode de contrôleur WebAPI (sans que l'utilisateur ne saisisse le mot de passe dans le navigateur Web) dans le noyau aspnet RC2. Possible? Bientôt possible ?

Pour ce faire, il vous suffit d'utiliser withCredentials dans vos requêtes http du client. Ensuite, vous pouvez obtenir des informations sur les utilisateurs et des réclamations dans vos contrôleurs en utilisant User.Identity.
Cela fonctionne dans ie et chrome mais avec Firefox, une fenêtre contextuelle sera automatiquement affichée pour que l'utilisateur tape son utilisateur et son mot de passe Windows

Nous avons rencontré le même problème (par exemple en essayant d'utiliser un serveur LDAP comme magasin d'utilisateurs) il y a environ deux mois. Nous n'avons trouvé aucune solution autre que le portage de la bibliothèque Novell LDAP (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) vers .net core (voir ici https://github.com/dsbenghe/Novell. Directory.Ldap.NETStandard). Il y a un paquet nuget publié. Nous utilisons la bibliothèque avec le serveur OpenDJ LDAP (devrait fonctionner avec n'importe quel serveur LDAP) - aucun problème en 1,5 mois d'utilisation.

@dsbenghe, nous venons de compiler notre bibliothèque Novell LDAP sur netstandard, la nôtre contient également la pagination. Cela a été fait par @igorshmukler . Vous souhaitez comparer et collaborer ? Le nôtre est WIP ici https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Merci pour votre travail sur l'implémentation de .NET Core.
Après avoir obtenu le package nuget, j'ai créé le code suivant pour tester si le mot de passe ActiveDirectory de l'utilisateur est correct

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

Il appelle 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;
}

Et utilise une simple classe d'assistance pour informer l'application angulaire de ce qui se passe

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

Pour UWP, il y a une demande pour cette fonctionnalité sur notre UserVoice : https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cc @tquerec @jimuphaus qui travaillera sur la prise en charge de System.DirectoryServices pour .NET Core.

Je ne peux pas attendre ! ETA ? Spécifications de conception ?

Lorsqu'il sera enfin transféré, aurons-nous accès à :

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

Je sais qu'il y a quelques défauts mineurs dans cet espace de noms, mais c'est quand même assez utile.

@GArrigotti lors des tests, l'utilisation de LdapDirectoryIdentifier est généralement plus rapide 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;  
}

Y a-t-il une ETA ? Je pourrais l'utiliser dans un système qui devrait être terminé à la fin de ce mois...

@johnkwaters y a-t-il une raison pour laquelle vous ne pouvez pas mettre le code AD dans une bibliothèque de classes ? Certaines personnes (dont moi) ont eu des problèmes pour référencer des bibliothèques de classes héritées dans une application ASP.NET Core. Mais il n'y a aucun problème si vous créez l'application Web et la bibliothèque de classes dans VS 2015 Update 3 et ciblez .NET Framework 4.61 dans l'application Web et la bibliothèque de classes.

y a-t-il une raison pour laquelle vous ne pouvez pas mettre le code AD dans une bibliothèque de classes ?

Voulez-vous dire PCL suivi de "imports": "portable-net45+win8" dans project.json pour .NET Core TxM ? Cela nécessitera que des assemblages de référence Mono PCL soient présents sur Unix et non une solution "pur donet-core", qui garantit l'autosuffisance sur Unix. C'est un bon hack pour faire taire le compilateur, mais ne fonctionne que si le CoreFX BCL a l'implémentation correspondante. En règle générale, le project.json sans "imports" pour netcoreapp/netstandard1.x est toujours meilleur. par exemple https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Une mise à jour sur un ETA ? Où puis-je accéder au libre-service pour répondre à cette question récurrente ?

_Vraiment_ impatient de découvrir cette fonctionnalité !

J'attends vraiment avec impatience cette fonctionnalité aussi !!

J'attends vraiment avec impatience cette fonctionnalité aussi !!

J'ai aussi désespérément besoin de cette fonctionnalité!

Les gars, pourriez-vous tous simplement ajouter des réactions au message principal ?

Ou utilisez les bibliothèques qui ont été mises sur nuget par 2 personnes distinctes. Son
tous les OSS. Si vous n'aimez pas le paquet, envoyez un PR

Le 8 septembre 2016 à 12h19, Mikhail Orlov [email protected]
a écrit:

Les gars, pourriez-vous tous simplement ajouter des réactions au message principal ?

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328, ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 pour @jchannon Novell LDAP. Cela nous a fait avancer et n'a apporté pratiquement aucune modification à notre implémentation LDAP. Je veux dire que vous résumez correctement, n'est-ce pas ;)

Oui, j'ai fini par utiliser @jchannon Novell LDAP aussi, cela a bien fonctionné.

Si je ne l'ai pas déjà dit, voici la branche sur https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Correspond bien à nos besoins du moment...

@h3smith @johnkwaters tous les problèmes n'hésitez pas à soulever un problème 😄

J'ai décidé d'essayer avec Novell, les exemples semblent assez bons mais je ne sais pas comment expulser (supprimer) un membre utilisateur d'un groupe avec Novell LDAP.
Je ne peux pas changer mon mot de passe sur MSAD LDAP car je ne vois pas userPassword et il n'a pas été défini sur le serveur LDAP.

Vraiment besoin de ça !

@joshfree ou toute autre personne au courant...
Nous cherchons à démarrer un nouveau projet qui a besoin d'accéder à ActiveDirectoryServices.AccountManagement Question, le port est-il ciblé pour 1.1 ou 1.2 ?

Il ne fait pas partie de la 1.1 (qui est sur le point d'être finalisée). @tquerec , pouvez-vous s'il vous plaît commenter vos plans ici ?

cc: @danmosemsft

Donc, si cela ne fait pas partie de 1.1, quelqu'un a-t-il un plan ? Cela semble être un problème majeur de ne pas avoir ce support. De toute évidence, Microsoft souhaiterait cette intégration.

Juste un autre vote pour. Difficile d'investir pour créer des systèmes de classe entreprise sur .NET Core lorsqu'il manque des fonctionnalités d'entreprise fondamentales. Le projet Novel fonctionne, mais n'est pas à la hauteur.

Encore un autre vote. Je ferai écho à la même déclaration selon laquelle cela fait partie intégrante de la création de toute application d'entreprise.

@nevcoBpalacio Je pense qu'ils essaient de nous pousser à utiliser Azure Active Directory

Cela ne fonctionnera jamais pour ceux qui utilisent des accords d'entreprise exigeant que les services restent en interne.

J'ai travaillé pour des agences gouvernementales, à la fois fédérales et maintenant locales, et dans tous les cas, vous auriez toujours besoin d'une interface ou de capacités à intégrer à un service d'annuaire, basé sur le cloud ou sur site. J'ai co-développé des applications gérant des milliards de dollars et toujours un besoin de services d'annuaire se fait sentir. Je pense que c'est plus qu'un autre vote, mais plutôt une déclaration de ce que vous attendez ? Je suis d'accord avec un article précédent selon lequel il s'agissait à l'origine d'une solution prête à l'emploi dans les versions précédentes de .NET. Je comprends que la structure plus ouverte de CORE devrait gagner l'élan de la communauté et si c'est ce que Microsoft choisit d'attendre, peut-être qu'ils l'ont dit et que je l'ai manqué, ils devraient le dire pour que quelqu'un puisse prendre l'initiative d'investir du temps pour le faire.

Oui, veuillez ajouter System.DirectoryServices à .NET Core !

Nous prévoyons de porter System.DirectoryServices.Protocols au cours de l'année prochaine. À ce stade, je ne peux pas fournir de date plus précise. Nous n'avons pas encore prévu de porter System.DirectoryServices ou System.DirectoryServices.AccountManagement, mais je souhaite évaluer l'intérêt. Y a-t-il des fonctionnalités de ces espaces de noms que les gens utilisent qui ne peuvent pas être résolues avec les protocoles ?

@tquerec Je ne connais pas les protocoles. Nous avons un projet de libre-service Active Directory pour déverrouiller le compte et réinitialiser le mot de passe du compte. Nous utilisons UserPrincipal dans le projet et invoquons les méthodes telles que FindByIdentity, UnlockAccount, SetPassword,, ExpirePasswordNow,.
Je ne sais pas si cela peut être fait sur les protocoles, mais il semble que les protocoles soient une implémentation de niveau inférieur par rapport à AccountManagement est une meilleure abstraction pour travailler avec ActiveDirectory.
Merci
Rockmeister

@nevcoBpalacio devrait certainement être plus qu'un vote, je suis d'accord. Je pense que cela a vraiment besoin de plus de priorité.

@CalebMacdonaldBlack , il serait utile que vous puissiez répondre à la question @tquerec sur les modèles d'utilisation et pourquoi est-ce nécessaire. Plus de votes positifs ou "Je suis d'accord/c'est important" sans scénarios n'aideront pas à augmenter la priorité en ce moment... Merci !

Notre utilisation consiste à analyser/rechercher LDAP, à effectuer BIND pour vérifier les informations d'identification, à ajouter/supprimer des objets LDAP (utilisateurs, groupes), à modifier l'appartenance à des groupes, etc.

@tquerec J'ai vraiment besoin de System.DirectoryServices.AccountManagement pour pouvoir authentifier nos utilisateurs par rapport à Active Directory et les autoriser sur les groupes auxquels ils ont accès.

tout à fait d'accord avec h3smith. avoir l'air mauvais comme effet secondaire ..

@liquidboy

nous en avions besoin pour la v1

Voulez-vous dire .NET Core v1 ? -- c'est fait et expédié. Nous travaillons actuellement sur la 1.2. Ou vouliez-vous dire autre chose ?

à la place sont obligés d'emprunter le chemin du roman

Qu'est-ce que ça veut dire? (Désolé, je n'ai aucun contexte sur DirectoryServices, mais j'aimerais comprendre ce qui nous manque du point de vue des scénarios)

@karelz fait juste une recherche dans ce fil pour le mot "roman" et vous verrez ce que je veux dire. Un autre développeur (dsbenge) de mon équipe a commenté (avec d'autres) l'écart qui nous a amenés à utiliser novel. [voici le lien vers le commentaire ci-dessus https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

Et oui, je voulais dire .NET Core v1 qui a déjà été livré, nous travaillons sur notre solution depuis plus d'un an et nous avions besoin d'une bonne solution DirectoryServices à l'époque. Nous avons heurté un mur et n'avions donc pas d'autre choix que d'utiliser un roman .

@liquidboy merci pour le lien - s'il est en Mono, nous devrions pouvoir réutiliser le code source dans .NET Core AFAIK. @tquerec compte tenu de l'intérêt, est-ce quelque chose que votre équipe envisagerait ?

@tquerec : Nous avons besoin des éléments suivants :
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory et System.DirectoryServices.Protocols.

Ceux-ci sont nécessaires pour se connecter et gérer les utilisateurs, les groupes et les attributs d'Active Directory (et d'autres serveurs LDAP), comme décrit dans les réponses ci-dessus. Il est important d'avoir ces fonctionnalités dans .Net Core !

Je suis d'accord avec les autres. J'en ai besoin pour porter n'importe laquelle de nos applications qui s'authentifient sur ActiveDirectory vers .NET Core. C'est assez fondamental, cela devrait certainement être dans la version la plus rapide possible. C'est le bloqueur du portage de tant de choses.

La page de la feuille de route .NET Core (https://github.com/dotnet/core/blob/master/roadmap.md) a ce plan pour .NET Core 1.2 : "amener .NET Core à parité avec .NET Framework et Mono pour un grande collection de types de base."

Je pense que le portage de System.DirectoryServices correspond très bien à ce plan et devrait en effet faire partie de la version 1.2. Juste mes 5 cents (euro) :)

Juste pour clarifier : les API portées en 1.2 ont été choisies en fonction des données d'utilisation (et rarement de la complexité) - @weshaggard @danmosemsft pouvez-vous donner des détails, pourquoi nous n'avons pas inclus System.DirectoryServices ?

La liste des assemblages que nous avons choisi de faire correspondre est ici . @weshaggard devra me rappeler comment il a choisi cette liste. (Mono a S.DirectoryServices)

Je pense que vous pourrez faire à peu près tout ce dont vous avez besoin pour parler avec ActiveDirectory (et d'autres serveurs LDAP) en utilisant System.DirectoryServices.Protocols, mais beaucoup de gens devront réécrire leur code pour utiliser S.DS.Protocols.

Personnellement, je préférerais que MS porte S.DS.Protocols et MS ou la communauté pour créer une bibliothèque facile à utiliser pour la gestion des utilisateurs/groupes en plus de cela.

La liste des assemblages que nous avons choisi de faire correspondre est ici. @weshaggard devra me rappeler comment il a choisi cette liste. (Mono a S.DirectoryServices)

L'amorçage initial a été effectué à partir de l'intersection de profils Xamarin avec .NET Framework. Les profils Xamarain (qui est un sous-ensemble de mono) ne prennent pas en charge DirectoryServices, c'est pourquoi ce n'était pas dans l'intersection.

Que pouvons-nous faire pour affirmer que cela devrait figurer ? L'impossibilité d'utiliser le schéma d'authentification le plus courant dans les applications Microsoft est un peu bloquante, non ? L'accent est-il mis sur Azure ici et sur AAD à la place ? Ou est-ce que le bloqueur que le portage de ceci à travers les plates-formes est une plus grande inconnue des protocoles ?

Existe-t-il un moyen d'augmenter la priorité ici ? 2.0 est encore loin, et c'est vraiment dommage si _tout_ le reste fonctionne, mais nous ne pouvons pas authentifier les utilisateurs. C'est la porte d'entrée virtuelle pour tant d'applications. IMO, en termes de priorité, c'est un peu différent car ce n'est pas un bloqueur partiel, mais souvent un bloqueur complet par nature.

Je ne pense pas qu'il y ait de désaccord sur le fait que nous voulons prendre en charge cela dans .NET Core, ce qui est différent de faire partie de .NET Standard, c'est juste une question de quand. @tquerec est propriétaire de la zone et serait celui qui en parlerait.

Quelqu'un de .NET Foundation a demandé, mais les espaces de noms que nous utilisons spécifiquement sont :
System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

Alors, @tquerec , comment faire pour que System.DirectoryServices soit marqué pour .NET Core 1.2 ? Au moins System.DirectoryServices.Protocols. Est-ce possible?

Merci beaucoup!

[mis à jour avec plus d'infos de @tquerec]
J'ai rencontré @tquerec lundi. Je dois à tout le monde une écriture. En résumé:

• Système. DirectoryServices est faisable sur Windows uniquement (il appelle dans Windows DLL où vit toute l'implémentation), totalement inconnu pour Linux/Mac
• System.DirectoryServices. AccountManagement se trouve au-dessus, donc également faisable uniquement pour Windows et inconnu pour Linux/Mac
• System.DirectoryServices. ActiveDirectory est faisable sur Windows uniquement (il appelle de nombreuses API spécifiques à Windows)
• System.DirectoryServices. Les protocoles doivent être raisonnablement simples pour Windows et plus de travail pour Linux (nous devons trouver une bibliothèque LDAP à utiliser).
  Nous essayons de comprendre avec @tquerec comment financer le travail - idéalement pour la 1.2, mais aucune promesse pour le moment. Je m'attends à ce que la décision prenne au moins deux semaines.

Questions à tous :

• La portée Windows uniquement ci-dessus est-elle acceptable pour les principaux cas d'utilisation ? (Sys.DirSer et Sys.DirSer.AccountManagement et Sys.DirSer.ActiveDirectory)
• Si Sys.DirSer.Protocols Linux vient après la version 1.2 ou s'appuie sur les contributions de la communauté, serait-ce un obstacle majeur ?

@karelz System.DirectoryServices.ActiveDirectory est basé sur un grand nombre d'API spécifiques à Windows, il tombe donc dans le même compartiment que S.DS et S.DS.AM.

@karelz Je ne suis pas sûr de ce que vous entendez par une solution Windows uniquement pour 1.2. Nous avons déjà une solution Windows uniquement qui fonctionne.

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

@rock-meister Je veux dire .NET Core. Celui que vous avez mentionné cible "full" .NET 4.5.2+.

Oui, la prise en charge de Windows uniquement est un énorme débloqueur pour nous. Nous pouvons faire tout le travail pour le portage .NET Core et étendre les supports de plate-forme "gratuitement" plus tard, lorsque les bits sous-jacents le font. Juste pas le bloqueur pour même _starting_ au port est énorme. Ce départ est une grande victoire.

Étant un magasin Windows, ce serait également une grande victoire ici. Tant de grandes entreprises considéreraient cela comme une énorme victoire ! Merci de vous tenir au courant de vos informations. Tenez-nous au courant. Merci.

@karelz Merci pour la clarification. Oui, la portée de Windows uniquement pour 1.2 fonctionne pour nous.
Rockmeister

System.DirectoryServices.Protocols avec le support Linux /LDAP est la plus haute priorité pour le travail que nous faisons.

ps la portée de Windows uniquement semble aller à l'encontre des objectifs de .netcore / .netstandard

Nous sommes passés de l'utilisation de System.DirectoryServices à l'utilisation System.DirectoryServices.Protocols il y a quelque temps afin de pouvoir prendre en charge les serveurs LDAP non-AD. Avoir accès à l'espace de noms Protocols serait un pas de plus pour nous permettre de porter notre code sur le noyau .NET.

Cependant, si cela doit être spécifique à la plate-forme, cela nous servira moins. La portabilité de la plate-forme est l'un des principaux points de la migration vers le noyau .NET. Nous devrons probablement encore attendre cela.

Pour nous, accéder à .NET Core était la possibilité de tirer parti de Docker et d'être totalement indépendant de la plate-forme. Donc, être bloqué avec le support LDAP de Windows uniquement ne serait pas bénéfique.

Merci d'avoir discuté en interne.

Mon vote va avec une route indépendante de la plateforme 🦃

Je suis d'accord avec le commentaire agnostique de la plate-forme, même si cela fait mal de ne pas pouvoir utiliser le noyau tant que cela n'est pas accompli. Je pense que c'est quelque chose qui doit être revu à un niveau supérieur. La chose que je ne comprends pas, c'est la complexité du concept? Il existe plusieurs solutions d'annuaire, AD, Novell, etc... Cela nécessite une solution d'interface multiplateforme (agnostique)... Joyeuses Fêtes !

Alors que personnellement, je pourrais parfaitement vivre avec une portée Windows uniquement, à mon avis, cela brise l'idée du .NET Core et de sa portabilité.
Une solution indépendante de la plate-forme devrait être la voie sur laquelle se concentrer.

Oui, d'accord, .NET Core doit être multiplateforme et les fonctionnalités/API doivent fonctionner sur toutes les plateformes prises en charge !
Donc, si System.DirectoryServices.Protocols doit être porté/implémenté en premier, cela devrait également fonctionner sous Linux.

Je suis d'accord que, idéalement, une solution indépendante de la plate-forme devrait être l'objectif. Bien que ne l'ayant toujours pas sur Windows soit un obstacle pour de nombreux développeurs qui souhaitent simplement expérimenter la plate-forme dans un environnement d'entreprise (AD), comme moi. C'est pourquoi j'accueillerais favorablement une solution Windows uniquement pour le moment.

Je voudrais simplement intervenir et dire que je suis d'accord avec une solution Windows uniquement jusqu'à ce que quelque chose de multiplateforme puisse être mis en place.

J'imagine que 99,9 % des développeurs qui ont besoin de se connecter à Active Directory le font dans un environnement d'entreprise où ils développent sur des machines Windows.

Nous discutons du financement de notre côté (mise à jour prévue dans environ 2 semaines), c'est actuellement la priorité absolue des API qui ne font pas encore partie de .NET Standard 2.0.

Y a-t-il des gens autour qui seraient prêts à aider/contribuer à l'implémentation de Windows et/ou à l'implémentation de Linux ? (nous pourrions déposer le code de Desktop et cela nécessiterait un massage supplémentaire pour construire + quelques tests)

@karelz J'adorerais contribuer pour le côté Linux des choses. Nous avons besoin de cette prise en charge pour l'authentification Windows et non Windows (sur site). C'est un bloqueur pour nous, et nous ciblons le noyau .NET pour notre projet multiplateforme (auparavant, c'était Mono du côté Linux et .NET du côté Windows).

Voudrais aider là où nous le pouvons, sans aucun doute.

J'aimerais beaucoup aider, mais je suis sûr que vous avez beaucoup plus d'expérience que moi et que je ne vous serais d'aucune utilité.

@karelz @tquerec Je serais heureux d'aider aux tests sur Windows et, à l'avenir, sur Linux. Je me suis abonné au fil de discussion, alors répondez simplement ici ou mentionnez-moi pour entrer en contact lorsque vous avez besoin que je m'implique. Merci pour votre travail à ce sujet. Il est attendu depuis longtemps et, même s'il est incrémentiel, ce sera une bonne étape vers une adoption plus poussée de .NET Core.

Je pense que "Windows étendu" est une bonne cible au départ, "étendu" signifiant qu'il fonctionne sur NanoServer et dans les conteneurs (c'est-à-dire des machines non jointes à un domaine qui ne peuvent pas exécuter le CLR .NET complet). Cela vous donnera une victoire rapide et un point de départ pour travailler en arrière pour l'implémenter sur d'autres serveurs.

Nous avons travaillé avec @tquerec et nos chaînes de direction pour trouver le meilleur moyen de débloquer ce travail au plus vite. Malheureusement, nous n'avons personne de libre avant fin janvier, nous essaierons donc de faire de notre mieux en attendant pour débloquer les contributions de la communauté avec des ressources limitées et du travail bénévole de notre côté ( @ianhays @tquerec et @karelz).

Voici ce que nous prévoyons de faire :
@ianhays nous aidera à lancer le projet dans le référentiel CoreFX (ajouter du code source, montrer des exemples comment le faire, conseiller sur la configuration de la construction, l'empaquetage, préparer le projet pour les futurs ports Linux/Mac, etc.).
Nous commencerons par une implémentation Windows uniquement (les contributions sont les bienvenues). Nous n'apporterons aucune modification fonctionnelle à l'implémentation ou à la surface de l'API à ce stade, sauf si elles sont nécessaires pour le port vers .NET Core.
La prochaine étape (potentiellement parallèle) consistera à ajouter des tests. Nous devrions lancer la discussion avec @tquerec sur la conception de test existante (.NET Framework à source fermée) s'il y a quelque chose que nous pouvons exploiter, ou si nous devons repartir de zéro.
Plus tard, nous pourrons nous concentrer sur les ports Linux/Mac.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte, et toute autre personne intéressée, nous serons heureux de recevoir vos contributions une fois que @ianhays aura lancé l'effort (ETA : mi-semaine prochaine, je pense). Si vous avez des questions ou des suggestions, veuillez nous en informer.

Cela permet-il également aux bibliothèques telles que SqlClient d'effectuer l'authentification Windows lorsqu'elles s'exécutent sous Linux mais se connectent à un serveur SQL qui nécessite l'authentification Windows ?

C'est l'un de mes obstacles à la possibilité de porter des choses sur .NET Core sous Linux. Tous nos serveurs Microsoft SQL d'entreprise autorisent uniquement la connexion via un ID de service (non interactif) qui se trouve dans AD.

blgboy. Votre problème est un excellent exemple de la raison pour laquelle les choses doivent être "vérifiées" pour assurer une véritable compatibilité multiplateforme avec les nouveaux modèles suggérés. Si vous avez plus de scénarios, je pense que votre environnement est un bon exemple de la façon dont les choses doivent se croiser et vous devriez énumérer tous les autres problèmes que vous rencontrez avec la partie AD de Core.

Oui, je vais certainement garder ce fil à l'esprit et partager tout ce que je trouve. Je voulais juste faire savoir à tout le monde qu'il s'agit d'un gros bouchon de spectacle pour les entreprises avec des fermes SQL qui ont une sécurité stricte comme décrit.

C'est également un obstacle à l'utilisation de quelque chose comme EF Core qui aurait finalement le même problème.

System.DirectoryServices est maintenant fusionné avec CoreFX. L'étape suivante consiste à le faire construire pour .NET Core - Windows et à ajouter des tests.

Merci Ian. C'est bon de voir un peu de traction sur cette question!

Merci Ian !

Plan d'exécution mis à jour : EDIT : déplacé vers le premier article de ce numéro pour une meilleure visibilité

Si quelqu'un travaille sur une étape, veuillez le mentionner et coordonner ici pour éviter les efforts en double. Je vous coattribuerai également le problème.

Les espaces de noms System.DirectoryServices contiennent des fonctionnalités si importantes pour les applications Windows d'entreprise sur site qu'il est formidable de constater des progrès sur ce problème. Continuez votre bon travail.

J'ai corrigé les sources et System.DirectoryServices est en train de se construire. Je devrais bientôt envoyer un PR.

Merci @tquerec d'avoir contribué au deuxième tour !
Y a-t-il des volontaires pour aider avec les 2 espaces de noms ou tests restants ? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 a un PR ici https://github.com/dotnet/corefx/pull/15324 pour ajouter un support supplémentaire et obtenir la construction de Protocols/AccountManagement.

Pour ce que ça vaut, j'ai récemment expérimenté System.DirectoryServices.Protocols et j'ai découvert que de nombreux scénarios simples de System.DirectoryServices ne sont pas difficiles à imiter avec System.DirecotryServices.Protocols. Sur cette base, je pense que le fonctionnement multiplateforme de S.DS et S.DS.AM peut être une priorité moindre, car un System.DirectoryServices.Protocols multiplateforme pourrait constituer une solution de contournement utile pour de nombreux utilisateurs.

Bien entendu, cela signifie que le fonctionnement de System.DirectoryServices.Protocols en tant que solution LDAP multiplateforme reste une priorité élevée.

Suis-je en train de lire la pull request, n'est-ce pas ? On dirait que cela a été accepté il y a quelques jours, donc si nous construisons à partir de la source, nous devrions pouvoir l'essayer ?

Oui, je pense que nous avons tous construit DirectoryServices, mais nous n'avons aucun test - ce qui nous empêche d'expédier le paquet comme stable et d'améliorer la base de code (corrections de bogues, améliorations, etc.).
Si vous pouviez essayer de construire à partir de la source, ce serait formidable. Si vous (ou quelqu'un d'autre) voulez nous aider à ajouter des tests ou à démarrer le port Linux, ce serait encore mieux :)

Salut à tous,

Nous nous préparons à démarrer un projet d'entreprise qui nécessite le support d'Active Directory car nous sommes 100% internes à notre domaine. Quelqu'un peut-il fournir le statut de ce problème et les attentes pour la prochaine version principale ? Je m'excuse, mais je suis nouveau dans la communauté GitHub et je ne comprends pas encore toutes les différentes terminologies et informations de statut.

Ce serait formidable d'utiliser Active Directory pour l'adhésion au lieu d'un modèle d'identité entièrement distinct qui devrait être géré séparément et qui entraînerait également une inadéquation des données.

Merci d'avance!

@karelz pour cette question, mais je pense que la réponse est que cela n'est pas actuellement prévu dans la version 2.0, car nous n'avons pas de développeur prévu pour cela. Les contributions de la communauté sont les bienvenues. il n'a pas besoin d'être livré _in_ la version 2.0, il peut sortir sur NuGet à tout moment, il est prêt à être livré.

Parfait! Vous avez répondu à ma question.

Merci.

@nevcoBpalacio est-il intéressé à essayer une contribution ?

J'ai un intérêt, en particulier avec ce sujet car je sais qu'il empêche beaucoup d'aller au cœur des solutions d'entreprise. Cependant, nous avons du travail et je n'arrive pas à trouver le temps dans la journée (soirée avec les enfants) pour cela. Je vais essayer de rééquiper mon système à la maison pour travailler avec GitHub. J'apprécie que vous demandiez si! Merci.

Nevcobpalacio, si vous utilisez vs17 et que vous n'avez pas besoin de cross plat, vous pouvez vous rapprocher un peu de ce que vous voulez en utilisant le modèle d'application Web de base ciblant le framework .net complet et en référant la dll system.directoryservices.accountmanagement à l'ancienne et lancez votre propre middleware pour le faire en attendant. D'après ce que j'ai vu, le même code devrait être transféré au ciblage du noyau .net une fois qu'il sera disponible, sauf que vous utiliserez le package nuget et supprimerez la référence. J'espère que ces informations vous aideront à mettre votre projet sur la bonne voie.

@ los93sol merci pour cette suggestion. Nos discussions initiales sont de le construire de la même manière que cette suggestion et d'en faire un module intermédiaire que nous pouvons "couper" vers tout ce qui atterrira ultérieurement dans Nuget. Merci beaucoup !

Je dois commenter et vous féliciter pour cette suggestion. J'étais sceptique au début sur ce changement de noyau. Cependant, avec cette approche communautaire, des discussions comme celle-ci se font jour et nous aident tous à arranger les choses lors de ces changements majeurs.

Merci.

Quelqu'un travaille-t-il actuellement sur l'ajout des tests manquants ou sur le portage de System.DirectoryServices.Protocols vers Linux/Mac ?

@pasikarkkainen AFAIK, il n'y a pas un tel effort actif pour le moment de la part des équipes Microsoft (ce qui pourrait ou non changer dans un avenir proche). Je n'ai vu personne de la communauté commencer à travailler dessus non plus.
Êtes-vous intéressé à contribuer ou simplement curieux de connaître le statut ?

@karelz Il semble qu'ils ciblent les DirectoryServices pour la version .NET Core 2.0 cet été.

Citation de @shanselman

AD - Totalement, c'est une lacune SI vous souhaitez appeler LDAP directement. Vous pouvez certainement vous authentifier contre Windows Auth MAINTENANT. Nous prévoyons d'avoir spécifiquement l'espace de noms DirectoryServices pour Core 2.0 vers l'été

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

Oui, cela correspond aux discussions de couloir que j'ai entendues. Je ne savais tout simplement pas s'il s'agissait d'informations publiques et combien (et qui) s'y était engagé. Je pense qu'il est prudent de dire que cela fait l'objet d'un très sérieux examen et que cela va probablement se produire. Je laisse les propriétaires de @shanselman & DirectoryServices commenter les délais.

@karelz : Merci pour la mise à jour ! J'étais surtout curieux de connaître le statut. Je peux certainement aider avec les tests au moins, quand cela sera disponible.

@pasikarkkainen si vous êtes également prêt à aider à écrire des cas de test, ce serait très apprécié.
Si vous voulez "juste" tester le package sur votre application/code, cela devrait être faisable aujourd'hui. Nous avons juste besoin de commencer à publier le package en tant qu'aperçu sur myget (je pense que la publication est désactivée aujourd'hui).

@karelz Cela ne me dérangerait pas d'aider spécifiquement à la mise en œuvre de Mac. J'ai peu de connaissances, donc je ne sais pas dans quelle mesure je peux contribuer. J'ai fait des recherches à ce sujet et il y a une bibliothèque de romans que les gens semblent suggérer. J'ai trouvé l'implémentation de quelqu'un d'autre autour de cette bibliothèque novell ici : https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt L'auteur du package l'a déjà mentionné ici.
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

Alors est-ce quelque chose qui sera dans le core 2.0 ? Je suis un peu confus quant à son statut.

Non, il ne fera pas partie de .NET Core 2.0, cependant, lors de la conférence Build, nous avons promis la disponibilité du package pendant l'été. Le package (Windows) devrait être disponible sur .NET Core 2.0, à peu près au moment où .NET Core 2.0 sera livré.
Nous travaillons actuellement à rendre les packages disponibles en aperçu dans la branche master (#18090) et à travailler sur des actifs de test en parallèle (#20669).

Obtiendrons-nous des erreurs de compilation lorsque nous ciblons le runtime partagé ou un runtime non Windows ? Ou allons-nous nous retrouver avec le PlatformNotSupported ?

Ce sera un package autonome sans aucun actif non Windows. La compilation devrait casser. @ericstj peut confirmer.

Vous n'obtiendrez pas d'erreurs de compilation, ce seront des exceptions d'exécution "PlatformNotSupported".

Ouais, c'est l'ancien - bloquons-nous les personnes qui l'utilisent à partir des bibliothèques .NET Standard, ou transformons-nous les erreurs de compilation en exceptions PlatformNotSupported ? ... Heureusement, il existe un juste milieu : les outils ApiCompat vous indiqueront à l'avance que vous utilisez quelque chose qui n'est pas partout.

J'obtiens l'erreur suivante lorsque j'essaie de packager System.DirectoryServices dans le projet netstandard 1.6 :

Install-Package : Le package System.DirectoryServices 4.0.0 n'est pas compatible avec netstandard1.6 (.NETStandard,Version=v1.6). Le package System.DirectoryServices 4.0.0 prend en charge : net (.NETFramework,Version=v0.0)

Existe-t-il un contournement ou une solution pour cela?
Salutations,
Varun

@ vrn11 ce package provient d'un autre fournisseur et ne prend en charge que le framework net complet

Quoi qu'il en soit, je voulais demander s'il y avait une mise à jour à ce sujet. Peut-être un package de prévisualisation que nous pouvons récupérer sur myget ? Ce serait génial de tester ça

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

Comme @MarcusKohnert l'a mentionné, vous pouvez les récupérer sur https://dotnet.myget.org/F/dotnet-core/api/v3/index.json. Il y a System.DirectoryServices, System.DirectoryServices.AccountManagement et System.DirectoryServices.Protocols.

Impressionnant! merci à @MarcusKohnert et @ericstj pour les liens !

J'essaie les packages 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" />
Lors de l'exécution sur un MacOS 10.12.6, et lors de l'exécution :

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

Je suis en train:

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

Est-ce que PrincipalContext devrait fonctionner sur un Mac ?

@bruno-garcia il n'y a pas d'implémentation dans CoreFX pour le moment pour DirectoryServices sauf sur Windows. @karelz devrait parler des plans/aspirations s'il y en a.

Seul System.DirectoryServices.Protocol est potentiellement faisable x-plat (pas encore implémenté) - voir les détails dans certaines de mes réponses ci-dessus et dans le premier article.

Faire en sorte que System.DirectoryServices.Protocols fonctionne sur plusieurs plates-formes (également sur Linux/Mac) est important... ai-je bien compris que le principal problème actuellement est que la bibliothèque LDAP utilisée par System.DirectoryServices (sur Windows) n'est pas open source, et donc uniquement fonctionne sous Windows ?

Si j'ai bien compris, System.DirectoryServices sera difficile à créer xplat en raison de nombreuses dépendances sur les interfaces COM ADSI, qui ne sont disponibles que sur Windows.

System.DirectoryServices.Protocols devrait toujours être possible pour exécuter xplat.

Exécution du même code que j'ai mentionné précédemment :
```c#
en utilisant (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

Sur un Win7 x64 avec .NET Core 2.0, cela donne :

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)

J'ai utilisé les packages :

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

[EDIT] Correction de la mise en évidence de la syntaxe de la pile d'appels et du code xml/C# par @karelz

@bruno-garcia, veuillez déposer un numéro séparé. Celui-ci suit l'effort global du port, pas les bugs/différences particuliers. Merci!

@bruno-garcia suivi par https://github.com/dotnet/corefx/issues/23605

La prochaine étape peut être de déboguer via le bureau et de voir où le comportement diverge. Je vais essayer de libérer un développeur pour le regarder.

Même problème sur le serveur 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'en pensez-vous, quand cela fonctionnera-t-il?

avoir un problème lors de la tentative d'installation d'un paquet

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 quelqu'un a le même problème que moi, utilisez .NET CLI à la place

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

@papamamadoii c'est parce qu'il vous manque https://dotnet.myget.org/F/dotnet-core/api/v3/index.json comme source et apparemment Install-Package n'a pas utilisé votre flux spécifié pour trouver des dépendances. Vous voudrez peut-être signaler un bogue sur http://github.com/nuget/home avec des étapes de reproduction spécifiques.

@karelz Si je comprends bien les commentaires, cela ne fonctionne pas sur les déploiements basés sur Linux?

@euclid47 System.DirectoryServices.* n'est actuellement pas pris en charge sous Linux. Comme indiqué ci-dessus, certaines parties de celui-ci pourraient potentiellement être portées si l'intérêt/la participation de la communauté est suffisant.

@danmosemsft Je ne comprends pas comment vous ne pouvez pas voir tout ce fil ouvert depuis octobre 2015 comme un intérêt communautaire suffisant. Si je possédais les compétences requises pour écrire quelque chose d'aussi compliqué qu'une couche de communication LDAP, j'aurais déjà travaillé dessus, car l'AD était l'un des mécanismes d'authentification de base dans un environnement d'entreprise. Je soulignerai que pour la plupart des grandes entreprises, l'incapacité d'effectuer ce type d'interactions sur Linux va littéralement à l'encontre de l'objectif de Core et les obligera à s'en tenir aux versions pré-core de dotnet, limitant ainsi votre précieuse interaction avec la communauté.

@danmosemsft De plus, si vous ne prévoyez littéralement pas de travailler là-dessus, faites-le savoir définitivement à la communauté afin que d'autres développeurs puissent ramasser les morceaux.

@shairozan jusqu'à présent, nous avons noté 7 votes sur 54 qui considèrent DirectoryServices sur Linux comme une priorité plus élevée que Windows - voir https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
Il existe également d'autres avantages que les développeurs retirent de .NET Core en plus de la plate-forme x (bien que je convienne que x-plat est l'une des principales raisons).

Je recommanderais de terminer d'abord la publication du package Windows uniquement, puis nous pourrons ouvrir un nouveau problème pour suivre plus précisément l'intérêt pour le port Linux.

Nous avons déjà dit à la communauté que nous recherchions de l'aide et que le problème est à saisir - voir https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. Et @hughbe a aidé avec la première série de tests pour DirectoryServices - voir l'historique ici , ici et ici .

@karelz Où est géré le vote pour ces composants ? Je peux vous garantir qu'après SELF / POSSCON, vous verrez une augmentation assez drastique de l'intérêt.

@karelz Où est le vote pour cette fonctionnalité ? Je suis absolument d'accord avec @shairozan avec le besoin. Il y a un commentaire dans ce numéro qui décrit notre environnement de développement et de production. Il est assez choquant qu'il n'y ait eu aucun mouvement sur la mise en œuvre depuis que les évangélistes de .Net Core prêchent qu'il est indépendant de la plate-forme.

J'ai créé un nouveau problème pour suivre le port Linux/Mac dotnet/corefx#24843 pour un vote plus facile que sur le commentaire au milieu de ce problème (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

J'ai également ajouté le lien dans le premier article de ce numéro.

@ euclid47 jusqu'à présent, le vote concernait ce numéro - voir les liens ci-dessus. C'est ce qui a résulté en 7 votes (+1 pour le soumissionnaire original du problème).

Notre équipe a besoin d'un support LDAP sur Linux.
Parce que la plupart de nos clients utilisent l'authentification via LDAP.

@balkarov Si vous le pouvez, votez pour le problème que @karelz vient de créer ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 Si vous ne le savez pas déjà, il existe le package Novell.Directory.Ldap.NETStandard Nuget que vous pouvez utiliser pour intégrer LDAP dans vos projets. Nous ne sommes pas des utilisateurs avancés de LDAP, nous l'utilisons simplement pour valider les informations d'identification et obtenir des informations sur l'utilisateur, mais cela fonctionne bien pour nous, à la fois sur 1.0 et 2.0 fonctionnant sur l'image docker d'exécution dotnet core. Ce n'est pas un moyen officiel, mais le travail est fait jusqu'à ce qu'il y ait un port multiplateforme de System.DirectoryServices .

@OskarKlintrot merci. Mais cette bibliothèque ne prend pas en charge la connexion sans domaine.
Je crée un problème https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
Pouvez-vous m'aider à résoudre ce problème ?

Je ne fais pas partie de ce projet ou un utilisateur avancé mais je vais y jeter un œil, à bientôt !

(Nous ne nous connectons pas avec un domaine)

Étant donné que @karelz a signalé un problème pour Unix, j'ai renommé celui-ci pour plus de clarté.

@danmosemsft mais le problème a un plan
Ports Linux/Mac.

@balkarov J'ai mis à jour le plan pour créer un lien vers d'autres problèmes de suivi et supprimé les cases à cocher pour les éléments suivis séparément (travail interrompu) ou ne bloquant pas le travail de Windows.

Le port System.DS sera-t-il compatible avec les serveurs RODC (contrôleurs de domaine en lecture seule) ?

@PKGeorgiev , vous devriez obtenir le même support System.DirectoryServices que nous avons dans le cadre complet.

Le travail sur DirectoryServices pour Windows est terminé, fermant le problème.
Noter:

• La publication finale du package est suivie par dotnet/corefx#24909
• Le port Linux/Mac est suivi séparément par dotnet/corefx#24843

Salut, cela fonctionnera-t-il dans UWP?

Salut, cela fonctionnera-t-il dans UWP?

Non, il n'est pris en charge que pour les applications Net Core exécutées sur Windows et le framework complet. si vous l'utilisez dans UWP ou sous Linux, vous obtiendrez une exception PlatformNotSupported.

J'utilise ce code dans une fonction lambda dans AWS qui s'exécute sur Linux en arrière-plan et j'obtiens cette erreur. "System.DirectoryServices.AccountManagement n'est pas pris en charge sur cette plate-forme."
J'utilise le noyau 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 Oui, cela n'est pas encore pris en charge sous Linux. Il est pris en charge sur Windows uniquement.

@sscoleman , un problème a été créé dessus, https://github.com/dotnet/corefx/issues/24843. On a dit qu'il n'y avait pas assez d'intérêt communautaire à l'exception de cette question qui revient tout le temps. Alors maintenant, vous êtes dans un endroit de merde. Vous avez passé du temps à implémenter des services d'annuaire, puis vous avez découvert que Linux est pris en charge. Maintenant, vous vous demandez pourquoi cela est présenté comme indépendant de la plate-forme s'il n'y a que des fonctionnalités Windows.

C'est assez évident si vous regardez la stratégie globale de Microsoft. Microsoft met TOUTES ses ressources de développement dans Azure, et cela inclut Active Directory. Découvrez "Quoi de neuf en 2016", il s'agit principalement d'investissements AzureAD/Hybrid. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft n'investit pas dans cette bibliothèque pour Linux car ils souhaitent que tout le monde passe plutôt à Azure AD. C'est logique, pourquoi investiriez-vous dans quelque chose dont vous essayez d'éloigner les clients ?

Vous faites quelque chose de relativement simple cependant. Vous pouvez utiliser les bibliothèques Novel LDAP, elles fonctionnent avec AD et sur .NET Core pour Linux. Vous devez faire le travail de protocole vous-même, mais ce n'est pas trop complexe, et il y a beaucoup d'échantillons là-bas. L'inconvénient est que vous devez gérer vous-même la liaison, ce qui nécessite un nom d'utilisateur et un mot de passe.

System.DirectoryServices est actuellement une API Windows uniquement et fait partie du pack de compatibilité Windows pour .NET Core . En principe, nous pouvons faire fonctionner des parties de System.DirectoryServices sous Linux, mais nous n'avons pas encore les ressources pour le faire. dotnet/corefx#24843 suit cet élément de travail.

Pourquoi autorisons-nous l'installation de packages qui ne fonctionneront pas sous Linux ? L'alternative serait de bifurquer la surface de l'API, mais cela ne fonctionne pas bien dans tous les cas non plus et rend le système global plus difficile à coder. Bien sûr, notre choix n'est pas non plus sans problème, car il peut être plus difficile de prédire si le code fonctionnera sur plusieurs plates-formes ou. Nous avons un aperçu d'un analyseur de compatibilité qui vous donne un retour en direct pendant que vous codez.

Regardez cette vidéo pour plus de contexte sur la façon dont nous voyons le pack de compatibilité Windows et l'analyseur multiplateforme fonctionner main dans la main :

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

@thedevopsmachine

Microsoft n'investit pas dans cette bibliothèque pour Linux car ils souhaitent que tout le monde passe plutôt à Azure AD.

Ce n'est pas comme ça que je le vois. Comme vous l'avez souligné, nous avons l'intention de gagner de l'argent via Azure. Et Azure est une plate-forme cloud qui offre une grande variété de technologies et de systèmes d'exploitation. Nous n'avons aucun intérêt commercial à promouvoir Windows dans le cloud plutôt que Linux dans le cloud. Mais bien sûr, .NET est fortement présent sur Windows depuis 15 ans. Rendre les choses entièrement fonctionnelles sur tous les systèmes d'exploitation prend du temps, mais je pense honnêtement que la plupart des gens qui suivent nos efforts open source peuvent voir que nous ne paralysons pas Linux exprès. Cela prend juste du temps.

Je suis d'accord avec l'approche consistant à avoir une api x-plat et un cadre x cohérents, mais c'est destructeur d'âme chaque fois que je rencontre cette erreur redoutée .. je ressens pour @sscoleman ...

Ce package DirectoryServices peut-il fonctionner sur CentOS 7 ?

Ce package DirectoryServices peut-il fonctionner sur CentOS 7 ?

Le package peut être installé mais ne fonctionnera pas. lors de son utilisation, vous obtiendrez une exception de plate-forme non prise en charge. nous cherchons comment nous pouvons prendre en charge les services d'annuaire en général sur Linux. c'est sur notre radar.

Cela a vraiment besoin de support Linux

CC @joperezr

@niemyjski voir dotnet/corefx#24843

Cela a vraiment besoin de support Linux

.. plus être capable de fonctionner dans un conteneur docker. À mon humble avis, il est pénible de devoir revenir à l'ancienne implémentation du répertoire Novell lorsque l'on souhaite utiliser .NET Core 2+ sur Linux.
Merci quand même d'avoir travaillé dessus !

Pourquoi fermer ce sujet ? System.DirectoryServices.AccountManagement n'est toujours pas dans .NET Core en dehors 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]

rouvrir 14734

@tarekgh toujours sur le radar ?

rouvrir 14734

@JustinGrote quelle est la fonctionnalité exacte que vous souhaitez pour le scénario ? DirectoryServices est énorme et je doute que toute la fonctionnalité puisse être prise en charge dans une seule version. Avoir des demandes spécifiques peut aider mieux que de simplement demander que toutes les bibliothèques DS soient prises en charge. Dans .NET 5.0, nous avons activé un scénario https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
Je ne savais pas que System.DirectoryServices.Protocols avait été porté, mais il semble qu'il dépende toujours de security.principal.windows, fonctionne-t-il sous Linux même avec cela (via l'authentification de base, etc.) erreur de montage ?

L'objectif est de réimplémenter quelque chose comme le module ActiveDirectory Powershell pour être xplat, j'envisageais soit le module novell ldap ou ldap4net à cette fin s'il n'y avait pas au moins un support d'interaction de base disponible.

L'implémentation d'ActiveDirectory Powershell est probablement un cas d'utilisation très important. Permettez-moi de partager mes deux cas d'utilisation :

1) Je dérive de UserPrincipal car j'ai besoin d'attributs qui ne sont pas pris en charge par défaut. J'ai suivi https://stackoverflow.com/questions/24798037/extend-userprincipal-class et je suppose que c'est une sorte de norme dans l'ancien framework .NET, et que cette approche fonctionne aidera probablement plus de développeurs.

2) J'ai aussi un code comme celui-ci :

`

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

`

Aucune idée de ce qui est déjà pris en charge aujourd'hui, la dernière fois que j'ai vérifié, c'était en février.
Merci Joachim

@jol64 ne pouvez-vous pas obtenir la même chose en utilisant les protocoles ?

@jol64 ne pouvez-vous pas obtenir la même chose en utilisant les protocoles ?

Probablement que je peux. J'ai réécrit certaines choses pour utiliser la bibliothèque Novell. Mais cela nécessite une réécriture et donc un code redondant par rapport à mon code de framework .NET existant. Je préfère définitivement éviter une division de code de tout le code, et je suis sûr que d'autres n'aiment pas non plus l'idée.
Je me demande également comment fonctionne l'authentification. Avec Novell (l'ancienne version que j'ai essayée), je dois spécifier des informations d'identification, alors qu'avec mon code existant, je n'en ai pas besoin.
Merci Joachim