Active Directory Identity in Azure and access management operations
These suggestions are current as of the date of publication, but they may change in the future. As Microsoft’s products and services evolve, organizations should examine their identification procedures on a regular basis.
Main Operational Process
Assignment of owners to the key tasks in Azure
Managing Azure Active Directory necessitates the ongoing execution of important operational tasks and processes that aren’t always part of a rollout. It’s nevertheless critical that we set up these chores to keep our surroundings in good shape.
It is mandatory to assign an owner to activities that don’t have one or alter ownership for tasks as we go over the list.
Identity synchronization of the On-premises system
The identification & solution of the synchronization issues
Support issues can be caused by unsolved synchronization faults that have been present for a long time. Troubleshooting synchronization errors gives an overview of the various types of sync failures, as well as some of the likely conditions that cause them and possible solutions.
Note: If a single human identity has numerous accounts as a result of a legacy domain migration, merger, or acquisition, we should only synchronize the account that the user uses on a daily basis, such as the account that they use to log into their computer.
In an ideal world, we’d strike a balance between the amount of items to synchronize and the rules’ complexity.
Important
If we’re still using group filtering in production, we should switch to a different filtering method.
The disaster Recovery in Azure
The disaster recovery is also known as the sync failover. The provisioning process relies heavily on Azure AD Connect. Changes made on-premises will not be updated in the cloud if the Sync Server goes down for any reason, which may cause access issues for users. As a result, defining a failover plan that allows administrators to immediately resume synchronization if the sync server goes offline is critical. The following are some examples of such strategies:
- Deploy Azure AD Connect Server(s) in Staging Mode – The administrator can “promote” the staging server to production simply just by making a small modification.
- The Use of the Virtualization method – If Azure AD connect is installed on a virtual machine (VM), administrators can use their virtualization stack to live move or fast reinstall the VM, resuming synchronization.
Custom rules
Custom rules in Azure AD Connect allow us to govern the flow of attributes between on-premises and cloud objects. Overusing or misusing custom rules results into the many risks which can be very dangerous for the organisation.
They can be :
- Performance degradation while executing complex actions across items when troubleshooting complexity.
- Higher probability of configuration divergence between the production server and staging server (used by built-in rules)
- Additional overhead while upgrading Azure AD Connect if custom rules are established within the precedence more than 100
If we have extremely complex regulations, we should look into why they are so complicated and look for ways to simplify them. Similarly, if we’ve written custom rules with a precedence value more than 100, we should make sure they’re not in jeopardy or in conflict with the default set.
Examples of misusing custom rules include:- Make up for filthy directory data – In this instance, it’s best to engage with the AD team’s owners to clean up the directory’s data as a remediation task, and alter protocols to avoid reintroduction of poor data.
- Individual user repair on a one-time basis – It’s typical to come across rules that special case outliers, usually due to a problem with a specific user.
- Overcomplicated “CloudFiltering” – While decreasing the amount of items is a good idea, there’s a risk of overcomplicating the sync scope by employing a lot of sync rules. If there is complicated logic to include/exclude items that isn’t covered by the OU filtering, it’s best to do it outside of sync and designate the objects with a simple “cloudFiltered” attribute that may be triggered by a simple Sync Rule.
Licensing for Microsoft cloud services (Group based)
Licensing for Microsoft cloud services is simplified with Azure Active Directory’s group-based licensing. In this way, IAM offers group infrastructure while delegating group management to the appropriate teams within the company. In Azure AD, we may set up group membership in a variety of methods, including:
- Groups can be synchronized from on-premises directories, which could be a suitable fit for enterprises that already have group management systems in place that can be expanded to assign licenses in Microsoft 365.
- Attribute-based / dynamic – Azure AD keeps track of the group’s members and ensures that they match the phrase. When this type of group is used for license assignment, attribute-based license assignment is possible, which is ideal for enterprises with high data quality in their directory.
- Delegated ownership – The creation of the groups can be done and owners can also be assigned. We may enable company leaders, such as the Collaboration or BI teams, to define who should have access in this way.
The definition of service plans (license components) that should be enabled depending on job roles in the company is another facet of licensing management. Giving users access to service plans they don’t need can lead to their seeing tools on the Office portal they haven’t been trained for or shouldn’t be utilizing. When provisioning OneDrive for Business to personnel who may not be allowed to share content, it might result in increased help desk volume, wasteful provisioning, and jeopardize our compliance and governance.
To define service plans for users, apply the following guidelines:
- Administrators should create “bundles” of service plans for users based on their job function, such as white-collar vs. floor worker.
- Assign the license to the service plan and create groups by cluster.
Important
If we find any licensing errors, we should investigate and remedy any license assignment issues right away.
Lifecycle management IMA
If our current method does not account for new employees or employees who leave the company, we should implement dynamic group-based licensing and specify a group membership lifecycle. Finally, if we’re using group-based licensing with on-premises groups that don’t have lifecycle management, think about leveraging cloud groups to provide features like delegated ownership and attribute-based dynamic membership.
Apps assigned to the “All users” group
The All-users group may appear to contain solely Enterprise Employees, but it may actually have both Enterprise Employees and Guests.
Azure AD Connect delta sync cycle baseline
Understanding the volume of changes in our business is critical, as is ensuring that synchronization takes a reasonable amount of time.
The delta sync frequency is set to 30 minutes by default. If the delta sync takes more than 30 minutes on a regular basis, or if the delta sync performance of staging and production differs significantly, we should analyze and review the variables affecting Azure AD Connect performance.
Recommended reading for Azure AD Connect troubleshooting
- Using the IdFix tool, prepare directory properties for synchronization with Microsoft 365
- Azure AD Connect: Troubleshooting Synchronization Errors
A safe Identity infrastructure has five components. This list will assist us in swiftly identifying and implementing the steps required to secure and manage the lifecycle of identities and their entitlements in our company.
- Assign key responsibilities to owners.
- Identify and correct synchronization issues.
- Define a disaster recovery failover strategy.
- Simplify the management of licenses and app assignment.
- Automate user app provisioning.