Welcome to Langenile

[email protected]
Contact Us

Category Archives: Password hash synchronization

  1. Home / 
  2. Archive by category "Password hash synchronization"
Jul 31, 2024
Managing and monitoring Microsoft 365 license allocations– Planning and Managing Azure AD Identities

If identity is the foundation for security in the Microsoft 365 platform, licensing is the entitlement engine that is used to grant identities access to the tools and applications.

Every Microsoft 365 service is tied to a license—whether that’s individual product licenses for Exchange Online or SharePoint Online or bundled offerings such as Microsoft 365 E3, which include multiple services.

In Microsoft terminology, there are a number of key terms to be aware of:

  • Licensing plans: In broad terms, a licensing plan is any purchased licensing item. For example, standalone Exchange Online P2 and Microsoft 365 E3 are both examples of licensing plans.
  • Services: Also known as service plans, these are the individual services that exist inside of a licensing plan. For example, Exchange Online P2 has a single Exchange Online P2 service plan, while Microsoft 365 E3 has an Exchange Online service plan, a Microsoft 365 Apps service plan, a SharePoint Online service plan, and so on.
  • Licenses: This is the actual number of individual license plans of a particular type that you have purchased. For example, If you have 5 subscriptions to Exchange Online P2 and 5 subscriptions to Microsoft 365 E3, you have 10 licenses (or 5 each of Exchange Online P2 and Microsoft 365 E3). Licenses are frequently mapped 1:1 with users or service principals, though some users may have more than one license plan associated with them.
  • SkuPartNumber: When reviewing licensing in PowerShell, the SkuPartNumber is the keyword that maps to a licensing plan. For example, Office 365 E3 is represented by the ENTERPRISEPACK SkuPartNumber.
  • AccountSkuId: The AccountSkuId is the combination of your tenant name (such as Contoso) and the SkuPartNumber or licensing plan. For example, the Office 365 E3 licensing plan belonging to the contoso.onmicrosoft.com tenant has an AccountSkuId of contoso:ENTERPRISEPACK.
  • ConsumedUnits: Consumed units represent the number of items in a licensing plan that you have assigned to users. For example, if you have assigned a Microsoft 365 E3 licensing plan to three users, you have three ConsumedUnits of the Microsoft 365 E3 licensing plan. If reviewing licensing from the Azure AD portal, this field is sometimes displayed as Assigned.
  • ActiveUnits: Number of units that you have purchased for a particular licensing plan. If reviewing licensing from the Azure AD portal, this field is sometimes displayed as Total.
  • WarningUnits: Number of units that you haven’t renewed purchasing for in a particular license plan. These units will be expired after the 30-day grace period. If reviewing licensing in the Azure AD portal, this field is also sometimes displayed as Expiring soon.

You can easily view purchased licensing plan details in the Microsoft 365 admin center under Billing | Licenses:

Figure 5.22 – License details in the Microsoft 365 admin center

You can assign licenses in many ways:

  • Through the Licenses page in the Microsoft 365 admin center (Microsoft 365 admin center | Billing | Licenses)
  • In the properties of a user on the Active users page in the Microsoft 365 admin center (Microsoft 365 admin center | Users | Active Users | User properties)
  • To users through the Licenses page in the Azure AD portal (Azure AD Portal | Azure AD | Licenses | Licensed users)
  • To users through the User properties page in the Azure AD portal (Azure AD Portal | Azure AD | Users | User properties)
  • To groups through group-based licensing (Azure AD Portal | Azure AD | Licenses | Licensed groups)
  • Through PowerShell cmdlets such as Set-MsolUserLicense

Each licensing method provides you with similar options for assigning license plans to users, including assigning multiple license plans or selectively enabling service plans inside an individual license plan.

For example, in the Microsoft 365 admin center, you can view and modify a user’s licenses on the Licenses and apps tab of their profile.

Figure 5.23 – User license management

As you can see in Figure 5.23, the user has the Office 365 E5 licensing plan enabled as well as individual services such as Common Data Service, Common Data Service for Teams, and Customer Lockbox, while the Azure Rights Management service plan for this licensing plan is disabled.

More Details
Apr 4, 2024
Creating and managing groups– Planning and Managing Azure AD Identities

Groups are directory objects used to perform operations, grant rights or permissions, or communicate with one or more users collectively. In Azure Active Directory, there are several kinds of groups:

  • Security groups – This type of group is typically used for granting permissions to resources, either on-premises or in Azure AD.
  • Distribution lists or distribution groups – These groups are usually used for sending emails to multiple recipients, though they can also sometimes be used to restrict the scope of rules or for filtering purposes in Azure AD, SharePoint Online, and Exchange Online.
  • Microsoft 365 groups – Formerly called modern groups (and sometimes still referred to as unified groups), Microsoft 365 groups are an all-purpose group type that can be used as a security group for assigning permissions to resources or a distribution group for handling email. Microsoft 365 groups are special objects that are connected to SharePoint Online sites and form the basis for teams in Microsoft Teams. In addition, each Microsoft 365 group is connected to an Exchange group mailbox, allowing it to store persistent messages (such as email or, in the case of Microsoft Teams, channel conversations). Microsoft 365 groups are only available in Azure AD. There is no on-premises corollary.

Each of these groups has certain capabilities and benefits. One or more types of groups may be appropriate for a specific task. In Azure Active Directory, security groups can be mail-enabled (or not), while distribution groups and Microsoft 365 groups are always mail-enabled.

In Azure Active Directory, any of the cloud-based groups can be configured to have their membership be assigned or dynamic. With assigned membership, an administrator is responsible for periodically updating group members. Dynamic groups are built by creating an object query that is periodically used to add or remove members. For example, you may choose to create a dynamic group called Sales that automatically includes users whose job title or department value is set to Sales. Groups in Azure AD can contain users, contacts, devices, and other groups. Groups can be converted between assigned and dynamic membership.

When working with groups, there are several important things to remember:

  • An Azure AD tenant can have groups that are synchronized from on-premises environments as well as cloud-only groups.
  • Both security and distribution groups can be synchronized from on-premises environments. The exception to this is on-premises dynamic distribution groups. Because they can be based on queries that aren’t possible in Azure AD, they are not synchronized. You will have to either recreate the dynamic groups in Azure AD using supported query parameters or modify the on-premises group to be based on assigned membership.
  • Microsoft 365 groups, due to their unique construction, cannot be a member of a group nor can they have other groups of any type nested in them.
  • Microsoft 365 groups are the only type of object with a cloud source of authority that can be written back on-premises.

With all of that said, let’s take a look at administering groups in Azure AD!

More Details
Dec 7, 2023
Creating and managing users– Planning and Managing Azure AD Identities

As you’ve seen throughout this book, identity is the foundation of Azure AD. Without it, people wouldn’t be able to access services. Azure AD identity covers a broad range of objects, including cloud-only accounts, synchronized accounts, and external accounts (as well as groups, devices, and contacts).

Each of these types of objects has a purpose, and one is generally more suited to a business case than another.

In this chapter, we’re going to look at the following topics, as they relate to the MS-100 exam objectives:

  • Creating and managing users
  • Creating and managing guest users
  • Creating and managing groups
  • Managing and monitoring Microsoft 365 license allocations
  • Performing bulk user management

By the end of this chapter, you should be comfortable articulating the differences between the different kinds of objects and familiar with methods for provisioning and managing them.

Let’s get started!

Creating and managing users

Creating and managing users is central to administrating an information system—whether that system is an application on a small network, an enterprise-scale directory, or a cloud service hosted by a SaaS provider. In any instance, identities are used by people, applications, and devices to authenticate and perform activities.

In the context of Azure AD, there are three core types of identity:

  • Cloud-based users
  • Synchronized users
  • Guest users

When planning out identity scenarios, it’s important to understand the benefits, features, drawbacks, or capabilities associated with each type of identity and authentication scheme—including ease of provisioning, integration with existing directory or security products, requirements for on-premises infrastructure, and network availability.

In this section, we’ll learn about managing each of these kinds of users.

More Details
Sep 22, 2023
Installing the provisioning agent– Implementing and Managing Identity Synchronization with Azure AD

To begin installing Azure AD Connect cloud sync, follow these steps:

  1. Log on to a server where you wish to install the Azure AD Connect cloud sync provisioning agent.
  2. Navigate to the Azure portal (https://portal.azure.com) and select Active Directory | Azure AD Connect.

Figure 4.25 – Azure AD Connect in the Azure portal

  1. From the navigation menu, select Cloud sync.
  2. Under Monitor, select Agents.
  3. Select Download on-premises agent.

Figure 4.26 – Download on-premises agent for Azure AD Connect cloud sync

  1. On the Azure AD Provisioning Agent flyout, select Accept terms & download to begin the download.
  2. Open the AADConnectProvisioningAgentSetup.exe file to begin the installation.
  3. Agree to the licensing terms and click Install to deploy the Microsoft Azure AD Connect provisioning package.
  4. After the software installation is complete, the configuration wizard will launch. Click Next on the splash page to begin the configuration.
  5. On the Select Extension page, choose the HR-driven provisioning (Workday and SuccessFactors) / Azure AD Connect Cloud Sync radio button and click Next.

Figure 4.27 – The Azure AD Connect cloud sync Select Extension page

  1. On the Connect Azure AD page, click Authenticate to sign in to Azure AD.
  2. On the Configure Service Account page, select the Create gMSA radio button to instruct the setup process to provision a new gMSA in the format of DOMAIN\provAgentgMSA. Enter either a Domain Administrator or Enterprise Administrator credential and click Next.

Figure 4.28 – Configuring an Azure AD Connect cloud sync service account
CREATING A CUSTOM GMSA
You can also create a gMSA if desired. The custom service account will need to be delegated permissions to read all properties on all User, inetOrgPerson, computer, device, Group, foreignSecurityPrincipal, and Contact objects, as well as being able to create and delete user objects. For more information, see https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account.

  1. On the Connect Active Directory page, click Add Directory and provide the domain credentials to add the directory to the configuration. When finished, click Next.

Figure 4.29 – Adding a directory to Azure AD Connect cloud sync

  1. Review the details on the Agent configuration page and click Confirm to deploy the provisioning agent. When finished, click Exit.

After the agent has been deployed, you will need to continue in the Azure AD portal.

More Details
May 22, 2023
Preparing for identity synchronization by using IdFix– Implementing and Managing Identity Synchronization with Azure AD

IdFix is Microsoft’s tool for detecting common issues with on-premises AD identity data. While it doesn’t fix all errors, it is able to identify and remediate data formatting errors so that objects have valid data to synchronize.
IdFix supports the following features:
• Transaction rollback
• Verbose logging
• Exporting data to the CSV and LDF formats for offline review and editing
To get started with the tool, follow these steps:

  1. Navigate to https://aka.ms/idfix.
  2. Scroll to the bottom of the page and click Next.
  3. Review the prerequisites for the tool. Scroll to the bottom of the page and click Next.
  4. Click setup.exe to download the file and start the installation.
  5. After the installation wizard starts, click Install.
  6. Acknowledge the IdFix privacy statement by clicking OK.
  7. IdFix, by default, targets the entire directory. You can select Settings (the gear icon) to change the options for IdFix. You can edit the filter to scope to certain object types. You can also select the search base to specify a starting point for IdFix to begin its query. After modifying any settings, click OK.

Figure 4.1 – The IdFix settings

  1. Click Query to connect to AD and begin the analysis.
    SCHEMA WARNING
    If you receive a schema warning, such as the one in Figure 4.2, you can click Yes to proceed or click No to return to the IdFix tool. The schema warning is generally presented when attributes are present in the AD schema but have not been marked for replication (usually because Exchange Server has not been installed or replication hasn’t completed successfully in your organization for an extended period of time). If you receive this error, you should check to ensure that you have at least run the Exchange Server setup with the /PrepareSchema and /PrepareAD switches and have validated that AD replication is working correctly.

Figure 4.2 – The IdFix schema warning
After IdFix has analyzed the environment, results are returned to the data grid, shown in Figure 4.3. The DISTINGUISHEDNAME column shows the full path to the object in question, while the ATTRIBUTE column shows the attribute or property impacted. The ERROR column shows what type of error was encountered (such as an invalid character or duplicate object value). The VALUE column shows the existing value and the UPDATE column shows any suggested value.

Figure 4.3 – The IdFix data grid
After you have investigated an object, you can choose to accept the suggested value in the UPDATE column (if one exists). You can also choose to either enter or edit a new value in the UPDATE column.
Once you’re done investigating or updating an object, you can use the dropdown in the ACTION column to mark an object:
• Selecting EDIT indicates that you want to configure the object attribute with the value in the UPDATE column
• Selecting COMPLETE indicates that you want to leave the object as is
• Selecting REMOVE instructs IdFix to clear the offending attribute
In addition, you can select Accept to accept any suggested values in the UPDATE column. Choosing this option will configure all objects with a value in the UPDATE column to EDIT, indicating that the changes are ready to be processed.
Once you have configured an action for each object, select Apply to instruct IdFix to make the changes.

  1. IdFix will process the changes. Transactions are written to a log that can be imported and used to roll back any mistakes.
  2. Once you have ensured that your on-premises directory data is ready to synchronize to Azure AD, you can deploy and configure one of the Azure AD Connect synchronization products.
More Details
Mar 15, 2023
Configuring Azure AD Connect filters– Implementing and Managing Identity Synchronization with Azure AD

If you need to exclude objects from Azure AD Connect’s synchronization scope, you can do so through a number of different methods:
• Domain and organizational unit-based filtering
• Group-based filtering
• Attribute-based filtering
Let’s quickly examine these.


Domain and organizational unit-based filtering
With this method, you can deselect large portions of your directory by modifying the list of domains or organizational units that are selected for synchronization. While there are several ways to do this, the easiest way is through the Azure AD Connect setup and configuration tool:

  1. To launch the Azure AD Connect configuration tool, double-click the Azure AD Connect icon on the desktop of the server where Azure AD Connect is installed. After it launches, click Configure.
  2. On the Additional tasks page, select Customize synchronization options and then click Next.

Figure 4.8 – The Additional tasks page

  1. On the Connect to Azure AD page, enter a credential with either the Global Administrator or Hybrid Identity Administrator role and click Next.
  2. On the Connect your directories page, click Next.
  3. On the Domain and OU filtering page, select the Sync selected domains and OUs radio button, and then select or clear objects to include or exclude from synchronization.

Figure 4.9 – The Azure AD Connect Domain and OU filtering page

  1. Click Next.
  2. On the Optional features page, click Next.
  3. On the Ready to configure page, click Configure.
    After synchronization completes, verify that only objects from in-scope organizational units or domains are present in Azure AD.
    Group-based filtering
    Azure AD Connect only supports the configuration of group-based filtering if you choose to customize the Azure AD Connect setup. It is not available if you perform an express installation.
    That being said, if you’ve chosen a custom installation, you can choose to limit the synchronization scope to a single group. On the Filter users and devices page of the configuration wizard, select the Synchronize selected radio button and then enter the name or distinguished name (DN) of a group that contains the users and devices to be synchronized.

Figure 4.10 – The Filter users and devices page
With group-based filtering, only direct members of the group are synchronized. Users, groups, contacts, or devices nested inside other groups are not resolved or synchronized.
Microsoft recommends group-based filtering for piloting purposes only.

More Details
Feb 7, 2023
Attribute-based filtering– Implementing and Managing Identity Synchronization with Azure AD

Another way to filter objects to Azure AD is through the use of an attribute filter. This advanced method requires creating a custom synchronization rule in the Azure AD Connect Synchronization Rules Editor.
To create an attribute-based filtering rule, select an attribute that isn’t currently being used by your organization for another purpose. You can use this attribute as a scoping filter to exclude objects.
The following procedure can be used to create a simple filtering rule:

  1. On the server running Azure AD Connect, launch the Synchronization Rules Editor.
  2. Under Direction, select Inbound, and then click Add new rule.

Figure 4.11 – Synchronization Rules Editor

  1. Provide a name and a description for the rule.
  2. Under Connected System, select the object that represents your on-premises Active Directory forest.
  3. Under Connected System Object Type, select user.
  4. Under Metaverse Object Type, select person.
  5. Under Link Type, select Join.
  6. In the Precedence text field, enter an unused number (such as 50). Click Next.

Figure 4.12 – Creating a new inbound synchronization rule

  1. On the Scoping filter page, click Add group and then click Add clause.
  2. Under Attribute, select extensionAttribute1 (or whichever unused attribute you have selected).
  3. Under Operator, select EQUAL.
  4. In the Value text field, enter NOSYNC and then click Next.

Figure 4.13 – Configuring a scoping filter for extensionAttribute1

  1. On the Join rules page, click Next without adding any parameters.
  2. On the Transformations page, click Add transformation.
  3. Under FlowType, select Constant.
  4. Under Target Attribute, select cloudFiltered.
  5. In the Source text field, enter the value True. Click Add transformation.

Figure 4.14 – Adding a transformation for the cloudFiltered attribute

  1. Acknowledge the warning that a full import will be required by clicking OK.

Figure 4.15 – The warning for full import and synchronization
After modifying a synchronization rule, a full import and full synchronization is required. You don’t have to perform any special steps, however; Azure AD Connect is aware of the update and will automatically perform the necessary full imports and synchronizations.
Monitoring synchronization by using Azure AD Connect Health
Azure AD Connect Health is a premium feature of the Azure AD license. Azure AD Connect Health has separate agent features for Azure AD Connect, Azure AD Health for Directory Services, and Azure AD Health for Active Directory Federation Services (AD FS).

More Details
Sep 15, 2022
AD FS– Planning Identity Synchronization

If you are using the Azure AD Connect installation wizard to configure AD FS, there are additional requirements that must be met:

  • If you are using Azure AD Connect to configure AD FS, the federation and web application proxy (WAP) servers must already have TLS/SSL certificates installed and the servers must be accessible via WinRM.
  • AD FS server hosts must be Windows Server 2012 R2 or later.
  • The AD FS farm servers must be domain-joined. The AD FS web application proxy servers must not be domain-joined.
  • AD FS also has specific name resolution requirements. The internal DNS domain must use A records for the federation server farm (external DNS can use A records or CNAME records).

Further information

While it is not covered by the MS-100 exam, per se, it’s important to note that externally, DNS will point to the AD FS WAP servers using the name deployed on the SSL/TLS certificate (such as sts.contoso.com or adfs.contoso.com). However, the AD FS WAP servers need to resolve the AD FS farm name to the internal farm servers, not to themselves. This is frequently accomplished by configuring a host’s file on the AD FS WAP servers.

Accounts and security

To successfully configure Azure AD Connect, you must have access to privileged accounts:

  • You must have either an Azure AD Global Administrator or Hybrid Identity Administrator account to configure synchronization. These credentials are used to create a service account in Azure AD that’s used to provision and synchronize objects.
  • If you use the Express setup option or upgrade from the legacy DirSync product, the installation account must be a member of Enterprise Admins in the local Active Directory.
  • If you are configuring Azure AD Connect with a service account, the account must have the following permissions delegated:
    • Write permissions to Active Directory (if any hybrid writeback features are enabled, such as Exchange hybrid writeback, password writeback, group writeback, or device writeback)
    • If password hash synchronization is deployed, the service account must be delegated the special permissions called Replicating Directory Changes and Replicating Directory Changes All to read the password data from Active Directory

Connectivity

Azure AD Connect needs to be able to communicate with both on-premises directories as well as Azure AD:

  • Azure AD Connect must be able to resolve DNS for both internet and intranet locations.
  • Azure AD Connect must be able to communicate with the root domain of all configured forests.
  • If your network requires a proxy to connect to the internet, you must update the .NET Framework’s machine.config file with the appropriate proxy server address and port. If your proxy server requires authentication, you must use a custom installation and specify a domain-member service account.

If your environment meets the minimum requirements for deploying Azure AD Connect, you can download the components and begin the installation. You can download the most recent version of Azure AD Connect from https://aka.ms/aadconnect.

More Details
Mar 22, 2022
Understanding Azure AD Connect with multi-tenant scenarios– Planning Identity Synchronization

In more complex scenarios, you can synchronize objects from one (or more) on-premises forests to one (or more) Azure AD tenants, as shown in Figure 3.5:

Figure 3.5 – Synchronization to multiple Azure AD tenants

This is relatively new, from a supported topologies perspective. This is a potential solution if you need to support multiple tenants in your organization. Microsoft, however, recommends trying to consolidate to a single tenant where possible.

There are some important caveats with this design, primarily the following:

  • You need to deploy an Azure AD Connect server to communicate with each tenant.
  • While the same object can be in scope for multiple Azure AD Connect instances, Exchange hybrid writeback, device writeback, and group writeback are only supported by one tenant. If you configure those writeback features for more than one tenant and have the same object in scope for those Azure AD Connect servers, you will enter a race condition where the object will get continuously updated errantly.
  • You can have Password Write-back enabled on multiple tenants for the same user object.
  • Hybrid Azure AD Join and Seamless SSO can only be configured with one tenant.
  • You cannot configure the same custom domain in more than one tenant.

As previously mentioned, Microsoft recommends trying to consolidate into a single tenant to get the best experience. And, regardless of the Azure AD Connect topologies selected, it is not supported to deploy more than one active Azure AD Connect server to a single tenant. If you need to connect multiple on-premises systems to a single Azure AD tenant, you can achieve that with a single Azure AD Connect server.

Identifying object source requirements

Since the purpose of Azure AD Connect is synchronizing user, group, contact, and device objects to Azure AD, you’ll need to make sure your objects meet the minimum requirements.

Microsoft has guidance surrounding preparing user objects for synchronization. Some attributes (specifically those that are used to identify the user throughout the system) must be unique throughout the organization. For example, you cannot have two users that have the same userPrincipalName value.

As you can see, very few attributes are required for an object to synchronize. Each attribute that is synchronized does have some core requirements around formatting, including length and allowed characters. Several attributes (such as mailNickname, userPrincipalName, mail, sAMAccountName, and proxyAddresses) must contain unique values – that is, no other object in the directory of any type can share those values.

More Details
Jan 24, 2022
Understanding Azure AD Connect with multi-forest scenarios– Planning Identity Synchronization

Azure AD Connect also supports several multi-forest scenarios.

In a basic multi-forest scenario, you have one or more on-premises Active Directory forests all contributing unique objects to a single Azure AD tenant.

You might need to support a configuration like this if you have multiple business units within your organization with their own autonomous Active Directory environments that all want to share a single Microsoft 365 environment:

Figure 3.2 – Multiple Active Directory forests contributing to a single Azure AD tenant

There are other organizational scenarios where you may need to support multiple forests. Large organizations sometimes configure multiple directories in what’s called a resource forest configuration.

In this structure, application resources (such as Microsoft Exchange) are configured in one forest (called the resource forest). A trust relationship is established with another forest containing accounts (intuitively called the account forest). The trust allows objects from the account forest to access applications and services in the resource forest. The user objects in the account forests are linked to a corresponding security principal account in the resource forest, thereby granting access to the resource forest. See Figure 3.3:

Figure 3.3 – Account forests and a resource forest contributing to a single Azure AD tenant

Another common multi-forest scenario involves two or more on-premises organizations that utilize some other form of directory synchronization (such as MIM GALSync) to ensure that each organization’s Exchange environment contains a full list of the objects in their partner’s directories. This example is shown in Figure 3.4:

Figure 3.4 – Multiple forests with on-premises synchronization to a single Azure AD tenant

In this scenario, users have a single primary account that they use for accessing services and resources. That account is represented in the partner organization’s directory as a contact object.

Multiple forests, multiple users, multiple options

Multi-forest configurations can be quite tricky. During the Azure AD Connect setup, you’ll be prompted to select how your users are represented across the organization. You have two core options: Users are represented only once across all directories and User identities exist across multiple directories.

The first option is straightforward – it’s a scenario where users only have one object.

The second option, though, has two additional choices: to match using Mail attribute or ObjectSID and msExchangeMasterAccountSID attributes.

In an on-premises directory synchronization scenario (which Microsoft refers to as full mesh), users may be represented by several objects, such as a security principal (user account), as well as a contact object in other forests. For this scenario, you would choose to match users based on the mail attribute.

In a resource forest configuration, users typically have more than one identity: an identity in the account forest that is linked to a corresponding account in the resource forest. Typically, the account in the resource forest is set to disabled. In an Exchange resource forest scenario, the objects are linked by copying the ObjectSID value from the user object in the account forest to the msExchangeMasterAccountSID value of the user object in the resource forest. With an Exchange resource forest design, you’ll want to select the ObjectSID and msExchangeMasterAccountSID attributes option.

More Details