 G'day Windows Server Hybrid Administrators. Welcome to this Learn Training Module. The title of this module is Implement Hybrid Identity with Windows Server. In this module, you'll learn about the following topics, understanding identity integration, synchronizing on-premises Active Directory domain services, leverage single sign-on, deploy as your ADDS and join Windows Server VMs to as your ADDS domains. This module functions as preparation for AZ800 Objective Domain 1, deploy and manage ADDS in on-premises and cloud environments. You can follow along with the contents of this module on Microsoft Learn at the address shown on the screen and listed in the video description. The Windows Server Hybrid Administrator Associate Certification is Microsoft's successor to the Windows Server MCSE. Certification has always been important for Windows Server Administrators and the Windows Server Hybrid Administrator Associate brings the old MCSE into the 2020s. To earn the certification, you need to pass two exams, AZ800 and AZ801. Being successful on the exam requires that you not only understand how to do common administrative tasks such as manage Active Directory, storage, networking, security, disaster recovery, monitoring and virtualization on-premises, just as you would have had to for the last few years of Windows Server. But also know how you can integrate and extend Windows Server with all of the relevant services that are available in Azure. As your AD is not Active Directory Domain Services ADDS in the cloud, instead it's an entirely new directory service designed for cloud-based and web-based applications which shares some functionalities with ADDS. For example, the Contoso IT10 can implement Azure AD and synchronize its on-premises identities to the cloud. These steps would enable Contoso staff to use SSO to access both on-premises resources and those related resources in there as your tenant. The IT team can use Azure AD to increase employee productivity, streamline IT processes and improve security for adopting various cloud services. Contoso employees can access online applications by using a single user account. Contoso can also perform central user management by using well-known Windows PowerShell command loads. It's also worth noting that because Azure AD is highly scalable and highly available by design, the IT team won't have to maintain related infrastructure or worry about disaster recovery. As a component of Azure, Azure AD can support multi-factor authentication as part of an overall access strategy for cloud services, thus providing an additional layer of security, role-based access control, self-service password, group management and device registration provide enterprise identity management solutions. Azure AD also provides advanced identity protection in addition to enhanced reporting and alerting that can help you recognize threats more efficiently. Azure AD is part of the platform as a service offering and operates as a Microsoft Managed Directory service in the cloud. It's not a part of the core infrastructure that customers own and manage, nor is it an infrastructure as a service offering. While this implies that you have less control over its implementation, it also means that you don't have to dedicate resources to its deployment or maintenance. With Azure AD, you also have access to a set of features that are not natively available in Active Directory domain services such as support for multi-factor authentication, identity protection and self-service password reset. You can use Azure AD to provide more secure access to cloud-based resources for organizations and individuals by configuring access to applications, configuring SSI to cloud-based SaaS applications, managing users and groups, provisioning users, enabling federation between organizations, providing an identity management solution, identifying a regular sign-in activity, configuring multi-factor authentication, extending existing on-premises Active Directory implementations to Azure AD, configuring application proxy for cloud and local applications, and configuring conditional access for users and devices. Unlike on-premises Active Directory, Azure AD is multi-tenant by design and is implemented specifically to ensure isolation between its individual directory instances. The term tenant represents an individual Azure AD instance. Within and Azure subscription, you can create multiple Azure AD tenants. Having multiple Azure AD tenants might be convenient if you want to test Azure AD functionality in one tenant without affecting the others. At any given time and Azure subscription must be associated with one and only one Azure AD tenant. However, you can associate the same Azure AD tenant with multiple Azure subscriptions. Each Azure AD tenant is assigned the default DNS domain name that consists of a unique prefix. The prefix is derived from the name of the Microsoft account you use to create an Azure subscription or provided explicitly when creating an Azure AD tenant and is followed by the on-Microsoft.com suffix. Adding at least one custom domain name to the same as your AD tenant is possible and common. This name utilizes the DNS domain namespace that the corresponding company or organization owns. For example, Contoso.com. The Azure AD tenant serves as the security boundary and a container for Azure AD objects such as users, groups and applications. Although Azure AD has many similarities to on-premises Active Directory, there are also many differences. It's important to realize that using Azure AD is not the same as deploying an AD-DS domain controller on an Azure VM and then adding it to your on-premises domain. When comparing Azure AD with AD-DS, it's important to note the Azure AD characteristics that differ from AD-DS. Azure AD is primarily an identity solution and it is designed for internet-based applications by using HTTP, port AD and HTTPS port 443 communications. Azure AD is a multi-tenant directory service. Azure AD users and groups are created in a flight structure and there are no organizational units or group policy objects. You cannot query Azure AD by using LDAP. Instead, Azure AD uses the REST API over HTTP and HTTPS. Azure AD doesn't use Kerberos authentication. Instead, it uses HTTP and HTTPS protocols such as Security Assertion Markup Language, SAML, Web Services Federation, AWS Federation and OpenID Connect for Authentication. It also uses Open Authorization, OAuth for Authorization. Azure AD includes Federation Services and many third-party services are federated with and trust Azure AD. Small organizations that don't have an on-premises directory such as AD-DS can fully rely on Azure AD as an authentication and authorization service. However, the number of these organizations is still quite small, so most companies search for a way to integrate on-premises AD-DS with Azure AD. Microsoft offers cloud-scale identity and access management via Azure AD, which provides several options for integrating AD-DS with Azure. The Azure AD directory is not an extension of an on-premises directory. Rather, it's a copy that contains the same objects and identities. Changes made to these items on-premises are copied to Azure AD, but changes made in Azure AD are not replicated back to the on-premises domain. Note that you can also use Azure AD without using an on-premises directory. In this case, Azure AD acts as a primary source of all identity information rather than containing data replicated from an on-premises directory. Directory synchronization enables synchronization between on-premises active directory and Azure AD for users, groups and contacts. In its simplest form, you install a directory synchronization component on a server in your on-premises domain. You then provide an account with domain admin and enterprise admin access to on-premises AD-DS and another account with administrator access to Azure AD and let it run. User accounts, groups and contacts that you select from AD-DS are then replicated into Azure AD. Users can then use those accounts to sign into and access Azure services that rely on Azure AD for authentication. Unless you activate password synchronization, users will have a separate password from their on-premises environment to sign into an Azure resource. Even if you implement password sync, users are still prompted for their credentials when they access the Azure resource on domain join computers. The advantage with password sync is that to sign into the Azure resource, users can use the same username and password as their domain login. Don't confuse this with SSI. The behavior provided with password sync is called same signing. With Azure, the synchronization flow is one way from local AD-DS to Azure. However, with Azure AD premium features, some attributes replicate in the other direction. For example, you can configure Azure to write passwords back to an on-premises AD-DS and to groups and devices from Azure AD. If you don't want to synchronize your entire on-premises AD-DS, directory synchronization for Azure AD supports limited filtering and customization of attribute flow based on the following values, OU, domain, user attributes and applications. You can use Azure Active Directory Connect, Azure AD Connect to perform synchronization between on-premises AD-DS and Azure AD. Azure AD Connect is a wizard-based tool designed to enable connectivity between an on-premises identity infrastructure and Azure. Using the wizard, you can choose your topology and requirements and then the wizard deploys and configures all the required components for you. Depending on the requirements selected, this can include Azure Active Directory sync, Azure AD sync, exchange hybrid deployment, password change right back, ADFS and ADFS proxy servers or web application proxy, Azure AD PowerShell module. When you run Azure AD Connect, the following occurs, new users, groups and contact objects in on-premises AD-DS are added to Azure AD. However, licenses for cloud services such as Microsoft 365 are not automatically assigned to these objects. Attributes of existing users, groups or contact objects that are modified in on-premises AD-DS are modified in Azure AD. However, not all on-premises AD-DS attributes are synchronized to Azure AD. You can configure a set of attributes that synchronize to Azure AD by using synchronization manager component of Azure AD Connect. Existing users, groups and contact objects that are deleted from the on-premises AD-DS are deleted from Azure AD. Existing user objects that are disabled on-premises are disabled in Azure. However, licenses are not automatically unassigned. Azure AD requires that you have a single source of authority for every object. Therefore, it's important to understand that in an Azure AD Connect scenario, when you're running Active Directory synchronization, you'll master an object from within your on-premises AD-DS using tools such as Active Directory users and computers or Windows PowerShop. However, the source of authority is the on-premises AD-DS. After the first synchronization cycle is complete, the source of authority is transferred from the cloud to the on-premises AD-DS. All subsequent changes to cloud objects except for licensing are mastered from the on-premises AD-DS tools. The corresponding cloud objects are read-only and Azure AD administrators cannot edit cloud objects if the source of authority is on-premises AD-DS unless you implement some of the technologies that allow write back. To implement Azure AD Connect, you must have an account with required permissions assigned on both the local AD-DS and Azure AD. Installing and configuring Azure AD Connect requires the following accounts and Azure account with global administrator permission in the Azure Tenant such as an organizational account that is not the account that was used to set up the account itself. An on-premises account with Enterprise Administrator permissions in the on-premises AD-DS. In the Azure AD Connect wizard, you can choose to use an existing account for this purpose or let the wizard create an account for you. As your AD Connect uses an Azure Global Administrator account to provision and update objects when the Azure AD Connect configuration wizard is run, you should create a dedicated service account in Azure for directory synchronization to use because you cannot use the Azure Tenant Administrator account. This restriction is because the account that you used to set up Azure might not have a domain name suffix that matches the domain name. The account needs to be a member of the global administrator's role group. In the on-premises environment, the account that is used to install and configure Azure AD Connect must have the following commissions. Enterprise Administrator permissions in AD-DS. This permission is required to create the synchronization user account in Active Directory. Local Machine Administrator permissions. This permission is required to install the Azure AD Connect software. The account used to configure Azure AD Connect and run the configuration wizard must reside in the local machine AD-SyncAdmin's group. By default, the account used to install Azure AD Connect is automatically added to this group. The account used to install AD Connect is automatically added to the AD-SyncAdmin's group when you install a product. You must sign out and sign in again to use the synchronization service manager interface because the account will not pick up the group security identifier, SID, until the next time the account is used to sign in. The Enterprise Administrator account is only required when you install and configure Azure AD Connect, but its credential is not stored or saved by the configuration wizard. Therefore, you should create a special Azure AD Connect Administrator account for installing and configuring Azure AD Connect and assign this account to the Enterprise Administrator's group when Azure AD Connect is set up. However, this Azure AD Connect Administrator account should be removed from the Enterprise Administrator's group after Azure AD Connect setup is complete. You should not change the service account for Azure AD Connect after you install Azure AD Connect because Azure AD Connect always attempts to run using the account created during setup. If you change the account, Azure AD Connect stops running and the scheduled synchronizations no longer occur. Pre-deployment checks should include analyzing the on-premises environment for invalid characters in ADDS object attributes and for incorrect use of principal names, UPNs, performing domain email discovery and user counts, identifying domain functional levels and schema extensions, and identifying custom attributes in use, identifying proxy servers used for Microsoft Exchange or Skype for Business if you deploy as your AD Connect as a part of a Microsoft 365 deployment. Identifying Microsoft SharePoint domains if you deploy as your AD Connect as part of a Microsoft 365 deployment, evaluating client for symbol sign-on readiness, recording network port use, and DNS records related to Office 365 if you deploy as your AD Connect as part of Office 365 deployment. After you complete these checks, tier remediation tasks include removing duplicate proxy address and user principal name attributes, updating blank and invalid user principal name attributes and replacing with valid user principal name attributes, removing invalid characters in the following attributes, given name, surname, SN, SAM account name, display name, mail proxy addresses, mail nickname, and user principal UPNs that are used for SSR can contain letters, numbers, periods, dashes, and underscores. No other character types are allowed. If you're deploying Microsoft 365 and your deployment includes plans for SSO, you should ensure that UPN names meet this requirement before SSO is rolled out. Domains used for SSO and directory synchronization must be rootable, which means that you cannot use local domain names such as Contoso.local. After you have set up as your with an active directory tenant, you must complete the primary tasks to deploy directory synchronization using the following steps. Add your ADDS domain into Azure, verify the domain, and then set the domain as the primary domain. Download and install as your AD connect. Run the Azure AD connect configuration wizard. As an option, you can configure as your AD connect to synchronize specific OUs in the on-premises ADDS environment. Enable optional features such as password hash sync, password writeback, and exchange hybrid deployment. Run Azure AD connect and let it configure the environment for directory synchronization. Validate the synchronization results. After you set up as your AD connect and perform the initial synchronization, you can reconfigure synchronization options if needed. The Azure AD connect software installation includes several applications related to directory synchronization. When you run as your AD connect, you have the option to use express installation settings, which sets up directory synchronization with the most commonly used settings, or you can choose to customize setup options. If you choose to use custom installation, at the beginning of the setup, you can choose to use a custom SQL server instead of a local database. You can also choose to use an existing service account instead of the one created by the automatic setup process. In addition, you can specify custom sync groups by default. The administrators, operators, browse, and the password reset groups are created by Azure AD connect, but you can choose to use your own custom groups for this purpose. By default, Azure AD connect sets up password hash synchronization for the directory synchronization mode. If you choose custom installation, you can also choose the federation with ADFS option or pass through authentication. Alternatively, you can manually configure directory synchronization if you have a non-Microsoft federation server or another existing solution deployed. Customers, your AD connect installation also allows you to choose the way you identify your users. By default, setup presumes that your users are represented only once across all directories. However, if you have a scenario where user identities exist across multiple directories, you must choose the matching attribute. You can configure the user principal name attribute in the same window. This is the attribute that users use when they sign into Azure AD. The domains used for this purpose, also known as the UPN suffix, should be verified in Azure AD before synchronizing the user objects. In some cases, you might want to synchronize only a subset of your users from your local ADDS. Azure AD connect allows you to select a specific group of users that you want to synchronize to Azure AD. You should create this group before you run Azure AD connect. After you complete the setup, you can add and remove users from this group to maintain the list of user objects that should be present in Azure AD. You also can use OUs from your local ADDS as the scope for replication. In the final step, Azure AD connect lets you set up some optional features available in Azure AD premium. Azure AD pass through authentication helps ensure that services which rely on Azure AD always validate passwords against an on-premises ADDS instance. You can configure Azure AD pass through authentication by using Azure AD connect, which uses an on-premises agent that listens for external password validation requests. You can deploy this agent to one or more servers to provide high availability. It's not necessary to deploy this server to a perimeter network because all communication is outbound only. You should join a server that runs a pass through authentication agent to the ADDS domain where users are located. Before you deploy Azure AD pass through authentication, you should know which authentication scenarios are supported and which are not. You can use pass through authentication for the following authentication scenarios. Use assignings to all web browser based applications supported by Azure AD. Use assignings to office applications that support modern authentication. Use assignings to Microsoft Outlook clients by using legacy protocols such as exchange active sync, simple mount transfer protocol, SNTP, post office protocol, POP, and internet message access protocol IMAT. Use assignings to spite for business application that supports modern authentication, including online and hybrid topologies. As your AD domain joins for Windows 10 devices, app passwords for multi-factor authentication. Although pass through authentication supports most common authentication scenarios, there are still some scenarios in which you can't use this method. These scenarios include user signings to legacy office client applications excluding Outlook, user signings to Skype for business client applications without modern authentication, user signings to Windows PowerShell version 1.0, detection of users with leaked credentials, scenarios that require Azure AD DS. Azure AD DS requires tenants to have password hash synchronization enabled, so tenants that use only pass through authentication won't work in these scenarios. Scenarios that require Azure AD Connect Health. Pass through authentication is not integrated with Azure AD Connect Health. If you use the Apple Device Enrollment Program, Apple DAP, that uses the iOS setup assistant, then you can't use modern authentication as it isn't supported. It will fail to enroll Apple DAP devices into Intune for managed domains that use pass through authentication. Consider using the Intune company portal app as an alternative. Before you deploy pass through authentication, you should understand how it works and how this method of authentication differs from ADFS. Pass through authentication is not just a simpler form of ADFS authentication. Both methods use the on-premises infrastructure to authenticate users when accessing resources such as Microsoft 365 but not in the same way. Pass through authentication uses a component called authentication agent to authenticate users. Azure AD Connect installs the authentication agent during configuration. After installation, the authentication agent registers itself in your Microsoft 365 tenants Azure AD. During registration, Azure AD assigns the authentication agent a unique digital identity certificate. This certificate with a key pair enables secure communication with Azure AD. The registration procedure also binds the authentication agent to your Azure AD tenant. Note that authentication requests are not pushed to the authentication agent. Instead, during its initialization, the authentication agent connects to Azure AD over port 443, an HTTPS channel that is secured by using mutual authentication. After establishing the connection, Azure AD provides the authentication agent with access to the Azure service bus queue. From this queue, the authentication agent retrieves and manages password validation requests. Because of this, there is no inbound traffic, so it's not necessary to install the authentication agent in the perimeter network. Azure AD DS, which runs as part of the Azure AD premium tier, provides domain services such as correct policy management, domain joining, and Kerberos authentication to your Azure AD tenant. These services are fully compatible with on-premises AD DS, so you can use them without deploying and managing additional domain controllers in the cloud. Because Azure AD can integrate with your on-premises AD DS, when you implement Azure AD Connect, users can utilize organizational credentials in both on-premises AD DS and in Azure AD DS. Even if you don't have AD DS deployed locally, you can choose to use Azure AD DS as a cloud-only service. This enables you to have similar functionality of locally deployed AD DS without having to deploy a single domain controller on-premises or in the cloud. For example, Contoso IT staff can choose to create an Azure AD tenant and enable Azure AD DS and then deploy a virtual network, VNet between its on-premises resources and the Azure AD tenant. Contoso IT staff can enable Azure AD DS for this VNet so that all on-premises users and services can use domain services from Azure AD. Azure AD DS provides several benefits for organizations such as administrators not needing to manage, update, and monitor domain controllers. Administrators not needing to deploy and manage Active Directory replication. There's no need to have domain admins or enterprise admins grids for domains that Azure AD DS manages. If you choose to implement Azure AD DS, you must understand the services current limitations. These include only the base computer Active Directory object is supported. It's not possible to extend the schema for the Azure AD DS domain. The OU structure is flat and nested OUs are not currently supported. There is a built-in GPO which exists for computer and user accounts. It's not possible to target OUs with built-in GPOs. Additionally, you cannot use Windows Management Instrumentation, WMI, filters, or security group filtering. By using Azure AD DS, you can freely migrate applications that use LDAC in TLM or the Kerberos protocols from your on-premises infrastructure to the cloud. You can also use applications such as Microsoft SQL Server or SharePoint Server on VMs or deploy them in Azure IS. All this without needing domain controllers in the cloud or a VPN to local infrastructure. When implementing the Azure AD DS scenarios, the following deployment considerations apply. Azure AD DS managed domains use a single flat OU structure by default. All domain join VMs are in a single OU. If desired, you can create custom OUs. Azure AD DS uses a built-in GPO each for the users and computers containers. For additional control, you can create custom GPOs and target them to custom OUs. Azure AD DS supports the base Active Directory computer object schema. However, you can't extend the computer object schema. You can't change passwords directly in an Azure AD DS managed domain. End users can change the password either using Azure AD's self-service password change mechanism or against the on-premises directory. These changes are then automatically synchronized and available in the Azure AD DS managed domain. Also, make sure that any applications don't need to modify slash right to the old app directory. Old app write access to an Azure AD DS managed domain isn't supported. The application doesn't need a custom slash extended Active Directory schema. Schema extensions aren't supported in Azure AD DS. The applications use a username and password for authentication. Certificate or smart card based on authentication isn't supported by Azure AD DS. To implement, configure and use Azure AD DS, you must have an Azure AD tenant created on an Azure AD subscription. Additionally, to use Azure AD DS, you must have password hash synchronization deployed with Azure AD Connect. This is necessary because Azure AD DS provides NTLM and Kerberos authentication, so users credentials are required. When you enable Azure AD DS for your tenant, you have to select the DNS domain name that you will use for this service. You also need to select the domain that you will synchronize with your on-premises environment. You should not use an existing Azure or on-premises DNS domain namespace. You might need to create additional DNS records for other services in your environment or conditional DNS forwarders between existing DNS namespaces in your environment. During implementation, you must also select which type of forest to provision. A forest is a logical construct used by AD DS to group one or more domains. Next, you will need to choose the Azure location in which the managed domain should be created. If you choose a region that supports availability zones, here's your AD DS resources are distributed across zones for additional redundancy. You must also select a vNet to which you will connect this service because as your AD DS provides functionalities for on-premises resources, you must have a vNet between your local and Azure environments. During provisioning, as your AD DS creates two enterprise applications in your Azure AD tenant, these applications are needed to service your managed domain and therefore you should not delete these applications. The enterprise applications are domain controller services as your Active Directory domain controller services. After you deploy the Azure AD DS instance, you must configure the vNet to enable other connected VMs and applications to use the managed domain. To provide this connectivity, you must update the DNS server scenes for your vNet to point to the IP addresses associated with your Azure AD DS instance. To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NTLM and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS to your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials. After the usable password hashes are configured that are stored in the Azure AD DS managed domain. Note that if you delete the Azure AD DS managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Azure AD can't be reused if you later create in Azure AD DS managed domain. You must reconfigure the password hashes synchronization to store the password hashes again. Previously, domain join VMs or users won't be able to immediately authenticate as your AD needs to generate and store the password hashes in the new Azure AD DS managed domain. The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect. A cloud-only user account is an account that was created in your Azure AD directory using either the Azure portal or Azure AD PowerShell commandlets. These user accounts aren't synchronized from an on-premises directory. For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos authentication and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant you need to use Azure AD DS, which forces a password change on next signing or instruct cloud users to manually change their passwords. Before a user can reset their password, you must configure the Azure AD tenant for self-service password reset. Members of the ADDC administrators group are granted privileges on the Azure AD DS managed domain. As a result, these administrators can perform the following tasks on the domain. Configure the built-in GPO for the containers ADDC computers and ADDC users. In the managed domain, administer DNS on the managed domain. Create and administer customer use on the managed domain. Gain administrative access to computers joined to the managed domain. Because as your ADDS managed domain is locked down, you do not have privileges to complete certain administrative tasks on the domain. Some of the following examples are tasks you cannot perform. Extend the schema of the managed domain. Connect to domain controllers for the managed domain using remote desktop. Add domain controllers to the managed domain. Employee domain administrator or enterprise administrator privileges for the managed domain. After creating an Azure AD DS instance, you must join a computer to an Azure AD DS managed domain. This computer is connected to an Azure vNet that provides connectivity to the Azure AD DS managed domain. The process to join an Azure AD DS managed domain is the same as joining a regular on-premises AD DS domain. After the computer is joined, you must install the tools to manage the Azure AD DS instance. To securely connect to the computer, you might consider using an Azure Bastion host. With Azure Bastion, a managed host is deployed into your vNet and provides web-based remote desktop protocol RDP or secure shell SSH connections to VMs. No public IP addresses are required for the VMs and you don't need to open network security group rules for external remote traffic. You connect to VMs using the Azure portal. You manage Azure AD DS domains using the same administrative tools as on-premises AD DS environments such as the Active Directory Administrative Center or Active Directory PowerShell. You can install these tools as part of the remote server administration tools feature on Windows Server and client computers. Members of the ADDC Administrators group can then administer Azure AD DS managed domains remotely using these Active Directory Administrative tools from a computer that is joined to the managed domain. Common ADAC actions such as resetting your user account password or managing group membership are available. However, these actions only work for users and groups created directly in the Azure AD DS managed domain. Identity information only synchronizes from Azure AD to Azure AD DS. There's no right back from Azure AD DS to Azure AD. As a result, you can't change passwords or manage group membership for users synchronized from Azure AD and have those changes synchronized back. You can also use the Active Directory module for Windows PowerShell which is installed as part of the administrative tools to manage common actions in your Azure AD DS managed domain, to authenticate users on the managed domain as your AD DS needs password hashes in a format that's suitable for NTLM and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS to your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials. Once appropriately configured, the usable password hashes are stored in the Azure AD DS managed domain. If you delete this domain, any password hashes stored at that point are also deleted. Synchronized credential information in Azure AD can't be reused if you later create in Azure AD DS managed domain. As a result, you must reconfigure the password hash synchronization to store the password hashes again. Even then, previously domain join VMs or users won't be able to immediately authenticate because Azure AD needs to generate and store the password hashes in the new Azure AD DS managed domain. The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect. A cloud-only user account is an account that is created in Azure AD directory using either the Azure portal or Azure AD PowerShell command list. These user accounts aren't synchronized from an on-premises directory. For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for both Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. As a result, you should either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next signing or instruct cloud users to manually change their passwords. However, you might need to enable self-service password reset for cloud users to reset their password. In this module, you learned how to select an Azure AD integration model and plan for integration. Also, you learned to prepare and install AD DS synchronization in addition to implement single sign-on and enable Azure AD login for an Azure VM. Finally, you learned to plan and implement Azure AD DS. We publish content regularly on this channel related to Windows Server, Hybrid Cloud and Infrastructure Operations and the certifications related to these topics. We hope you found this video informative and look forward to seeing you in future videos.