Exchange Server 2013 PowerShell Implicit Remoting over the Internet using IIS ARR as the Reverse Proxy
In this article
We will talk about, harnessing the power of IIS ARR the Reverse Proxy for Exchange Server to publish Exchange Management Shell cmdlets over the internet. Of course securely using HTTPS. This guide specifically talks about Exchange Server 2013, but it should be fairly applicable for Exchange 2010 as well.
Let’s have some background covered before we dive into setting up IIS ARR (Application Request Routing). (Click here to skip)
Background:
We can use PowerShell v2 (or higher), and connect to our Exchange server by establishing a persistent connection to it using the cmdlet New-PSSession
Implicit remoting
Implicit remoting is not full featured and colorful as the out of the box Exchange Management Shell (EMS), however it gives us the flexibility to connect and manage our exchange environment from virtually anywhere as long as you can connect to the /PowerShell endpoint on the IIS Website virtual directory.
Going on details of how implicit remoting works and the pre-requisites would be beyond scope of this document. Please refer to this article to know more about Implicit Remoting.
There are two common techniques where we use implicit remoting.
- On-Premises (Connect to Exchange using remote Shell):
*$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<CAS_FQDN>/PowerShell/ -Authentication Kerberos -Credential $UserCredential
*
*$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection
*
If you go and check the Authentication Status on PowerShell virtual directory on the CAS 'Default Web Site\PowerShell’ , you would notice that all the authentication mechanisms are ‘Disabled’!
Now this will make you wonder, how it is working then.
If you have noticed the On-Premises version Authentication is on Kerberos and protocol is HTTP. Whereas O365 is Basic Authentication and on HTTPS.
By default PowerShell will be using Kerberos as the Authentication mechanism with HTTP (Read more here) and any other authentication mechanism would obviously fail.
We can use HTTP internally as Kerberos allows us to do that by securing and encrypting the session traffic. Check this article out to know how secure it is.
Whereas when we are on the internet we can no longer use Kerberos (Read more here why not, requirements for Kerberos Authentication), hence we use Basic authentication which would be plain text along with HTTPS (SSL), which secures and encrypts the connection for us over the internet.
I’m not quite clear why, but as per this article’s last para and my tests Kerberos with HTTPS doesn’t work for Exchange PowerShell, but we have these articles stating Kerberos works with HTTPS. If you try and force the PowerShell virtual directory to enforce SSL then you will not be able to connect. Anyways I wanted to point this out to you all. Figuring out why, would be something for another day.
It is worth pointing out that while you may be able to use Exchange remoting, it is separate from Windows remoting. And different TCP endpoints are used. By default Exchange remoting uses TCP 80\443, and Windows remoting uses 5985\5986 TCP (They are the same ports as WinRM).
So, if we put it in a table for standard Exchange PowerShell authentication:
Protocol |
Authentication (Default) |
Comments |
HTTP |
Kerberos (Default-Enabled) |
|
HTTPS |
Basic (Default- Disabled) |
Negotiate - ‘Windows Authentication’ for Internal works too if enabled |
Any other form of Authentication doesn’t seem to work, very well limited to my test is concerned.
By now you must have guessed how O365 does this. Incase wondering how, wouldn’t it be nice if you could manage your On-Premises Exchange environment over the Internet (Provided you have the go from the security guys, shouldn’t be a problem for you to convince them as MS Exchange Online has it open for all over the internet) All the security mechanism of OWA or rather SSL applies and your connection is secure indeed. I’ll also show some techniques which you can use to harden this up later.
I would have to admit that I’m inspired by Mike Pfeiffer’s excellent article on using Forefront TMG 2010 for publishing PowerShell over the internet for Exchange 2010.
As we all know, TMG is no longer in Microsoft’s development roadmap, we have the supported option to use ARR as the Reverse Proxy solution for Exchange 2013, which works pretty well. (You can refer to this link for the sizing of ARR servers which should be same as for TMG.)
Let’s begin the configuration now:
There are certain assumptions or rather pre-requisites prior to following the steps below:
Pre-requisites:
- You have already followed this guide (Part 1: Reverse Proxy for Exchange Server 2013 using IIS ARR) and have setup a working Reverse Proxy solution for OWA \ Autodiscover atleast.
- You have the required certificates in-place and is trusted by the external client machine.
[In my test I had used Self-Signed, the steps below to prep it:
- Export the certificate used on the ARR server, that would be the Exchange CAS Server certificate itself
- Use mmc ->certificates snap-in , goto Trusted Root Certification Authorities
- Rt click Import.
- The mail.contoso.com certificate would be visible]
NOTE:- We can use PSSessionOption –SessionOption to override this certificate check.
Screenshot of URL Rewrite Rules on ARR server.
If you are done with the pre-requisites there is nothing much into setting up the remaining part.
Steps on Exchange Server:
You need to have necessary permissions to make changes to the Windows Server or Exchange Components.
- Enable Basic Authentication for the PowerShell virtual directory:
** a. Using IIS Manager:**
-
- Open IIS Manager and navigate to ServerName\Sites\Default Web Site\PowerShell.
- In Features View, double-click Authentication.
- On the Authentication page, select Basic Authentication.
- In the Actions pane, click Enable to use Basic authentication with the default settings.
Repeat the steps on every server you like to participate. For Eg. All members of the Internet-facing CAS Array or Load-Balanced name has to be modified for it to work seamlessly.
** b. Using cmd.exe**
appcmd set config "Default Web Site/Powershell" /section:BasicAuthentication /enabled:true /commit:apphost
Repeat on all CAS servers.
** c. Using Exchange Management Shell**
Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -BasicAuthentication $true
This command would modify the virtual directory on every CAS Exchange server in the organization, if you had more than one.
If you want to specify a particular server, use this:
Get-PowerShellVirtualDirectory -Server EXCH1 | Set-PowerShellVirtualDirectory -BasicAuthentication $true
2. Change SSL Settings to Ignore Client certificates for the PowerShell virtual directory:
- Open IIS Manager and navigate to ServerName\Sites\Default Web Site\PowerShell.
- In Features View, double-click SSL Settings.
- On the SSL Settings page, in the Client certificates area:
- Select Ignore.
- Ensure Require SSL is unchecked
- In the Actions pane, click Apply.
Ensure you don’t check the Require SSL checkbox, else your Internal Kerberos Authentication would fail and things would start falling apart. Especially PowerShell EMS.
Repeat on all CAS servers.
How do you know it works? Simple, test it:
Using Internet Explorer or any other web browser over the internet:
You get a ‘200 OK’ message.
Enter your credentials ’domain\username’ and password
You are presented with a blank screen. Cool!
Using PowerShell to Manage Exchange 2013 over the internet:
On any client PC with PowerShell v2
- Set-ExecutionPolicy RemoteSigned
- $cred = Get-Credential
- $exchangesession = New-PSSession -Credential $cred -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://mail.contoso.com/PowerShell -AllowRedirection
- Import-PSSession $exchangesession
- Get-Mailbox User1
At this point you should be getting the PowerShell tab completion for Exchange cmdlets and able to retrieve exchange related data.
NOTE: - When the Shell is started, it connects to an Exchange server and authenticates you. As part of the authentication process, Exchange checks RBAC to see what roles you're assigned. Each management role has a list of cmdlets and their parameters that users assigned the role can use. When the Shell creates your environment, only the cmdlets and parameters that you can access are added to the environment.
Troubleshooting:
Incase any of the above tests gave you an error. Find these common errors below:
- 502 – Issue with the certificate (Can be client or the Server),
Solutions:
*Try using -SessionOption<PSSessionOption> to ignore certificates with New-PSSession
*Install Exchange Server certificate on the ARR Trusted Root certification Authorities and Intermediate using MMC.
*Check CAS PowerShell Virtual Directory is set to Ignore Client certificates.
- Kerberos error: HTTP Kerberos error on VIPName or load balanced DNS Record:
Solution: Use internal CASFQDN instead of VIPname in –ConnectionURi. You are not using the’ –Authentication Basic’ switch on http:// , its defaulting to Kerberos.
This doesn’t work on Alias names as Kerberos require you to have related SPNs (ServicePrincipalName) for the VIPNames. If you need to use Kerberos on alias itself use this guide, else simply add https:// and the switch ‘–Authentication Basic’ to the cmdlet to use Basic Authentication which doesn’t need SPNs.
- HTTP bad request status (400) error: Internally you are not using the –Authentication Basic and using https:// it is defaulting to Negotiate. Windows Authentication is disabled on PowerShell Virtual Directory, hence failing.
Solution: Enable Windows Authentication or use –Authentication Basic or other possible reasons you are using invalid credentials, cross check the credentials passed are correct.
- Your client machine must find, mail.contoso.com. External DNS record must be pointing towards the ARR server, Public \External IP. You can make manual HOSTS file entry if required.
nslookup mail.contoso.com on client PC and ARR server, should resolve to ARR server and CAS server respectively.
- If you are using a CNAME or Virtual name for the domain.com, check you have proper certificates with Subject Name and proper redirection\load-balancing is happening.
- Trying to access Basic Authentication internally over http.
Solution: Use https://. Configuration doesn’t allow you to connect to the PowerShell Endpoint without encryption.
- HTTP with Negotiate Authentication Error with Windows Authentication Enabled:
Solution: You can’t use http://, use https:// with Negotiate
- You are connected to the session and tab completion works, but existing users are not listed or Get-Mailbox list only your\limited name.
Solution: You are logged in with lower permission credentials. When the Shell creates your environment, only the cmdlets and parameters that you can access are added to the environment.
PS C:\Users\administrator.BLUEBELL> (Get-Module tmp_ibxlmujv.rm4 | select -ExpandProperty ExportedFunctions).count
90
Same for an administrator:
PS C:\Users\administrator.BLUEBELL> (Get-Module tmp_t5jnf00a.4g0 | select -ExpandProperty ExportedFunctions).count
692
- HTTP Status code of 403 Error: - Exchange Management Shell fails to connect.
Solution: Uncheck ‘Require SSL’ from the PowerShell Virtual Directory.
Still not working, you can follow this guide to enable Failed Request Logging and troubleshoot it in detail.
Benefits:
- The best part is you can pull this off without breaking a thing in the existing internal setup and functionality.
- Access is based on RBAC permissions model and very flexible
- This works with DNS Round Robin or any other Load balanced solutions in place as well. You don’t have to setup complicated Kerberos –SPN setup for using a Virtual Name.
- URL Rewrite is already enforcing HTTPS on external clients, without us enforcing it on /PowerShell virtual directory internally.
- You can connect from any device capable of running PowerShell v2
- Client doesn’t have to be on 64 bit hardware
- Don’t have to worry about client side certificates or if its Domain Joined
- As Mike Pfeiffer says in Core Solutions for Exchange 2013 Microsoft virtual academy course, you can be sitting at a beach, and working. (Ya… I know! What I’m doing at a beach if I have to work. But you can if you want, that’s the point)
Few Hardening Tips:
- Dedicated CAS servers farm, which has Basic Authentication on PS Directory enabled.
- Selective protocol Pattern ^PowerShell/* on URL Rewrite module (‘Part4 article - Additional Information 1 ‘for details).
- Separate namespace for PowerShell, so that users can’t guess the ConnectionURi.
- Ensure you don’t have http URL Rewrite rules on the ARR server enabled.
- I’m sure this list can go on...
That’s it!
References:
- Part 1,3: Reverse Proxy for Exchange Server 2013 using IIS ARR:
- How to Manage Your Exchange 2010 Organization with PowerShell Implicit Remoting over the Internet:
- AuthenticationMechanism Enumeration:
- New-PSSession:
- New-PSSessionOption:
- How To Maximize Exchange Administrator Productivity With PowerShell–Part 2:
- How secure Remote PowerShell is - techdays follow-up: remote powershell, what’s encrypted?
- Directly Loading Exchange 2010 or 2013 SnapIn Is Not Supported :
- What port does PowerShell remoting use?
http://blogs.technet.com/b/christwe/archive/2012/06/20/what-port-does-powershell-remoting-use.aspx
- Troubleshooting Exchange 2010 Management Tools startup issues:
http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
- Configuring Kerberos authentication for load-balanced Client Access servers:
[https://technet.microsoft.com/en-us/library/ff808312%28v=exchg.150%29.aspx
NOTE:- The references has changed a bit pointing towards technet.com , http://blogs.technet.com/b/exchange/archive is now http://blogs.technet.microsoft.com/exchange. If you are not able to find anything Bing the topic name and you should be redirected to the new URL.](https://technet.microsoft.com/en-us/library/ff808312%28v=exchg.150%29.aspx)