Target Audience

[jdhitsolutions]

Who are you targeting as a typical user of this module? Is it a developer with LDAP experience? It is an IT Pro who manages Active Directory and wants to use something other than the RSAT Active Directory module? Or maybe for a senior AD administrator who understands LDAP. Maybe you have someone else in mind.

The reason I ask is that the answer can influence how you design your module. I would write a module with a developer audience very differently than something that targets an IT Pro in the trenches just trying to get work done. This can influence how you might use aliases, format and type extensions, and even what commands to build.

Of course, you can target multiple audiences but I suggest you make expectations and requirements clear in your documentation, e.g. the README

[jborean93]

My overall goal with this library is to try and bridge the gap between what is possible using PowerShell on Windows vs other platforms. The current state today is to interact with AD you essentially need to:

• Use PowerShell on Windows through ADSI or the ActiveDirectory module
• Use the System.DirectoryServices.Protocol class on non-Windows which wraps OpenLDAP
• Call OpenLDAP binaries like ldapsearch and manually parse the information yourself

When initially exploring this work I tried to have this module work on S.DS.Protocol but I found the user experience of setting up OpenLDAP was very poor and support things like Negotiate auth, session signing/encryption, TLS support was either non-existent or very difficult to set up. By writing my own client I am able to create a module that is truly cross platform and mostly works out of the box.

With that in mind I would say the IT professional or sysadmin that needs to perform ad duties like create users/groups/etc, gather information about ad objects, set ad object attributes would be the main target audience. In saying that I do wish to try and mirror the behaviour and UX (where it is relevant) of the Windows ActiveDirectory module. The cmdlets that have been written so far are mostly the same but there are a few exceptions where things either don't make sense or could be improved.

[jdhitsolutions]

There is definitely a need for a set of AD management tools that do not require RSAT and that can be installed from a gallery or repository. I noticed a subtle distinction in your language which highlights the different perspectives we have on this project.

You used the term 'library` and I'm thinking 'module'. To me, a library is a set of routines or commands that I can build my own tooling on. I think of the .NET framework as a library and Microsoft built a set of commands based on the library. The commands are packaged and delivered to end-users as modules. IT Pros interact with the module commands which are written to be easy to use and abstract a lot of the underlying .NET library code.

This is why I asked who your target user is.

You could write this module with a set of building blocks. Maybe you expose your classes and have a few reference commands like Get-OpenADGroup. I, and other experience IT Pros, could use your module to build our own tooling.

Or you can write a complete AD management module with commands designed to be easy to use and user-friendly for IT Pros who may not have much LDAP scripting experience.

Isn't this fun?

[jborean93]

Yes sorry I use the term library and module interchangeably which isn't correct. I definitely don't see this as being a generic library for other modules to build upon. It's designed to paper over all the edge cases when it comes to talking to AD instances which I find OpenLDAP doesn't really help with. Things like encryption, signing, LDAPS, cert validation, authentication is meant to be as secure as possible on a default with the ability to customize easily as needed.

I have written the underlying code in a way that makes it possible to split out the LDAP work into it's own nuget for others to use in the future and have the pwsh layer on top as it's own separate thing. But right now that's all internal details from an implementation perspective and I don't think this targets actual developers wanting to work on the internals of LDAP.

So I think my target aligns with what you originally though it would be, something for IT props to use to manage their AD instances without them worrying about the whole LDAP protocol itself. In saying that some LDAP-isms, like attribute names, value collections, etc, will bleed through due to the nature of the beast. But they don't have to know that to authenticate with LDAP you need to use auth x with TLS and so on.

The initial work I've done is mostly around Get-* operations. It covers the basics like Get-OpenADUser, Get-OpenADObject, etc. Going forward I do wish to add Set-*, New-*, and Remove-* operations as well as expand what's currently available through Get-*. There's a massive scope of work that the ActiveDirectory module provides and I'm just one person. I can only slowly add things as I go along and hopefully pick up some other contributions along the way.

[jdhitsolutions]

I wish I could help more with the coding. I can write terrific PowerShell modules but I'm not a C# developer.

[Denney-tech]

Once the next preview is pushed with the pagination fix, I will fork the repo to try and work on some stuff. I'm not much of a C# developer either, but I can at least do some QoL stuff and spit and polish. I was going to make an issue for a tiny QoL request but decided to try doing it myself and it built fine, so I will submit it as a pull request later instead.

[jborean93]

I wish I could help more with the coding. I can write terrific PowerShell modules but I'm not a C# developer.

Both have helped immensely just by using the module and trying out things I either missed or worked on environments I don't have access to which is just invaluable.

I appreciate any help I can get, whether it's just talking about thinks, suggestions, bug reports not just pull requests!

[jdhitsolutions]

That's why I encouraged you to open up Discussions.

[Denney-tech]

My motivation as a consumer is to use this for a dynamic inventory plugin for Ansible. It works swimmingly over non-encrypted sessions lol. I like that it can use an available kerberos ticket for password-less authentication, removing the need for plaintext credentials in the plugin.