共用方式為

Windows PowerShell remoting and delegating user credentials

  • 發行項

Hey all Rob Greene here again. Yeah, I know, it’s been a while since I’ve written anything for you good people of the Internet.

I recently had an interesting issue with the Active Directory Web Services and the Active Directory Windows PowerShell 2.0 modules in Windows 7 and Windows Server 2008 R2. Let me explain the scenario to you.

We have a group of helpdesk users that need to be able to run certain Windows PowerShell commands to manage users and objects within Active Directory. We do not want to install any of the Active Directory RSAT tools on helpdesk groups Windows 7 workstations directly because these users should not have access to Active Directory console snap-ins [Note: as pointed out in the Comments, you don't have to install all RSAT AD tools if you just want AD Windows PowerShell; now back to the action - the Neditor] . We have written specific Windows PowerShell scripts that the help desk users employ to manage user accounts. We are storing the Windows PowerShell scripts on a central server that the users need to be able to access and run the scripts remotely.

Hmmm…. Well my mind starts thinking, man this is way too complicated, but hey that’s what our customers like to do sometimes… Make things complicated.

clip_image002

The basic requirement is that the help desk admins must run some Windows PowerShell scripts on a remote computer that leverages the ActiveDirectory Windows PowerShell cmdlets to manage user accounts in the domain.

So let’s think about the “ask” here:

  • We are going to require Windows PowerShell remoting from the Windows 7 client to the middle tier server where the ActiveDirectory Windows PowerShell modules are installed.

By default you must connect to the remote server with an Administrator level account when PS remoting otherwise the remote session will not be allowed to connect. That means the helpdesk users cannot connect to the domain controllers directly.

If you are interested in changing this requirement the Scripting Guy blog has two ways of doing this via:

  • The middle tier server where the ActiveDirectory Windows PowerShell cmdlets are installed has to connect to a domain controller running the Active Directory Web Service as the PS remoted user account.

Wow, how do we make all this happen?

1. You need to enable Windows PowerShell Remoting on the Remote Admin Server. The simplest way to do this is by launching an elevated Windows PowerShell command prompt and type:

Enable-PSRemoting -Force

To specify HTTPS be used for the remote connectivity instead of HTTP, you can use the following cmdlet (this requires a certificate environment that's outside the scope of this conversation):

Set-WSManQuickConfig –Force -UseSSL

2. On the Remote Admin Server you will also want to make sure that the “Windows Remote Management (WS-Management)” service is started and set to automatic.

If you have done a decent amount of Windows PowerShell scripting you probably got this part.

Alright, the next part is kind of tricky. Since we are delegating the user’s credentials from the Remote Admin Server to the ADWS service, you are probably thinking that we are going to setup some kind of Kerberos delegation here. That would be incorrect. Windows PowerShell remoting does not support Kerberos delegation. You have to use CredSSP to delegate the user account to the Remote Admin Server (which does a logon to the Remote Admin Server) and then it is allowed to interact with the ADWS service on the domain controller.

More information about CredSSP:

MSDN Magazine: Credential Security Support Provider

951608 Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3
https://support.microsoft.com/kb/951608/EN-US

If you have done some research on CredSSP, it takes the user's name and password and passes it on to the target server. It is not sending a Kerberos ticket or NTLM token for validation. This can be somewhat risky. Just like with Windows PowerShell remoting CredSSP usage is disabled by default and must be enabled. The other key thing to understand about CredSSP is you have to enable the “Client” and the “Server” to be able to use it.

NOTE: Although Windows XP Service Pack 3 does have CredSSP in it. The version of Windows PowerShell for Windows XP does not support CredSSP with remote management.

3. On the Remote Admin Server, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:

Enable-WSManCredSSP –Role Server -Force

4. On the Windows 7 client, we need to configure the “Windows Remote Management (WS-Management)” service startup to Automatic. Failure to do this will result in the following error being displayed at the next step:

Enable-WSManCredSSP : The client cannot connect to the destination specified in the request. Very that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination to analyze and configure the winRM service: “winrm quickconfig”

5. On the Windows 7 client, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:

Enable-WSManCredSSP -Role Client -DelegateComputer *.contoso.com -Force

NOTE: “*.contoso.com” is a placeholder for your DNS domain name. Within the client configuration is where you can constrain the CredSSP credentials to certain “Targets” or destination computers. If you want them to only work to a specific computer replace *.contoso.com with the specific servers name.

6. Lastly, when the remote session is created to the target server we need to make sure that the “-Authentication CredSSP” switch is provided. Here are a couple of remote session examples:

Enter-PSSession -ComputerName con-rt-ts.contoso.com -Credential (Get-Credential) -Authentication CredSSP

Invoke-Command –ComputerName con-rt-ts.contoso.com –Credential (Get-Credential) –Authentication CredSSP –ScriptBlock {Import-Module ActiveDirectory; get-aduser administrator}

I hope that you have some new information around Windows PowerShell remoting today to make your Windows PowerShell adventures more successful. This story changes in Windows 8 and Windows Server 2012 for the better, so use this article only with your legacy operating systems.

Rob “Power Shrek” Greene

Comments

  • Anonymous
    August 02, 2012
    The comment has been removed

  • Anonymous
    August 02, 2012
    You would not like working here, LA. :-)

  • Anonymous
    August 02, 2012
    Well, I imagine at the end of the day there is satisfaction knowing you delivered the product per your customers request.  And, ultimately it is their decision, as long as their configuration stays in a "supported" configuration.  Right? I imagine the detachment from a project or problem takes a little getting used to.  :)  (I'd totally work for Microsoft, difficult problems and all)

  • Anonymous
    August 02, 2012
    Right on all counts. Or at least, that's what I keep telling myself. :-) The company is always hiring, give us a look: careers.microsoft.com/gclp.aspx

  • Anonymous
    August 02, 2012
    Thanks, Ravikanth Chaganti (MVP) has same article and great PDF about PowerShell 2.0 remoting guide. www.ravichaganti.com/blog www.ravichaganti.com/.../A%20layman%27s%20guide%20to%20PowerShell%202.0%20remoting-v2.pdf Thanks again Regards

  • Anonymous
    August 03, 2012
    I agree with LA, it seems like they forgot to sit 5 minutes in front of the coffee machine and think about it (well at least it works for me. Sometime :D). Well i've seen far worse. What about installing ADAC on Helpdesk computers ? Could this work ?

  • Anonymous
    August 04, 2012
    Totally agree with all of the above. The reasons for not having RSAT installed sound weird. Especially if it's fine for you to have all those helpdesk people enjoy Admin rights on that pretty strange middle server. But anyway, who said PowerShell Remoting doesn't support Kerberos? It might be that particular module (didn't try that) but in general it works. E.g. you can enable Kerberos delegation (instead of using CredSSP) and have browsing remote file shares from inside remote PowerShell session. I tried it many times and it works. Also I don't like the idea of configuring all the stuff manually. There are Group Policy settings for all of that. And if you're speaking of such things as ensuring the service is set to autostart, it's also worth to note that firewall exceptions should be in place. Yeah, normally Enable-PSRemoting would take care of that. But I often have Firewall state enforced with Group Policy without permitting locally defined exceptions.

  • Anonymous
    August 08, 2012
    Regardless of what one or the other customer wants. This article is very relevant. Think about applications like System Center Service Manager and creating a Self Service portal to do a particular action like disable and account, rename an account and all of the related items like Exchange, add group memberships. Today we would create a service account that has the access and let the portal run the job with the proper access and stop there. But lets tie in SC Orchestrator having the ability to run Runbooks, administrators wanting to use PowerShell to fix things while on the move. This causes a lot of issues because now we are passing around a service account to do all kinds of stuff that is just really messy. Looking forward, we already see PowerShell Web Access coming in Windows Server 2012, and the OData Management stuff. It is completely legit today to think that I can take a new Windows Surface, IPad, Android device and manage entire entreprise from anywhere, no VPN required. Attach all of this to SSL and read Don Jones PowerShell Remoting Guide from PowerShellbooks dot com and you would see that having the tools locally is not needed and executing commands against a central server will improve security by decreasing your exposure. Nice Rob!

  • Anonymous
    November 11, 2014
    Windows PowerShell remoting and delegating user credentials - Ask the Directory Services Team - Site Home - TechNet Blogs