- January 25, 2016 at 9:44 pm #34286
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?
David ZJanuary 26, 2016 at 7:40 am #34311
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.January 26, 2016 at 1:24 pm #34333
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?January 26, 2016 at 1:36 pm #34335
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.January 26, 2016 at 1:39 pm #34336
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.January 26, 2016 at 1:43 pm #34338
You probably used PDF. That's a known issue; I believe it's noted on the first page. Most of us use EPUB.January 26, 2016 at 1:45 pm #34339
Now I need myself an EPUB reader on windows...January 26, 2016 at 2:13 pm #34341
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?January 26, 2016 at 2:28 pm #34342
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.January 26, 2016 at 3:51 pm #34344
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?February 1, 2016 at 3:07 pm #34676
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.February 1, 2016 at 3:23 pm #34677
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?February 1, 2016 at 4:55 pm #34683
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..February 1, 2016 at 5:03 pm #34684
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.February 1, 2016 at 5:20 pm #34685
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.
You must be logged in to reply to this topic.