AD utility on all workstations

This topic contains 20 replies, has 2 voices, and was last updated by Profile photo of David Zemdegs David Zemdegs 7 months, 4 weeks ago.

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
    Posts
  • #34286
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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

    #34311
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    #34333
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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?

    #34335
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    #34336
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

    #34338
    Profile photo of Don Jones
    Don Jones
    Keymaster

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

    #34339
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    Now I need myself an EPUB reader on windows...

    #34341
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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?

    #34342
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    #34344
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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?

    #34676
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

    #34677
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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?

    #34683
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

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

    #34684
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    #34685
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic.