Best Practices for Azure AD Hybrid Organizations

[MUSIC PLAYING] Hello, everybody. Thank you for joining. My name is Jorge Lopez. I'm a senior product Manager at Microsoft and I'm part of the Identity Division. So part of my work is actually build Azure AD features and products. Today, I'm here to talk to you about best practices for hybrid identity organizations that you're going to take advantage of, especially if you have cases where you still have on premises resources and features in Azure AD that you want to take advantage. First of all, I'm going to walk you through some of the overview and the agenda that I'm going to talk to you today. So first, we're going to do a quick recap on what a hybrid identity organization means. And then, I'm going to walk you through some of the scenarios and best practices that we have, basically, for three main pillars, which is users, apps, and devices. To begin with, let's put ourselves a little bit in maybe 10 years ago. What you're seeing right now is a very typical topology infrastructure environment for those hybrid identity organizations where you're going to have an on premises active directory forests, maybe multiple forests. Some Kerberos applications, header base applications, internet servers, and employees accessing all of these applications from corporate devices within the same network. Some organizations may actually have a little bit more modern applications based on SAML protocols and federation servers. Because of the challenges that these organizations started having at some point, most of these organizations, they started deploying DMCs with virtual private networks, or VPNS. And that was basically to provide access to remote employees. Employees that were in the field, external vendors, partners, and suppliers with different organizations. And with all of the different modernization of the applications, a lot of vendors and a lot of third party apps, they started deploying what we call SAS apps, or Software As a Service apps, which means applications like Box, Salesforce, ServiceNow started deploying all of these different platforms that were actually born in the cloud. With that, there were some challenges coming from all of these organizations where, how do my users start accessing these apps? So unfortunately, a lot of organizations were actually doing-- creating separate username and passwords for these applications. That meant that, basically, a lot of the users were creating n number of accounts-- x number of accounts, with probably the same password. And that's, as you may know, it's not really the best practice. One of the other challenges that we had at that time is because the separation of identities, right? So if I had a partner or a supplier that needed access to one of my applications on premises, but I don't want to mix up my corporate identities with my partner identity. So they were creating all their forests sitting on the DMZ. Maybe now that doesn't really sounds like the great idea. But at that time, it was probably the only way to make it work. As time started going on, we, of course, Microsoft, develop and deployed Office 365. And with that, we came up with Azure Active Directory, which is basically a presence of your on premises identities in the cloud. So basically, a representation of those identities, whether you're maybe creating cloud only users or synchronizing them from on premises you see naturally connect, as you may know. So what you're seeing right here is, like I said, a typical topology for a hybrid organization. So as you can tell, this is where we actually base our recommendation, which is at the top, or applications, in the middle or devices. And at the bottom, of course, the users where-- most of the recommendations that I'm going to talk to you about today are based on the users, but I also have a few things about devices and applications. So let's start with the users. And one of the main things that I like to say is that a lot of organizations are still stuck in recommendations and guidance for almost 20 years, right? NIST in 2004 came out with the very first password recommendations approach, which is eight characters minimum, uppercase, lowercase, complex passwords, change it regularly. And that's been, like I said, 2004. It's been a lot of time now. And one of my recommendations is organizations needs to start thinking about updated guidance, right? So even NIST, in 2017, came out with another guidance that says, use easy to remember phrases. And only change your password if you think that it has been compromised. We, at Microsoft, also recommend to follow aka.ms password guidance, which is our own guidance as well, that follow some of the NIST guidelines, too. And mainly, it's just, basically, that passwords by themselves are not enough protection anymore. And if you're familiar with Azure AD password protection, it's one of those features that I keep talking about that we have in the cloud that you can extend to your on premises environment, especially if you do it in hybrid mode. And one of the main things that you've been probably hearing from Microsoft a lot lately, evaluate password solutions. And that's some of the other things that we've been recommending because we do have some things that you can do today to implement passwordless. And we can provide you some deployment plans on all of the other things that you can look in the near future for your passwordless needs. Something that you're hearing a lot and we are not going to get tired of saying it, please enable MFA. Some of the number shows us that a lot-- around 26% of the users population are not using any sort of MFA. We're going to talk about the authentication methods in some of the next slides. But please enable MFA. It's super important for your security approach. When we talk about MFA, of course, and authentication methods, we need to discuss that not all authentication methods are equal. And we know, by now, that a password by itself is just not strong enough. It's bad. If you want to make it a little better, well, you can do a password and some sort of form of MFA, if you want, even if it's SMS and voice. We know that those are more prone to channel hijacking, SIEM swap, and some of the things that, yeah, it may not be the most secure one. But it's still better than just a password, OK? It cannot be good if you can do it better, right? If you can do it better, then go with a password and maybe some of the other modern methods for MFA, like the authenticator app with push notifications. Azure AD also supports software one time passcodes token, or even you can bring your own hardware tokens if you already deploy some of those. If you want to do it best, for the authentication methods, go passwordless. You can do that today with the authenticator app and do phone sign in without typing a password. We have plenty of things around Windows Hello For Business. Deployment plans that you can find to do Windows Hello For Business for passwordless solutions with authentication methods. And one of the main things that I want to highlight about this is that Windows Hello For Business, FIDO2 security keys, and the recently released certificate-based authentication for Azure AD are phishing resistant, which means you are protected against replay token attacks if you're using these type of devices or password and authentication methods because we're-- the actual authentication is bound to the device that generated the request for the token. So if you want to know more, you can go to aka.ms/deploymentplans. One of the main things that you will also hear from us a lot, optimize the authentication methods. The famous requirement for every time, right? The reason why we say that is because more prompts are not necessarily more secure. You've got to be careful. You've got to find the right balance between these. Because too many of these prompts can actually lead the users to blindly approve MFA prompts. They may not even looking at their screen and they receive a notification to approve MFA. They may actually do it. So that's not very secure. So be mindful of finding that right balance between how much time or how many times am I going to prompt my users versus we need to make it secure. We acknowledge and we understand that there's applications that maybe require some sort of MFA every time. But at the same time, we tell organizations and customers, as a best practice, don't do it just for general all user population in all of your apps. If you think you have an MFA prompt problem, you can visit aka.ms/mfapromptsworkbook, which is an Azure AD workbook that will tell you what applications are generating the most prompts. One of the things that we're doing as well in the realm of improving the MFA experience to avoid all of these different MFA fatigue attacks, or muscle memory for the users that they just get a prompt and they will approve it, number matching. You may be familiar with this. So number matching will present the number on the screen that a user will have to type in their authenticator app. So we switch from the form of saying, you only have two options, approve or deny, which is a 50/50 chance that you're going to pick the wrong one, versus 1 in 100, which is you actually have to type the number that is on the screen. It also gives you the solution of the muscle memory because let's say that you're not in front of your computer. If you get a prompt on your phone that is asking you for a number that you don't even know what number is it or what is being generated, you're going to actually question that, and that's the main point. Question your MFA prompts. Another thing that we also offer in the authenticator app is additional context. Additional context will give you a little map and the name of the application that is generated in the prompt. And the best of both things is-- the best of the things is that you can actually combine both on the same prompt. So a number matching additional contexts. We're in the process of developing other nice features around this particular thing. But if you are able to do this today, I will highly recommend it. Some of the other possible solutions that we have, especially for onboarding and recovery of the account. So Temporary Access Path, or TAP. TAP is a time limited passcode that needs to be issued by an administrator. It's not a password and it's time limited and you can even do a one time passcode, which is if you think about a good scenario will be, you have somebody new joining the organization. You can ship the new computer to that person if it's remote. And maybe ship a FIDO2 key so they can log into Windows or just have an-- with autopilot to the Windows Hello For Business or something like that. And then, you generate a TAP for the user. So when the user receives the laptop, that user already has some sort of passwordless method that they can onboard that account and log into Azure AD with a tap. And then, set up the FIDO2 key so they can log into the machine with either the FIDO2 key or set up the machine for Windows Hello For Business without even typing a password. The user wouldn't even know what password they have. So especially for, like I said, user onboarding or account recovery, TAP is a passwordles solution that you can also use today. Another very cool feature-- and we're probably moving away a little bit from the security side, let's talk about Group Writeback. And Group Writeback has been, actually, around for maybe a few years. This new version that came out this year, or version 2, allows you to write back your cloud managed security groups, which means even if you have manual assignments as members of the security groups, or dynamic security groups, which is one of the coolest features in Azure, you can write them back for your on premises needs. So think about a security dynamic group that lives in Azure is cloud managed. It doesn't exist on premises yet. And then, it's dynamic. You create a rule that says, if a user has finance value on their department attribute, then put that user on this dynamic group. That is the finance group. Write them back and maybe you can have an on premises finance app that you can give access to that group and use the cloud managed capabilities in Azure AD for managing the access to that. One of the other cool features is that you can actually use all the things that we have in the cloud to manage those groups, like access reviews, which is some sort of attestation. And all of the other things that you can take advantage for groups that are cloud managed and take advantage of them on premises. All of those groups can be synchronized, even if they are Microsoft 365 groups. And you can put them-- or synchronize them back or write them back into your on premises AD as distribution groups or security groups. Another cool feature around the user provisioning. We have something that is called HR cloud app driven user provisioning to on prem AD. It sounds like-- it's not a typo. It's not provisioning to Azure AD, it's provisioning to on prem AD. So if you have an application that is cloud HR app, like Workday or SuccessFactors, you can take advantage of this. And the way it works is that we use the authoritative data from the HR app and put it back on your on premises AD. We use the Azure AD provision in service to basically run those cycles and put that account on premises in your Active Directory. And then, maybe you need to update certain attributes to that account on premises. We will use Azure AD Connect to synchronize those changes to Azure AD, and from Azure AD back to the cloud our application for those specific attributes that maybe you filled out after that account was on premises. So the authoritative data is your cloud HR application, and we provision that to on prem AD. So this is perfect for the joiner, mover, leaver scenarios where you may have somebody that is switching roles joining a new department. And that happens on the cloud HR application and all the changes will happen automatically fulfilling the cycle for synchronizing all of the way back to the cloud HR. Azure AD on premises app provisioning. So if you have on premises applications that require provisioning, like the user doesn't exist on those apps, but they live in Azure AD. If they are based on own on SQL or LDAP applications, we have a solution for you as well. It's called ECMA host, or it stands for Extensible Connectivity Management Agent. And for those that are familiar with MIM, this is not a new concept. However, this particular solution doesn't require you to deploy MIM. You can still do it if you have some more complex scenarios. But this one doesn't require it. And the way it works, once you deploy the provisioning agent and the ECMA host on premises, what you do is connect your target apps. If they are SQL based or LDAP apps, we will give you the connectors to install on the ECMA host. Once you do that, the rest of the process is actually done in the Azure AD portal. You will manage the scope of the users. What attributes are you going to change in the Azure portal. And you will map them using our scheme capabilities, which is the open standard or system for cross-domain identity management. Once a user falls into the scope of the provisioning, we will use our Azure provisioning service to put that user back into the ECMA host connector. And ECMA host will just basically put that user and provision it into those on premises SQL or LDAP-based applications. If you have applications already on premises that they support scheme protocols, these things, actually, it's easier for that so-- for those particular scenarios. So let's take a look at how do we do this, or how do we actually map the solutions that I'm talking to you about? On the user provisioning space, if you look at this diagram right now, what we will have will be a typical organization that has an on premises provisioning system, maybe MIM, or Microsoft Identity Management, with an on prem HR application. So the way it works, somebody joins the organization and the company. And that on premises provisioning system will take care of provisioning that through either on premises web applications, maybe you already have some form of cloud HR that provisions there, third party SAS apps, and then, Active Directory, that, of course, will synchronize those identities to Azure AD for Office 365 and all of our other Microsoft services. And we still see the partners and vendor supplies in areas where maybe you still doing that for them. You manage those identities because you're required to do so. We also have solutions for that that we call B2B, or guest access into Azure AD. So we will talk about that in a moment. How do we make Azure AD to be the center and the new control plane of this? And before I forget, you may also have some scenarios about disconnected forests, which is maybe those Active Directory forests that started in your organization as part of a merge or an acquisition, right? You don't have them. They don't have any presence in Azure AD or identities in Azure AD because you don't want to deal with the connectivity between your Azure AD connect server and trusts and all of the other things that you may require. We do have a solution as well. So the way we do it is we put Azure AD in the middle, like the control plane. With this, we can take advantage of the things that I just mentioned, right? We will use the cloud HR application to provision that into Azure AD and back to on premises. You can take advantage of the external identities capabilities in trade or guest accounts for your partners and vendors and suppliers. Of course, Azure AD will be the main identity provider for the Microsoft services and the third party SAS apps as well like, SAP, Oracle, AWS, ServiceNow, and all of those. With the ECMA connector that I talked to you about, you can then now provision applications or users in your on premises applications if they are LDAP or SQL-based from Azure AD. And at the same time, we do the disconnected forests through cloud provisioning, which is a lightweight agent that doesn't require the same rules. You manage all of the rules and provisioning methods and rules from the Azure AD portal. So it's lightweight, so you can put that user presence for those disconnected forests in Azure AD. And on top of that, all of the other things that we offer in Azure AD, like the governance capabilities, like I say, access reviews, just in time access, or PIM, to all of those apps, right? Because Azure AD is a control plane for all of these different things. And if we talk about the Group Writeback as well you can do that today and provision those groups that are cloud managed to your on premises needs. All right, so that was for the userspace. Let's talk about applications. For applications, we'd like to offer some of our plans on aka.ms/migrateapps. And what we do is we give you a four phase approach. And the first, of course, will be Discover in Scope, which is basically find all of the applications and their current IDP. The scope all of those applications that are ready to be migrated. Find those quick wins and document and put catalogs on the IDPs for those applications, what type of provisioning they use, and all of the different information that you can collect about them. The next step is classify them. So prioritize those apps. And I'm going to show you in a slide how you could better prioritize them and categorize them. The third phase is migration and testing. We acknowledge this is probably the phase that takes the longest time because it's the actual phase where you're going to start migrating those applications. But we do have recommendations about that, like integrate those SAS apps that we already have in the Azure AD gallery. And then, start discovering those that can be actually migrated, even if we don't have them in the gallery. The last step will be manage and gain insight about those apps. So manage the end user experience. So start doing attestation for those. Start doing governance capabilities for those applications. Talking about the categorization, we will offer what we call the three axes approach, which is define the business criticality for those apps, the usage of the apps, and the expected lifespan. So in this particular example, if you have an application that is business critical or mission critical and their usage is definitely high, that will be your highest priority application. Something that is low in the business criticality but is still long in aspect of lifespan, that will be kind of like the second priority apps. And the lowest priority apps, of course, will become when you have a usage low for those applications and maybe they're ready to be retired. So anything in between, we recommend to actually just discuss it and classify it accordingly. One other tool that we can give you to help with the categorization and see what are those quick wins and what are the things that you can migrate today. If you have AD FS on premises, we recommend you to start looking into what applications can you migrate today to Azure AD and have a plan for the rest of them. So one of the things that we offer is Azure AD Connect Health for the AD FS. It's not a new tool. You may have heard about it. We have it for your Azure AD connect server to show you the health of the synchronization. We also have some agents for your on premises domain controllers if you want to see the health of your domain controllers. This one for AD FS not only show you the health of your AD FS farm, we will also tell you and give you a readiness report with the usage and insights capabilities. So we will show you the application activity, how many users are accessing that application, with a readiness report that will tell you what is the migration status for that. So you can be probably closer than you think to migrate those applications already. We will compare what type of roles you have, what configuration you have on premises AD FS, and see if that's available already in Azure AD so you can load those apps. The next step that you do, enable password hash sync. So we can start authenticating users in the cloud through a feature that we call staged rollout. So you can select a pilot group of users, put them in stage rollout, and those users will authenticate directly in Azure AD if you already enable password hash sync and they won't go to AD FS to authenticate. And that will give you a testing capabilities, if you will, for those users. So they can start getting familiar with how the Azure AD authentication works before you migrate the whole domain and do the whole cut for the domain. Once you do that, then you can move-- what we discussed, partners, vendors, and supplies with external identities authenticated against Azure AD directly. You move your applications, Workday, ServiceNow, Salesforce, your line of business applications, anything that supports modern authentication that you can migrate to Azure AD directly and take advantage of the passwordless credentials capabilities that we have out there. Once you see what you have in the picture right here, then you're ready to just take AD FS out of the equation. So reduce your attack surface is basically your main message. For AD FS, you at least need to have four servers, right? For redundancy, two AD FS farm-- server farms, two web application proxies. You have to maintain them, you have to update them, you have to pay for them. And like I said, the attack surface is just, basically, there. You're taking the risk for exposing those, especially your application proxies, that are just sitting on a DMZ. Let us handle that. So remove AD FS, reduce your attack surface, and put all of those applications in Azure AD. And you can find a lot of recommendations and all of the plans that I've been talking about in aka.ms/migrateapps. You may be asking right now, yeah, what about my legacy protocols? My legacy authentication protocols that I have for my on premises apps. We do have options for those as well. It depends on if you require remote access for those, we have an Azure AD application proxy, which is an agent that you put on premises that literally proxies traffic to Azure AD so you can put and publish those on premises applications that are maybe header-based or Kerberos applications from on premises as if they were an Azure AD application or an application in the cloud. With these, you gain the insights of the signing logs, audit logs, conditional access rules. Do MFA on those apps, which is one of the most important things. And your app will still be on premises, even if only supports Kerberos and all of these legacy protocols. If you require more than just remote access, we recommend to work with some of our partners. We call it the secure high rate access partnership program where we work with Silverfort, Akamai, and some other partners that you can install and, basically, deploy a network and application delivery controller for all of the other protocols like SSH or Radius or NTLM. So we work with them to make sure that you take advantage of the Azure AD capabilities while you need to maintain and you're not ready to retire those maybe legacy protocols. The recommendation will-- we always try to move in and modernize them. But if you can't, we do have some of those options as well. Let's switch to the devices now. And for these, I'm just going to discuss the type of registrations and presence that we have for those devices in Azure AD. You may be aware that we have a hybrid Azure AD join, which is the most popular one. That means that is a device that is joined to an on premises domain and an Azure AD tenant. We do this with a one time configuration that you can do it through a PowerShell command or through Azure AD connect, which is easier. Once you do that, all of the domain join machines on premises will be automatically show up in Azure AD as hybrid join. And every other machine or all of the other machines that you start joining to that domain will automatically also show up as hybrid join. The next one is Azure AD Join. Azure AD Join, it's machines that are only joined to Azure AD. But a lot of misconception around this is to think that this is only the scenario for those machines that are for cloud only users or cloud only applications. That's not the case. We also have capabilities to access some of on premises resources with Azure AD join machines. The simplification of deployment for Azure AD Joins is actually easier than hybrid joins, right? But you need to be aware that, to manage those, we don't have the GPO advantages. We will have MDMs of your choice or Intune or mobile device management solutions that-- for co-management, those Azure AD machines. The next one is Azure AD Registered for two different scenarios, which is the work on devices and personal devices. For both, we recommend to either do your own MDM, like Endpoint Manager or Intune, and with mobile application management. So for work on devices, this will be the category of those maybe iPads or mobile devices-- mobile phones that are not Windows, right? And you still need to manage and maybe your end users will require access to your applications. And the personal devices will be-- all the personal devices that you require them or the end users will require some sort of access to your applications. Maybe you don't need to manage the entire phone, but you still need half the capabilities of doing some sort of mobile application management where you can control the access on the application without really managing the whole device. So what am I saying this? Because it is important to understand the type of trust that we have for these devices, right? Because this will help you on all of those phishing attacks that we were discussing before through conditional access policies. Because you can say, I don't give you access to this application unless you're coming from a device that I trust. How do you trust it? Well, it could be trusted by the virtue of a domain join device, or trusted if the device complies with the MDM policies that you may have, or if it complies with the mobile application management policies. If it's compliant, then I trust it. Those policies or rules can be, basically, as basic and simple as maybe just require a passcode for those devices. Or they may actually need something more complex like a specific operating system level or something like that. And we, of course, need to talk about Windows Hello For Business, and especially if we discuss devices and passwordless solutions, right? One of the main things that I want to highlight for this particular slide-- because you may be aware of all of the different deployments for Windows Hello For Business is not a new solution. And before this year, we only had Key Trust and Cert Trust. Both things had their own requirements. And the main one of them is that it requires an Active Directory certificate services, or PKI. With Cloud Trust, which is our new deployment model, you don't require certificate services on premises or PKI. The authentication itself is all driven by Azure AD. So you can take advantage of-- and of the benefits of doing Windows Hello For Business without the requirements from the other two. We also provide some migration approach that you can follow and take advantage of this. So you don't require all of those other on premises. And the best of both worlds for Cloud Trust is that you will have two tokens, a TGT, or a Ticket Granting Ticket, that will give you access to your on premises resources, and a PRT, or a Primary Refresh Token, which is a token that we use in Azure AD to access cloud resources. And all of those, without even typing a single character of a password. All through Windows Hello For Business. And I want to thank you for joining my session. That was the last slide. And I'm looking forward for any questions after the session. Thank you so much. [MUSIC PLAYING]