@Vibronet

Gibt es hierzu ein Update?

Auch ich hätte gerne ein Update dazu. Mein Unternehmen lässt mich eine neue App erstellen, die die Möglichkeit erfordert, Active Directory über LDAP abzufragen, aber es scheint, dass dies derzeit nicht möglich ist. Gibt es geplante Unterstützung dafür, wird es zugunsten von etwas anderem fallen gelassen oder funktioniert es bereits, nur nirgendwo dokumentiert?

Ein neuer, frischer Blick auf die Implementierung der LDAP- und Active Directory-Unterstützung wäre großartig, wenn man sie in .NET CoreFX hätte.

Wir brauchen wirklich eine Active Directory/LDAP-Lösung, die wir in .NET Core nutzen können. Ob es sich um eine Clean-Sheet-Implementierung oder eine Portierung von System.DirectoryServices handelt, spielt für mich keine so große Rolle. Es gibt viele geschäftsorientierte Windows-Anwendungen, die unbedingt eine AD-Authentifizierung benötigen, und die LDAP-Authentifizierung wäre ein großartiger Feature-Aufzählungspunkt für plattformübergreifende Entwickler.

Ich stimme den obigen abwärtskompatiblen Anmerkungen zu - ich glaube nicht, dass ein direkter Port wirklich benötigt wird, wir brauchen nur eine Möglichkeit, auf die Authentifizierung zuzugreifen (und andere Aktionen durchzuführen: Suchen, Entsperren, Löschen usw.) gegen Active Directory oder einen beliebigen LDAP-Anbieter .

@ Nick Craver

Ich glaube nicht, dass ein direkter Port wirklich benötigt wird, wir brauchen nur eine Möglichkeit, auf die Authentifizierung [...] gegen Active Directory zuzugreifen

Das ist gut zu wissen. Lesen Sie nicht zu viel in mein Port-to-Core-Label, das ich gerade angebracht habe. Es ist nur meine Art, Lücken im .NET Core-Angebot aufzuspüren, die Kunden wie Sie davon abhalten, ihre App auf .NET Core zu portieren.

@terrajobst Erwischt . Ich denke nicht unbedingt, dass dies aufgrund seiner Modularität ein 1.0-Element sein muss (und es _klingt_ sowieso so, als wäre es für Post-RTM vorgesehen), aber ich freue mich darauf. Es wird für mich ein Blocker bei der Portierung von Opserver sein, also nehme ich gerne an API-Diskussionen teil, wenn wir von Nutzen sein können. Wir haben eine breite Palette von Anwendungsfällen auf der Sysadmin-Seite von Dingen, die hilfreich sein könnten, ping, wenn ich helfen kann.

Nur um einen weiteren Hut in den Ring zu werfen. Im Moment ist das auch für mich der größte Blocker, den es noch gibt. Einfach in der Lage zu sein, sich zu authentifizieren, wäre vorerst eine große Hilfe.

Können wir eine offizielle Antwort von jemandem aus dem Entwicklerteam zu den Plänen dafür erhalten, wenn es überhaupt Pläne gibt, dies zu unterstützen?

Ich glaube nicht, dass ein direkter Port wirklich benötigt wird

Wieso den? Entschuldigung, ich bin verwirrt. Wäre das nicht die einfachste Lösung für alle und nach dem DRY-Prinzip?
Wenn es jedoch einen Grund gibt, die gesamte API von Grund auf neu zu schreiben, wäre eine gewisse Konsistenz mit der alten API (gleiche Methodensignaturen) für den Verbraucher weniger verwirrend.

@jasonwilliams200OK , lass mich klarstellen, ich meinte wirklich speziell DirectoryServices.ActiveDirectory . Ich denke, Authentifizierung und das Drumherum: zB Gruppenmitgliedschaft ist der 95-99%ige Anwendungsfall des Namensraums. Ich denke, eine direkte Portierung von Signaturen von _that_ ist ziemlich nützlich. Wenn sich der Rest aus irgendeinem Grund ändert, wäre ich damit ziemlich einverstanden, und okay, wenn es später käme ... die Authentifizierung wäre gut, so schnell wie möglich aus der Tür zu kommen, da dies für viele ein Blocker ist.

Das Integrieren mindestens einer grundlegenden Funktionalität zum Suchen von Active Directory-Benutzern und deren Zuordnung zu benutzerdefinierten Rollen mit ASP.NET 5 erleichtert die Implementierung der Windows-Authentifizierung in ASP.NET-Webanwendungen. Wir benötigen diese Funktionalität auf unserer Intranetseite.

Das ist auch für uns ein Blocker. Wir müssen in der Lage sein, Benutzer und Gruppen zu authentifizieren, abzufragen, neue Benutzer und Gruppen usw. auf einem LDAP-Server zu erstellen.

Es ist auch ein Blocker für mich - ich muss Benutzer abfragen und authentifizieren.

Ich habe eine Lösung für die Authentifizierung gegen Active Directory in einer .NET Core rc1-Webanwendung entwickelt. Sie müssen nur die CheckPasswordAsync-Methode in der UserManager-Klasse überschreiben. Lass mich wissen was du denkst.

Zuerst müssen Sie eine benutzerdefinierte Registrierungsseite erstellen, die es dem Benutzer ermöglicht, einen AD-Benutzernamen anstelle einer E-Mail-Adresse und eines Passworts einzugeben. Dieser Benutzername wird in die UserName-Eigenschaft der ApplicationUser-Klasse eingefügt, die von der ASP.NET 5-Vorlage generiert wird, wenn Sie die Authentifizierung einzelner Benutzerkonten auswählen. Außerdem müssen Sie die Password-Eigenschaft standardmäßig auf etwas setzen, das die interne Validierung in der IdentityUser-Klasse übergibt.

Mein Registrierungsseitencontroller ruft eine Web-API-2-Methode auf, die den Benutzernamen in AD findet und JSON zurückgibt, das die AD-Informationen für diesen Benutzer enthält. Ich habe der ApplicationUser-Klasse einige benutzerdefinierte Eigenschaften hinzugefügt, um die AD-Informationen aufzunehmen. Ich werde den Code aus meinem Projekt nächste Woche posten.

Fügen Sie dann eine Klassendatei im Ordner „Dienste“ hinzu. Ich habe meine ApplicationUserManager.cs genannt. Fügen Sie dieser Klassendatei den folgenden Code hinzu.

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

Öffnen Sie dann die Datei Startup.cs. Fügen Sie .AddUserManager hinzu() zum AddIdentity-Aufruf in der ConfigureServices-Methode, wie unten gezeigt.

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

Dadurch kann ich zumindest die richtlinien-/anspruchsbasierte Autorisierung einrichten, während ich auf die Unterstützung von DirectoryServices warte.

Ich verlasse mich auf diese Bibliothek. Schade, dass ich jetzt nicht portieren kann.

@ClintBailiff Ich muss mich hier einmischen - weil es eine _wirklich_ schlechte Idee ist, das Passwort des Benutzers erneut über die Leitung an eine andere Anwendung im Klartext weiterzuleiten. Bitte verwenden Sie diesen Ansatz nicht. Es ist eine Sicherheitslücke.

@terrajobst dies wird der Blocker bei der Portierung meiner größeren Anwendungen wie Opserver sein - können wir das bitte priorisieren?

@NickCraver Ich habe nie vorgeschlagen, die Anmeldeinformationen als Klartext zu übergeben. In der Regel verwende ich SSL für alle meine Webanwendungen/-dienste, da sie normalerweise Daten zurückgeben, die nur autorisierte Benutzer sehen sollten. Ich habe nicht daran gedacht, das anzugeben, wahrscheinlich weil es so offensichtlich ist, dass Sie Anmeldeinformationen nicht im Klartext senden möchten.

Ich würde mich dafür einsetzen, zumindest einen Port von System.DirectoryServices.Protocols . Wir haben kürzlich unseren LDAP-bezogenen Code darauf umgestellt, um eine größere Auswahl an LDAP-Servern zu unterstützen, da der System.DirectoryServices.ActiveDirectory -Namespace nur mit AD-Servern kommunizieren möchte.

Ich nehme an, es wäre möglich, dass eine Bibliothek eines Drittanbieters diese Art von Unterstützung bereitstellt, aber da sie bereits im Framework vorhanden ist, würde ich mir vorstellen, dass eine Portierung einfacher wäre.

Das WTF-ASP-Team stellt diese grundlegende Funktionalität nicht bereit
Das ist wirklich ein Blocker-Problem :(

Gibt es ein Update zur LDAP-Unterstützung in CoreCLR?

Auch hierzu hätte ich gerne ein Update. Ich werde eine Unternehmensanwendung mit ASP.NET Core entwickeln, die Benutzer gegenüber einem AD-Server authentifizieren muss.

Ich werde mich mit der Portierung von System.DirectoryServices auf .NET Core für v1.1.0 (https://github.com/dotnet/corefx/milestones) befassen.

@joshfrei
Ich muss auch Benutzer von ADLDS authentifizieren, bitte beachten Sie auch System.DirectoryServices.AccountManagement

Vor ein paar Jahren übernahm das Unternehmen, für das ich arbeitete, den Quellcode der Novell (Mono) LDAP-Bibliothek, damit unsere Anwendung mit Active Directory-, OpenLDAP- und Oracle-Systemen kommunizieren konnte, und wir fügten Unterstützung für ausgelagerte Steuerelemente hinzu und aktualisierten einige TLS-Korrekturen. Wir haben dies getan, da wir unter Linux laufen wollten. Eine PR mit unseren Änderungen wurde an die Eigentümer gesendet. Da wir jetzt auf CoreCLR zugreifen möchten, musste diese Bibliothek in RC2 konvertiert werden. Die Arbeit hat hier https://github.com/VQComms/CsharpLDAP/pull/1 begonnen, es gibt noch 17 Compiler-Fehler, die behoben werden müssen. Sie sind hauptsächlich Thread.Abort , ThreadInterruptedException , ersetzen TLS-Streams von Mono zu CoreCLR SslStream Wenn jemand interessiert ist und LDAP-Unterstützung für CoreCLR benötigt, können Sie gerne helfen.

Ich habe bestätigt, dass ein RC2-Projekt einer ASP.NET Core-Webanwendung (.NET Framework) auf eine Klassenbibliothek verweisen kann, die System.DirectoryServices.AccountManagement verwendet. Ich konnte es nur zum Laufen bringen, wenn sowohl die Webanwendung als auch die Klassenbibliothek mit VS 2015 Update 2 erstellt wurden und beide .NET Framework 4.6.1 verwenden.

Nur um die Meinung anderer wiederzugeben, wir sind tot in der Wasserportierung, ohne in der Lage zu sein, LDAP und dergleichen abzufragen.

@h3smith
Siehe meinen vorherigen Beitrag. Mit der Veröffentlichung von RC2 können Sie jetzt auf eine Klassenbibliothek verweisen, die System.DirectoryServices.AccountManagement verwendet.

Nicht auf Netstandard.

Aber wie gesagt, wir arbeiten daran, dass dies funktioniert. Hoffentlich haben
etwas in etwa 2-3 Wochen

Am Freitag, den 17. Juni 2016, schrieb Clinton Bailiff [email protected] :

@h3smith https://github.com/h3smith
Siehe meinen vorherigen Beitrag. Mit der Veröffentlichung von RC2 können Sie jetzt auf a verweisen
Klassenbibliothek, die _System.DirectoryServices.AccountManagement_ verwendet.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/corefx/issues/2089#issuecomment -226837679 oder stumm
der Faden
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

Irgendwelche Updates dazu? Ich muss den aufrufenden Benutzer authentifizieren, wenn der Benutzer eine Winkel-Web-App im LAN verwendet, bei AD angemeldet ist und eine WebAPI-Controller-Methode (ohne dass der Benutzer ein Passwort in den Webbrowser eingibt) in Aspnet Core RC2 aufruft. Möglich? Bald möglich?

Dazu müssen Sie nur withCredentials in Ihren HTTP-Anforderungen vom Client verwenden. Dann können Sie Benutzerinformationen und Ansprüche in Ihren Controllern mit User.Identity abrufen.
Dies funktioniert in IE und Chrome, aber mit Firefox wird automatisch ein Popup angezeigt, in dem der Benutzer seinen Windows-Benutzer und sein Passwort eingibt

Wir sind vor ungefähr zwei Monaten auf das gleiche Problem gestoßen (z. B. beim Versuch, einen LDAP-Server als Benutzerspeicher zu verwenden). Wir konnten keine Lösung finden, außer die Novell LDAP-Bibliothek (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) auf .net Core zu portieren (siehe hier https://github.com/dsbenghe/Novell. Verzeichnis.Ldap.NETStandard). Es ist ein Nuget-Paket veröffentlicht. Wir verwenden die Bibliothek mit OpenDJ LDAP-Server (sollte mit jedem LDAP-Server funktionieren) - keine Probleme in 1,5 Monaten Nutzung.

@dsbenghe Wir haben gerade unsere Novell LDAP-Bibliothek auf Netstandard kompiliert, unsere enthält auch Paging. Dies wurde von @igorshmukler durchgeführt . Möchten Sie vergleichen und zusammenarbeiten? Unsere ist WIP hier https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Vielen Dank für Ihre Arbeit an der .NET Core-Implementierung.
Nachdem ich das Nuget-Paket erhalten habe, habe ich den folgenden Code erstellt, um zu testen, ob das ActiveDirectory-Passwort des Benutzers korrekt ist

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

Es ruft AuthenticateWithActiveDirectory auf:

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

Und verwendet eine einfache Hilfsklasse, um die eckige Anwendung wissen zu lassen, was vor sich geht

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

Für UWP gibt es eine Anfrage für dieses Feature auf unserer UserVoice: https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cc @tquerec @jimuphaus , der an der System.DirectoryServices-Unterstützung für .NET Core arbeiten wird.

Kann es kaum erwarten! Voraussichtliche Ankunftszeit? Designvorgaben?

Wenn es endlich portiert ist, haben wir Zugriff auf:

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

Ich weiß, dass es in diesem Namensraum einige kleinere Mängel gibt, aber es ist immer noch ziemlich hilfreich.

@GArrigotti beim Testen ist die Verwendung von LdapDirectoryIdentifier normalerweise schneller als 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;  
}

Gibt es eine ETA? Ich könnte dies in einem System verwenden, das Ende dieses Monats fertiggestellt werden soll ...

@johnkwaters gibt es einen Grund, warum Sie den AD-Code nicht in eine Klassenbibliothek einfügen können? Einige Personen (mich eingeschlossen) hatten Probleme beim Verweisen auf Legacy-Klassenbibliotheken in einer ASP.NET Core-Anwendung. Aber es gibt keine Probleme, wenn Sie die Web-App und Klassenbibliothek in VS 2015 Update 3 erstellen und .NET Framework 4.61 in der Web-App und Klassenbibliothek als Ziel verwenden.

Gibt es einen Grund, warum Sie den AD-Code nicht in eine Klassenbibliothek einfügen können?

Meinen Sie PCL gefolgt von "imports": "portable-net45+win8" in project.json für .NET Core TxM? Dazu müssen unter Unix Mono-PCL-Referenz-Assemblies vorhanden sein und keine "reine Donet-Core"-Lösung, die unter Unix Autarkie gewährt. Es ist ein guter Hack, den Compiler stumm zu schalten, aber nur dann durchzuarbeiten, wenn die CoreFX-BCL die entsprechende Implementierung hat. In der Regel ist die project.json ohne "imports" für netcoreapp/netstandard1.x immer besser. zB https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Irgendwelche Neuigkeiten zu einer ETA? Wo kann ich diese wiederkehrende Frage zum Self-Service aufrufen?

_Wirklich_ freue mich auf dieses Feature!

Freue mich auch sehr auf diese Funktion!!

Freue mich auch sehr auf diese Funktion!!

Ich brauche diese Funktion auch dringend!

Leute, könntet ihr alle einfach Reaktionen zum Hauptbeitrag hinzufügen?

Oder verwenden Sie die Bibliotheken, die von zwei verschiedenen Personen auf Nuget abgelegt wurden. Es ist
alles OSS. Wenn Ihnen das Paket nicht gefällt, senden Sie eine PR

Am 8. September 2016 um 12:19 Uhr Mikhail Orlov [email protected]
schrieb:

Leute, könntet ihr alle einfach Reaktionen zum Hauptbeitrag hinzufügen?

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/corefx/issues/2089#issuecomment -245567328 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+1 für @jchannon Novell LDAP. Es brachte uns voran und erforderte praktisch keine Änderungen an unserer LDAP-Implementierung. Ich meine, du abstrahierst richtig, richtig ;)

Ja, ich habe schließlich auch @jchannon Novell LDAP verwendet, es hat gut funktioniert.

Wenn ich es noch nicht gesagt habe, hier ist der Zweig, alles auf https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Funktioniert für unsere Anforderungen im Moment gut ...

@h3smith @johnkwaters Bei Problemen können Sie gerne ein Problem melden 😄

Ich habe mich entschieden, es mit Novell zu versuchen, die Beispiele sehen gut genug aus, aber ich weiß nicht, wie ich Benutzermitglieder mit Novell LDAP aus einer Gruppe werfen (entfernen) kann.
Ich kann mein Passwort auf MSAD LDAP nicht ändern, da ich userPassword nicht sehen kann und es nicht auf dem LDAP-Server festgelegt wurde.

Brauche das wirklich!

@joshfree oder jemand anderes, der Bescheid weiß ...
Wir möchten ein neues Projekt starten, das Zugriff auf ActiveDirectoryServices.AccountManagement benötigt. Frage: Ist der Port entweder auf 1.1 oder 1.2 ausgerichtet?

Es ist nicht Teil von 1.1 (das kurz vor der Fertigstellung steht). @tquerec , kannst du bitte deine Pläne hier kommentieren?

cc: @danmosemsft

SO, wenn nicht Teil von 1.1, hat jemand einen Plan? Scheint ein großes Problem zu sein, diese Unterstützung nicht zu haben. Offensichtlich würde vor allem Microsoft diese Integration wollen.

Noch eine Stimme dafür. Es ist schwierig, die Investition zu tätigen, um Systeme der Enterprise-Klasse auf .NET Core zu erstellen, wenn grundlegende Unternehmensfunktionen fehlen. Das Novel-Projekt funktioniert, ist aber nicht gut genug.

Noch eine Abstimmung. Ich werde die gleiche Aussage wiederholen, dass dies ein wesentlicher Bestandteil der Erstellung jeder Unternehmensanwendung ist.

@nevcoBpalacio Ich glaube, sie versuchen, uns dazu zu drängen, Azure Active Directory zu verwenden

Das wird niemals für diejenigen funktionieren, die mit Unternehmensvereinbarungen arbeiten, die erfordern, dass Dienstleistungen im Haus bleiben.

Ich habe für Regierungsbehörden gearbeitet, sowohl auf Bundes- als auch jetzt auf lokaler Ebene, und so oder so würden Sie immer noch eine Schnittstelle oder Fähigkeiten benötigen, um sich in einen Verzeichnisdienst zu integrieren, entweder Cloud-basiert oder vor Ort. Ich habe Anwendungen mitentwickelt, die Milliarden von Dollar verwalten, und es entsteht immer ein gewisser Bedarf an Verzeichnisdiensten. Ich denke, dies ist mehr als eine weitere Abstimmung, sondern eher eine Aussage darüber, worauf Sie warten? Ich stimme einem früheren Beitrag zu, dass dies ursprünglich eine sofort einsatzbereite Lösung in früheren .NET-Versionen war. Ich verstehe, dass die offenere Struktur von CORE die Dynamik der Community gewinnen sollte, und wenn Microsoft sich dafür entscheidet, darauf zu warten, haben sie das vielleicht gesagt und ich habe es verpasst, sie sollten es sagen, damit jemand die Initiative ergreifen und Zeit investieren kann um es zu erledigen.

Ja, bitte fügen Sie System.DirectoryServices zu .NET Core hinzu!

Wir haben Pläne, System.DirectoryServices.Protocols innerhalb des nächsten Jahres zu portieren. Einen genaueren Termin kann ich an dieser Stelle nicht nennen. Wir haben noch keine Pläne, System.DirectoryServices oder System.DirectoryServices.AccountManagement zu portieren, aber ich bin daran interessiert, das Interesse zu messen. Gibt es Merkmale dieser Namensräume, die von Benutzern verwendet werden und die nicht mit Protokollen gelöst werden können?

@tquerec Ich bin mit Protokollen nicht vertraut. Wir haben ein Projekt für den Active Directory-Self-Service, um das Konto zu entsperren und das Kontokennwort zurückzusetzen. Wir verwenden UserPrincipal im Projekt und rufen die Methoden wie FindByIdentity, UnlockAccount, SetPassword,, ExpirePasswordNow, auf.
Ich bin mir nicht sicher, ob dies für Protokolle durchgeführt werden kann, aber es sieht so aus, als ob Protokolle eine Implementierung auf niedrigerer Ebene sind, während AccountManagement eine bessere Abstraktion für die Arbeit mit ActiveDirectory ist.
Danke
Rockmeister

@nevcoBpalacio sollte definitiv mehr als eine Abstimmung sein, da stimme ich zu. Ich denke, das braucht wirklich mehr Priorität.

@CalebMacdonaldBlack , es wäre hilfreich, wenn Sie die @tquerec- Frage zu Nutzungsmustern beantworten könnten und warum was benötigt wird. Mehr Upvotes oder "Ich stimme zu / es ist wichtig" ohne Szenarien werden in diesem Moment nicht dazu beitragen, die Priorität zu erhöhen ... Danke!

Unsere Verwendung besteht darin, LDAP zu scannen/durchsuchen, BIND durchzuführen, um Anmeldeinformationen zu überprüfen, LDAP-Objekte (Benutzer, Gruppen) hinzuzufügen/zu entfernen, die Mitgliedschaft in Gruppen zu ändern usw.

@tquerec Ich brauche wirklich System.DirectoryServices.AccountManagement, damit ich unsere Benutzer gegen Active Directory authentifizieren und sie für Gruppen autorisieren kann, auf die sie Zugriff haben.

stimme h3smith definitiv zu. Wir brauchten dies für v1 und sind stattdessen gezwungen, den Novel-Pfad zu gehen, den wir zusammengewürfelt haben (insbesondere die Replikationsbits) und der uns mit dem Overhead der Wartung usw. Kummer bereitet. Dies macht .NETCore schlecht aussehen als nebenwirkung..

@LiquidBoy

wir brauchten das für v1

Meinst du .NET Core v1? - fertig und verschickt. Wir arbeiten gerade an 1.2. Oder meintest du etwas anderes?

stattdessen sind sie gezwungen, den neuartigen Weg zu gehen

Was bedeutet das? (Entschuldigung, ich habe keinen Kontext zu DirectoryServices, aber ich würde gerne verstehen, was uns aus Sicht der Szenarien fehlt.)

@karelz suche einfach in diesem Thread nach dem Wort "Roman" und du wirst sehen, was ich meine. Ein anderer Entwickler (dsbenge) in meinem Team kommentierte (zusammen mit anderen) die Lücke, die dazu führte, dass wir Roman verwendeten. [hier der Link zum obigen Kommentar https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297]

Und ja, ich meinte .NET Core v1, das bereits ausgeliefert wurde. Wir haben über ein Jahr an unserer Lösung gearbeitet und brauchten damals eine gute DirectoryServices-Lösung. Wir stießen an eine Wand und hatten daher keine andere Wahl, als Novel zu verwenden .

@liquidboy danke für den Link – wenn es sich um Mono handelt, sollten wir den Quellcode in .NET Core AFAIK wiederverwenden können. @tquerec Angesichts des Interesses, würde Ihr Team darüber nachdenken?

@tquerec : Wir brauchen Folgendes:
System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory und System.DirectoryServices.Protocols.

Diese werden benötigt, um sich mit Benutzern, Gruppen und Attributen von Active Directory (und anderen LDAP-Servern) zu verbinden und diese zu verwalten, genau wie in den obigen Antworten beschrieben. Es ist wichtig, diese Funktionen in .Net Core zu haben!

Ich stimme anderen zu. Ich brauche dies, um eine unserer Apps, die sich gegen ActiveDirectory authentifizieren, auf .NET Core zu portieren. Das ist ziemlich grundlegend, es sollte definitiv in der schnellstmöglichen Veröffentlichung sein. Es ist der Blocker, um so viele Dinge zu portieren.

Die .NET Core-Roadmap-Seite (https://github.com/dotnet/core/blob/master/roadmap.md) enthält diesen Plan für .NET Core 1.2: „bring .NET Core to parity with .NET Framework and Mono for a große Sammlung von Basistypen."

Ich denke, dass die Portierung von System.DirectoryServices sehr gut zu diesem Plan passt und tatsächlich Teil der 1.2-Version sein sollte. Nur meine 5 (Euro) Cent :)

Nur zur Verdeutlichung: Die in 1.2 portierten APIs wurden basierend auf Nutzungsdaten (und selten Komplexität) ausgewählt - @weshaggard @danmosemsft, können Sie sich mit Details

Die Liste der Baugruppen, die wir zum Abgleich ausgewählt haben, finden Sie hier . @weshaggard muss mich daran erinnern, wie er diese Liste ausgewählt hat. (Mono hat S.DirectoryServices)

Ich glaube, dass Sie in Bezug auf die Kommunikation mit ActiveDirectory (und anderen LDAP-Servern) mithilfe von System.DirectoryServices.Protocols fast alles tun können, aber viele Leute müssen ihren Code neu schreiben, um S.DS.Protocols zu verwenden.

Ich persönlich würde es vorziehen, dass MS S.DS.Protocols portiert und MS oder die Community darüber eine einfach zu verwendende Bibliothek für die Benutzer-/Gruppenverwaltung erstellt.

Die Liste der Baugruppen, die wir zum Abgleich ausgewählt haben, finden Sie hier. @weshaggard muss mich daran erinnern, wie er diese Liste ausgewählt hat. (Mono hat S.DirectoryServices)

Das anfängliche Seeding erfolgte aus sich überschneidenden Xamarin-Profilen mit .NET Framework. Xamarain-Profile (eine Teilmenge von Mono) unterstützen keine DirectoryServices, weshalb dies nicht in der Schnittmenge enthalten war.

Was können wir tun, um zu argumentieren, dass dies in sein sollte? Die Unfähigkeit, das gebräuchlichste Authentifizierungsschema in Microsoft-Anwendungen zu verwenden, ist ein bisschen ein Hindernis, nicht wahr? Liegt der Fokus hier auf Azure und stattdessen auf AAD? Oder ist der Blocker, dass die Portierung über Plattformen hinweg eine größere Unbekannte von Protokollen ist?

Gibt es eine Möglichkeit, die Priorität hier zu erhöhen? 2.0 ist noch weit weg, und das ist wirklich schade, wenn _alles_ sonst funktioniert, aber wir können keine Benutzer authentifizieren. Dies ist die virtuelle Haustür für so viele Anwendungen. IMO, in Bezug auf die Priorität ist es ein wenig anders, weil es kein teilweiser Blocker ist, sondern oft von Natur aus ein vollständiger Blocker.

Ich glaube nicht, dass es Unstimmigkeiten darüber gibt, dass wir dies in .NET Core unterstützen wollen, was anders ist, als Teil von .NET Standard zu sein, es ist nur eine Frage des Zeitpunkts. @tquerec besitzt das Gebiet und wäre derjenige, der damit sprechen würde.

Jemand von .NET Foundation hat gefragt, aber die Namespaces, die wir speziell verwenden, sind:
System.DirectoryServices, System.DirectoryServices.Protokolle, System.DirectoryServices.AccountManagement

Also, @tquerec , wie bekommen wir System.DirectoryServices für .NET Core 1.2 gekennzeichnet? Mindestens System.DirectoryServices.Protocols. Ist das möglich?

Vielen Dank!

[aktualisiert mit mehr Informationen von @tquerec]
Ich habe mich am Montag mit

• System. DirectoryServices ist nur unter Windows machbar (es ruft in Windows DLL auf, wo die gesamte Implementierung lebt), völlig unbekannt für Linux/Mac
• System.DirectoryServices. AccountManagement sitzt darauf, also auch nur für Windows machbar und für Linux/Mac unbekannt
• System.DirectoryServices. ActiveDirectory ist nur unter Windows machbar (es ruft viele Windows-spezifische APIs auf)
• System.DirectoryServices. Protokolle sollten für Windows relativ einfach sein und für Linux mehr funktionieren (wir müssen eine zu verwendende LDAP-Bibliothek finden).
  Wir versuchen mit @tquerec herauszufinden, wie wir die Arbeit finanzieren können - idealerweise für 1.2, aber noch keine Zusage. Ich gehe davon aus, dass die Entscheidung mindestens ein paar Wochen dauern wird.

Fragen an alle :

• Ist der obige Bereich nur für Windows für die wichtigsten Anwendungsfälle akzeptabel? (Sys.DirSer und Sys.DirSer.AccountManagement und Sys.DirSer.ActiveDirectory)
• Wenn Sys.DirSer.Protocols Linux nach 1.2 kommt oder auf Community-Beiträge angewiesen ist, wäre das ein großer Blocker?

@karelz System.DirectoryServices.ActiveDirectory basiert auf einer großen Anzahl von Windows-spezifischen APIs, sodass es in denselben Bereich wie S.DS und S.DS.AM fällt.

@karelz Ich bin mir nicht sicher, was du mit einer reinen Windows-Lösung für 1.2 meinst. Wir haben bereits eine reine Windows-Lösung, die funktioniert.

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

@rock-meister Ich meine .NET Core. Der von Ihnen erwähnte zielt auf "vollständiges" .NET 4.5.2+ ab.

Ja, die reine Windows-Unterstützung ist für uns ein großer Entblocker. Wir können die gesamte Arbeit für die .NET Core-Portierung und Erweiterung der Plattformunterstützung „kostenlos“ später erledigen, wenn die zugrunde liegenden Bits dies tun. Richtig nicht der Blocker, um überhaupt _starting_ zu portieren, ist riesig. Dass es weg ist, ist ein großer Gewinn.

Als Windows-Shop wäre dies auch hier ein großer Gewinn. So viele große Unternehmen würden dies als großen Gewinn betrachten! Vielen Dank, dass Sie mit Ihren Informationen auf dem Laufenden bleiben. Halten uns auf dem Laufenden. Danke.

@karelz Danke für die Klarstellung. Ja, das Windows-only-Scoping für 1.2 funktioniert für uns.
Rockmeister

System.DirectoryServices.Protocols mit Linux /LDAP-Unterstützung haben bei unserer Arbeit höchste Priorität.

ps-Windows-only-Scoping scheint den Zielen von .netcore / .netstandard zu widersprechen

Wir haben vor einiger Zeit von System.DirectoryServices auf System.DirectoryServices.Protocols umgestellt, damit wir Nicht-AD-LDAP-Server unterstützen können. Der Zugriff auf den Protocols-Namespace wäre der Möglichkeit, unseren Code auf .NET Core zu portieren, einen Schritt näher gekommen.

Wenn dies jedoch plattformspezifisch sein soll, ist dies für uns weniger sinnvoll. Ein Hauptgrund für den Umstieg auf .NET Core ist die Plattformportabilität. Darauf müssen wir wohl noch warten.

Für uns war der Weg zu .NET Core die Möglichkeit, Docker zu nutzen und völlig plattformunabhängig zu sein. Es wäre also nicht vorteilhaft, nur mit Windows-LDAP-Unterstützung festzuhalten.

Danke für die interne Diskussion.

Meine Abstimmung geht plattformunabhängig 🦃

Ich muss dem plattformagnostischen Kommentar zustimmen, so sehr es auch schmerzt, dass ich Core nicht verwenden kann, bis dies erledigt ist. Ich denke, das ist etwas, das auf einer höheren Ebene überprüft werden muss. Was ich nicht verstehe, ist die Komplexität des Konzepts? Es gibt mehrere Verzeichnislösungen, AD, Novell usw. Dies erfordert eine plattformübergreifende (agnostische) Schnittstellenlösung ... Frohe Feiertage!

Während ich persönlich mit einem reinen Windows-Bereich vollkommen gut leben könnte, bricht dies meiner Meinung nach die Idee von .NET Core und seiner Portabilität.
Eine plattformunabhängige Lösung sollte der Weg sein, auf den man sich konzentrieren sollte.

Ja, einverstanden, .NET Core sollte plattformübergreifend sein und Funktionen/APIs sollten auf allen unterstützten Plattformen funktionieren!
Wenn also System.DirectoryServices.Protocols zuerst portiert/implementiert wird, sollte es auch unter Linux funktionieren.

Ich stimme zu, dass idealerweise eine plattformunabhängige Lösung das Ziel sein sollte. Obwohl es immer noch nicht unter Windows verfügbar ist, ist es ein Hindernis für viele Entwickler, die wie ich nur mit der Plattform in einer Unternehmensumgebung (AD) experimentieren möchten. Deshalb würde ich vorerst eine reine Windows-Lösung begrüßen.

Ich möchte mich nur einschalten und sagen, dass ich mit einer reinen Windows-Lösung einverstanden bin, bis etwas Plattformübergreifendes zusammengestellt werden kann.

Ich könnte mir vorstellen, dass 99,9 % der Entwickler, die sich mit Active Directory verbinden müssen, dies in einer Unternehmensumgebung tun, in der sie auf Windows-Systemen entwickeln.

Wir diskutieren die Finanzierung auf unserer Seite (erwarten Sie ein Update in ca. 2 Wochen), dies hat derzeit höchste Priorität von APIs, die noch nicht Teil von .NET Standard 2.0 sind.

Gibt es Leute in der Nähe, die bereit wären, bei der Windows-Implementierung und/oder Linux-Implementierung zu helfen/einen Beitrag zu leisten? (Wir könnten den Code von Desktop einfügen und es würde weiteres Massieren zum Erstellen + einige Tests erfordern)

@karelz Ich würde gerne für die Linux-Seite der Dinge beitragen. Wir benötigen diese Unterstützung sowohl für die Windows- als auch für die Nicht-Windows-Authentifizierung (lokal). Dies ist ein Blocker für uns, und wir zielen auf .NET Core für unser plattformübergreifendes Projekt ab (früher war Mono auf der Linux-Seite und .NET auf der Windows-Seite).

Würde ohne Zweifel gerne helfen wo wir können.

Ich würde gerne helfen, aber ich bin mir sicher, dass Sie viel erfahrener sind als ich, und ich wäre nicht von Nutzen.

@karelz @tquerec Ich

Ich denke, dass "erweitertes Windows" zunächst ein gutes Ziel ist, "erweitert" bedeutet, dass es auf NanoServer und in Containern funktioniert (dh nicht in die Domäne eingebundene Computer, die nicht die vollständige .NET CLR ausführen können). Dies gibt Ihnen einen schnellen Gewinn und einen Ausgangspunkt, um rückwärts zu arbeiten, um es auf anderen Servern zu implementieren.

Wir haben mit @tquerec und unseren Managementketten zusammengearbeitet, um herauszufinden, wie wir diese Arbeit so schnell wie möglich entsperren können. Leider haben wir vor Ende Januar niemanden frei, daher werden wir in der Zwischenzeit unser Bestes tun, um Community-Beiträge mit nur begrenzten Ressourcen und etwas Freiwilligenarbeit von unserer Seite ( @ianhays @tquerec und @karelz) freizugeben.

Folgendes planen wir:
@ianhays wird uns helfen, das Projekt im CoreFX-Repo zu starten (fügen Sie etwas Quellcode hinzu, zeigen Sie Beispiele, wie es geht, beraten Sie beim Einrichten des Builds, Packen, bereiten Sie das Projekt für zukünftige Linux/Mac-Portierungen vor usw.).
Wir beginnen mit einer reinen Windows-Implementierung (Beiträge sind willkommen). Wir werden an dieser Stelle keine funktionalen Änderungen an der Implementierung oder API-Oberfläche vornehmen, es sei denn, sie sind für die Portierung auf .NET Core erforderlich.
Der nächste (möglicherweise parallele) Schritt wird das Hinzufügen von Tests sein. Wir sollten die Diskussion mit @tquerec über bestehende Testdesigns (Closed-Source-.NET-Framework) anstoßen, wenn wir irgendetwas nutzen können oder wenn wir bei Null anfangen müssen.
Später können wir uns auf Linux/Mac-Portierungen konzentrieren.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte und alle anderen Interessierten, wir nehmen gerne Ihre Beiträge entgegen, sobald @ianhays Kick mit den Bemühungen beginnt (voraussichtliche Ankunft: Mitte nächster Woche, glaube ich). Wenn Sie Fragen oder Anregungen haben, lassen Sie es uns bitte wissen.

Ermöglicht diese Arbeit auch Bibliotheken wie SqlClient, die Windows-Authentifizierung durchzuführen, wenn sie unter Linux ausgeführt werden, aber eine Verbindung zu einem SQL Server herstellen, der eine Windows-Authentifizierung erfordert?

Das ist eine meiner Hürden, um Dinge auf .NET Core unter Linux portieren zu können. Alle unsere Enterprise-Microsoft-SQL-Server erlauben nur die Verbindung über eine Service-ID (nicht interaktiv), die sich in AD befindet.

blgmboy. Ihr Problem ist ein Paradebeispiel dafür, warum Dinge "geprüft" werden müssen, um eine echte plattformübergreifende Kompatibilität mit den neuen vorgeschlagenen Modellen sicherzustellen. Wenn Sie mehr Szenarien haben, denke ich, dass Ihre Umgebung ein gutes Beispiel dafür ist, wie sich die Dinge kreuzen müssen, und Sie sollten alle anderen Probleme auflisten, die Sie mit dem AD-Teil von Core haben.

Ja, ich werde diesen Thread auf jeden Fall im Hinterkopf behalten und alles teilen, was ich finde. Ich wollte nur alle wissen lassen, dass dies ein ziemlich großer Showstopper für Unternehmen mit SQL-Farmen ist, die wie beschrieben strenge Sicherheitsvorkehrungen treffen.

Es ist auch ein Showstopper für die Verwendung von etwas wie EF Core, das letztendlich das gleiche Problem hätte.

System.DirectoryServices wird jetzt in CoreFX zusammengeführt. Der nächste Schritt besteht darin, es für .NET Core – Windows zu erstellen und Tests hinzuzufügen.

Danke Ian. Es ist gut, etwas Traktion zu diesem Thema zu sehen!

Danke Jan!

Aktualisierter Ausführungsplan: BEARBEITEN: Zur besseren Auffindbarkeit in den obersten Beitrag in dieser Ausgabe verschoben

Wenn jemand an einem Schritt arbeitet, erwähnen Sie ihn bitte und koordinieren Sie ihn hier, um doppelten Aufwand zu vermeiden. Ich werde das Thema auch an Sie weitergeben.

Die System.DirectoryServices -Namespaces enthalten so wichtige Funktionen für lokale Windows-Unternehmensanwendungen, dass es großartig ist, einige Fortschritte bei diesem Problem zu sehen. Mach weiter so.

Ich habe die Quellen repariert und System.DirectoryServices wird jetzt erstellt. Ich sollte bald eine PR verschicken.

Danke @tquerec für den Beitrag zur zweiten Runde!
Gibt es Freiwillige, die bei den verbleibenden 2 Namespaces oder Tests helfen? ( @gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 hat hier oben einen PR https://github.com/dotnet/corefx/pull/15324 , um weitere Unterstützung hinzuzufügen und das Erstellen von Protokollen/Kontoverwaltung zu erhalten.

Für das, was es wert ist, habe ich kürzlich mit System.DirectoryServices.Protocols experimentiert und festgestellt, dass viele einfache System.DirectoryServices-Szenarien mit System.DirectoryServices.Protocols nicht schwer nachzuahmen sind. Ausgehend davon denke ich, dass es eine geringere Priorität haben kann, S.DS und S.DS.AM plattformübergreifend zum Laufen zu bringen, da ein plattformübergreifendes System.DirectoryServices.Protocols für viele Benutzer eine brauchbare Problemumgehung darstellen könnte.

Das bedeutet natürlich, dass es eine hohe Priorität bleibt, System.DirectoryServices.Protocols als plattformübergreifende LDAP-Lösung zum Laufen zu bringen.

Lese ich den Pull-Request richtig? Sieht so aus, als ob dies vor ein paar Tagen akzeptiert wurde. Wenn wir also aus dem Quellcode bauen, sollten wir es ausprobieren können?

Ja, ich denke, wir haben alle DirectoryServices erstellt, aber wir haben keine Tests - was uns daran hindert, das Paket als stabil auszuliefern und an Verbesserungen an der Codebasis (Bugfixes, Erweiterungen usw.).
Wenn Sie es versuchen könnten, es aus dem Quellcode zu erstellen, wäre das großartig. Wenn Sie (oder jemand anderes) uns helfen möchten, Tests hinzuzufügen oder eine Linux-Portierung zu starten, wäre das noch besser :)

Hallo allerseits,

Wir bereiten uns darauf vor, ein Unternehmensprojekt zu starten, das Active Directory-Unterstützung erfordert, da wir in unserer Domäne zu 100 % intern sind. Kann jemand bitte den Status für dieses Problem und die Erwartungen für die nächste Kernversion angeben? Ich entschuldige mich, aber ich bin neu in der GitHub-Community und verstehe noch nicht alle verschiedenen Terminologien und Statusinformationen.

Es wäre großartig, Active Directory für die Mitgliedschaft zu verwenden, anstatt ein völlig separates Identitätsmodell zu verwenden, das separat verwaltet werden müsste und auch nur Datenkonflikte verursachen würde.

Vielen Dank im Voraus!

@karelz für diese Frage, aber ich denke, die Antwort ist, dass dies derzeit nicht in der Version 2.0 erwartet wird, da wir keinen Entwickler dafür geplant haben. Gemeinschaftsbeiträge sind willkommen. Es muss nicht _in_ der Version 2.0 ausgeliefert werden, es kann jederzeit auf NuGet veröffentlicht werden, wenn es versandfertig ist.

Perfekt! Du hast meine Frage beantwortet.

Danke.

@nevcoBpalacio Interesse an einem Beitrag?

Ich habe ein Interesse, insbesondere an diesem Thema, da ich weiß, dass es viele davon abhält, sich mit Unternehmenslösungen auf den Kern zu konzentrieren. Wir haben jedoch eine Arbeit und ich finde tagsüber (abends mit Kindern) keine Zeit dafür. Ich werde versuchen, mein System zu Hause so umzurüsten, dass es mit GitHub funktioniert. Ich weiß es zu schätzen, dass du fragst! Danke.

Nevcobpalacio, wenn Sie vs17 verwenden und kein Cross-Plat benötigen, können Sie dem, was Sie wollen, etwas näher kommen, indem Sie die Kern-Web-App-Vorlage verwenden, die auf das vollständige .net-Framework abzielt, und die system.directoryservices.accountmanagement-DLL auf die altmodische Weise und referenzieren Rollen Sie in der Zwischenzeit Ihre eigene Middleware, um dies zu tun. Soweit ich gesehen habe, sollte derselbe Code auf den .net-Kern übertragen werden, sobald dieser verfügbar ist, außer dass Sie das nuget-Paket verwenden und die Referenz löschen. Ich hoffe, diese Informationen helfen dabei, Ihr Projekt auf Kurs zu bringen.

@los93sol danke für diesen Vorschlag. Unsere anfänglichen Diskussionen zielen darauf ab, es ähnlich wie dieser Vorschlag zu bauen und es zu einem Middleware-Modul zu machen, das wir später auf alle Länder in Nuget "übernehmen" können. Vielen Dank!

Ich muss Sie zu diesem Vorschlag kommentieren und loben. Ich war anfangs skeptisch gegenüber dieser Änderung des Kerns. Mit diesem Community-Ansatz kommen Diskussionen wie diese jedoch ans Licht und helfen uns allen, die Dinge während dieser großen Veränderungen zu klären.

Danke.

Arbeitet jemand derzeit daran, die fehlenden Tests hinzuzufügen oder System.DirectoryServices.Protocols auf Linux/Mac zu portieren?

@pasikarkkainen AFAIK , es gibt derzeit keine solchen aktiven Bemühungen von Microsoft-Teams (was sich in naher Zukunft ändern könnte oder auch nicht). Ich habe auch niemanden aus der Community gesehen, der damit begonnen hat, daran zu arbeiten.
Sind Sie daran interessiert, einen Beitrag zu leisten, oder sind Sie nur neugierig auf den Status?

@karelz Es sieht so aus, als würden sie diesen Sommer auf die DirectoryServices für die Veröffentlichung von .NET Core 2.0 abzielen.

Zitat von @shanselman

AD – Insgesamt ist dies eine Lücke, wenn Sie LDAP direkt aufrufen möchten. Sie können sich sicherlich JETZT gegen Windows Auth authentifizieren. Wir planen, um den Sommer herum speziell den DirectoryServices-Namespace für Core 2.0 zu haben

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

Ja, das stimmt mit Flurdiskussionen überein, die ich gehört habe. Ich war mir nur nicht sicher, ob es sich um öffentliche Informationen handelt und wie viel (und wer) sich dafür engagiert hat. Ich denke, man kann mit Sicherheit sagen, dass es sehr stark in Erwägung gezogen wird und wahrscheinlich passieren wird. Ich lasse Besitzer von @shanselman & DirectoryServices die Zeitleisten kommentieren.

@karelz : Danke für das Update! Ich war hauptsächlich neugierig auf den Status. Ich kann definitiv beim Testen helfen, zumindest wenn dies verfügbar ist.

@pasikarkkainen Wenn Sie auch bereit sind, beim Schreiben einiger Testfälle zu helfen, wäre das sehr zu schätzen.
Wenn Sie das Paket "nur" auf Ihrer App/Ihrem Code testen möchten, sollte dies heute machbar sein. Wir müssen nur damit beginnen, das Paket als Vorschau auf myget zu veröffentlichen (ich denke, die Veröffentlichung ist heute deaktiviert).

@karelz Ich hätte nichts dagegen, speziell bei der Mac-Implementierung zu helfen. Ich habe wenig Wissen, also bin ich mir nicht sicher, wie gut ich beitragen kann. Ich habe darüber recherchiert und es gibt eine Romanbibliothek, die die Leute vorzuschlagen scheinen. Hier haben Sie die Implementierung einer anderen Person rund um diese Novell-Bibliothek gefunden: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt Autor des Pakets hat es hier schon erwähnt.
https://github.com/dotnet/corefx/issues/2089#issuecomment -228043297

Ist das also etwas, das in Core 2.0 enthalten sein wird? Ich bin etwas verwirrt, was den Status angeht.

Nein, es wird nicht Teil von .NET Core 2.0 sein, aber auf der Build-Konferenz haben wir die Verfügbarkeit des Pakets im Sommer versprochen. Das (Windows-)Paket sollte zusätzlich zu .NET Core 2.0 verfügbar sein, etwa zu dem Zeitpunkt, zu dem .NET Core 2.0 ausgeliefert wird.
Wir arbeiten derzeit daran, die Pakete als Preview im Master-Branch verfügbar zu machen (#18090) und arbeiten parallel an Test-Assets (#20669).

Erhalten wir Kompilierungsfehler, wenn wir auf die gemeinsam genutzte Laufzeit oder eine Nicht-Windows-Laufzeit abzielen? Oder enden wir in der PlatformNotSupported -Falle?

Es wird ein eigenständiges Paket ohne Nicht-Windows-Assets sein. Die Zusammenstellung sollte brechen. @ericstj kann das bestätigen.

Sie erhalten keine Kompilierungsfehler, es handelt sich um „PlatformNotSupported“-Ausnahmen zur Laufzeit.

Ja, es ist das alte – blockieren wir Leute, die es aus .NET Standard-Bibliotheken verwenden, oder wandeln wir Kompilierungsfehler in PlatformNotSupported-Ausnahmen um? ... Glücklicherweise gibt es einen Mittelweg: ApiCompat- Tools sagen Ihnen im Voraus, dass Sie etwas verwenden, das nicht überall vorhanden ist.

Ich erhalte die folgende Fehlermeldung, wenn ich versuche, das System.DirectoryServices-Paket im netstandard 1.6-Projekt abzurufen:

Installationspaket : Paket System.DirectoryServices 4.0.0 ist nicht kompatibel mit netstandard1.6 (.NETStandard,Version=v1.6). Paket System.DirectoryServices 4.0.0 unterstützt: net (.NETFramework,Version=v0.0)

Gibt es dafür einen Workaround oder eine Lösung?
Grüße,
Varun

@vrn11 Dieses Paket stammt von einem anderen Anbieter und unterstützt nur das vollständige Net-Framework

Wollte trotzdem fragen, ob es diesbezüglich ein Update gibt. Vielleicht ein Preview-Paket, das wir von myget bekommen können? Wäre toll, das mal zu testen

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

Wie @MarcusKohnert erwähnt hat, können Sie sie von https://dotnet.myget.org/F/dotnet-core/api/v3/index.json abrufen. Es gibt System.DirectoryServices, System.DirectoryServices.AccountManagement und System.DirectoryServices.Protocols.

Genial! danke an @MarcusKohnert und @ericstj für die Links!

Ich versuche die Pakete von myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
Während der Ausführung auf einem MacOS 10.12.6 und während der Ausführung:

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

Ich erhalte:

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

Soll PrincipalContext auf einem Mac funktionieren?

@bruno-garcia Derzeit gibt es keine Implementierung in CoreFX für DirectoryServices, außer unter Windows. @karelz müsste mit Plänen / Bestrebungen sprechen, falls vorhanden.

Nur System.DirectoryServices.Protocol ist potenziell x-plat machbar (noch nicht implementiert) - siehe Details in einigen meiner Antworten oben und im obersten Beitrag.

Es ist wichtig, dass System.DirectoryServices.Protocols plattformübergreifend funktioniert (auch unter Linux/Mac). Habe ich das richtig verstanden, besteht das Hauptproblem derzeit darin, dass die von System.DirectoryServices (unter Windows) verwendete LDAP-Bibliothek nicht Open Source und daher nur ist funktioniert unter Windows?

Wenn ich es richtig verstanden habe, wird es schwierig sein, System.DirectoryServices xplat zu machen, da viele Abhängigkeiten von ADSI-COM-Schnittstellen bestehen, die nur unter Windows verfügbar sind.

System.DirectoryServices.Protocols sollte weiterhin möglich sein, xplat auszuführen.

Ausführen des gleichen Codes, den ich zuvor erwähnt habe:
```c#
using (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

Auf einem Win7 x64 mit .NET Core 2.0 ergibt sich:

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)

Benutzte die Pakete:

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

[BEARBEITEN] Hervorhebung der Callstack- und XML/C#-Codesyntax durch @karelz korrigiert

@bruno-garcia reichen Sie bitte ein separates Problem ein. Dieser verfolgt den gesamten Portierungsaufwand, nicht bestimmte Fehler/Unterschiede. Danke!

@bruno-garcia, das von https://github.com/dotnet/corefx/issues/23605 verfolgt wird

Der nächste Schritt kann sein, über den Desktop zu debuggen und zu sehen, wo das Verhalten abweicht. Ich werde versuchen, einen Entwickler freizugeben, der sich das ansieht.

Gleiches Problem auf Windows Server :( (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)

Was meint ihr, wann klappt es?

ein Problem haben, wenn Sie versuchen, ein Paket zu installieren

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

=============================================
Wenn jemand das gleiche Problem wie ich hat, verwenden Sie stattdessen .NET CLI

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 das liegt daran, dass Ihnen https://dotnet.myget.org/F/dotnet-core/api/v3/index.json als Quelle fehlt und Install-Package Ihren angegebenen Feed nicht zum Suchen von Abhängigkeiten verwendet hat. Möglicherweise möchten Sie einen Fehler auf http://github.com/nuget/home mit bestimmten Repro-Schritten melden.

@karelz Wenn ich die Kommentare richtig verstehe, funktioniert dies nicht bei Linux-basierten Bereitstellungen?

@euclid47 System.DirectoryServices.* wird derzeit nicht unter Linux unterstützt. Wie oben besprochen, könnten Teile davon bei ausreichendem Interesse/Beteiligung der Community möglicherweise portiert werden.

@danmosemsft Ich verstehe nicht, wie Sie diesen gesamten seit Oktober 2015 geöffneten Thread nicht als ausreichendes Community-Interesse ansehen können. Wenn ich über die Fähigkeiten verfügen würde, etwas so Kompliziertes wie eine LDAP-Kommunikationsschicht zu schreiben, hätte ich bereits daran gearbeitet, da das AD einer der zentralen Authentifizierungsmechanismen in einer Unternehmensumgebung ist. Ich möchte darauf hinweisen, dass für die meisten großen Unternehmen die Unfähigkeit, diese Art von Interaktionen unter Linux durchzuführen, den Zweck von Core buchstäblich zunichte macht und dazu führt, dass sie sich an Pre-Core-Builds von dotnet halten, wodurch Ihre wertvolle Community-Interaktion eingeschränkt wird.

@danmosemsft Wenn Sie buchstäblich nicht vorhaben, daran zu arbeiten, teilen Sie dies der Community einfach endgültig mit, damit andere Entwickler die Teile aufgreifen können.

@shairozan bisher haben wir 7 von 54 Stimmen notiert, die DirectoryServices unter Linux als höhere Priorität als Windows ansehen – siehe https://github.com/dotnet/corefx/issues/2089#issuecomment -261093217
Es gibt auch andere Vorteile, die Entwickler aus .NET Core ziehen, als nur die x-Plattform (obwohl ich zustimme, dass x-Plat einer der Hauptgründe ist).

Ich würde empfehlen, zuerst die Veröffentlichung des reinen Windows-Pakets abzuschließen, dann können wir ein neues Problem eröffnen, um das Interesse an der Linux-Portierung genauer zu verfolgen.

Wir haben der Community bereits mitgeteilt, dass wir nach Hilfe suchen und dass das Problem als offen markiert ist – siehe https://github.com/dotnet/corefx/issues/2089#issuecomment -261681168. Und @hughbe half bei der ersten hier , hier und hier .

@karelz Wo wird die Abstimmung für diese Komponenten verwaltet? Ich kann garantieren, dass Sie nach SELF / POSSCON einen ziemlich drastischen Anstieg des Interesses feststellen werden.

@karelz Wo ist die Abstimmung für dieses Feature? Ich stimme @shairozan mit der Notwendigkeit absolut zu. In dieser Ausgabe gibt es einen Kommentar , der unsere Entwicklungs- und Produktionsumgebung beschreibt. Es ist ziemlich schockierend, dass es bei der Implementierung keine Bewegung gegeben hat, seit .Net Core-Evangelisten predigen, dass es plattformunabhängig ist.

Ich habe eine neue Ausgabe erstellt, um den Linux/Mac-Port dotnet/corefx#24843 zu verfolgen, damit die Abstimmung einfacher ist als im Kommentar in der Mitte dieser Ausgabe (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217 ).

Ich habe den Link auch in den obersten Beitrag dieser Ausgabe eingefügt.

@euclid47 die bisherige Abstimmung fand in dieser Ausgabe statt - siehe die Links oben. Das führte zu den 7 Stimmen (+1 für den Einreicher der ursprünglichen Ausgabe).

Unser Team benötigt Unterstützung für LDAP unter Linux.
Weil die meisten unserer Kunden die Authentifizierung über LDAP verwenden.

@balkarov Wenn Sie können, stimmen Sie für das Problem ab, das @karelz gerade erstellt hat ( https://github.com/dotnet/corefx/issues/24843 ).

@balkarov @shairozan @euclid47 Wenn Sie es noch nicht wissen, gibt es das Nuget -Paket Novell.Directory.Ldap.NETStandard, mit dem Sie LDAP in Ihre Projekte integrieren können. Wir sind keine fortgeschrittenen LDAP-Benutzer, wir verwenden es nur, um Anmeldeinformationen zu validieren und Benutzerinformationen abzurufen, aber es funktioniert gut für uns, sowohl auf 1.0 als auch auf 2.0, die auf dem Dotnet-Core-Laufzeit-Docker-Image ausgeführt werden. Es ist kein offizieller Weg, aber es erledigt die Arbeit, bis es einen plattformübergreifenden Port von System.DirectoryServices gibt.

@OskarKlintrot danke. Diese Bibliothek unterstützt jedoch keine Anmeldung ohne Domäne.
Ich erstelle das Problem https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
Können Sie mir helfen, dieses Problem zu lösen?

Ich bin kein Teil dieses Projekts oder ein fortgeschrittener Benutzer, aber ich werde einen Blick darauf werfen, wir sehen uns dort!

(Wir melden uns nicht mit einer Domain an)

Da @karelz ein Problem für Unix ausbrach, habe ich dieses zur Verdeutlichung umbenannt.

@danmosemsft , aber das Problem hat einen Plan
Linux/Mac-Ports.

@balkarov Ich habe den Plan aktualisiert, um auf andere Nachverfolgungsprobleme zu verlinken, und Kontrollkästchen für Elemente entfernt, die separat nachverfolgt werden (unterbrochene Arbeit) oder die Windows-Arbeit nicht blockieren.

Wird der System.DS-Port mit RODC-Servern (Read-Only Domain Controllers) kompatibel sein?

@PKGeorgiev Sie sollten die gleiche System.DirectoryServices-Unterstützung erhalten, die wir im vollständigen Framework haben.

Die Arbeit an DirectoryServices für Windows ist abgeschlossen und das Problem damit geschlossen.
Notiz:

• Die endgültige Paketveröffentlichung wird von dotnet/corefx#24909 nachverfolgt
• Der Linux/Mac-Port wird separat von dotnet/corefx#24843 nachverfolgt

Hallo, funktioniert das in UWP?

Hallo, funktioniert das in UWP?

Nein, es wird nur für Net Core-Apps unterstützt, die unter Windows und dem vollständigen Framework ausgeführt werden. Wenn Sie es in UWP oder unter Linux verwenden, erhalten Sie eine PlatformNotSupported-Ausnahme.

Ich verwende diesen Code in einer Lambda-Funktion in AWS, die unter Linux im Hintergrund ausgeführt wird, und erhalte diesen Fehler. "System.DirectoryServices.AccountManagement wird auf dieser Plattform nicht unterstützt."
Ich verwende Core 2.0

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

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

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

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

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

            return result;
        }

@sscoleman Ja, dies wird unter Linux noch nicht unterstützt. Es wird nur unter Windows unterstützt.

@sscoleman , es wurde ein Problem erstellt, https://github.com/dotnet/corefx/issues/24843. Es wurde gesagt, dass es nicht genug Interesse der Gemeinschaft daran gab, mit der Ausnahme, dass diese Frage die ganze Zeit auftaucht. Jetzt sind Sie also in einer schlechten Lage. Sie haben Zeit damit verbracht, Verzeichnisdienste zu implementieren, und finden dann heraus, dass Linux unterstützt wird. Jetzt fragen Sie sich, warum dies als plattformunabhängig angepriesen wird, wenn es nur Windows-Funktionen gibt.

Es ist ziemlich offensichtlich, wenn man sich die umfassendere Microsoft-Strategie ansieht. Microsoft wirft ALLE seine Entwicklungsressourcen in Azure, und dazu gehört auch Active Directory. Sehen Sie sich „Was ist neu in 2016“ an, es handelt sich hauptsächlich um AzureAD/Hybrid-Investitionen. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft investiert nicht in diese Bibliothek für Linux, weil sie möchten, dass alle stattdessen zu Azure AD wechseln. Es macht Sinn, warum sollten Sie in etwas investieren, von dem Sie versuchen, Kunden davon abzubringen?

Du machst aber etwas relativ Einfaches. Sie können die Novel LDAP-Bibliotheken verwenden, sie funktionieren mit AD und auf .NET Core für Linux. Sie müssen die Protokollarbeit selbst durchführen, aber es ist nicht übermäßig komplex, und es gibt viele Proben da draußen. Der Nachteil ist, dass Sie die Bindung selbst verwalten müssen, was einen Benutzer-DN und ein Passwort erfordert.

System.DirectoryServices ist derzeit eine reine Windows-API und Teil des Windows-Kompatibilitätspakets für .NET Core . Im Prinzip können wir Teile von System.DirectoryServices unter Linux zum Laufen bringen, aber wir hatten noch nicht die Ressourcen dafür. dotnet/corefx#24843 verfolgt dieses Arbeitselement.

Warum erlauben wir die Installation von Paketen, die unter Linux nicht funktionieren? Die Alternative wäre, die API-Oberfläche zu forken, aber das funktioniert auch nicht in allen Fällen gut und erschwert das Coden gegen das Gesamtsystem. Natürlich ist unsere Wahl auch nicht ohne Probleme, da es schwieriger vorherzusagen sein kann, ob Code plattformübergreifend funktioniert oder nicht. Wir haben eine Vorschau auf einen Kompatibilitätsanalysator, der Ihnen beim Codieren Live-Feedback gibt.

Sehen Sie sich dieses Video an, um mehr Kontext dazu zu erhalten, wie das Windows Compatibility Pack und der Cross-Platform-Analyzer unserer Meinung nach Hand in Hand arbeiten:

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

@thedevopsmachine

Microsoft investiert nicht in diese Bibliothek für Linux, weil sie möchten, dass alle stattdessen zu Azure AD wechseln.

So sehe ich das nicht. Wie Sie bereits sagten, beabsichtigen wir, über Azure Geld zu verdienen. Und Azure ist eine Cloud-Plattform, die eine Vielzahl von Technologien und Betriebssystemen bietet. Wir haben kein geschäftliches Interesse daran, Windows in der Cloud gegenüber Linux in der Cloud zu fördern. Aber natürlich ist .NET seit 15 Jahren unter Windows stark vertreten. Es braucht Zeit, Dinge auf allen Betriebssystemen voll funktionsfähig zu machen, aber ich denke ehrlich, dass die meisten Leute, die unsere Open-Source-Bemühungen verfolgen, erkennen können, dass wir Linux nicht absichtlich behindern. Es braucht nur Zeit.

Ich stimme dem Ansatz zu, ein konsistentes API-X-Plat- und X-Framework zu haben, aber es ist seelenzerstörend, wann immer ich auf diesen gefürchteten Fehler gestoßen bin. Ich fühle mich für @sscoleman ...

Funktioniert dieses DirectoryServices-Paket unter CentOS 7?

Funktioniert dieses DirectoryServices-Paket unter CentOS 7?

Das Paket kann installiert werden, funktioniert aber nicht. Wenn Sie es verwenden, erhalten Sie eine Plattform nicht unterstützte Ausnahme. wir prüfen, wie wir Verzeichnisdienste im Allgemeinen unter Linux unterstützen können. das ist auf unserem Radar.

Dies braucht wirklich Unterstützung Linux

CC @joperezr

@niemyjski siehe dotnet/corefx#24843

Dies braucht wirklich Unterstützung Linux

.. plus in der Lage sein, in einem Docker-Container zu laufen. Imho ist es ein Ärgernis, dass man auf die alte Novell-Verzeichnisimplementierung zurückgreifen muss, wenn man .NET Core 2+ unter Linux verwenden möchte.
Danke trotzdem für die Arbeit daran!

Warum dieses Thema schließen? System.DirectoryServices.AccountManagement ist immer noch nicht in .NET Core außerhalb von Windows:

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

14734 wieder öffnen

@tarekgh immer noch auf dem Radar?

14734 wieder öffnen

@JustinGrote Was ist die genaue Funktionalität, die Sie für das Szenario wünschen? DirectoryServices ist riesig und ich bezweifle, dass die gesamte Funktionalität in nur einer Version unterstützt werden kann. Spezifische Anfragen zu haben, kann besser helfen, als nur die Unterstützung der gesamten DS-Bibliotheken anzufordern. In .NET 5.0 haben wir ein Szenario https://github.com/dotnet/runtime/issues/23944 aktiviert.

CC @joperezr

@tarekgh
Ich war mir nicht bewusst, dass System.DirectoryServices.Protocols portiert wurde, aber es sieht so aus, als ob es immer noch eine Abhängigkeit von security.principal.windows hat, funktioniert es unter Linux auch damit (über grundlegende Authentifizierung usw.) oder wird es eine fehlende werfen Montagefehler?

Ziel ist es, so etwas wie das ActiveDirectory-Powershell-Modul als xplat neu zu implementieren. Ich habe für diesen Zweck entweder das Novell-LDAP-Modul oder ldap4net in Betracht gezogen, wenn nicht zumindest eine grundlegende Interaktionsunterstützung verfügbar wäre.

Die Implementierung von ActiveDirectory Powershell ist wahrscheinlich ein sehr großer Anwendungsfall. Lassen Sie mich meine zwei Anwendungsfälle teilen:

1) Ich leite von UserPrincipal ab, da ich Attribute benötige, die nicht standardmäßig unterstützt werden. Ich bin https://stackoverflow.com/questions/24798037/extend-userprincipal-class gefolgt und denke, dass dies eine Art Standard im alten .NET-Framework ist, und es wird wahrscheinlich mehr Entwicklern helfen, diesen Ansatz zum Laufen zu bringen.

2) Ich habe auch Code wie den folgenden:

`

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

`

Keine Ahnung, was heute schon unterstützt wird, das letzte Mal habe ich im Februar nachgesehen.
Danke Joachim

@jol64 kannst du nicht dasselbe mit den Protokollen erreichen?

@jol64 kannst du nicht dasselbe mit den Protokollen erreichen?

Wahrscheinlich kann ich das. Ich habe einige Sachen umgeschrieben, um die Novell-Bibliothek zu verwenden. Aber es erfordert ein Umschreiben und damit redundanten Code zu meinem bestehenden .NET-Framework-Code. Ich ziehe es definitiv vor, eine Codeaufteilung des gesamten Codes zu vermeiden, und ich bin sicher, dass andere die Idee auch nicht mögen.
Ich frage mich auch, wie die Authentifizierung funktioniert. Bei Novell (der alten Version, die ich ausprobiert habe) muss ich Anmeldeinformationen angeben, während ich dies bei meinem vorhandenen Code nicht brauche.
Danke Joachim