Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support System.DirectoryServices.AccountManagement on Linux(/macOS) #37100

Open
FWest98 opened this issue May 27, 2020 · 1 comment
Open

Support System.DirectoryServices.AccountManagement on Linux(/macOS) #37100

FWest98 opened this issue May 27, 2020 · 1 comment
Labels
area-System.DirectoryServices enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors os-linux Linux OS (any supported distro) os-mac-os-x macOS aka OSX
Milestone

Comments

@FWest98
Copy link
Contributor

FWest98 commented May 27, 2020

Following the discussion in #23944 (comment), this issue is to track adding support for Linux (and/or macOS) to the S.DS.AM namespace. Since S.DS.Protocols is now implemented for all platforms, a logical next step would be to look into the "derived" namespaces.

As for a use-case, I quote myself from the other issue:

I'm working on an application that does a lot of user and group management through S.DS.AM, which I am planning on running in Kubernetes. Currently, it works with Windows hosts and pods within Kubernetes, but that is tricky to manage and some of our toolkit does not work (nicely) with Windows in K8s (for example, secret injection from HashiCorp Vault). Add to that the extra licensing costs and computing resources...

Reworking the application to S.DS.P is probably possible, but very inconvenient and would require significant work, as well as being more cumbersome to work with native LDAP objects instead of full-featured Principal objects from AM.

I believe everything in S.DS.AM is also possible using just S.DS.P, but especially converting existing applications might be too much of a burden to make this feasible for many. On top of that, it is more difficult to manage and it makes the code more difficult to work with in general.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.DirectoryServices untriaged New issue has not been triaged by the area owner labels May 27, 2020
@joperezr joperezr added help wanted [up-for-grabs] Good issue for external contributors os-linux Linux OS (any supported distro) os-mac-os-x macOS aka OSX labels May 27, 2020
@joperezr joperezr added this to the Future milestone May 27, 2020
@joperezr joperezr added enhancement Product code improvement that does NOT require public API changes/additions and removed untriaged New issue has not been triaged by the area owner labels May 27, 2020
@iSazonov
Copy link
Contributor

iSazonov commented May 28, 2020

S.DS.AM on Windows works with local accounts too.
I'd enhance the request to support the same on Unix-s too.
On Linux S.DS.AM could utilize PAM.

My request come from PowerShell where is a LocalAccounts module. The module uses non-public API and I port it to S.DS.AM with expectation that S.DS.AM will work on Unix-s in future for local and LDAP accounts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.DirectoryServices enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors os-linux Linux OS (any supported distro) os-mac-os-x macOS aka OSX
Projects
No open projects
Development

No branches or pull requests

4 participants