The Identity stupid!

James Carville’s campaign strategy for Bill Clinton’s ’92 campaign was “The economy, stupid!” These 3 words left no doubt to what was important, what to focus on, and the fact that getting the Economy right would make everything else possible. Today, as we look at changes to the corporate IT network and infrastructure we should adopt a similar slogan:

The Identity, stupid!

Identity is a core enabler of modern solutions be they Collaboration, Security, from IaaS to PaaS. Companies in the past could rely on physical controls to secure information, but today Cloud and the interconnectedness of businesses has destroyed those controls. So where does this leave us in a world where we don’t control where information is accessed from, by what devices, or where the information is stored? We are left with one truth, unique to everyone and applicable to devices and data: Identity.

The funny think is, we’ve known identity has been important for a long time. If you ever took a class on journalism the first thing they taught was the mantra “Who, What, When, Where, Why.” When you log into your computer today the first thing it asks you is: Who are you? When you go to buy a car, boat, or house you have to tell them is who you are. You even have to tell the barista at Starbucks who you are!

Identity is important, so protect it!

Identity is the control mechanism today for enabling technology, if you secure the identity you’ve gone a long way to securing your systems and your data. Here are some methods to improve your organization’s identity strength without hampering their ability to do work.

Update your password policy

Recently even NIST updated their password policy (Section 5.1.1.2) to reduce the artificial complexity rules, changes passwords only when suspected of compromise, and perform checks against ‘dirty words’ and previously compromised passwords. At Microsoft the use of ‘Seattle’, and ‘Seahawks’ are rumored to be banned (I wouldn’t know because I don’t live in Seattle and I’m not a Seahawks fan).

Beyond these recommendations think Passphrase not Password. The longer the password the more difficult it is to guess so brute force and dictionary attacks are less likely to be successful.

All of these policies are easy to implement, prohibited words/phrases, detection of compromised passwords, and password length controls, and even self service password resets are built into Azure Active Directory. Azure Active Directory can become the central hub for password management with the ability to synchronization changes to your on-premise systems.

Enable MFA

I wrote about this in another post, but seriously if you have any admin accounts that don’t have MFA enabled stop reading this and go GO TURN IT ON NOW!

MFA is one of the simplest solutions to interrupt account compromises, and it has become more common for users because it is used in Banking Apps, Commercial Email, and even Facebook recommends your account be protected with MFA. At Microsoft we see a decrease in account compromises by over 99%. Clearly, this is the first step in enhancing the security of your identities. This is already included in O365 E3 or Azure Premium licenses and enabling it is just a few checkboxes, so there really is NO EXCUSE!

Use data

Monitoring accounts is critical, but there is a lot of information about what is happening in the world, like Dark Web sale of Credentials, that may not show up in your organization’s monitoring of accounts. However, a service like Azure Active Directory which is used by millions of user accounts daily gets lots of insight not only about your accounts but from all accounts, so when an attack is detected everywhere everyone can benefit from awareness and steps taken to block this type of attack.

Use AI and ML

Along with information about what is happening globally around authentications, it is also important to understand what is ‘normal’ and what is ‘abnormal’ for your users. If users sign in Monday-Friday between 9am and 5pm for 15 years then your identity system should recognize that a sign in on Saturday at 2:30am is abnormal. In this scenario the system may require extra identity validation (MFA), block the login attempt, or alert your other security monitoring tools and personnel. This capability is part of the Azure Active Directory Conditional Access which natively learns user behavior patters and can dynamically adapt the authentication experience based on user behavior patterns.

Change Written Policy to Automated Action

If you want to protect identities, really if you want to protect anything these days, then you need to take written policies and automate them in your identity system. A written policy like “If a password is compromised require a user to change it” requires a user to be notified and then for them to take action. Instead, your Identity tools should be able to detect the credential compromise and require a password reset (with MFA validation) on the next login attempt. In Azure Active Directory this can be done with Identity Protection policies, so if a user’s authentication event appears risky then flag the account for a password reset.

Loose the Password

I mention this one last because a Zero Password World isn’t quite there for everyone, but we are close. With Windows Hello and the Microsoft Azure Authenticator app we are moving closer and closer. Personally I don’t have a password for any of my Microsoft consumer accounts (Hotmail, OneDrive, etc.) and I very seldom use a password when accessing my Microsoft corporate resources. Actually, one the rare occasion I am prompted for a password I usually have to perform a Self Service Password reset, because I honestly don’t remember it.

Azure Active Directory has added this ability, but it is currently in Preview (maybe even Private Preview) so customers have to opt it to enabling the capability, but this is coming and I predict by the end of 2019 this capability will be readily and easily available to customers.

The Identity, Stupid!

It is time for us to focus on what is most important to the success of modern IT, both for usability and security, and it is all about Who! Like the 90’s campaign use this motto/mantra/whatever you want to call it to help you focus on The Identity, Stupid! If you get Identity right you can make everything else happen.

Azure AD MFA managed by User Account Administrator Role

Many organizations want to delegate enabling and disabling MFA for a user to their helpdesk, but the only RBAC role that allows MFA management is the Global Administrator and no one wants to grant helpdesk technicians Global Admin access to their tenant. However, there is a way around this RBAC limitation if your organization has Azure AD Premium.

General Concept

At a high level enabling and disabling MFA will be managed by adding and removing users from a security group. The security group will be included in a Conditional Access policy which defines the MFA requirements.

Setup

Requirements

Admin with Conditional Access administrator role
Helpdesk user(s) with User Administrator role assigned

Setup

Have a Helpdesk user create a security group in Azure Active Directory and assign the users your organization wants to require MFA when accessing applications. Make sure to include a descriptive name like MFA Required Users.

Next, have the Conditional Access Admin create a new Conditional Access rule with Assignments target set to the group created by the Helpdesk user.

Next, select the Cloud apps you want to require MFA before allowing access, or select All Cloud Apps.

Next, choose the option to Grant Access and check Require multi-factor authentication.

Finally, Enable the policy and choose Create.

Operations

Now, when the Helpdesk (someone with User Administrator Role) needs to enable or disable MFA for a user all they need to do is add (Enable MFA) or remove (Disable MFA) the user from your MFA Security Group.

O365 MFA vs Azure AD MFA

As a Technical Solutions Professional at Microsoft who covers Identity and Security I get a lot of questions about Office 365 MFA vs. Azure Active Directory MFA around the differences, benefits, and what I suggest. Customers always assume because I concentrate on the EMS stack Microsoft offers (Intune, Azure AD, Azure Information Protection) I recommend Azure AD MFA over Office 365 MFA, but the reality is when customers really compare the experiences they will almost always go with Azure AD MFA.

Before we talk about Office 365 vs Azure AD MFA let me make this position perfectly clear.

Use MFA! If you are not using, or haven’t implemented, MFA stop reading and GO TURN IT ON especially for your Administrator accounts.

Why? We, Microsoft, find that by enabling MFA on your accounts the your organization will reduce account compromise by OVER 99%!

Office 365 MFA

Office 365 E3, and up, subscriptions entitle an organization to enable Multi Factor Authentication for their users who will be accessing O365 resources (SharePoint, OneDrive, Office Pro Plus, etc.). When a user is entitled and enabled to use MFA they have three (3) options:

Azure Authenticator App
Text Message
Phone Call + PIN

To enable Office 365 MFA you must turn the feature on for each user individually (user-by-user), and once MFA is required for the user, it is always required for the user. Therefore, when a user is authenticating to O365 resources from their work computer or home computer using Office or browser, they will be prompted for MFA verification.

Azure AD MFA

Azure AD MFA is available for organizations that purchase Azure AD Premium P1, or P2, licenses for their users and this Multi Factor Authentication solution can be use with Office 365, Azure, On-Premise applications, third party applications (SaaS), and custom built Line of Business applications. Like the O365 MFA offering Azure AD MFA provides three (3) ‘native’ options:

Azure Authenticator App
Text Message
Phone Call + PIN

Azure AD also offers customers the ability to use 3rd party MFA providers including the following:

RSA
DUO
Trusona
(More to come)

This additional integration with 3rd party MFA providers means that any existing investment in MFA can continue to be leveraged and we can provide MFA support even in locations where mobile or office phone access is limited or prohibited.

The way an organization applies MFA with Azure AD is also different than Office 365. When applying MFA with Azure AD an organization does so by creating Conditional Access (CA) rules. CA rules for MFA can be very simple:

All Users + All App + MFA = Grant Access

Basically this is what the Office 365 MFA solution provides, but limited to O365 apps that is. However, CA can do much better, it can actually allow you to address questions and policies intelligently:

Why prompt for MFA when a user is connecting from a corporate network and is using a corporate device?
Why prompt for MFA when a user is connecting to their time card the same way you would if they were connecting to the corporate account line of business application?
Why MFA everyone all the time, can we target specific users when they are accessing accessing sensitive information?

Using CA to drive MFA also allows your organization to integrate MFA easily with Windows Always-On VPN solutions. Now not only do you protect a user when their app connects to a service, but you protect your corporate network when an endpoint device connects and its all managed with the same CA, MFA, and identities.

What drive Azure AD MFA over Office 365 MFA

I find most organizations choose Azure AD MFA over Office 365 MFA for one of these two reasons:

They already invested in an MFA solution, maybe RSA, so the users know it, IT trusts it, and they can continue to use it.
They don’t have to use an All-Or-Nothing approach, they can apply a Who-What-When-Where approach to their MFA policy and only require MFA when necessary.

To me, the greatest benefit of Azure AD MFA is the ability to target MFA scenarios. I’ve seen many customers push MFA for everyone all the time, and within a short period of time they turn it off because “there was too much prompting”

SAML Security Vulnerability

Duo Labs announced on Feb 27th that it had discovered a security vulnerability in some SAML SSO providers. The outline of their public post showed how an attacker could authenticate so a SAML SSO provider, and then manipulate the SAML response to allow them to impersonate a user based thanks to different canonicalization algorithms.

As you can imagine this raised serious concerns across the IT industry who relies on SAML for Federated Identity and Authentication services.

On March 2nd, following a review of the issue Microsoft announced that our core products, Azure Active Directory, Azure Active Directory B2C, and Windows Server Active Directory Federation Services are NOT affected by this vulnerability. In addition, any services which utilize Windows Identity Foundation (WIF) and/or ASP.NET WS-Federation as their identity middleware are also NOT affected.

ADFS: Certificate Authentication and A Dirty Certificate Store

I often support ADFS configurations that are used to enable Client Certificate Authentication. Typically, these deployments are straight forward: we have certificates that cover the URLs ([sts url] and certauth.[sts url] see this article for more details), we enable the client certificate authentication and it works.

Then there are the other deployments.

The Dirty Certificate Store

Symptom

After enabling client certificate authentication when the test user selects the X.509 Certificate link they are redirected to the certauth url, but the option to select a client certificate never appears and after an extended period of time, something like 2-5 minutes, the request times out.

Troubleshooting

The easiest or most obvious cause would be a SSL certificate that doesn’t support the auth.[sts url] which would cause ADFS to use port 49443 and the traffic being blocked by the firewall. However, working with the firewall administrator we could see the traffic coming in and going out on 443 and never moving to 49443. Further testing with a client ‘inside’ the organization showed similar timeout behavior so we eliminated both the firewall and the bad SSL certificate.

I began hunting through the ADFS logs as well as the client logs, but found nothing so I was stuck. Fortunately, I was able to use some of the internal Microsoft resources and was told to try adding the following registry key:

KEY: HKLM\system\currentcontrolset\control\securityproviders\schannel\sendtrustedissuerlist
Type: DWORD (32 bit)
Value: 0

After adding this to the ADFS server, and performing a reboot, we started getting prompted to pick a client certificate. So doing a little research I came across this TechNet which outlines what the registry key above does.

https://technet.microsoft.com/en-us/library/cc776467(v=ws.10).aspx

The result is this key blocks the ADFS server from sending a list of Trusted Certificate Issuers (TCL) to the client machine. This is desired, normally, because we don’t want a user to pick a certificate for authentication that the ADFS server doesn’t trust. However, in troubleshooting turning this setting ‘off’ is useful because we can now validate that ADFS is sending the request to the client for an authentication certificate, and the client can provide a certificate to authenticate with.

SUCCESS, right?

Fix It

It’s not recommended to leave the TCL disabled because a user will eventually try to authenticate with the wrong certificate, fail, and then you’ll have to troubleshoot that problem…and fix it.

There are two issues that can occur with the TCL. First, if there are too many certificates then the server can’t send them all to the client. Second, if there are non-root certificates in the root certificate store, or root certificates in the intermediate certificate store then the list is corrupted. In either case, the client sees no certificate selection prompt and authentication stalls resulting in failure.

To solve the first problem of too many TCL entries you can remove old or unused Certificates from the Root Certificate store to reduce the size of the TCL.

To solve the problem of Certificates in the wrong certificate store you can review each root certificate and verify it’s issuer IS itself. You can then review each Intermediate Certificate and verify it’s issuer IS NOT itself. Or, you could use the below PowerShell script to help you identify the possible certificate errors.

Write-Output "Issued To,Issued By,Certificate Store"

$rootconflicts = Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Issuer -ne $_.Subject }
$rootconflicts | ForEach-Object { 
 $subj = $_.SubjectName.Name.Split(",")[0].Split("=")[1]
 $issr = $_.Issuer.split(",")[0].Split("=")[1]
 Write-Output "$subj,$issr,Root"
}

$conflicts = Get-ChildItem Cert:\LocalMachine\CA | Where-Object { $_.Issuer -eq $_.Subject }
$conflicts | ForEach-Object { 
 $subj = $_.SubjectName.Name.Split(",")[0].Split("=")[1]
 $issr = $_.Issuer.split(",")[0].Split("=")[1]
 Write-Output "$subj,$issr,CA"
}

Write-Output "Found $($rootconflicts.Length) Non-Root Certificates in the Root Certificate Store."
Write-Output "Found $($conflicts.Length) Root Certificates in the Intermediate CA Store."

This is also available at my GitHub repository.

https://github.com/dmcwee/azure/tree/master/Scripts

[3/5/18 Update]: Added link to the AD FS Requirements article on docs.microsoft.com

Azure – PowerShell Capabilities I Love

I use Azure for Development and Testing very heavily with my job as a consultant for Microsoft. Since most of my work is done deploying systems On-Premises I usually have to build environments for testing of deployment scripts etc. This means I have the option to go through the Azure Portal and create machine after machine, or I can use PowerShell to script these processes. As such I have gone through many of the IAAS PowerShell commands and thought I would share some of my commonly used commands.

IAAS Commands I Always Use

Set-AzureRmVMCustomScriptExtension

So, you create a VM and now you want to configure it before you actually log in, like make it a domain controller or join it to a domain. No problem, the Set-AzureRmVMCustomScriptExtension allows you to push and run a script file on the Azure VM without needing to log in, and you can even pass arguments to the script. This command does require a bit of information (Resource Group Name, Storage Account Name, Container, and others) but being able to create a VM AND set it up as the domain controller without ever logging in first…you can’t beat that.

Set-AzureStorageBlobContent

This command is a MUST KNOW because it allows you to move content from your local machine to an Azure Storage Blob, and if you want to use Set-AzureRmCustomScriptExtentions, your scripts have to be in an Azure Storage Blog. This command is actually pretty straight forward, give it the filename (blob), Container, Storage Account Context and the local file path and upload away.

New-AzureRmResourceGroup

Every time I create a new “Environment” I create a new resource group partly because I’m lazy, but also because I’m really picky. I don’t like having 2, 3, 4, … environments inside of one resource group because when I script things I really just want to say something like “Start My Resource Group xyz” and let the script handle the rest. Also when I’m done with an environment I can easily clean it up by using the Remove-AzureRmResourceGroup, and poof its gone.

New-AzureRmVm

Need a new VM, here you go. This command isn’t as straight forward as it seems, really to use New-AzureRmVm you must create the Azure RM Config object and all the necessary elements, but this inside of a simple ForEach-Object loop can save you hours of entering information into the Azure Portal forms.

Runbooks – Stay under that spending limit

Azure Runbooks are one of my favorite capabilities available. First, the interface is web based so you can write and test your PowerShell directly in the Azure Portal which is a really nice capability. Second, you can schedule these books to run so if you forget to shutdown and environment, the scheduler will do it for you. Third, if there was a problem your output from each run is available for review so you can always go back and review the Runbook output and check the script health. Finally, Runbooks have access to variables stored Outside of the Runbook, so no need to include the admin account’s info in your PowerShell script, just save it in the Runbook’s variables (as a Credential, so the password is hashed) and make nice generic runbooks.

I highly recommend using runbooks to at least stop your development, and possibly test, environment on a daily basis. My Stop-Daily runbook is configured to run every day at 6PM so I know all of my VMs will be shutdown. I typically keep my runbook(s) in a separate Resource Group from the different Development/Test environments I create, this way I can destroy the environment without losing the runbooks.

Runbook(s) work within a single subscription, so if you have multiple Subscriptions you will need to create runbooks for each.

Another Change

You may have noticed that the site look and feel has changed. I felt it was about time to get a new theme on the blog since much has recently changed. For those that didn’t know I began working directly for Microsoft at the end of June 2015. As I continue to grow professionally I have decided it is time for me to spend a greater amount of time focusing on Identity and to begin to move away from my focus in SharePoint.

The wonderful thing about identity is that I won’t actually leave SharePoint, but now my focus will be on WHO is accessing the portal. I also get the opportunity to expand my technology base into Skype for Business, CRM, Mobile Apps, basically any and every technology you can think of. I’m excited about this change and I hope to share lots of new information with everyone.

As always, come back often and if you have questions always reach out.

David McWee

Security that works together, Works.

The Identity stupid!