Putting your public website on your Domain Controllers .... Sort of

In a post a while back I talked about a current trend to move websites from www.contoso.one to just contoso.one . The method I outlined in the previous post sets up a Scheduled Task to create a port forward for normal web server ports (80 and 443), but instead of manually setting it up on each Domain Controller, we can push it through Group Policy.


So, our method here is mostly the same. Use the netsh portproxy capabilities to create port forwards, just pushing it out through Group Policy and applying it to all Domain Controllers.

We will use the same example Port Proxy Scheduled Task from the previous script as a baseline, but with some tweaks.

First off, I don't want to depend on the .bat script being available over network or locally to run. So we are going to have to code in the commands to do the forwards directly. So instead of the somewhat more obvious to maintain %ServerAddress% variable, we just have to drop in the hardcode replacement.

Second, we can only run one command at a time here, and rather than get fancy with conditional execution ( firstCommand.exe /stuff && secondCommand.exe /morestuff ) we can just push two separate Tasks for port 80 and 443.


So, our first command

netsh interface portproxy add v4tov4 listenport=443 connectaddress=%ServerAddress% connectport=443 

becomes

Command: %windir%\system32\\netsh.exe
Arguments: interface portproxy add v4tov4 listenport=443 connectaddress=www.contoso.one connectport=443 

Create a GPO Applying to the Domain Controllers OU, Under Computer Config -> Preferences -> Control Panel Settings -> Scheduled Tasks 

I like to add multiple triggers, one for startup, and once a day, with both scheduled to repeat every hour. 

This way, in case there was a problem with it creating the port forward on startup (maybe the network driver crashed?) it should pick it up again shortly afterwards. 

Cannot Access Public Website due to AD Domain

Lately it is getting more popular to drop the www from your public domain; this means that www.contoso.one becomes contoso.one

For a lot of the smaller domains that I work with, that means the public website is the same place as their domain controllers inside the network, which causes problems. 

The ideal solutions to this are to either 

1. Host your AD off a subdomain, like ad.contoso.one 
2. Don't redirect www.contoso.one to contoso.one on your website

But that doesn't work well for an existing domain. AD migrations are not a simple endeavor, and as I mentioned before, dropping the www is the hip thing to do. 

As a quick work around, I found out about the netsh portproxy capabilities. 

Simply put, this lets the server listen on a port and forward it to another hostname or IP address - we can use this to listen to port 80 and 443 on the domain controllers and forward the traffic to our public website. Keep in mind that when you `nslookup www.contoso.one` you need to get the correct IP address for the website. 

This will look up the hostname www.contoso.one, and forward the traffic received on ports 80 and 443 to it. However, these port forwards are lost on reboot, so I used a Scheduled Task to run the script on startup and once an hour to setup the port forwards.

You could easily change these commands to run directly from the Scheduled Task, amd/or push the Scheduled Task through GPO to all domain controllers.
Here is a quick Scheduled Task that you could import to run on system startup.

There are more benefits to moving AD of to it's own subdomain, like being able to let normal public DNS come through, but still override interior records for internal connections to things like Exchange or internal hosts.

To read more about pushing these out to all Domain Controllers automatically, check out this post

Syncing MFA Office Phone information with extensions from AD to Azure AD / Office 365

In anticipation of rolling out MFA to our Office 365 users I was looking at the setup page (aka.ms/MFASetup) and I noticed that the Office Phone area was showing some of my information, but not the correct information.

Let's track that down, figure out how it works, talk about the Standards, and push a correctly formatted Office Phone to all the users

Setting up email for Brand Protection domains

So at my dayjob we have a pretty good amount of domain names we've registered for brand protection or typo domains. 3 domains we send or receive emails on, and 23 domains that just forward to a URL on our main domain. Our customer care got word of someone sending scam emails on one of the brand protection domains that should never be sending emails.

Let's explore how I setup our parked domains to report spoofers to me and help other mail servers know they shouldn't trust these emails pretending to be us.

Image Source: LifeHacker

Updating iDRAC SSL Certs through Powershell

One of the things I'm working on at work right now is updating all our iDRACs after Meltdown/Spectre. We had never had the SSL set up, we had just always clicked through the security warning. I got tired of this and decided to setup proper SSL from our enterprise CA,

At first I went to do a manual signing for a multi-year period with a wildcard issued from my enterprise CA, but I decided that automating it with PowerShell would be better, since it would be more dynamic, and scale to more servers.

In this post, I will be talking about setting

1. generating a Certificate Signing Request (CSR) from the iDRAC,
2. sign it with an enterprise CA, 
3. uploads the signed cert to the iDRAC, and  
4. reloads the iDRAC to apply the new cert