How to get started with hybrid identity in Azure Active Directory

[MUSIC] Martin Coetzer: Hi, there. My name is Martin Coetzer. I’m a Program Manager in the Microsoft Identity team. I’m here to talk about how you can get started with Hybrid Identity in Azure Active Directory. The story of Hybrid Identity starts and ends with Azure AD Connect. In this video, I’m going to cover all the details of moving your identities to the cloud First, I’m going to set the scene with an overview of Azure AD Connect and its requirements. Next, I will cover all the sign-in methods that are available in Azure AD. After that, I will explain the details of identity synchronization, custom configuration options, and then I’ll leave you with some online resources to learn more Azure AD Connect is a tool that helps you to synchronize your identities that’s on-premises in your current AD environment to Azure AD in the cloud Azure AD in the cloud then provides single sign-on capabilities, multi-factor authentication, and even self-service capabilities for your end users. But Azure AD Connect is a tool that copies the users from your on-premises AD to the cloud. So, this is really your identity breach to get the same users into the cloud so that they can use the resources in them So, let’s cover the prerequisites of Azure AD Connect Azure AD Connect requires forest functional level 2003 or higher. This is typically not a problem for most organizations because Windows 2003 is no longer supported, and you may be running much later versions of Windows Server Keep in mind that this is a setting that you have to change manually on your domain controllers and a lot of customers don’t; they just upgrade their domain controllers, so this may be something that you need to do. We also only support writeable domain controllers. Read only domain controllers are not supported because we have to also write back to the domain controllers. And, obviously, we won’t be able to do that if it’s an auto DC. The server itself needs to run on Windows Server 2008 or later. And if you’re going to use the express settings, that machine needs to be domain joined as well. Password hash synchronization, which I will cover later in this presentation, requires Windows Service 2008 R2 Service Pack 1 or later. And then password writeback requires Windows Server 2008 with the latest Service Pack or later as well. The good news is with ports, you only need outbound connections. Azure AD Connect connects to Azure and it uses the default SSL ports that everybody uses. Port 5671 is required if you’re going to use the Azure AD Connect out features that gives Azure AD monitoring updates of your environment and tells you if your synchronization infrastructure is healthy In terms of licensing, Azure AD Connect is a free product that you can use to synchronize your identities. You can use it to synchronize for Office 365 so that you can have an Exchange hybrid deployment. But some features, for example writeback, requires Azure AD Premium. This is a special license that you have to buy. Group licensing as well as the connect health requires Azure AD Premium And then in some cases, you may need to have a full SQL Server version and we’ll cover that. But in that case, you’re also going to need a special licensing for that server This is our Azure AD Connect sizing recommendations Keep in mind that we are talking about objects. It’s not just users. So, objects includes users, groups, as well as devices. So, you have to add all of those objects together to determine the sizing of your Azure AD Connect server The big difference here is when you’ve got over 100,000 users, you have to get a dedicated SQL Server. We still recommend that you run SQL Server on the same server so that you don’t have any latency between the sync engine and the database. But in this case, you have to also look at maybe running something like solid state disks, so that you have really fast access on your databases If you have less than 100,000 users, you can use SQL Express, which is a free version of SQL that works with Azure AD Connect and it doesn’t require any additional licensing The easiest way to setup Azure AD Connect is with express This is for smaller organizations that don’t have multiple

forests, will use the SQL Express installation because they have less than 100,000 objects in their forest and they don’t want to do any custom installation options. It’s only four clicks. And so you basically just setup Azure AD Connect and you forget about it When you setup Azure AD Connect with customized settings, you have the option to setup multiple forest topologies, also specify a separate SQL Server. You also have the option of filtering users so that you don’t synchronize all your users You have the option of setting up a staging mode server, which is a standby server in order for you to failover to if your primary server goes down. You can also setup other sign-in methods, for example, federation or passthrough authentication, and then you can also enable the optional features like writeback and also synchronize custom attributes So, custom settings are really for more complex organizations that want to ensure that it also caters for the environment But smaller organizations will just go with the express settings So, let’s talk about sign-in methods. Azure AD Connect is the tool that configures the sign-in methods. This is the way your users will sign into Azure AD We support basically two types of sign-in methods that can be broadly put into these buckets. On the one side, we have cloud authentication and on the other side, we have federated authentication. With cloud authentication, it means that the authentication happens in the cloud in Azure AD. In here, we cater for cloud only users, which are not hybrid identities. This means that you’ve only created the users in the cloud. Or password hash sync, which means you’ve synchronized password hashes from your on-premises Active Directory or passthrough authentication, which uses that agent on-premises to verify passwords. On the other hand, you can use federated authentication. Federated authentication includes options like Microsoft AD FS, a tool that Microsoft supplies, as well as third party federation providers. In this case, if you have a third party federation provider and you want to integrate it with Azure AD, you can use federated authentication So, you may ask me, which one is the correct one for me? So, I’ve highlighted an article that you can go and look at It’s aka.ms/auth-options, which will actually give you a breakdown of each one of these—the benefits, why you should choose it, and what is the correct one for your organization In that article, we provide you with a decision tree that will ask the most important questions and then actually recommend a sign-in method for you, but I want to just explain each one of them So, the first one you have is password hash synchronization The way this works is the Azure AD Connect server reads the password hash from Active Directory. It then hashes that same password 1,000 times with a new hash and moves that or copies that to Azure AD. So when a user wants to sign-in, the Azure AD System will run the password that the user provides through the same algorithms and it will then verify if those hashes are the same. And if they are the same, the user will get access to the application But if they’re not the same, then that authentication request will fail. Keep in mind that there’s no dependency on Azure AD Connect when the user signs in. The hashes will be already in the cloud. Every time a user’s password is updated, Azure AD Connect polls the Active Directory and it will update Azure AD to make sure that the passwords are up to date It does this every two minutes Other features of users, for example, updating of the telephone numbers or other user attributes will only happen every 30 minutes. So if you disable a user, that can take up to 30 minutes before the user is disabled in Azure AD. We do recommend if you’re going to do a lot of disables and do some sort of bulk operation that you go ahead and force a synchronization cycle so that those users are immediately updated and disabled in Azure AD Another option that you can run with password hash sync is seamless single sign-on. The way this works is you actually give your users a seamless single sign-in experience when they are connected to your corporate network and they have access to your domain controllers. During setup, Azure

AD Connect will go and create a disabled computer object And then when the user signs in and you’ve given the computer access through a group policy to the sign-in page as a trusted website, that sign-in page will go and check if it can verify that the disabled computer account using Kerberos authentication. If that succeeds, it means the user was able to authenticate using his username and password, and this also happens seamlessly in the background The user is not prompted for a password So, this means that the user will have a great experience signing into Office 365 or other SaaS applications that uses Azure AD for authentication. If it doesn’t work, then it’s not going to be a big problem; it’s not going to throw an error for your users. It will just fall back to the normal mechanism of asking the user to specify a username and password. So, this is a great way to give your users a good experience Our next option is pass through authentication. Passthrough authentication works with running agents on-premises These agents make outbound connections to Azure AD, so you don’t need to open up any firewalls to the PTA agents And any password request will then be delivered to those agents via that open channel to the PTA agents. The PTA agents will then connect directly to the domain controllers to verify the username and password. So, this is a great way to make sure that any password policy that you’ve implemented on your on-premises Active Directory is always honored when the users sign in. So, for example, if you setup a user to only sign in during the day—they’re not allowed to sign in after hours—the PTA agent when the user authenticates will fail because the user’s not allowed to sign in a that time—after hours—and, therefore, the user will not gain access to their resources in the cloud. The PTA agent is a nice way of making sure that your users will always have that great experience of making sure that they pass with policy or the sign-in experience is similar to what they have in Active Directory Our last option for sign-in method is federation authentication A lot of customers already have AD FS servers or AD FS infrastructure or another type of federation system, and they may want to reuse that infrastructure. In this case, when a user signs into application, Azure AD will know that this user is a federated user and then will redirect the user to the federation system. In most cases, that will be a federation proxy form in your perimeter network, which will then authenticate the user and send the request back to the federation system on-premises that will do the validation in Active Directory Keep in mind that in this case, you need multiple servers to make sure that you have high availability, you need to open up firewalls for the old users to be able to connect to those servers. And you also need to have SSL certificates to make sure that those connections are secure Users that are on-premises will actually connect to the AD FS servers internally and they will use Windows integrated authentication for the authentication process, so they will also have a single sign-on experience This is a lot more complex installation and is needed for some customers that need to do very advanced features, like for example smart card authentication. Smart card authentication will be handled by the AD FS system and will allow users with smart cards to authentication if that is a requirement Most users or most organizations can actually just do password hash sync, and that is the easiest way and the best way, the less complex way for you to handle authentication in the cloud Now that we’ve covered authentication and sign-in methods, let’s talk about how are we going to implement our synchronization in Azure AD? So, the first thing that you need to do is you need to identify which users are you going to synchronize in your organization? Now, this is normally not a problem for most companies because you only have one user in your AD, which will be one user in Azure AD. And you just want to synchronize that one user. The lifetime of that user is dependent on the lifetime of the user in AD. So if you delete the user in AD, you want the user to be eventually deleted in Azure AD as well In some cases when users can move between forests, you have to think about this more clearly. And you want to make sure that you actually track the way the user is

copied form one forest to another forest, if you’re going to do a migration on-premises or something like that. So, you have a few options here. You can go and choose mail attribute. So if the mail attribute of the user is the same between different forests, it means that you want to track the user through mail attributes. You can also use MS objectGUID and so on to make sure that those users are tracked in that way So, the purpose of this is to make sure that you don’t accidentally delete users when the users disappear in your Azure AD. So, there’s a couple of options. Traditionally, we chose objectGUID. ObjectGUID was a way for you to make sure that the users are unique every time you create them. But the problem with objectGUID is when you clone a user to another forest, it will create a new objectGUID So, there’s no way of actually making sure that it’s still the same user Now, we actually use a different attribute called the ms-DS- ConsistencyGUID, which will allow you to track the user across different forests. The way this works is initially that attribute will be null. So, there will be no value in that attributed. And then when Azure AD connects to that user the first time, it will actually populate that GUID from the objectGUID and then when you clone the user from one forest to another forest, attribute’s already populated and it will know that it’s the same user and it’s not going to remove the user in Azure AD and create the new user in that case because it’s just the same user. You can also use other attributes, for example, employee IDs, but don’t use something like email addresses or user account names, user principal names because those can change. Sometimes people change their names or they change their last names and you want to make sure that any of those changes is not going to cause you to create the new user. You want those users to always be joined or matched during the lifetime of the property of the identity Another important decision is user principal name. If your organization created a domain called something like Contoso.local, you actually created a domain that you don’t own. Azure AD doesn’t allow you to have a domain that you didn’t own. So, in that case, you have to go and register a domain that you own with your local Active Directory so that the usernames are valid in the cloud as well. So, we recommend that you register a new suffix that you own and then populate each user with that username value that is a domain that you own. In this case, you have to go and tell your users that these are your new usernames. Maybe you make it the same as the email address and then it will be easier for them to remember the username when they sign into applications in the cloud. So, this is an important thing that you have to ensure works. Azure AD doesn’t support other accounts like, for example, same account name. This is a domain/username format. It doesn’t support it. You have to specify user principal name, which looks like an email address. So, make sure that you use that standard in your environment If you have multiple forests, you have to make sure that your company effectively using multiple forests as well We see a lot of different ways people have multiple forests In some companies, forests are detached. This means every user in every forest is a valid user. There’s no duplicates of users in different organizations. So, if there’s a Mary in one forest and a John in another forest, you want both of them to also exist in Azure AD. Some companies take that principle one step further and they actually implement a solution called GALSYNC, or global address list synchronization. What this does is it creates contacts for every user in other forest so that every forest does have a complete global address list of the organization The problem is you don’t want to go and create contacts for all of those contacts that exist in every forest because that will just duplicate all the users and it will be confusing because now there will be a Mary user mailbox. There will be a Mary contact object for every forest that you synchronize. So, in this case, you want to tell Azure AD to ignore or to actually match that user with the user in the other forest and only create one object in Azure AD

And this is something you can do with Azure AD Connect Another paradigm that we see is the account resource forest model. This is for companies that actually have dedicated forests for services. So, they may have a dedicated forest for Skype for Business or maybe even Lync, or they may have a dedicated forest for Exchange So the way that usually works is you have a disabled user in those resource forests and those disabled users points through to the account forest in other domains. And, again, you don’t want to create duplicate users in Azure AD. You want to tell Azure AD Connect to match those users and only create one user in Azure AD. And that way, it enables you to make sure that you have the lifecycle under control of those users So, let’s look at how Azure AD Connect addresses those requirements. The first option is to do no matching. This is where you have multiple forests and you don’t have any duplication between those multiple forests, so every user in every forest will go to Azure AD. The next option is to actually go and look at the mail attribute. So, this will look at the email address of the user. And this is typical where you have GALSYNC in place. So, we’ll see that this is the same user in another forest because the email address is the same. So, it’s not going to recreate that user. It will just match them and create one object in Azure AD Our next option is to look at the ObjectSID of the primary user and the MS Exchange master AccountSID or Exchange or the msRTCSP-OriginatorSid for Lync or Skype for Business users. So, those objects are referred to the original account forest and when Azure AD Connect sees that it’s the same SID in those attributes, it will again only create one object in Azure AD or one user You can also match on other objects, for example, sAMAccountName. This is typically in cases where you are doing a migration from one forest to another forest and you’re going to keep the same username, then you can match them as well. And in some cases, you may even want to match on other attributes as well. And this will make sure that you don’t duplicate users and handle your perfect multi-forest scenarios Our next topic is custom configuration settings. Custom configuration settings allows you to go and extend the functionality of Azure AD Connect or to do something different than it normally does with express settings So to look at our options, the first option that you have is to configure filtering. Filtering is a way of not replicating all your users in your forests to Azure AD. You may want to do this because you are currently running a POC or there might be some objects that you just don’t want in the cloud. Your options are, firstly, to do group based filtering How this works is you specify a group and only the members of that group will be synchronized to Azure AD We recommend that you only do this for test labs or POCs. It is actually quite taxing on the Azure AD Connect server to go and look at the group membership of all those users and to make sure that they are valid and they should be synchronized. So, this is something that you only want to do temporary while you’re doing a lab or you’re doing a POC A next option is to do domain based. This works well and maybe you have a configuration where there are certain domains that are dedicated to management of services or they are dedicated to other spots of the business and you don’t want those users in the cloud. And so, you would just unselect a domain and those users will not be synchronized to the cloud Another way of doing this is with organizational units. You can unselect certain organizational units. Maybe there’s some organizational units that contains administration accounts or service accounts, and you don’t want those accounts to be in the cloud because they’re only used in your on-premises services. So, you can actually just exclude them Keep in mind if you exclude any of these users, it will sometimes cause undesired effects. Users that use Exchange on-premises might see a larger global address than users in the cloud. And you don’t want to confuse your users. So, be careful on choosing how you’re going to filter users Another way of filtering is by using attribute filtering Attribute filtering is a way of selectively going and making

sure that some users are not synchronized. When you use this method, it’s sort of a fine grained method of excluding some users in OU. So if you want to exclude specific users, but you don’t want to move a user out of an OU, you can set up attribute based filtering and it will then filter that user or not synchronize that filter if it contains a specific attribute value. This is a nice way of doing that fine grained filtering required in some organizations Let’s look at some other optional features that are available in Azure AD Connect. Azure AD Connect allows you to also synchronize your Exchange hybrid configuration. This is a mechanism required for Exchange to live in a hybrid environment where you have some users on-premises and some users in the cloud and in Exchange hybrid, it tells Azure AD Connect to also synchronize the attribute that is required for Exchange hybrid components. Similarly, with Exchange mail public folders, you want to synchronize those or not as well if you’re running Exchange. Then you can also setup your Azure AD Connect to do application filtering as well. And you can also if you chose federation or passthrough authentication, enable password hash synchronization on top of federation and PTA. Now, you may ask why do I want to do that? I decided to do federation or I decided to do passthrough authentication, but you’re giving me another option to do password hash sync. The reason why we do this is to actually give you the ability to have a backup authentication method for your users. Say, for example, your federation system goes down. Something happened to your network or you are a victim of a cyber attack and it took down all your infrastructure. Now, your AD FS system is down and users cannot authenticate and basically your users cannot send emails. They cannot connect If you have password hash sync enabled on top of federation and this is where you do it, then you can actually switch over to password hash synchronization in that disaster moment and then allow users to authenticate using password hash synchronization and carry on working Just imagine it’s a disaster and you can use your corporate email and continue working. This could be a great benefit to your organization Another benefit of using password hash synchronization on top of federation or passthrough authentication is for leaked credential detection. This is a feature of Azure AD Premium P2 identity protection. And the way this works is we go ahead and find any leaked credentials on the internet If there’s a leaked credential on the internet that we acquired maybe through working with law enforcement companies, we can go and take those passwords and run them through the same algorithms and alert the administrator or the user that the password is leaked. We know that sometimes users use the same passwords with the corporate credentials as well as with other websites where they register for social media and so on. And if a site gets compromised, your company can also be compromised because users use the same password. So with leaked credential detection, we can actually prevent that and we could block users or force them to change their passwords next time they sign in if their passwords were found leaked We also allow you to do password writeback with optional features as well as group writeback and device writeback So, let’s talk about why would you want to do this. Password writeback is for companies that want to deploy the self-service password management capabilities of Azure AD. This is a great way of allowing your users to go and change their password if they forget their password by first verifying their identity through something like the Microsoft Authenticator app or through another email system. This is a great way of actually cancelling out all the social engineering that can happen, maybe if a hacker calls your help desk and they are really difficult with the help desk, they might convince your help desk to change a password for a user. But if you provide this mechanism, they’re not going to convince the system to change their password because it will verify the identity Group writeback is also required for if you want to synchronize Office 365 groups as modern groups to your on-premise

environment. So, this allows you to email those groups for any users that are still in the on-premises environment and using Exchange And then finally, device writeback is for users that do an Azure AD Join only and you want to synchronize those accounts back to your AD environment so that you can consider that device as part of an AD FS authentication process, so device writeback will do that You can also set up an Azure AD Connect server as a staging server. This allows you to have a backup server if your primary server goes down. In this way, if your primary server goes down, you can switch it over to your Azure AD Connect staging server and carry on synchronizing users to the cloud. Keep in mind that it’s not that important to make sure that your Azure AD Connect synchronization happens all the time, but if you want to make sure that your Azure AD Connect system doesn’t get out of date, then we recommend that you have a staging server. When you set up a staging server, you set it up with the same configuration that reads everything from your Active Directory system and it doesn’t synchronize this to the cloud. It’s just there waiting for that event to happen and then you enable the server and you can go ahead and make sure that those users stay synchronized So, once you’ve installed your Azure AD Connect system, you have this final option to say whether or not you want immediately synchronize. Some organizations want to make sure that everything is set up perfectly, the schedules are fine-tuned before they’re synchronized, or maybe they want to wait until that evening to start the synchronization process. So, this is your chance to say I want to synchronize immediately or if you untick this box, you can synchronize later When we setup Azure AD Connect, you have the option to actually go and make sure that users are not deleted immediately if it’s more than 500 deletes. You can disable this feature if you regularly delete more than 500 users in your Active Directory, but this is a safety mechanism to make sure that if maybe you move users from one organizational unit to another organizational unit, they are not part of your scope that you filter and those users disappear from the scope, that you don’t accidentally delete them from your environment. So, this is something that you may have to fine tune in your environment depending on how many users do you delete on a daily basis I mentioned in the beginning that Azure AD Connect updates every 30 minutes for users, so it only syncs changes, but it does it only every 30 minutes. Password changes are done every two minutes. But you can go and look at the schedule with PowerShell on the Azure AD Connect server with the command Get-ADSyncSchedule. You can also change this So if you have a large organization that have a lot of changes, maybe you want to change your delta sync to only happen once an hour. Or maybe you want to not run during certain times, so this is a way of making sure that your sync cycle is according to your requirements Azure AD Connect now also supports auto upgrade. If you’ve upgraded a previous server or if you’re still running an old version, you may not be doing auto upgrades. And so, I would recommend that you go and look at the Get-ADSyncAutoUpgrade status on your server to make sure that it’s actually running. This is making sure that your service is running the latest bit and it’s doing all the new functionality that are available to our customers You can also look in the application event log if that is happening on your system So, finally, I want to leave you with some resources. I mentioned that authentication method article. In there, we explain all the different authentication methods that are available to you that will help you choose the right authentication method. We also have an article that explains Azure AD Connect performance factors. This article goes into all the different details and all the configuration options in filtering and why certain settings are important and why certain settings will impact your sync cycle. So, you can use that article to go and make sure that you are optimized in your environment. If I’ve convinced you to move to password hash sync or to passthrough authentication, I actually do have whitepapers available that will take you through the process of moving AD FS to password hash sync, so check out those articles Then we also have the Azure AD blog, where we announce all our product features and we also announce all sorts of

other new tidbits and interesting information to our customers And please sign up for our webinars. You can reach out to that URL to find webinars Well, I hope you’ve enjoyed this session and you learned about hybrid identity and thank you for watching [MUSIC]