Project Honolulu and Server Core

By now many IT administrators have heard of Project Honolulu from Microsoft. I must admit, when I heard the headline and initial talk about it, I book-marked the info intending to come back but didn’t really dig into it. I thought, “oh a revamped Server Manager.”

My perspective is all changed now.

I’m watching the “Windows Server: What’s new and what’s next” session from Ignite 2017. I have been following Aidan Finn’s blogging of Ignite sessions including this one in particular for the “What’s new” session, and recall reading his notes about Server Core being in semi-annual channel, but not Server GUI, so “you better learn some PowerShell to troubleshoot your networking and drivers/firmware”.

But now having watched the session myself, it makes Microsoft’s vision and a path forward here very clear to me.

Using Server Core allows an organization to reduce their surface area for vulnerability, streamline the size/frequency of Windows Updates, optimize performance and scalability on hardware, and stay up to date on the Windows Server cadence.

Project Honolulu makes using Server Core viable. This is the answer to the Windows system administrator saying “Server Core just doesn’t give me the visibility I need into my servers”. As Jeff Woolsey walks through the functions of Project Honolulu, it is obvious that THIS is where the visibility will be; no more RDP into individual servers to manage their roles, devices, and settings. No more MMC windows to open Event Viewer and Shares and other applets.

Now I’m excited.

Azure PowerShell DNS – Modify TTL

A brief note on modifying TTL on an Azure DNS record set. This is changed on the record set, not the record itself.

The Azure DNS PowerShell docs don’t make it explicitly clear how to do this, however using “help set-AzureRmDnsRecordSet -examples” gave me a clue on how to achieve it.

The key is the middle line here:

$rs = Get-AzureRmDnsRecordSet -Name "msoid" -RecordType CNAME -ZoneName "domain.com" -ResourceGroupName "DNS"
$rs.TTL = 3600
Set-AzureRmDnsRecordSet -RecordSet $rs

 

 

Exchange Online PowerShell access denied

I am attempting to test aspects of Office 365 Modern Authentication in a UAT environment prior to enabling it within our production Tenant.

Part of this work is testing the Exchange Online PowerShell access, as there is quite amount of automation configured in our environment and we want to ensure it doesn’t break. I’ve read it “shouldn’t”, but that’s a dangerous word to trust.

Until now I’ve been unable to make the PowerShell connection to Exchange Online in our UAT environment, receiving the following during my attempts:

New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message:[ClientAccessServer=servername,BackEndServer=servername.prod.outlook.com,RequestId=e6f6b9e7-7c5e-45ec-87fe-59332db1fb95,TimeStamp=8/17/2017 3:16:52 PM] Access Denied For more information, see the about_Remote_Troubleshooting Help topic.

I can use the same account to connect in-browser to http://portal.office.com, and it is set as a Global Administrator in O365, so I know that the account itself has appropriate access.

Interestingly, if I connect with the MFA-supported PowerShell method, with the same account, it connects successfully.

Through testing I’ve determined that using any on-premise account synchronized through Azure AD Connect fails with the same “Access Denied” message, while any cloud-only account connects successfully.

I began to look at our ADFS implementation in UAT since that is a key component for authenticating the on-premise user account. This environment has ADFS 2.0 on Server 2008 R2, which is different than production but shouldn’t be a barrier to connectivity (without MFA).

After comparing the O365 trust configuration and finding no issues, I decided to use the Microsoft Connectivity tool to test. Using the Office 365 Single Sign On test, I saw a failure with this error:

A certificate chain couldn't be constructed for the certificate.
Additional Details
The certificate chain has errors. Chain status = NotTimeValid.

This let me on the path to fixing expired/broken SSL certificates in our UAT ADFS, which I posted about previously here.

Now that the SSL problem is resolved, I attempted to connect to Exchange Online PowerShell again, and was successful!

Looks like this “Access Denied” message was directly related to the expired certificate of the ADFS proxy.

 

 

ADFS 2.0 renew Service Communications certificate

I’ve recently solved a problem with the help of Microsoft Premier Support that didn’t have any references online that I could find.

Looking at the ADFS console under Certificates, the “Service Communications” section had a message of “Certificate not found in store”.

Connecting to the certificate store showed a proper external SSL cert for our UAT ADFS DNS name. Trying the option “Set Service Communications Certificate” in ADFS produced the error:

The Certificate could not be processed.
Error message: Object reference not set to an instance of an object.

This error led me to this discussion on the Microsoft forums, with the following command to attempt:

AddPsSnapin Microsoft.Adfs.PowerShell SetAdfsCertificate CertificateType “Service-Communications” Thumbprintaa bb cc dd …”

However, when I tried to run this command I repeatedly got the following error:

The type initializer for 'Microsoft.IdentityServer.Dkm.ADRepository' threw an exception. Microsoft.IdentityServer.PowerShell.Commands.SetCertificateCommand

The resolution: run PowerShell as the ADFS service account, and then use the command above to set the certificate. After this, I was able to restart the ADFS service and the console displayed the certificate properly.

I also needed to update the certificate on the ADFS proxy in IIS to get a successful result from the Microsoft Remote Connectivity Analyzer.

NLB website behind Azure Application Proxy

This is a quick post noting the minimum steps required to get a network load balanced website in IIS accessible through Azure AD Application Proxy. I’ve recently set this up for Deltek iAccess, and after a bunch of minor issues and mis-configurations (which took me hours to find, of course) I thought it worthwhile to compile the information in one spot.

Note, when troubleshooting this process, many different items can be cached which causes problem solving to go down incorrect paths and assumptions. This was perhaps the most challenging part of getting this set up. You’ll likely need to use the following commands regularly, in addition to waiting for AD and DNS sync intervals, and re-testing some minutes after changes are made in the Azure portal.

  • net stop dnscache && net start dnscache
  • ipconfig /flushdns
  • klist purge

Assumptions in this post are that NLB is already configured and working, and the website (or at least a portion of it) uses integrated Windows Authentication (otherwise many of these steps are unnecessary).

  1. Determine your DNS records. We have split dns and so used the same name internally and externally: “webapp.domain.com”
    1. Create a CNAME in internal DNS for “webapp.domain.com” to point to your NLB cluster name
    2. Create a CNAME in external DNS for ‘webapp.domain.com” to point to the provided Azure Application Proxy name; likely something like app-domain.msappproxy.net
  2. In IIS on each web host, set “UseAppPoolCredentials” to True using Configuration Editor (or web config directly) for the path: system.webServer/security/authentication/windowsAuthentication
  3. In IIS on each web host, configure the application pool identity to a domain user service account
  4. Create an SPN delegation in AD to match your DNS name and this service account:
    1. SetSPN -S HTTP/webapp.domain.com domain\username
  5. Use this SPN “HTTP/webapp.domain.com” within the configuration of your Azure AD Application Proxy.
  6. Add this SPN entry on the Delegation tab of the Azure AD proxy connector object in AD. You would search for the domain user service account, and select the HTTP entry matching webapp.domain.com

Things you don’t have to do, discovered after some trial and error:

  • Use a CNAME vs A record for internal DNS; both should work properly
  • Configure “DisableStrictNameChecking” or “BackConnectionHostNames”, as these apply to NTLM only, not Kerberos
  • Grant NTFS permissions to the domain user service account on the web application files
  • Specify a specific hostname within IIS binding configuration
  • Add the NLB cluster server names to your proxy connector delegation tab