Welcome to Langenile

[email protected]
Contact Us

Yearly Archives: 2024

  1. Home / 
  2. 2024
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
Jun 11, 2024
The Azure AD portal– Planning and Managing Azure AD Identities

The Azure AD portal is the other interface that is used to create and manage groups. As with the user creation options, the Azure AD portal provides a slimmed-down feel without the wizard experience of the Microsoft 365 admin center.
To create and manage groups in the Azure AD portal, follow these steps:

  1. Navigate to the Azure AD portal (https://aad.portal.azure.com) and select Groups.
  2. With the default All groups navigation item selected, click New group.

Figure 5.15 – Azure AD all groups

  1. On the New Group page, specify either Security or Microsoft 365 for Group type, enter a name in the Group name field, and optionally, provide a description in the Group description field. If you’ve selected Microsoft 365 as the group type, you will also be required to enter Group email address. The security groups created in the Azure portal are not mail-enabled.

Figure 5.16 – New Group page

  1. You can choose whether or not Azure AD security roles can be assigned to the group. If you select Yes, then the group must have an assigned membership.
  2. Under Membership type, you can select Assigned, Dynamic User, or Dynamic Device (if it is a security group). If it is a Microsoft 365 group, you can choose from Assigned or Dynamic user. Security groups with assigned membership can have all supported object types, but dynamic groups are constrained to a single object type.

Figure 5.17 – Creating a new dynamic group

  1. If you select a group with an Assigned membership type, you can add Owners and Members. If you select a group with either of the dynamic membership types, you must add a dynamic query, as shown in Figure 5.17.
  2. To configure a dynamic query, click Add dynamic query.
  3. On the Configure Rules tab of the Dynamic membership rules page, configure an expression that represents the users or devices you want to have included in the group. For example, to create a user membership rule that looks for the value Engineering in either the jobTitle or department user attributes, select the appropriate property, select Equals or Contains under Operator, and then enter the value Engineering.

Figure 5.18 – Creating a dynamic membership rule

  1. You can view the construction of the rule in the Rule syntax output box. If necessary, you can edit the rule free-form to create a more complex rule type.
  2. You can select the Validate Rules (Preview) tab and add users you think should be in-scope or out-of-scope to verify that the rule is working correctly. Click Add users and then select users from the picker. In this example, Aamir E Cupp and Abagael R Rauch were selected. Aamir’s job title is Manager and his department is Sales, so the expected result is that he is not included in the group. Abagael’s job title is Scientist but her department is Engineering. Based on the way the query is constructed, she is included in the group. See Figure 5.19.

Figure 5.19 – Validating the dynamic membership rule

  1. When you have finished editing the rule, click Save.
  2. Click Create to create the new group.
    Using the Azure AD portal, you can also update the membership rules for existing groups or change a group’s membership from Assigned to Dynamic by selecting the group and then editing the details in its Properties menu, as shown in Figure 5.20.

Figure 5.20 – Editing a group
If you change a group from Assigned to Dynamic membership, you’ll need to create a query. It’s important to note, though, that you cannot change a group’s type (for example, from Security to Microsoft 365) or whether a group is eligible for Azure AD role assignment—those options can only be selected when creating a group.
NOTE
Microsoft Entra is the new umbrella product that covers Microsoft identity management and governance. Currently, the Microsoft Entra admin center (https://entra.microsoft.com) maps to specific blades or tabs inside the Azure portal and doesn’t really display anything new. Over the next year or two, anticipate that Microsoft will begin emphasizing the Entra admin center experience over the Azure portal experience for identity management tasks.

Figure 5.21 – Entra admin center

More Details
May 21, 2024
The Microsoft 365 admin center– Planning and Managing Azure AD Identities

For most Azure AD group administration use cases, you’ll probably use the Microsoft 365 admin center. To configure groups in the Microsoft 365 admin center, follow these steps:

  1. Navigate to the Microsoft 365 admin center (https://admin.microsoft.com). Expand Teams & groups and then select Active teams & groups.

Figure 5.12 – Active teams and groups

  1. Click Add a group.
  2. On the Group type page, select the type of group you wish to create. With the exception of Security groups, all group types will require essentially the same information (non-mail-enabled security groups do not allow you to add owners or members in the workflow, though they can be added later). If you select a Microsoft 365 group as your group type, you’ll also have the option at the end of the wizard to create a Microsoft Teams team from the group.

Figure 5.13 – Choose a group type

  1. On the Basics page, enter a name and an optional description for the group, and then click Next.
  2. On the Owners page, click Assign owners to assign at least a single owner. Microsoft recommends having at least two owners (in case one leaves the organization or is absent for a period of time). The owner cannot be an external guest. Click Next when finished.
  3. On the Members page, click Add members. This is an optional step. Click Next to proceed.
  4. On the Settings page, configure settings for the group and then click Next:
    • For distribution groups and mail-enabled security groups, this includes an email address.
    • For Microsoft 365 and security groups, this includes assigning Azure AD roles. The option does not appear for mail-enabled security groups, though it can be added later.
    • For distribution groups, this includes the ability for users outside the org to email the groups (Microsoft 365 groups must have this setting configured manually in the Exchange properties for the group object afterward).
    • For Microsoft 365 groups, you can also configure privacy settings (either Public or Private). Public groups can be browsed and joined by anyone while private groups require an owner to add additional members.
    • Also for Microsoft 365 groups, you can choose to convert the group into a team, though users must have a Teams license assigned to access the group.
  5. On the Finish page, review the settings and click Create group.
    After the group has been created, you can modify its settings in either the Microsoft 365 admin center or Azure AD portal, as shown in Figure 5.14:

Figure 5.14 – Modifying the settings of a Microsoft 365 group
As you can see in Figure 5.14, Microsoft 365 groups have some additional properties (such as determining whether to send copies of emails received by the group mailbox to individual team mailboxes or associate them with a sensitivity label).

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
Mar 24, 2024
MORE ABOUT GUESTS– Planning and Managing Azure AD Identities

While guests are typically part of an invitation process, with the new Azure AD cross-tenant synchronization feature (currently in preview), you can automate the provisioning of guest objects between trusted tenants similar to how you would with your own directory synchronization. Microsoft recommends this feature only for Azure AD tenants that belong to the same organization. For more information on the new cross-tenant sync feature, see https://learn.microsoft.com/en-us/azure/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview.

While guest users can be viewed and edited in the Microsoft 365 admin center, they can only be provisioned through the Azure AD portal. Clicking Add a guest user in the Microsoft 365 admin center transfers you over to the Azure AD portal to complete the invitation process.

Figure 5.7 – Guest users administration in Microsoft 365 admin center

After either logging in to the Azure AD portal or being redirected there by the Microsoft 365 admin, center you can begin the process of inviting guests. To invite a new guest user from the Azure AD portal, click New user and then select Invite external user.

Figure 5.8 – Inviting a new guest user

The user interface elements for inviting a guest user are very similar to those for creating a new cloud user. The main differences are in the selection of the template and, in the case of a guest user, you have the opportunity to supply message content (which will be included as part of the email invitation sent). See Figure 5.9.

Figure 5.9 – Configuring the guest invitation

Once a guest has been invited, take note of the properties:

  • The guest identity’s User principal name value is formatted as emailalias_domain.com#EXT#@tenantname.onmicrosoft.com
  • User type is set to Guest
  • Initially, the Identities property on the Overview tab is set to tenant.onmicrosoft.com
  • The invitation state is set to PendingAcceptance

See Figure 5.10 for reference.

Figure 5.10 – Newly invited guest user

Upon receiving and accepting the invitation, the recipient is prompted to read and accept certain terms and grant permissions:

  • Receive profile data including name, email address, and photo
  • Collect and log activity including logins, data that has been accessed, and content associated with apps and resources in the inviting tenant
  • Use profile and activity data by making it available to other apps inside the organization
  • Administer the guest user account

Figure 5.11 – Invitation redemption consent

After consenting, the invitation state in the Azure portal is updated from PendingAcceptance to Accepted. Additionally, depending on what identity source the guest user is authenticated against, the Identity property could be updated to one of several possible values:

  • External Azure AD: An Azure AD identity from another organization
  • Microsoft Account: An MSA account ID associated with Hotmail, Outlook.com, Xbox, LiveID, or other Microsoft consumer properties
  • Google.com: A user identity associated with Google’s consumer products (such as Gmail) or a Google Workspace offering
  • Facebook.com: A user identity authenticated by the Facebook service
  • {issuer URI}: Another SAML/WS-Fed-based identity provider

Guest users can be assigned licenses, granted access to apps, and delegated administrative roles inside the inviter’s tenant.

More Details
Feb 17, 2024
Creating and managing synchronized users– Planning and Managing Azure AD Identities

As you saw in Chapter 3 and Chapter 4, the process of identity synchronization replicates your on-premises identity in Azure AD. Whether you are using Azure AD Connect sync, Azure AD Connect Cloud sync, or a third-party product, the process is largely the same: an on-premises agent or service connects to both Active Directory and Azure Active Directory, reads the objects from Active Directory and recreates a corresponding object in Azure AD.

During this provisioning process, the on-premises and cloud objects are linked through a unique, immutable attribute, which stays the same throughout the life cycle of the object.

Exam tip

Originally, an on-premises object was linked to its corresponding cloud object by converting the on-premise object’s objectGUID attribute value into a base64 string, and stored in the cloud object’s ImmutableID attribute. Modern versions of Azure AD Connect use the ms-DS-ConsistencyGuid attribute instead. The ms-DS-ConsistencyGuid value is blank by default; after Azure AD Connect is configured to use ms-DS-ConsistencyGuid as the source anchor during setup, an object’s objectGUID value is copied to the ms-DS-ConsistencyGuid attribute. Since a new objectGUID attribute is generated every time an object is created, a static value such as ms-DS-ConsistencyGuid helps organizations maintain the relationship between identities through the Active Directory domain migrations that happen as part of business mergers, acquisitions, and divestitures.

After Azure AD Connect has been deployed, you can create a new synchronized identity by creating a new user in the on-premises Active Directory. See Figure 5.5.

Figure 5.5 – Creating a new user through Active Directory Users and Computers

After synchronization completes, the new user account is ready to sign into the service. From the Microsoft 365 admin center, it’s simple to visually distinguish between cloud and synchronized accounts. Figure 5.6 shows both a cloud user and a synchronized user.

Figure 5.6 – Displaying cloud and synchronized users

Under the Sync status column, a cloud user is represented by a cloud icon, while a synchronized user is represented by a notebook icon.

Creating and managing guest users

Guest users are special accounts that have limited rights in the Azure AD environment. In most contexts, guest users are synonymous with Azure Business-to-Business (B2B) identities, so that’s the reference point that we’ll use to discuss them.

Azure B2B guest accounts are generally created through an invitation process, such as inviting someone from an external organization to participate in a Microsoft SharePoint site, collaborate on a document in OneDrive, or access files in a Teams channel. When an invitation is sent, an Azure identity object is created in the inviting organization’s tenant and an invitation email is sent to the external recipient. After the recipient clicks on the link in the invitation email, the recipient is directed to an Azure sign-in flow, which prompts them to enter credentials corresponding to their own identity source (whether that’s another Azure AD or Microsoft 365 tenant, a consumer account (such as Microsoft, Google, or Facebook), or another third-party issuer that uses a SAML/WS-Fed-based identity provider. The process of the recipient accepting the invitation is called redemption.

More Details
Jan 23, 2024
Creating and managing cloud users– Planning and Managing Azure AD Identities

From an Azure AD perspective, cloud users are the easiest type of object to understand and manage. When you create an Azure AD or Microsoft 365 tenant, one of the first things you set up is your administrator user identity (in the form of [email protected]). This identity is stored in the Azure AD directory partition for your Microsoft 365 tenant. When we talk about Azure AD cloud users, we’re talking about users whose primary source of identity is in Azure AD.

Exam tip

Cloud users can be assigned to any domain that is verified in the Microsoft 365 tenant with a single caveat—the domain must be in managed mode. If a domain has been federated (such as with AD FS or PingFederate), users can only be assigned that domain when they are provisioned in the on-premises system.

The initial domain (or tenant domain) will always be a cloud-only domain since Azure AD will always be the source of authority for it. When you add domains to a tenant, the domains are initially configured as managed—that is, Azure AD is used to manage the identity store.

One benefit of configuring cloud-only users is that there is no dependency on any other infrastructure or identity service. For many small organizations, cloud-only identity is the perfect solution because it requires no hardware or software investment other than a Microsoft 365 subscription. Correspondingly, a drawback of cloud-only users is the lack of integration with on-premises directory solutions.

Exam tip

As a best practice, Microsoft recommends maintaining at least one cloud-only account in case you lose access to any on-premises environment.

The easiest way to provision cloud users is through the Microsoft 365 admin center (https://admin.microsoft.com). To configure a user, expand Users, select Active Users, and then click Add a user. The wizard, shown in Figure 5.1, will prompt you to configure an account.

Figure 5.1 – Adding a new cloud user

You can configure the name properties for a user as well as assign them any licenses and a location through the Add a user wizard’s workflow, as shown in Figure 5.2:

Figure 5.2 – Assign product licenses page

On the Optional settings page, you can also configure additional properties such as security roles, job title and department, addresses, and phone numbers, as shown in Figure 5.3.

Figure 5.3 – Add a user profile information

You can also add users through the Azure AD portal (https://aad.portal.azure.com). The Azure AD portal is arranged much differently from the Microsoft 365 admin center, due largely to the number of different types of resources and services that can be managed there. There are several differences in managing users and objects between the two interfaces; the Microsoft 365 admin center is a much more menu-driven experience, prompting administrators to configure common options and features inside the provisioning workflow.

Once you’ve logged in to the Azure AD portal, select Users and then select New user. The interface, shown in Figure 5.4, offers the opportunity to populate similar fields to those in the admin center.

Figure 5.4 – Creating a user through the Azure AD portal

Most organizations that are using Azure from a cloud-only identity perspective will likely provision objects inside the Microsoft 365 admin center.

More Details