Active Directory Fine-Grained Password Policies

This post isn’t going to set the world on fire because of it’s revelations and new features; instead, I am going to talk about a feature that has been around since Windows Server 2008 called Fine Grained Password Policies.

Active Directory Password Policies are, even in 2018, still misunderstood. For all the consulting engagements I do, I still encounter customer environments where admins have tried to configure multiple Group Policy Objects to control password policy at various levels within their OU structure. An example of this behaviour would be to set the Default Domain Policy object to a standard password complexity and then have an OU containing administrative accounts for Domain Admins which has a GPO applying a more complex policy.

Setting the Record Straight

Before we go any further then, let’s set the record straight. In a standard configuration AD domain there can be only one password policy. It matters not where or how many times you try to link and create GPOs to set different policies, it will not work. In a default AD domain, the password policy is configured in the Default Domain Policy which is applied at the root, the top-level of the domain. The password policy is enacted and controlled by the Domain Controllers not by the computer or user object of a client.

In the modern era of PowerShell, we can see that the default password policy for the domain is by using the Get-ADDefaultDomainPasswordPolicy PowerShell command which outputs similar to the screenshot below. In this example, the lockout duration and observation windows are 15 minutes each, accounts are locked out after five failed attempts and passwords must be at least seven characters long, meet complexity requirements, be no older than 90 days but more than 1 day old, and the previous 12 passwords are remembered.

Defining Granular Password Policies

Enter Windows Server 2008 R2 which brought with it a feature, as part of Active Directory, called Fine Grained Password Policies. What this new feature allows us to do, at last, it to have control over the password policy for specific users or groups. Want uber complex admin account passwords? Sure, do it. Want to force HR or Finance staff to have a slightly more complex policy than normal users but a little less than admins? Go right ahead! Now, it’s time to be honest. The feature was first introduced in Windows Server 2008, however, it got a lot easier with Windows Server 2012. In this post I will be concentrating on the latter.

To make this work, there are two things we need to do and one thing we need to understand.

  1. We need to create password policy objects
  2. We need to link password policy objects to users or groups
  3. We need to understand the precendence

Understanding Precedence

Clearing the understanding out of the way first, we need to make sure that the correct policy is applied to the correct user or group. When we create a policy, one of the parameters required is precedence. The value for this must be a positive integer starting from 1. A user or a group can be assigned multiple policies: when this happens, the policy which wins is determined by the precedence. If a user has a direct policy linked to them with a value of 10 but they are also a member of a group which has a policy value of 5, the policy with the value of 5 will win.

Creating the Password Policy

The first real step is to create the policy. This is one, albeit long, line of PowerShell. The full list of parameters and possible values are in the Microsoft documentation at https://technet.microsoft.com/ru-ru/library/hh852234(v=wps.620).aspx. In this example, I have created a policy which backs off the default policy to allow users to keep their current password for up to 365 days.

The command executed in the example and the screenshot below:

New-ADFineGrainedPasswordPolicy -Name "MaxPassword365Days" -DisplayName "Max Password Age 365 Days" -ComplexityEnabled $true -Description "Increases the Maximum Password Age to 365 days." -LockoutDuration 00:15:00 -LockoutObservationWindow 00:15:00 -LockoutThreshold 5 -MaxPasswordAge 365:00:00:00 -MinPasswordAge 1:00:00:00 -MinPasswordLength 7 -PasswordHistoryCount 12 -ReversibleEncryptionEnabled $false -Precedence 100

With our policy now created, it won’t do anything because it isn’t linked to a user or a group so the next step is to link it. If you are testing this then by all means link it to a single user, however, in the real-world I would always use a group to allow you to be flexible and manage these policies more effectively.

To link the policy, we use the Add-ADFineGrainedPasswordPolicySubject PowerShell command. Once linked, we can use the Get-ADFineGrainedPasswordPolicy command to verify that the policy is linked.

Add-ADFineGrainedPasswordPolicySubject MaxPassword365Days -Subjects Max_Password_Age_365_Days_GG

In the example above, we can see that I used the Add-ADFineGrainedPasswordPolicySubject command. In the command we give the name of the Password Settings Object that we want to use. We then use the -Subjects parameter to declare who it should be applied to. In my case, this is a Global Group in Active Directory but this could just as easily be a user object.

Once the policy has been applied we can use the Get-ADFineGrainedPasswordPolicy to see what’s being applied. In the screenshot, we see that the MaxPassword365Days policy has an AppliesTo value of the Global Group that I set in the former command.

Meltdown and Spectre CPU Flaws on Windows Systems

Over the course of the last few days, there has been much said online about a security flaw which is affecting the X86 CPU architecture and more specifically Intel CPUs*. This is an issue which has been known since earlier in 2017 but has only recently started doing the rounds. The issue was uncovered by Google (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html?m=1) and was not scheduled to be made public just yet, however, growing information and leaks online led Google to release it early. The issue has also been logged under three CVEs: CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754. Microsoft also has their own article at https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe.

The early release by Google prompted various things that were already in-play to also happen early. Microsoft was forced to release the hotfix for Windows immediately and the Microsoft Azure planned VM maintenance which was scheduled for the 10th January has been brought forward to happen almost immediately.

* There are numerous reports including the original publication from Google that the issues also affect ARM and AMD CPUs as well. I do not wish to get embroiled in a debate whether or not AMD and ARM are affected as there is arguments coming from both sides. For the purposes of this article, I will focus on Intel as we know 100% that their processors are affected. Intel is keen to point out that while they are still affected, CPUs based on the newer platforms like Skylake and Kaby Lake will experience a lesser performance drop-off.

Read the Full Post

Save with BYOL and Azure Hybrid Benefit

In my post from earlier today, I talked about the benefits of using Azure Instance Reservations to save money on the compute of IaaS virtual machines. When we think about the components that make up an IaaS VM, we have a few: the VM instance and configuration, the storage, and the software that runs on it. For most people, the software at the most basic level will be either Microsoft Windows or Linux and likely some application software layered on top such as SQL Server.

When we are talking about Microsoft Windows there is a license associated with running the operating system and when you commit to running a Microsoft Azure IaaS VM running Microsoft Windows, the cost of that virtual machine includes that license. If you are an enterprise client of Microsoft’s with an Enterprise Agreement you will likely already have entitlement some Windows Server licenses through that agreement. If you already have licenses that you are paying for, why would you want to pay for them again in Azure? The obvious answer is that you wouldn’t unless your intentions are to do away with the Enterprise Agreement and license everything through retail channels.

Microsoft Azure offers a lesser known option called Azure Hybrid Benefit which is often referred to as Hybrid Usage Benefit (HUB for short). HUB allows you to apply your Enterprise Agreement licenses to your IaaS VMs deployed in Azure. What this means in cost terms is that the price of the Azure IaaS VM ceases to include the Windows Server license element and you are paying purely for the compute. The benefits of HUB are not limited to Windows Server either. You can also use the HUB option with SQL Server IaaS VMs deployed to Azure which means you no longer pay the list price in Azure for either the Windows Server or the SQL Server application license.

Read the Full Post

Saving with Azure Reserved Instances

The cloud is everywhere we look in IT now: more, and more organisations are adopting cloud services of one flavour or another. One of the benefits of cloud is that the costs can come out of operational expenditure in nice little monthly packages instead of giant wedges of capital expenditure. While cloud also offers us the commodity of scale providing services faster, better protected, and more reliable than we can often build ourselves on-premises for equivalent cost but that doesn’t mean we need to pay the recommended retail price.

In this article, I’m going to cover a little-known feature in Microsoft Azure called Reserved Instances (RIs). Previously called Compute Pre-Purchase, this feature is available to anybody using a Pay As You Go (PAYG) subscription or an Enterprise Agreement Subscription. If you are using any other type of subscription such as one bundled as part of an offer then you will not be able to participate. Reserved Instances are only available for Infrastructure-as-a-Service (IaaS) virtual machines. They cannot be used for any other types of service.

Read the Full Post

Set the thumbnailPhoto in Active Directory with PowerShell

For years and years, as @LupoLoopy could probably attest to, I have been a fan of dumping user photos into Active Directory. Even as far back as Exchange 2010 we have been able to light up Outlook with user photos downloaded as part of the Global Address List and today; with the likes of Azure AD, Office 365, and more; the users’ photo is more and more prominent. Over the years, I have relied on a tool from Cjwdev called AD Photo Edit, however, only this week, I discovered that we can actually do this natively with PowerShell negating the need for the tool to be used at all.

The PowerShell for this requires you to have the Active Directory PowerShell Module imported but other than that, there are no complex requirements.

$photo = [byte[]](Get-Content "" -Encoding byte)
Set-ADUser  -Replace @{thumbnailPhoto=$photo}

It really is that simple! I do, however, have a segway here: there still, to this day, does not seem to be a way to reverse the flow of profile pictures with Azure AD Connect. It is possible and always has been to export the thumbnailPhoto attribute from Active Directory to Azure AD for use in Office 365. There does not, however, seem to be a way to have Azure AD and Office 365 act as the image source and have them imported into Active Directory from the cloud. This is a shame because in Azure AD and Office 365 we have native interface elements that allow the user to self-service upload and edit their own user photo but the same tools don’t exist on-premises. One day, I hope, we will have the ability to import to AD from AAD but until that time comes, I am planning on looking into building a really small web application that will execute the PowerShell code behind the scenes and allow users to self-service their images.

Azure Route-based VPN with a Cisco ASA 5505

I haven’t posted here for a while and I have a bit of a success story that I thought I would share and hopefully help somebody else encountering the same issues.

Over the last few weeks, I have been working with a customer: the customer has a Cisco ASA 5505 firewall in a co-lo datacentre operated by a third-party whose name is something like (big metal thing that vertically stores servers)(the place where Jean-Luc Picard travels around). The customer has started to consume some Azure IaaS VMs and wanted to be able to establish a VPN to the co-lo to enable them to hop from one location to the other; a VPN connection from Azure was already in place to the office site which means we needed to use a multi-site VPN to Azure.

With the VPN to the office already working, we knew that the VPN Gateway and Virtual Network in Azure were sound. A multi-site Azure VPN requires a Route-based connection, not the basic Policy-based connection. We got the VPN Gateway all set up for Route-based connections and confirmed that was still working; no dramas. After doing this, we started speaking to the co-lo. The first response from the co-lo was that the ASA 5505 didn’t support a Route-based VPN which put us in dangerous territory. Reading the Azure documentation, there are a few articles that seem to contradict and conflict and having the right documents to hand helped enormously.

The first article you will probably encounter is the generic supported devices list for Azure VPN with caveats around Policy-based only or only supported Route-based in specific circumstances which are at https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices. This article used to state that the ASA 5505 did not support Route-based connections but it no longer does state this. If your vendor is telling you otherwise, direct them to the article in the first instance. For the ASA 5505, we need to ensure that it is running ASA OS 8.4 or above; this added supported to IKEv2 which is a requirement for Route-based connections to Azure.

With the first hump over, we initially struggled to get the connection up and running which is where the next articles come in. Firstly, direct the vendor to https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-3rdparty-device-config-cisco-asa. This article is a specific example of the ASA 5505 using IKEv2 without BGP for a Route-based VPN. Once the vendor was on-board, we started to make progress, however, there are changes you will need to make in Azure too! Firstly, the implementation of a Route-based VPN with an ASA 5505 requires the use of Traffic Policy Selectors. When configured, this requires you to define a custom IPSec Policy in Azure for the connection and then apply the policy and the Use Traffic Policy Selectors option to the connection. The second part is that both these features require a Standard VPN Gateway and will not work with a Basic VPN Gateway. For this configuration, follow the guidance of https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell#workflow.

By the end of this, hopefully, you have a working VPN connection to an ASA 5505 using a multi-site Route-based Azure VPN, however, if you do not, here are a few things to check:

  1. Verify the pre-shared key at both ends of the connection matches
  2. Verify that the custom IPSec Policy in Azure matches that on the firewall
  3. Verify that the correct Traffic Policy Selectors are applied on the firewall
  4. Verify that the Azure Virtual Network and Azure VPN Connections have the correct address ranges configured

Any of the above will cause the connection to fail. If the connection still refuses to establish, you can enable the Azure Network Watcher feature and enable diagnostics for the VPN Connection. The diagnostic logging will generate a .zip file which contains two files of interest: ConnectionStats.txt and IKEError.txt. Below are the outputs for both files from my real-world scenario. As you will observe, IKEErrors.txt reported a generic authentication failed error and suggests checking the pre-shared key, crypto algorithms and the SA lifetimes, however, the ConnectionStats.txt file shows a more specific “Packets Dropped due to Traffic Selector Mismatch” error.

 

Error: Authenticated failed. Check keys and auth type offers. 
	 based on log : Peer sent AUTHENTICATION_FAILED notify
Error: Authentication failed. Check shared key. Check crypto. Check lifetimes. 
	 based on log : Peer failed with Windows error 13801(ERROR_IPSEC_IKE_AUTH_FAIL)

 

Connectivity State : Connecting
Remote Tunnel Endpoint : 1.2.3.4
Ingress Bytes (since last connected) : 0 B
Egress Bytes (since last connected) : 0 B
Ingress Packets (since last connected) : 0 Packets
Egress Packets (since last connected) : 0 Packets
Ingress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Egress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Bandwidth : 0 b/s
Peak Bandwidth : 0 b/s
Connected Since : 1/1/0001 12:00:00 AM

Polycom VVX Phones and UK Daylight Savings Time

This weekend just past, the UK observed the end of daylight savings time for another year, bitterly welcoming in the cold weather and the start of the dark months. With that comes the day that many administrators dread in fear that their devices and equipment will fail to update with the proper time. Suffice to say, I have learnt lessons from previous years and my servers and network equipment all survived to tell the tale, however, I noted this morning that my Polycom VVX 500 desk phone had not.

I was surprised by this as I had all the proper configurations in place to ensure that the phone was using the correct time zone, however, upon investigation, the phone does not link the DST setting to the time zone: DST is configured separately. After a couple of minutes tweaking it via the web interface, I extracted the configuration, made it pretty and here it is.

Please feel free to use this on your own Polycom Provisioning Server configuration file if you have found your own phones now behaving. The configuration does a few things and hopefully, it should be clear enough for you to modify for your own needs in other locales.

  • Forcibly enable DST
  • Forcibly set DST to occur on a fixed schedule
  • Set DST to start on the last Sunday of the third month (March)
  • Set DST to end on the last Sunday of the tenth month (October)
  • Set DST to begin at 1 a.m. and end at 2 a.m.

 

<tcpIpApp.sntp.daylightSavings tcpIpApp.sntp.daylightSavings.enable="1" tcpIpApp.sntp.daylightSavings.fixedDayEnable="1" />
<tcpIpApp.sntp.daylightSavings tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="1" tcpIpApp.sntp.daylightSavings.start.time="1" />
<tcpIpApp.sntp.daylightSavings tcpIpApp.sntp.daylightSavings.stop.month="10" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="1" tcpIpApp.sntp.daylightSavings.stop.time="2" />

Active Directory 2016 Time-Based Group Membership

Group membership control and management is one of the cornerstones of Active Directory Domain Services. In Windows Server 2016, Microsoft introduced a new feature to Active Directory that forms part of the Microsoft Privileged Access Management (PAM) strategy.

When used in conjunction with automation, this can be used to provide Just-In-Time (JIT) access to protected and administratively sensitive services. When used in an environment that is synchronised with Azure Active Directory using Azure AD Connect, this can be used to provide JIT for hybrid solutions in Microsoft Azure (when RBAC has been applied to Azure Resource Manager objects).

In this post, I will briefly explain the processing for implementing time-based group membership in Active Directory.

Read the Full Post

Scouting UK Web Colours

For any regular readers here, this is a pretty off-topic post, however, I decided it was worthy of submission. As some may know, I volunteer with a local Scout group, the 1st Chineham to be specific. As a group, we are exploring getting a website up and running; I will have more to post on this subject in the future.

Whilst navigating the branding guidelines and documentation for Scouting UK at http://members.scouts.org.uk/comms_centre/zip/Brand_Guidelines.pdf, I discovered that the official colour palette for Scouting UK is only advertised in RGB and CMYK and Pantone. This is great for working in Office apps (RGB) or print (CMYK) but does not help for web implementation. Using an online RGB to Hex converter, I have pulled together all of the colours. If you are struggling to find them yourself, please feel free to use this as a reference:

  • Scout Purple #4d2177
  • Scout Green #84a40b
  • Scout Mauve #8b0066
  • Scout Orange #ed7703
  • Scout Blue #006990
  • Scout Brown #9d552d
  • Scout Grey #415a68
  • Scout Black #001323

Introducing Microsoft Forms

In the ever expanding world of Office 365, Microsoft has introduced another, new, compelling product to the lineup. As with a number of the recent releases, Microsoft Forms is a free product, available to customers with a compatible license for existing services. Microsoft Forms is still in preview and is not production yet; this does not mean that it is viable to be used in anger though. We are all accustomed to Microsoft releasing features in preview with Office 365 and Azure.

Next, do not be fooled by the name as I was when I saw it. My first reaction was that Microsoft Forms is a replacement for InfoPath. InfoPath is a form filing application from the Office desktop suite which has long been marked for the end of life. Microsoft Forms is not an InfoPath replacement. Microsoft Forms offers two key pieces of functionality:

  • Surveys and Questionnaires
  • Quizzes and Test Taking

Each of these two areas offers slightly different modalities for client use and slightly different features that can be consumed which we will look at next. Read past the break to find out more.

Read the Full Post