10 Quick Hybrid Identity Wins

[MUSIC PLAYING] So good afternoon. Welcome back. My thing today is to talk a little bit about hybrid identity, which has become quite the Microsoft buzzword, in particular, specifically everything in this session really focuses around Azure Active Directory. Seven or eight years, ago whenever the last tech was, this was kind of a new thing that nobody wanted to talk about. So we talked about all sorts of fun AD stuff, which oddly enough, I think all still applies but is not nearly as nearly as shiny, so I didn't dig out the slides from last time. Before I get going, one kind of poll question I have, how many of you work for an organization that has Azure AD premium or one of the bundles like EMS or M365 that comes with it? So half-ish, OK. So I will endeavor to call out what requires the premium features-- pretty much everything does on some level. Obviously, Microsoft wants to make money. And if you've been following the news lately, they're doing a pretty good job of making money by selling the stuff. So that's what we'll do. A quick intro-- my name is Brian Desmond. I am a principal of an organization called Ravenswood Technology Group, and we spend a good chunk of our time implementing pretty much everything we're going to talk about primarily for enterprise and mid-market customers, so we should be able to work in a little bit of real-world how this stuff works, as opposed to just some fun stuff on some slides. I've got the Twitter thing on all that. I think I've got a couple thousand followers. I haven't tweeted in years, but you should feel free to follow me in suspense. You never know, but don't get your hopes up. And my email didn't make it on there, but I've got cards. Feel free to grab one at the end if you want to follow-up-- always happy to chat. So before we dive into the fun the cloud stuff. One thing I'd like to talk about is that despite what the salespeople that might come calling on you tell you, everything still starts, especially from an identity perspective, with your on-premises infrastructure, unless you're a really small organization. Maybe that's exclusively in the cloud, but I think pretty much all you probably come from enterprise or thereabout size organizations. So if you don't have a secure foundation with what is probably AS, that whole mess that you have is going to trickle down or up, depending on which direction you want to look at it, to Azure AD. So one of the things that I spend a lot of time talking to my customers about is, how do we make sure that we have that secure foundation on premises so that we can be trusting about what we have in the cloud. So there's a few things around that. Managing privileged access to AD is a really big topic. If you haven't followed the news at all lately, a lot of people are getting themselves into the paper. And a lot of those incidents, at least that we run into, start with really bad hygiene around privileged access. And unfortunately, becomes a wake-up call for people as these things happen. Another one is identity management. If you don't have a solid identity management infrastructure that's provisioning users, that's provisioning groups, that's putting governance around those, as all that synchronizes to the cloud, if what you have on premises is out of date, that infrastructure that you take with you to the cloud is also going to not be up to date-- not going to be timely. And that governance problem just expands two fold from just one place to another. And then of course, as I say that, it sounds like, well, we should spend all this time getting our house in order-- getting things cleaned up. And the answer is probably yes, you have problems. You have technical debt that you need to address. But at the same time, if you've made that investment in cloud services, you're paying every month, whether you're using it or not. So as we look at this, and one the themes for this discussion is, how can we make use of the investment we've made-- get some incremental wins without being completely blocked, maybe with technical debt that we've accrued on premises. And with that in mind, what we see when we do these deployment projects, if we can get really quick wins, we can build a ton of momentum. That creates the foundation to really be able to have a really successful project. The days where we go spend three years implementing a new identity management system, and all the people that are writing the huge checks for this are getting really tired of writing those checks before they even see any value, see any outcomes from that-- Instead, with a lot of these cloud services, because they're super easy to configure, how can we pick one of these features and start getting a lot of value from it really quickly? And that's going to build the momentum that we need to make even bigger investments. And in some cases, longer deployment cycles for some of the more complicated features to consume. So from an Azure AD perspective, one of the first things that we like to tackle is there's the self-service password reset feature that's been there-- one of the early Azure AD Premium features. And this is, of course, from an identity perspective, one of the things that we've been trying to solve, and many vendors have solved in different ways. And it's also really easy to calculate, how much value am I getting from this, if you talk to whichever your favorite analyst is that's coming along. They make a ton of money telling you that it costs probably somewhere between $30 and $100 every time someone calls the help desk and says, I forgot my password. I can't get in, et cetera. And if you can trust that number, you can figure out how many times people are calling. If I can make that go down, I can very easily show value for the investment. We've had a number of customers that have paid for the entire Azure AD or EMS spend, just by showing how much they can decrease password reset costs. In some cases, it's not even about offsetting maybe another third-party product that's in place doing that, but just the sheer number of call reductions that they can drive. There is one that we did. They enrolled over 80,000 people in self-service password reset over the course of about a month, and that went from all those people-- the only way they could get help was to pick up the phone and call, to being able to do this in a self-service manner. If you think about even just a small percentage of those people call over a given period of time, there's a massive call volume that tanked in a matter of a couple months. The important thing with SSPR, or self-service password reset-- this is useless if you can't drive behavior change. It's great that you turned on this feature, but if nobody ever uses it or they're not enrolled, they're not registered to use it, it's completely worthless. And so the first thing you have to do-- you have to force everyone to register for self-service password reset. The good news with Azure AD-- there's a switch we can flip. Next time someone signs in to an application, if they haven't enrolled, they'll be forced through an interrupt that makes them do that registration. So that will get everyone registered. And then the next thing is we have to drive a behavior change, where even if you call the help desk, you call the service desk, whatever your organization calls it, they need to be redirected. Go to this page. Reset your password. We're no longer the people that you call who reset your password or drive you through that process. Because if people don't take advantage of this, again, you don't get any ROI on the investment. And then if you're using Microsoft's MFA service with Azure AD, one of the things you might have noticed, if you've used these features together, is that you have to enroll for self-service password reset. Then you have to enroll again for two-factor or multi-factor auth. And it asks the exact same questions, which seems kind of strange. There is, in preview, what they're calling converged MFA and SSPR, where you only have to register one time. And because it's asking the same questions, you get enrolled for both. So that's something you can turn on in your tenant, if you want to use it. And it's there on a preview basis. It also turns on the ability to use the authenticator app-- the push notification app-- for self-service password reset, which before was only available for MFA. And then finally, there is also a Windows 10-- both on Windows 10 and then available to download for Windows 7 and 8.1-- a plug-in for the credential provider screen-- the Control-Alt-Delete screen-- where you can sit down, and there is a "I Forgot My Password" button that ties into this experience. So it's not just a web-based flow, but it's also there on the client. The next one we tend to tackle is looking at how we can drive single sign-on to two applications. Or if you're using something like an ADFS or SiteMinder, Ping-- whatever federation product you're using-- maybe you're looking to migrate some of those applications-- is how can we get people out of the business of signing in individually to different apps? And maybe even using different credentials to sign in to those apps. If people are using different credentials, A, they're probably using bad username and password combinations, because they have to remember them all. And B, they're probably driving a ton of help desk calls, because nobody remembers which set of credentials works on which app. So with Azure AD, there's been a ton of work that's been done over the past year or two to really drive feature parity in the federation platform so that you can move apps off of things like ADFS, Active Directory Federation Services, or various other competing federation platforms, and move them onto a cloud service that you no longer have to manage. And when we do this, it's contrary to what probably seems like the right way to start. We tend to start with apps that are either super high volume, so a huge portion of the organization uses them. Or we start with the apps that are maybe a lower volume, but they have high risks. So we want to make sure that everybody's going through the path that we've defined to sign in to those, and that we can apply controls to that. And around the high-volume apps, one of the nice things about that is that if we can get everybody running through the process-- maybe it's something like an HR system, like a Workday or a SuccessFactors or Benefits, or wherever you go to get your tax forms at the end of the year-- we can also wrap around things, like take self-service password reset or MFA. If we can get everybody using the system with one of these apps, that means we can also tie on how do we get people registered for these other features, because they're going to hit going to hit the service. And they're going to use it by virtue of one of these applications. And then once we've got that going, we've proved that this works really well, let's iterate through the entire catalog of apps that we have and start getting them onboarded. And inevitably, there will be apps that you hit that may have requirements that Azure AD doesn't meet today. That list is dramatically less than it was even six months ago, but there continue to be little pockets where you'll hit that. That shouldn't be a blocker. Let's skip over that. Let's move on to the next thing, and then come back later on. And then your other blocker may actually be vendors of these applications. Despite the fact that you're probably adding security to a service that you are buying, many of these vendors make it super difficult to actually get them onboarded into a single sign-on system, even if they support it. And then from a troubleshooting perspective, how many people have used a tool called Fiddler? It's a free download. So maybe a third of the room. If you haven't, getfiddler.com. It's a free download. It puts an HTTP proxy on your machine. All the web browsing that goes through your machine goes through this tool. You can now see all the raw HTTP requests. And it also decrypts HTTPS, so you can see that, even though it's encrypted. And from a troubleshooting perspective, that's probably the number-one tool to be using to troubleshoot app single sign-on. Next on my list is privileged identity management. So just like domain admins in traditional AD, there are roles like global admins, exchange admins, and a number of other roles in Azure AD that if you're in those roles, you have an immense amount of access to both Azure AD and many of the applications that depend on it. And one of the things you can do with privileged identity management, or PIM, is you can both audit who has that data or who has that access and when they're using it. But you can also move it to a just-in-time model, where rather than these five people or these 10 people always having global admin access, what if we said that those five people are eligible to have that access. And when they need it, we'll let them activate it for a period of time-- maybe for four hours. They have to put a business justification in for why they're using it, and they have to complete an MFA prompt-- a two-factor authentication prompt-- before that elevation happens. And then now, they have that access. At the end of that time period, maybe four hours, for example, they're automatically taken out of that and their account goes back to being a normal user. You can use this for any role that's defined in Azure AD. You can also use this for Azure Resource Groups and Resources. If you're using Azure for something, you can use PIM for that access as well. And one of the nice things that you can get from this is you get this audit trail. This is also a great way to solve for the perennial problem of trying to take access away. People say they need it. Well, according to this report, you haven't activated this in six months or 12 months. So how can you need it if you've never used it? You can also wrap approvals around this. So before I can elevate, maybe my manager needs to approve it, or a peer needs to approve it. That can be really helpful as a second factor on top of traditional two-factor auth for really sensitive roles, like actually editing who can activate this. This requires the P2 version of Azure AD Premium, which is-- there are two flavors of Azure AD Premium. There's P1, which was the vast majority of the features. And then there's an additive P2. The nice thing about this-- you don't have to license your entire organization for this. You only need to license the people that are using PIM. So if you have 20 people that have privileged access, 20 licenses covers this. It's a really small investment to be able to get this capability. Anybody using the Azure Application Proxy? Couple hands. So this is what I typically see. Nobody knows about this feature that's buried in Azure AD Premium. And it's super cool for a couple reasons. One, it starts giving us the ability to deliver access to internal apps-- to internal services without having to use traditional VPNs. Nobody likes having to deal with the VPNs. End users don't like trying to figure it out, IT doesn't like managing it, and they're really expensive as well, when you look at the total cost of the solution. So what the Azure App Proxy does-- it's a set of lightweight agents that you install on premises. Or it could run in the cloud, but technically, this runs on a Windows server. Each of those agents makes a pool of outbound connections to the cloud-- to Azure AD. And it sits there waiting for requests. You publish an application through the Azure App Proxy. You configure this in Azure AD. What that does is it defines an endpoint that Microsoft hosts. You create a DNS record that points to the URL that people have always gone to. Maybe they go to intranet.contoso.com to get to your internal SharePoint. You change that DNS record to point to the endpoint that Microsoft is hosting. Now, when I try to access this application, I'm first redirected to Azure AD to log in. I have to sign in. I have to pass any security checks that have been defined-- any policies that have been defined in Azure AD. Only after I complete that authentication, my request is proxied back through that tunnel that the connector made, and down to the application on premises. So there's no inbound firewall rules, and there's no need to be on VPN, because I don't actually have to touch the application directly. Instead, I connect to an endpoint in the Microsoft data center. That endpoint relays me back to the connector, which has made an outbound connection to that endpoint in the cloud. And in turn, that connector proxies me to the application. I also don't have to sign in multiple times, because the connector can do Kerberos constrained delegation to the application. What that means is that as long as I can sign in to Azure AD, the applications doing traditional integrated Windows authentication, the connector can impersonate me to the application, and it looks like I'm coming to it. If the app is actually [INAUDIBLE], the connector can also handle that. So that at the end of the day, I'm only signing in once, and I'm signing in to Azure AD. In addition to just making apps available outside, I can also do things like take an application that has no concept of what two-factor authentication is and publish it through the app proxy-- make the app proxy the only way I can get to that app. And define a rule with conditional access, which we'll talk about in a couple of minutes, that requires two-factor auth before I can connect to that app. So now I've taken a legacy application that might have been written a decade or two decades ago. No concept of a control like MFA, and I've been able to wrap that control on top of the app without a single change to the application. So basically, this is one of my favorite features. I talk about this a lot to customers. These connectors also super lightweight. Each one can process in the magnitude of 1,000 requests a second. So even from a large organization standpoint, it's not like you need a ton of these relative to however many apps you're publishing. You can also place these in different data centers. So if I have some apps that are in the US, I have some apps that are in Europe, I can have different groups of connectors that are pegged to those applications so that people get routed to the closest endpoint. Yeah. So the question was, can you walk through how the Kerb constrained delegation works if you're authenticating through Azure AD? And so I guess a quick refresher on how Kerb delegation works. This was-- I used to do a session back at the old TECH, like every year and talk about this. And I had this animation that explained it. So the idea is, I want to impersonate someone to another application. So when I log in to my PC, from a Kerb perspective, I work through that username and password flow. I get that TGT-- a ticket-granting ticket-- from AD. Now I want to connect to a service. Let's just pick up a file share for sake of discussion. I take that TGT, which is my proof that I've authenticated, I carry it back to the domain controller, and I say, I'd like to access this file share that's on this file server. The domain controller looks at that TGT. It's able to decrypt it and verifies that it's valid. It gives me a service ticket that says I'm Brian, and I can access this resource which is named by what's called a service principle name-- the identifier for that file share. Now when I make that SMB request to the file share, I present that service ticket. And because it's encrypted with the file server's computer account password, it's able to decrypt it and say, oh, you really are Brian, and this is a service ticket for me. And it lets me in. So that's all well and good. I've gone in directly from my PC. I've tried to connect to that file share. But what if instead another system wants to impersonate me? In this case, the app proxy connector. We can configure this thing called Kerb constrained delegation in AD. And what that says is, for a given user or computer account, allow it to impersonate another person to a given system. So in the case of the application proxy, we would configure the computer accounts for the app proxy connectors in AD. And we would say that they're allowed to perform delegation to these services. So that would probably be maybe your SharePoint internet or web application. They all use a service principle name to identify themselves. That's pre-configured in AD. Now what happens is, after that request is sent to the app proxy connector, it's able to go to AD and say, I need a service ticket for Brian to this application. AD will give it that service ticket. And now when it makes the connection on my behalf that's been proxied through to the application, it's identifying itself as me. So when I log in to that intranet, it says, welcome, Brian. It doesn't say welcome, app proxy connector one. Any other questions? Yeah. Do these have to be browser-based applications? Do they have to be browser-based applications? It's a good question. By and large, the answer is yes. However, this also works with remote desktop sessions. And there's also some work that's been done to publish APIs with it as well. What's probably the fastest-growing feature with Azure AD in terms of consumption is something called conditional access. And this gives you what's essentially a declarative policy engine to decide the who, what, and when of access to every single application that's published through Azure AD. That can be applications that are doing single sign-on. They can be ones that you purchase from a vendor. It could be a ServiceNow or a SuccessFactors, a Salesforce-- something like that. It could be an app that you've developed in-house. Or it could also be an application that's published through the application proxy that we just talked about. And fundamentally, what we can do-- we can take all these different factors and all these different decisions and we can declare, without writing any code, who can access that application. So we can say people in this group or this list of users are allowed to access that app. That's really simple. We've been putting [INAUDIBLE] like that on resources forever. But now let's compound that and start adding other things. Maybe we want to make sure that people have always done multi-factor authentication before they can access the app. That's a pretty good idea. If you're not doing that for things that are accessible from the outside today, that's something you should be doing. But is that even enough? Maybe you have really sensitive information that's in this app. Not only do I want the user to be doing two-factor auth, but I want to make sure that they're coming from a device that we know and trust. They're coming from a device that has a relationship with our on-premises actor directory that's domain joined. We can test for that and say, OK. Now you have to come to this app. You have to do two-factor, and you have to be coming from a compliant device. So even if I was trying to access it from my home PC-- of course, I can do two-factor from my phone, but it turns out I'm not on a company device-- I can't access that application. And so now we know a little bit about where they're coming from. But what about if we care about the health of the device as well? If you use Microsoft Intune or you're using Microsoft's Defender Advanced Threat Protection, we can take the health of that device as signals. And not only are we identifying that yes, I know this device, but we can inject, is the device healthy? Are we coming from a device that we trust? Because maybe we're coming from a company device, but something bad has happened to it. It's been compromised. That's not going to be enough for us to be comfortable with allowing access to that application. So we can compound those things together. We can also add in things like location. Are you coming from a known IP range? Or are you coming from a country that we either allow access to, or maybe we don't want to allow access to? Many of my customers, especially smaller customers, will say, well, there's absolutely no reason someone should be connecting from China, or they should be connecting from another location that's known to maybe not be up to good. We can factor that data in. It's not nearly as reliable as something where the device is self-identifying-- it's using a certificate to prove its identity. But it's another factor that you can work in. And then finally, there's a step-up feature, and we'll talk about this a little bit more at the end. But Microsoft actually risk scores every single sign in that happens with Azure AD. Every one of those sign ins goes through a pipeline. There's a machine learning engine that's looking at that and determining what the risk level is for that sign in. We can actually apply that as a control and make decisions, based on that sign-in risk, what we'll let someone do. So maybe for most applications, even if it's from a medium- or high-risk sign in, as long as they do two-factor auth-- maybe they're coming from a known device. We're OK with that. But then maybe we have an application that has something really sensitive. Maybe it has a bunch of intellectual property in it, or customer information that we wouldn't want to risk being disclosed. If that sign in is high risk, let's not even allow them to get into that application. So we can make those types of decisions. We can do it on a per-app basis. We can do it on a per-user or per-group basis. And we can compound all this together to put a really, really strong perimeter around applications that we have integrated with Azure AD. How many people do not have password hash synchronization enabled for their organization? A few. OK. So you should turn this on. Even if you're using federation or using pass-through authentication, that's fine. You can continue to authenticate with Azure AD-- however you want to do that. But when you turn password hash synchronization on, you get a couple things. You get a nice little DR plan for your federation solution. If something goes sideways and that falls over, you can switch people over to using password hash sync pretty quickly. That's great. But the other thing you get-- and this isn't really advertised all that much-- is you get something called the leaked credentials report, which is another risk event or risk indicator that's in Azure AD if you have Azure AD Premium. And what this is, as these password dumps end up on the internet, on the dark web, Microsoft is acquiring those lists through various means they don't really talk about. You can probably figure out how that happens. And what they do is, they take all the username or email address and password combinations that are in the lists that they acquire. They run the same passwords hashing algorithm that would happen with your on-premises passwords that get rehashed and sent to Azure AD. And if they find a match, they let you know that you have a user who has a username and password that's been leaked on the internet, and you should do something about that. The only way they can do that is if you have password hash synchronization enabled, because they have no way to run that data if you're only doing federation or you're only doing PTA. You can still use federation or PTA, but having password hash synchronization on in the background enables them to run this data, and provide you this information, and provide these risk indicators. There are also ways you can use conditional access to flag people when this happens. You can automatically have Azure AD force someone to reset their password with self-service password reset when they end up on one of these lists. So you can self-remediate without even having a help desk ticket involved, for example. So super important-- if you turn this on, you get this data. There is no other way to get this data at scale, other than having this. So it's something that I strongly recommend, that I talk to almost all my customers about. And I think the good news is, I only saw a few hands up that aren't doing this. Hopefully, this gives you something to think about and maybe something to take back and make an argument for turning this on. So passwords-- people are really good at picking really crappy passwords, because they're really easy to remember. I doubt anyone in here could say that they're not guilty of this on some level. But when you have a password policy, for example, that requires you to change your password every 90 days, you get this really interesting phenomenon where people start going with, oh, my password expires in June. I think this year, it'll be Summer2019! That's got a capital letter, some lowercase letters, a number, and the special character meets the password policy. And I can remember it, because it's my password that's good until Labor Day. When it becomes fall 2019-- and maybe an at sign on the end, because why not? Turns out that the end users that think of this weren't the only ones that were smart enough, and the bad guys are pretty good at this, too. If you happen to live in a town that wins the Super Bowl, turns out that after the Super Bowl, a lot of people have Patriots 2018 or 2019 and an exclamation point-- whatever. That works a lot of years, it seems, with the Patriots and the number of the year on the end. Also super, super predictable. So how do we get people to not do this? One way is not to have these archaic and crappy password policies that force people onto these schedules. That's a really heavy lift for many organizations for reasons that probably nobody can articulate, other than it's been this way since the beginning of time, and I'm not going to be the guy that sticks my neck out and changes it. So what Azure AD has had for quite a long time is, if you use self-service password reset and you put a pretty crappy password in there, it will say something like-- it tries to be funny. It says oops. We've seen that one before. You should try it again. Turns out that Microsoft has a ton of data about something called password spray attacks, which are-- they're actually really hard to detect. And rather than traditional brute force attack, where I take one username and then I try hundreds of passwords against it until the account gets locked out, what if I take summer2019!, and I try it once against all the usernames in your organization? That doesn't show up as someone trying to hammer on an account, because it's only one bad attempt. But guaranteed some percentage of your user accounts will pass through that. Right after the Super Bowl happens, why don't I go and put the name of the local team against a company that's in that city? Put the year, put something on the end, and I can iterate through that, and I can hit every account maybe once a day or once every couple of days. Over a period of time, the success rate is super high. And these attacks-- they're called password spray attacks. They're really hard to detect. And they succeed, because people use really bad passwords. So Azure AD has had this list of passwords that Microsoft knows are bad and that people try all the time. And then recently, they started letting you add words to it. So the name of your company, the street that headquarters is on, the name of the sports team in your hometown. Those are all really good keywords to put on that list that you don't want people to have in their passwords. And then, this was only good if people were using self-service password reset, which some customers are. But lots of people still get that prompt when they sign into their PC. Your password is expired. You need to change it. Or they press Control-Alt-Delete and they change it. And that bypasses the entire protection. And since that's where passwords are sourced from, it's not super, super helpful that Microsoft's had this capability in the cloud. So what they came out with relatively recently-- I think towards the beginning of this year-- was something called Azure AD Password Protection. And it is a package that you actually install on every one of your on-premises domain controllers. It installs what's called a password filter, which is a little mechanism that lets AD intercept password changes and decide what to do with them. And they took that same technology with this list of bad passwords. They dynamically update it all the time. They don't tell you what's on it, because of course, you don't want the bad guy to know, here's the 1,000 things I shouldn't try, because they're smarter than me. And then they take the list of bad keywords that you've come up with-- so that name your company, the name of the town you're in, something like that. Now your on-premises AD can apply that same protection when someone changes their password on premises. It validates that they're not on this list, and it's not just a one-for-one match. It knows how to normalize, so when people think they're smart enough and they do password with the at sign and the dollar sign, it knows how to normalize that down to just a simple text, so the at sign becomes an a. The dollar sign becomes an s, and so forth. And now only if you pass that extra check are you allowed to change your password. So this is something that, it's in Azure AD Premium. There's virtually no setup. You can install this on your domain [INAUDIBLE]. You can put it in audit mode, which means it won't enforce, but it'll log event log events. Now you can look at this after a period of 14 or 30 days and get data about what would have happened, given that cycle in your organization. And chances are, the data will say that if you turn this on, you're going to have a lot of bad passwords that are going to get blocked. So the MFA service that's in Azure AD is great for web applications-- great for a few other flows that are natively integrated with it. But chances are, you probably had things like VPN systems, Citrix, remote desktop gateways, other kind of traditional legacy on-premises stuff that you need to add two-factor auth to. Of course, those have been the purview and good moneymakers for vendors like RSA, with SecurID tokens, Symantec VIP. There's a few of those out there that lots of people have. What you can do is, there is an extension for the RADIUS server that's built into Windows NPS. I think it's Network Policy Server. It is one of the server roles in Windows. It lets you add radius capability based on AD authentication. There's a little download that you can install on it. And now, every single authentication that goes through that NPS server also calls out to the Azure MFA service. And assuming that the user is registered-- they've done MFA before with Azure AD-- it will apply MFA to that authentication attempt. So what you can do-- you can stand up this RADIUS service, which is typically how these appliances and applications authenticate. You can re-point them to the NPS server. And by virtue of doing that, you start getting MFA for that app or for that service, without you having to do essentially anything else other than reconfigure the app to authenticate from a different system. And that registration that the user's already done for the Azure MFA service works just fine for this, and they don't have to do anything else. And it gives you the ability to offer one MFA experience-- potentially decommission what could be a legacy or expensive third-party MFA that's hanging around just to support something like this. One thing I will call out about this-- there are no controls on this. So as soon as you install this extension, it starts trying to do MFA on every single authentication request that goes through the NPS server. So if you're also using that for something like wireless, for example, you will break wireless very quickly if you install this. So typically, the way we do these rollouts is we stand up new NPS servers, we install the extension, and then we reconfigure apps that need MFA to point to that. That's something that's not really evident in documentation until you try it, and will end pretty poorly if you try it and discover this on the fly. So we talked a little bit about risk-based sign-in and some of the detections where, if your password is matched on a leaked credentials report, those are all part of a feature that's in Azure AD Premium P2 called Identity Protection. And this gives you access to that sign-in risk pipeline that Microsoft runs on every sign in. And it's search provide new data about all sorts of risk factors for your users and for their sign ins. So you can A, make conditional access decisions based on the risk of the sign in, which is evaluated every time. Or the risk of the user, which might be an offline evaluation. That user matches on a leaked credential report, so we want to force the user to reset their password next time they sign in. Or we're going to block them from signing and until someone manually resolves this. One of the things I tell people to do-- there is an additive cost to turning this capability on. You can turn on a 30-day trial right in the Azure AD portal. You can turn this on from the Identity Protection area. It takes a couple weeks to populate. Chances are, if you're using Azure AD every day, whether it's for Office 365 for other applications, this will often sell itself to your leadership, just by showing them the data that comes out of this. It can be frightening at times, what is actually going on, once you get to be able to visualize this. Whether it's people hitting accounts from places that they should never be, passwords that get leaked-- It also identifies things like people coming from Tor browsers or other anonymizers-- people that are hopping through IP address ranges that are known to have bad things happening. It identifies if a machine is showing patterns of being infected with a virus or malware, and quite a few other things. You can also test this. A Tor browser, if you've never used it, essentially bounces you through all sorts of different places to effectively anonymize your session. If you have this turned on and you start signing in through the Tor browser, this is a pretty good way to demonstrate this fairly quickly, and go from a low or medium risk to a high-risk sign in. So if you don't have this, I'd encourage you to go flip the trial on. Let it crunch for a couple weeks in the background, and then take a look at the data. It can be pretty eye-opening at times. Last but not least, there is another one of those capabilities that's hidden a little bit in the back. But for a SaaS application, so you're extending your existing IAM processes to those-- extending governance to those applications can be super difficult to do. What Microsoft has done is they have now dozens of applications-- it might be even over 100 at this point, where not only have they built single sign-on integration to those applications, but they've also built an API-level integration that enables you to define rules in Azure AD to actually provision users and groups into those apps. So now I say that all these people in this group need to get access to Salesforce, for example. Any time some data changes on premises in AD, and that synchronize to Azure AD, the sync fabric in Azure AD will actually sync that data downstream to Salesforce, for example, so that the user is provisioned there. They have the appropriate roles that maybe you have mapped to existing security groups that are on premises. And when they change roles or they leave the organization or they drop out of those groups, you can deactivate their accounts automatically. You can recoup licensing costs in those SaaS applications. And this is all without having to build new integration, maybe, in the existing IAM stack that you use. So the list of apps that have this capability has grown tremendously in the past year or so. There's probably-- there are dozens, maybe even up to over 100 at this point. But most of what I would call tier-one SaaS applications that are the ones that your organization and virtually every organization is probably using a few of, have not only single sign-on integration, but also have outbound provisioning enabled with them as well. So it's something to check out. And if you haven't used this in a while, it is much speedier than it was, so it's worth trying out again, as well. And that is pretty much all I have. I've got I think about five minutes for questions as well. Oh, look. Subtitles. [LAUGHTER] I do have subtitles. OK. That kind of works. That's cool. If you haven't-- Also, there's a survey in the tech app. please do that. It helps us do better and lets the folks that are putting this on know what you want to hear about next year, or not. So thanks. Thanks for coming. happy to take any questions. And hopefully, this was useful. [MUSIC PLAYING] [APPLAUSE]