Configuring the Azure Portal Settings, Microsoft Azure, Migration Tables

Azure AD Connect- Understanding Azure Active Directory

Azure AD Connect (see Figure 10.6) lets you integrate your Azure AD with your Windows

Server AD or another directory on your network. One of the nice advantages of Azure AD

Connect is that you can download and install Azure AD Connect by using the Azure Active Directory Connect Download link. As you can see in Figure 10.6, Azure AD and my domain have already been connected by using seamless single sign- on.

Azure AD Connect helps you integrate your on- premises Active Directory with Azure AD. This allows your users to be more productive by giving those users access to both cloud and on- premises resources by using a common user account for accessing both networks. By using Azure AD Connect, users and organizations can take advantage of the following features:

       Users can have a common hybrid identity that allows them to access onsite or cloud- based services that use both Windows Server Active Directory and Azure AD.

       You can provide conditional access based on your device and user identity, network location, application resource, and multifactor authentication.

FIGURE 10.6 Azure AD Connect section

       Users can use this common identity in Azure AD, Microsoft 365, Intune, SaaS apps, and third- party applications.

       Developers can create applications that use the common identity model, thus integrating applications into onsite Active Directory or cloud-b ased Azure applications.

To use Azure AD Connect, your onsite network must be using Windows Server 2008 or higher.

Use the Azure AD Connect section to set up how your users will seamlessly pass between both networks. You can set up seamless connections by using a Federation server (including AD Federation Server), seamless single sign- on, or pass- through authentication.

Custom Domain Names

The Custom Domain Names section allows you to add and verify new domain names (see Figure 10.7). When you first build your Azure subscription, your new Azure AD tenant comes with an initial domain name (e.g., willpanek.onmicrosoft.com).

You can’t change or delete the initial domain name that is created but you do have the ability to add your organization’s domain names to the list of supported names. Adding custom domain names allows you to create usernames that are familiar to your users, such as wpanek@willpanek.com.

FIGURE 10.7 Custom Domain Names section

After you register your custom domain name, you can make sure it’s valid in Azure AD. As you can see in Figure 10.7, JohnDoe.com has not been verified. You can verify a custom domain name by clicking the domain name to open a screen where you can verify the custom domain name.

After creating a DNS TXT or MX record, you can click the Verify button to have Azure verify the custom domain name. These DNS records must be created either on your web server’s DNS server (ISP or hosting company) or on your onsite DNS server if you are hosting your own website. This step ensures that your company owns the custom name that you are trying to register.

Mobility (MDM and MAM)

One feature that many organizations have started to implement is the ability for their employees to bring in their own devices (Bring Your Own Device [BYOD]) to work.

Also, many organizations have started issuing devices such as tablets to their employees, and many companies do not mind if you use those devices for personal use. To address this, Microsoft has implemented mobility into their Azure AD networks. Click the Device Settings link to connect devices (either personal or corporate) to your corporate Azure AD network.

Once these devices are connected to Azure, you can control them by using Microsoft Intune and Microsoft Intune Enrollment utilities (as shown in Figure 10.8). As of this writing, Microsoft has begun using Microsoft Endpoint Manager for Intune. But as you can see, Intune is still being shown as one of the utilities.

FIGURE 10.8 Mobility (MDM and MAM) screen

Password Reset

The Password Reset section allows you to specify whether you want to enable self- service password resets (SSPRs). If you decide to enable this feature, users will be able to reset their own passwords or unlock their accounts.

You can allow all accounts to use SSPRs (see Figure 10.9), or you can choose certain groups that will have the ability to use SSPRs.

In the Password Reset section, you can also choose to use authentication methods. Authentication methods allow an organization to verify that the user is who they say they are. Methods for this include verification by mobile app notification, mobile app code, email, mobile phone, office phone, or security question. You can choose between using a single verification or using multiple verifications.

You can also require registrations when a user logs into Azure AD and set up password resets so that a user is notified if their password changes. You can also be notified when administrator passwords are reset. Also in the Password Reset section, you can choose to enable a custom help desk link (under the Customization link) for users.

FIGURE 10.9 Setting the self-s ervice password reset

You can specify that password changes be replicated back (password writeback) to an Active Directory network by configuring on- premises integration. Password writeback, when enabled in Azure AD Connect and SSPR, allows users who change or reset their password in Azure to have those passwords updated back to the on- premises Active Directory domain environment as well.

Finally, you can perform auditing and troubleshooting from the Password Reset section.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *