AD utility on all workstations

We are looking to deploy a utility that all users may need to use that does some basic stuff with AD objects. I was looking to write the utility using Powershell studio and AD cmdlets but then I realised that all workstations (win7) would have to have RSAT installed. The utility couldnt do implicit remoting to get to AD cmdlets because it is being run by non administrative users. One option is to use older style methods to access AD but I’d prefer to use AD cmdlets. We already have a website with ugly PHP code that does LDAP access which I am trying to replace. Anyone had to do this or could recommend how one could deploy a utility to all users written in powershell that does AD access?
Thanks
David Z

Well… you could certainly set up a new Remoting endpoint on a domain controller, and simply fire commands to it via Invoke-Command. Endpoints can run under alternate credentials, and can have an ACL that restricts who can connect. You can also limit the commands that are visible inside the endpoint. There’s an extensive example in “Secrets of PowerShell Remoting.” Essentially, this is what JEA does, although you can set it up manually as described in the ebook.

Thanks - I downloaded “secrets of powershell remoting” and unless I’ve missed something, I didn’t find a detailed reference on how to set up an ACL to allow others to invoke commands. And what is JEA please?

Just Enough Administration. It’s a v4 toolkit that uses Desired State Configuration to set these things up declaratively.

See https://www.penflip.com/powershellorg/secrets-of-powershell-remoting/blob/master/working-with-endpoints-aka-session-configurations.txt. “You can specify a security descriptor (SDDL) that determines who is allowed to connect.” It’s declared as a parameter of Register-PSSessionConfiguration, -SecurityDescriptorSddl, and there’s an entire walk through on using it.

Thanks - It’s a download thing. When I clicked download, it only seemed to download the first few pages on basics of remoting rather than everything I see on your web link.

You probably used PDF. That’s a known issue; I believe it’s noted on the first page. Most of us use EPUB.

Now I need myself an EPUB reader on windows…

So I can setup and register an endpoint which loads the activedirectorymodule by default and give “authenticated users” permission to read and invoke. This would then allow any user to use the AD cmdlets but only be allowed to do what their user account has AD permissions to do?

Yeah.

And, when you create the endpoint, you can specify a credential that will be a “RunAs,” meaning commands run in the endpoint will run under THAT, not the “dialed-in” user’s credential. So you could also let people run commands that they don’t normally have permission to, should that become a need.

Thanks for your help.
I’m guessing that this endpoint can be created on non DCs that have the AD cmdlets installed?
Also, I’m having trouble with the -sessiontype parameter. As mentioned earlier, the end user will run a powershell studio gui which will use invoke-command to run any number of AD cmdlets under their credentials. I have configured the session to automatically load the activedirectorymodule but what is the best sessiontype value to use in this situation please?

Sadly it didn’t work. I ran these commands on my 2008 R2 SP1 member server that has the activedirectory module:

New-PSSessionConfigurationFile -ModulesToImport ActiveDirectory -LanguageMode FullLanguage -SessionType Default -path D:\Scripts\util.pssc
Register-PSSessionConfiguration -path D:\Scripts\util.pssc -Name Util -ShowSecurityDescriptorUI

…and when the permissions dialog came up, I gave Auth Users Read and Invoke.
When I try and access this session it says that active Directory gateway services is not installed. I cannot run the above commands on my DCs as they are w2k3. So it appears that implicit remoting to give everyone access to AD cmdlets with installing them cannot be done until we upgrade our DCs.

Well… no, not exactly. First, you only need the Gateway running on one DC in the domain. I’m assuming your 2008 R2 SP1 box has it, but you should ensure it’s started.

Also, what you’re doing is not “implicit remoting.” You’ve set up a custom endpoint. Very different thing.

Do this as a test: Use Enter-PSSession to connect to the DC, as a Domain Admin, and try to run an AD command. What’s it do?

We have the gateway running on a few DCs. The 2008 R2 SP1 doesn’t have it as it’s a member server. If I do an Enter-PSsession to a DC and try to run an AD command it says that it is not recognized as the name of a cmdlet. Currently, those who need to run AD Cmdlets do so by having RSAT and the AD module installed on their workstations which is a limited number. As I want to deploy a utility to all workstations, I’m trying to find a way that end users, who are non administrators, can run this utility which uses AD cmdlets without having to install RSAT etc…

So, there’s a couple of things.

One, DCs don’t all necessarily have the commands. Depending on the version of PowerShell, you might also have to manually load the ActiveDirectory module in order to run commands. On 2008R2, for example, you can try running “Import-Module ActiveDirectory.” However, just because it’s a DC doesn’t mean the commands are installed - it’s entirely possible for them to not be present on the DC.

Second, the AD commands can’t really run from a member server. They need to be run on a member or a DC.

So your endpoint isn’t working because it isn’t on a domain member. That means it can’t “find” a gateway to talk to, and it doesn’t have a secure channel for doing so. You need to set up the endpoint on a machine that’s a domain member, and that has the commands installed, either natively or from the RSAT. It doesn’t need to be a server; a client machine can easily host the endpoint, provided Remoting is enabled and the RSAT is installed, and it’s in the domain.

By member server I mean that the 2008 R2 Sp1 server is not a DC - it is a member server that is part of the domain. It currently runs tons of scripts which use AD cmdlets - it’s a ‘script’ server. That’s where I am trying to create the endpoint without success at this stage.

Gotcha.

Ok, well, we need to find out why it isn’t letting you run the command when you remote in. Is the module in its default location? Can you manually import the module and run commands?

OK - I reset everything and started again. when I run the enter-possession command as a non admin using my defined endpoint I get in. If I start typing an ad cmdlet, intellisense will fill stuff in automatically so I know the ad cmdlets are there. The error when entering the session is now ‘Error initializing default drive’. It suggests the server doesn’t exist or active directory web services don’t exist. So its a problem of the member server, which has the endpoint, trying to contact web services? But on the member server itself, it can happily run AD cmdlets. Must be something simple that is missing here.

I changed one thing to see if it works. I added the -runascredential parameter on the register-pssessionconfiguration and now it works fine. But that’s not what I want - I want the session to run under the end user’s context. Different end users will have differing access to AD and that it was I need for my utility to work.

The problem is in how the AD module works.

It attempts to map an AD: PSDrive to your default domain. This drive’s connection is what all the cmdlets default to. Depending on how you’ve registered your endpoint, and on what permissions your users have, it may be unable to map that drive. I suspect it’s the permissions that are your problem. Without that drive, the cmdlets don’t have a default authentication context. If your users don’t have the permissions needed to create it (and before you ask, I’m not positive what permissions those are), then they can’t successfully use the module.

What you can try is letting the drive mapping fail, and then trying to run the cmdlets using an explicit -Credential, so that the cmdlets don’t need to use the drive’s authenticated connection. I’ve not tried that before, but you can. You can also try manually mapping a drive from within the remote run space - use New-PSDrive and map using the ActiveDirectory provider to your domain. If that works, it’s easy enough to automate.

It won’t let me do a new-psdrive but I did do an ad cmdlet with the credential parameter and it worked! Thanks for the tip. So when they fire up the utility and it does a get-credential, all they will get is a password prompt which is not too onerous. Then they will only be able to do what their credential allows which is perfect. It means that the entire script is running in the session but with -languagemode fulllanguage, that shouldn’t be a problem. I’ll get my powershell studio util to do a few basic things and test it out and report back.