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 10 months, 1 week ago.

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

  • #34686
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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?

  • #34689
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

  • #34692
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

  • #34714
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #34760
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    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.

  • #34770
    Profile photo of David Zemdegs
    David Zemdegs
    Participant

    It's a bit of messy code but it works. I have a Powershell Studio gui tool which I have tested for a non administrative user. I set up the constrained session using the pssessionconfiguration commands mentioned earlier and gave auth users the read and invoke permissions. This was done on a member server which had the AD cmdlets installed (w2k8). My DCs are all w2k3 and some have the AD gateway services installed.
    The code in the Form_Load event looks like this:

    	$Global:Session = New-PSSession -ComputerName W2K8MS -ConfigurationName Util
    	$RunUser = $env:username
    	$global:cred = Get-Credential "Contoso\$RunUser"
    	$PSDefaultParameterValues = @{
    		"Invoke-Command:Session" = $Global:Session
    	}
    

    And a typical command looks like this – One of the first things I do is get the user object for the running user:

    	$global:user = invoke-command -ScriptBlock {
    		param ($cred,$user) Get-ADUser $user -properties * -credential $cred
    		} -ArgumentList $cred,$RunUser
    

    Another example – I have to get a list of all groups the user is a member of but only those that manage other groups:

    	$ldapfilter = "(&(member:1.2.840.113556.1.4.1941:=$($user.DistinguishedName))(managedobjects=*))"
    	$Managegroups = invoke-command -ScriptBlock {
    		param ($cred,$lf) get-adgroup -ldapfilter ($lf) -Properties managedobjects -credential $cred
    	} -ArgumentList $cred, $ldapfilter
    

    I think you get the idea...

    Thanks heaps Don for your suggestions!

You must be logged in to reply to this topic.