Pass the Hash Mitigations

Over the last couple years, I’ve seen countless articles explaining Pass the Hash, and there are even a few high-level whitepapers about what to do about it. Here’s some of the best of those:

There’s also a good paper covering the Kerberos equivalent:

Awareness and understanding is all good, but there isn’t enough thinking and public discussion about the specific ways to mitigate the risk.

In many ways, it feels like folks are holding their breath and hoping Microsoft will fix it all.

And of course, in the meantime more places are getting compromised. I have little doubt that yesterday’s announcement of the Premera compromise will turn out to be yet another PtH story.

We’ve closely looked at the Protected Users & Authentication Policies stuff. Like several notable 3rd parties, we’re not convinced they are especially effective given the design. I have high hopes for the Aorato Directory App Firewall (or whatever Microsoft chooses to call it after it re-releases it) and its ability to detect PtH. Likewise, I’m hopeful about the Next Generation Credentials that Joe Belfiore publicly revealed more about recently (but it isn’t yet clear that NGCs help with PtH). And there is the Just in Time administration capabilities that should be released soon with MIM, which would limit how long a given account has privs, instead of it always having privs. There’s also the recent guidance on how to reset the KRBTGT account password. Those are the major things Microsoft has cooking/available for this problem. But those are just part of a strategy, most aren’t available yet, and in some cases require major changes that aren’t realistic to expect anytime soon.

Don’t get me wrong, I’m totally impressed with how much investment Microsoft has poured into this, it’s just that I don’t want to sit around idly any more and I don’t think anyone else should either.

We’ve been talking a bit here about potential ways to mitigate risk that don’t require some new thing and wouldn’t necessarily be a major impact to implement. Not eliminate the risk, but limit it. Here’s some ideas we’ve been tossing around:

  • Automatic user profile deletion after X days via group policy setting. Eliminates cached creds laying idly around. Definitely a good idea for servers, maybe not so much for workstations given the roaming scenario. 
  • Develop strategy to block ‘logon over the network’ user right. Idea here is to inhibit the lateral movement. Still struggling with whether this should leverage the block setting or reduce who has the allow, and beginning to lean toward the latter. Things that need more thought are how to break your sets of computers into logical groupings of levels of trust where you’d apply this–put another way, what are the trust boundaries for this idea? Also needing thought are which accounts would lose logon over the network–seems like you’d want to target accounts that have any sensitive permissions.This idea seems to have lots of promise, but the details are a bog.
  • Push Group Managed Service Accounts more heavily. Perhaps to the point of eliminating “normal” user accounts for services, scheduled tasks, etc.
  • Have better education/practices for which admin accounts should be used in which scenarios. “workstation admin” account only used to log into workstations. “server admin” account only used to log into servers. “domain admin” account only used to log into DCs. Never use these on the same computer, because then you’ve created an escalation bridge. If possible detect when a type of admin account has been used improperly, and alert to take actions to eliminate risk from that.

We’re open to hearing other’s ideas, hearing critiques, or collaboration on these ideas.

Diving Deeper on Azure AD Premium Licensing

Update 2/26/2015: This post resulted in a follow-up conversation with Microsoft. They suggested some changes and improvements which I’ve incorporated below in italics.

I recently seized an opportunity when an Azure AD product team member offered to explain anything about Azure AD licensing. Until that conversation, I was really confused about when we needed an Azure AD premium (AADp) license and when we didn’t.

There are a number of misconceptions around Azure AD premium. For example, AADp is not something you use to refer to a AAD tenant. AADp is something you use to refer to a user. You do not “have an Azure AD premium”. You have an Azure AD user with a AADp license. Unfortunately, some of the literature from Microsoft encourages this kind of misconception.

Anyhow, at the end of that conversation, I got their OK to share the info I learned (and I encouraged them to publish these more nuanced details), because I suspect that if you are like me, you may have some faulty assumptions like these:

  1. That to use any of the advanced capabilities, you need to have an AADp license for all of your users
  2. That since you had to license everyone, that resulting cost meant that the advanced AAD capabilities were dead to you

http://azure.microsoft.com/en-us/pricing/details/active-directory/ is the (only) published guidance to help you navigate these waters. Using the table at the heart of that page, for each of the capabilities listed (the rows) I got clarification about who (or how many) AADp licenses were needed to leverage that capability. I’ve taken the liberty of re-ordering those rows slightly, mostly to more closely group rows that are related to one another. AAD Basic (AADb) licensing is provided by an Office 365 license.

Here’s a breakdown:

Capability Licensing coverage needed
Directory as a Service AAD Free (AADf)
Service Level Agreement (99.9%) If you have one user with AADb or better, then you get this.NOTE: If there is an outage, only those users which have AADb or better are entitled for refunds. In other words, AADf users don’t pay anything, so they are entitled to no refund.
User and group management AADf
Directory Synchronization AADf
Directory Object Limit (500K) If you have one user with AADb or better, then no limit.Your number of AADf users can not exceed 500K.
Logon/Access Panel branding If you have one user with AADb or better, then you can use this.
Access Panel AADf
SSO for SaaS Apps (assignment limit of 10) AADp required for each user that you want to assign > 10 SaaS apps to.
Secure Remote Access and SSO to on-premises web apps (i.e. App Proxy) Each user that leverages this capability must have AADb or better.
MFA (AAD only) Each user needs AADb license or better.NOTE: see http://blogs.technet.com/b/ad/archive/2014/02/11/mfa-for-office-365-and-mfa-for-azure.aspx for more details about this and the following item.
MFA (AAD + on-premises) Each user needs AADp license or better.
Group-based Access Management and Provisioning (e.g. license assignment via group) Each admin that leverages this capability must have an AADp license.
Self-service password reset (SSPR) Each user that needs access to this capability must have an AADb license or better.
SSPR write-back to on-premises Each user that needs access to this capability must have an AADp license.
Self-service group management Each user that needs access to this capability must have an AADp license.
Microsoft Identity Manager User CAL Each user that leverages MIM portal must have an AADp license (or separately a MIM user CAL). This is relevant for the Just In Time (JIT) Admin and other on-premises capabilities
Basic Security Reports AADf
Advanced Usage and Security Reports Each admin that leverages this capability must have an AADp license.Every user in a report must have an AADp license.
NOTE: This isn’t yet enforced, and it’s unclear what future changes would reflect this.

So if you have Office 365 licensing, there are actually only a few of these capabilities that require a broad number of AADp licenses, many actually are either covered by AADb or you only need AADp licenses for a handful of users (your AAD admins).

The next trick is to analyze your needs and figure out how may AADp licenses you’ll need based on which of these capabilities you plan to leverage. Keep in mind that the Enterprise Mobility Suite (EMS) is likely the most cost-effective way to purchase an AADp license, so you may also need to take into account your Intune and Azure RMS licensing needs too.

Leveraging Azure AD authentication for an on-premise web app

I’ve been experimenting with using Azure AD for authentication of an on-premise web app. I thought I’d share some of my findings so far.

 

I was writing a web app to provide reporting on simple bind data UWWI is now collecting. When I added a asp.net web project to my Visual Studio solution, it asked me what authentication I wanted to use, with 3 or 4 choices. Since it happened to be a leap forward day, I decided to give AAD a try (to be clear, I’ve been intending to try this out for about 9 months, but never found the time).

 

The on-boarding process was amazingly simple. I happen to have a global admin account in our AAD, and currently without that, the experience isn’t as simple, but my understanding is that level of privilege won’t always be necessary in the future. In other words, in order to create the application in AAD, you currently need to be an AAD global admin. When I compare the on-board process of what it takes for a web app to integrate to an equivalent federated authentication solution that uses UW NetIDs, like Shibboleth or ADFS, there’s really no comparison. I had a registered app with working authentication within 30 seconds—and all from within Visual Studio.

 

Now, if I had a more complicated use case, e.g. I was writing a web service that other web apps could interact with, then the initial configuration to get multiple party OAuth setup would have been beyond that, but today there is no UW OAuth offering (or if there is, it isn’t documented). I haven’t experimented here, but I think Eric might have been looking into this.

 

My next (and active) hurdle was realizing that my AAD credentials wouldn’t allow me to get access to the SQL server where the data my report needed to access was. There are two solutions I can take to solve this. A common solution many websites take is to use the web app pool’s credentials to get access to the data. I’m generally not a fan of that type of architecture, because it complicates the audit picture and there is a strong temptation to not actually write the auditing the web app must now must do, so I resisted that. I spoke with a colleague of mine, Brian Desmond, and he suggested I leverage KCD (Kerberos constrained delegation) to transition the AAD credential to an AD credential—he had done this exact thing several times for similar use cases. Turns out that the C2WTS service (Claims to Windows Token Service) that was released with ADFS 1 was subsequently more broadly released with WIF 3.5. This service is commonly used with Sharepoint 2010 when it is configured to use federated authentication, e.g. see http://support.microsoft.com/kb/2722087. So I now need to explore writing some code that leverages the C2WTS stuff, which fortunately there are nice code examples for at http://msdn.microsoft.com/en-us/library/ee517278.aspx.

 

I’m beginning to think there is a nice emerging and reproducible authentication integration pattern here for future .NET web apps. You end up with a web app that has federated authentication, can benefit from all the cool AAD capabilities Microsoft is pouring investment into (like RBAC), but you can still get all the benefits of the traditional AD logon token. There’s a lot more to explore here before labeling it a preferred integration pattern, but it has definite potential in my mind.

 

Obviously I haven’t finished (and given my spare time to work on things like this, I probably won’t for a while), but I did think this was worth sharing more broadly.

 

If others have a web app they’d like to provision to Azure AD, let one of the AAD global admins know, and we’ll get your web app provisioned.

 

Azure AD RBAC

The URL in the tweet below talks about using a feature I’ve been talking about here at the UW—the emerging Azure AD RBAC capabilities.

 

The blog post below talks about using this feature in the context of a web app hosted in an Azure Website, but the capability is designed to be used by a web app hosted anywhere.

 

The post only talks about the 3 built-in roles, but the capability is designed so you can define your own custom roles—they just haven’t released that option yet.

 

If folks are interested in reading up on this, here are some good starting points:

 

Background: http://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/

 

Developers: http://social.technet.microsoft.com/wiki/contents/articles/4075.role-based-access-control-rbac-authorization-in-claims-aware-applications-and-services.aspx

 

Example app walkthrough: http://msdn.microsoft.com/en-us/library/azure/dn385717.aspx

 

David Ebbo (@davidebbo)
1/5/15 2:25 PMGreat article on the use of Role Based Access Control (RBAC) in Azure Websites: azure.microsoft.com/blog/2015/01/0… #azure #websites #rbac