Archives

All posts for the month September, 2018

802.1x Certificate Based Authentication against NPS on Windows Server 2016

Posted by James F. Prudente on September 20, 2018
Posted in: PKI, Windows Server. Tagged: , , . Leave a comment

When we were preparing to upgrade our domain controllers from 2008 R2 to 2016, we of course began inventorying all functions that were going to be migrated. One of these was Network Policy Server (NPS). NPS is one of the easiest services to migrate to a new system, since it’s basically a simple backup and restore, and we weren’t expecting any difficulties. Of course had things gone smoothly, this post wouldn’t exist.

A little background:

We use NPS for multiple functions, including Cisco AAA and wireless device authentication. Our Meraki wireless infrastructure has multiple SSIDs, some of which are for domain-joined devices, and others for non-domain devices. The domain-joined devices use 802.1x certificate-based authentication and the non-domain joined devices use various other methods.

NPS was migrated from 2008 R2 to 2016 and everything other than the 802.1x certificate authentication worked. The 2016 servers were correctly setup as RAS servers and had certificates that were valid for client & server authentication, as needed. I spent quite a long time troubleshooting this with no success, and eventually had to back-burner it. The 2008 R2 servers were due to be retired, so as a temporary measure I migrated NPS to a couple 2012 R2 servers, all of which worked flawlessly after about two minutes worth of effort.

This was pretty early in 2016’s lifecycle, so since it worked in 2008 R2 and 2012 R2, we chalked it up to a bug in the OS and intended to pursue it with Microsoft at a later date.

Before I had a chance to call Microsoft, another project had us looking at our PKI configuration. We were having issues using LDAPS with this particular system (despite using it elsewhere), and after extensive troubleshooting the vendor told us they thought the hash algorithm used by our PKI was unsupported.

Our PKI was originally setup on a 2003 server back when that was the current server OS. It had been migrated to a newer server since then but the hash algorithm had never been changed; it was still using md5RSA. Now upgrading the hash algorithm isn’t something to be taken lightly, as it can break a lot of things, but in our case since our PKI is pretty simple I decided (after backing everything up) that the upgrade risk was minimal. I changed the hash algorithm to SHA256, reissued RAS certificates to the NPS servers and just like that things started working.

I can’t find any changelog indicating why NPS would not work with an older certificate hash on 2016 but empirical evidence shows the hash was the problem.

There are plenty of resources about upgrading your root CA’s hash algorithm, but this is a good start from Jason Bender at Microsoft.

Managing Mail-Enabled Security Groups in O365

Posted by James F. Prudente on September 7, 2018
Posted in: Active Directory, Exchange, Office 365, PowerShell. 3 Comments

Office 365 certainly has its plusses and minuses, and one of the areas that clearly falls in the latter category is how O365 handles mail-enabled security groups.

Consider the following scenario:

  • You have an on-premise Active Directory sync’d to O365/Azure via ADSync.
  • You have an on-premise security group that you mail-enable, creating an e-mail address @yourdomain.com.
  • This mail-enabled group syncs to O365, and then exists in Exchange Online.
  • You then mail-disable the group on-premise and wait for the change to sync to Exchange Online.

Logic would dictate that once the mail-enabled attribute was removed from the group, it would disappear from Exchange Online. Of course it’s not that simple.

What you will instead find is that the security group still shows in Exchange Online, however it now has a proxy address @yourdomain.onmicrosoft.com. It will also continue to be visible in both the online and offline address books. If you are trying to move groups to the cloud and/or cleanup your distribution lists, this can cause confusion.

The fix fortunately is easy, but it’s an extra step that shouldn’t be necessary IMO. Credit to Tim McMichael’s TechNet post for the details.

The process to properly remove a mail-enabled security group from Exchange Online is as follows:

  • On-Premise, remove the mail-enabled attribute from the group using the Disable-DistributionGroup PowerShell command.
  • On Exchange Online, find the group via Get-MsolGroup –SearchString “Group Name”.
  • Once you’ve confirmed you have the right group, remove it via Get-MsolGroup –SearchString “Group Name” | Remove-MsolGroup

This will finally remove it from Exchange Online and your address books.

EDIT: There is a major caveat here to be aware of. If you are using mail-enabled security groups to grant permissions to shared calendars, you CANNOT remove the mail attributes or you will break access permissions. In that situation I would advise simply hiding the list from the address book.