January 2017

How to Configure a Port Proxy for RDP Connections

Friday, January 27, 2017

I'm working with a small business customer who uses my Hyper-V home lab server to run their lab. They have a Domain Controller and several application servers running behind an AT&T DSL consumer-grade wireless router and they want to be able to RDP directly to each VM. If you run your own home lab, you might want to do the same.

The trouble is, most consumer routers don't allow you to forward the same port to more than one IP address. You can create a port forwarding rule for TCP 3389 (RDP) to TCP 3389 on one, and only one, IP address. On a "real" router you could forward the external TCP ports 33891-33895 to the internal 3389 port on each of the five internal server IPs, but that's not an option here.

Traditionally, there are several ways of handling this problem, each with it's own limitations:

RDP to the one main server and then "leapfrog" to the other computers using RDP from the main server. This can cause confusion about which desktop you're working on, and provides a less than stellar experience.
Change the RDP listening port on all the other computers to use another port (for example, TCP 33891-33895). See How to change the listening port for Remote Desktop. The downside to this is that you will always need to specify the custom listening port when connecting both internally (on the LAN) and externally (from the Internet). This can be troublesome, especially in a larger environment where several admins need to use RDP. "What RDP port do I need to use for SERVER1 again?"
Install and configure Remote Desktop Gateway services on the server hosting HTTPS services. This has a fair amount of overhead and configuration, requires a valid SSL certificate, and RDP clients need to be manually configured to use the RDG for these connections.

A much more elegant solution is to use the netsh utility to configure a port proxy entry in the TCP stack for each server. With this configuration, each server will continue to listen on TCP port 3389 for normal internal RDP connections. External RDP connections to the proxy port, say TCP 33891, will be forwarded to TCP 3389. Brilliant! Here's how to configure it:

Run the following netsh command from an elevated CMD prompt on each server:

netsh interface portproxy add v4tov4 listenport=[ListeningPort] listenaddress=[ServerIP] connectport=3389 connectaddress=[ServerIP]

For example, the following netsh command configures TCP port 33891 to forward to TCP port 3389 for IP address 10.0.0.101:

netsh interface portproxy add v4tov4 listenport=33891 listenaddress=10.0.0.101 connectport=3389 connectaddress=10.0.0.101

Now configure port forwarding for each internal server on the DSL/cable router. Create a custom service for each new port - The external (base) port and internal (host) port both use the new custom port (i.e., 33891, 33892, etc.):

Then configure port forwarding for each of the new custom services to the IP addresses of the servers:

With this configuration, you can still make internal RDP connections to the each server using the traditional RDP port 3389 (no special configuration of the RDP client is needed). All external RDP connections are made to the same public IP address using one of the new custom ports (i.e., 33891):

How to Trigger an AAD Connect Sync from a Remote Computer

Thursday, January 26, 2017

If you use AAD Connect to synchronize on-premises Active Directory with Azure AD, you may find it more convenient to trigger an AAD sync from a remote domain-joined computer or server. I frequently do this when I make a change to an on-prem AD object from my Windows 10 workstation or Exchange server. Remote PowerShell to the rescue!

Copy the following Sync-AAD.ps1 script to your Windows path (I put it in C:\Windows) on the computer or server where you want to run it.

$AADComputer = ((Get-ADUser -Filter 'Name -like "AAD_*"' -Properties Description).Description).split(" ")[13].trim(".") + "." + (Get-WmiObject win32_computersystem).Domain
$session = New-PSSession -ComputerName $AADComputer
Invoke-Command -Session $session -ScriptBlock {Import-Module -Name 'ADSync'}
Invoke-Command -Session $session -ScriptBlock {Start-ADSyncSyncCycle -PolicyType Delta}
Remove-PSSession $session

Sync-AAD.ps1 output

I haven't found a better way to determine where AAD Connect is installed than the way I'm doing it in the first line. It uses the AD PowerShell module to parse out the AAD Connect computer name listed in the description property of the AAD_***** computer account. This assumes, of course, that the AD PowerShell module is installed on the local computer, and the description property is filled out correctly in AD. AAD Connect sets the description for this account to something like, "Service account for the Synchronization Service with installation identifier 16e45891... running on computer DC1." If that doesn't work for you for some reason, simply change the first line to your AAD computer FQDN, for example:

$AADComputer = "aad.contoso.com"

The second line, $session = New-PSSession -ComputerName $AADComputer,creates a new remote PowerShell connection to the computer where AAD Connect is installed.

The third line invokes a command to import the AAD Connect PowerShell module on the local computer.

The fourth line invokes a command to start the delta AD sync cycle.

The final line removes the remote PowerShell session.

Easy peasy!

How to confirm if your IP address is blocked by Exchange Online Protection (EOP)

Wednesday, January 11, 2017

Exchange Online Protection uses several mechanisms to protect the service and its customers from receiving spam from known bad or suspicious IP addresses. This article explains how to check if the public IP address used by your messaging server is on the EOP Anti-Spam IP List, and how to remove it if it is.

This is especially important to do for Office 365 hybrid customers, since the on-premises Exchange servers will need to send SMTP emails to cloud users via EOP. I always do this before I begin a hybrid deployment.

From a web browser go to the Office 365 Anti-Spam IP Delist Portal (https://sender.office.com).

Step 1: Enter a valid email address to receive a verification email to complete the check, and enter the public IP address of the messaging server you want to check. You can use a service like WhatIsMyIPAddress.com from the messaging server to determine your public IP. Enter the captcha characters and then click Submit.

Office 365 AntiSpam IP Delist Portal

You will receive an email with the subject Microsoft Office 365 Delisting Service where you need to click a link to confirm your email address. This link is valid for about 10 minutes. If you wait longer than that, you'll need to start over. The email is sent almost immediately, so if you don't see it in your Inbox within a minute, check your junk mail.

Click to confirm your email address

Step 2: A new browser window will open to allow you to delist the IP address you entered in step 1. Click the Delist IP Address button.

Step 2: Delist IP Address

If the IP address is not on the blocked list, you'll see a message similar to the one below:

Step 3: The IP address is not currently blocked by EOP

If the IP address is blocked it will be submitted to be automatically delisted. The website says this takes about 30 minutes, but in practice I've seen it take up to 24 hours. You will not get a confirmation email when the IP address has been delisted. You'll need to re-run the test occasionally until you see that it's not blocked.

Step 3: The IP address is blocked, but will be delisted

The quick geek way to test if your IP address is blocked is to use the telnet client. From the messaging server, telnet to the EOP endpoint using port 25 and try to send an SMTP email. You can find your EOP endpoint using www.mxtoolbox.com. If your IP address is on the EOP block list you will see it after the RCPT TO command . Here's an example of the telnet output:

Access denied

Here, you can see that the IP address is banned by EOP and instructions for removal.

550 5.7.606 Access denied, banned sending IP [x.x.x.x]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609)

Explaining Conditional Access and Azure Pass Through Authentication

Tuesday, January 3, 2017

My previous article, Is Azure AD Pass-Through Authentication Right for You? generated some comments and questions about how PTA works with conditional access in Azure AD. There was enough confusion that I wrote a companion article, Explaining Conditional Access and Azure Pass Through Authentication.

Conditional access works great in a cloud-only world, but the real world usually contains legacy clients. Learn when it's appropriate to use conditional access policies and when to use AD FS claims rules with Azure pass-through authentication.