Do’s and don’ts concerning security for Identity part 3

Continuing with the do’s of Identity and supposing that you have a Hybrid identity setup. This will translate to having Source of Authority (SoA) in your on-premises environment.

We covered parts of user sync, what kind of solutions to use inside your environment and now it’s time for more Cloud-based approach, this is any way the reason why you need to sync your users in the first place.

Use Hybrid-Identity admin role for syncing

How the sync works between the two environments with AAD Connect.

And keep this in mind for future designs.

But there is still limitations in Cloud Provisioning Agent:

  • Does not support hybrid writeback for Exchange.
  • Does not support identity stores that are LDAPv3 compliant.
  • Not compatible with device objects.
  • No Azure AD hybrid join.
  • There is no Windows Hello support.
  • Does not permit the synchronization of directory attributes.
  • Does not allow for the editing of synchronization rules.
  • Doesn’t support writeback for devices, groups, or passwords.
  • Does not permit domain-specific references.

If you want to test out your readiness to adopt Cloud sync, you can do it here.

It will display multiple choices and based on what you choose, you will be recommended the right solution.

Do not use Global Admin anymore, use Hybrid-Identity admin instead for both AAD Connect and AAD Connect Cloud Sync agent. No need to use the highest privilege account anymore and this way you can also comply with the model of least privileged.

Assigning the role

Just define a user with the role and connect to Azure AD.

AAD Connect

What does it look in the logs?

The setup logs for AAD Connect can be found here with CMD %ProgramData%\AADConnect\ and here with PowerShell $env:programdata\AADConnect\

Cloud sync provisioning agent

Changing account in the agent

How it show in the logs?

And this is what happens inside the logs inside CMD %ProgramData%\Microsoft\Azure AD Connect Provisioning Agent\Trace\ and here with PowerShell $env:programdata\Microsoft\Azure AD Connect Provisioning Agent\Trace\

Use Automation accounts

But be aware that Run-as accounts will be deprecated in 30th of September 2023 and will be replaced by Managed Identities.

How to migrate from Run As to Managed?

Microsoft has some sample scripts to different types of accounts, Run As, User-Managed and System-Managed and how you can login with them.

How to automate with Managed Identities?

And when need to use Runbook Workers, keep this in mind.

That in mind Managed Identities is a must if you are planning to …

Use Azure ARC

Azure ARC is a Hybrid management solution that cover your on-premises and it expands Azure platform and enables you to create services and applications that can run at the edge, across datacenters, and in multi-cloud scenarios. you can use in both new and used hardware, virtualization and Kubernetes platforms, IoT devices and integrated systems.

Use system-managed identities

When possible, use them. It’s just like using gMSA accounts under legacy on-premises Active directory.

Resources that support system assigned managed identities allow you to:

  • Enable or disable managed identities at the resource level.
  • Use role-based access control (RBAC) to grant permissions.
  • View the create, read, update, and delete (CRUD) operations in Azure Activity logs.
  • View sign in activity in Azure AD sign in logs.

If you choose a user assigned managed identity instead:

Operations on managed identities can be performed by using an Azure Resource Manager template, the Azure portal, Azure CLI, PowerShell, and REST APIs.

Different types of identities

There are two types of managed identities:

  • System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD. The identity is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
  • User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. For user-assigned managed identities, the identity is managed separately from the resources that use it.
PropertySystem-assigned managed identityUser-assigned managed identity
CreationCreated as part of an Azure resource (for example, Azure Virtual Machines or Azure App Service).Created as a stand-alone Azure resource.
Life cycleShared life cycle with the Azure resource that the managed identity is created with.
When the parent resource is deleted, the managed identity is deleted as well.
Independent life cycle.
Must be explicitly deleted.
Sharing across Azure resourcesCan’t be shared.
It can only be associated with a single Azure resource.
Can be shared.
The same user-assigned managed identity can be associated with more than one Azure resource.
Common use casesWorkloads that are contained within a single Azure resource.
Workloads for which you need independent identities.
For example, an application that runs on a single virtual machine.
Workloads that run on multiple resources and can share a single identity.
Workloads that need pre-authorization to a secure resource, as part of a provisioning flow.
Workloads where resources are recycled frequently, but permissions should stay consistent.
For example, a workload where multiple virtual machines need to access the same resource.

Use Service Principals

Using Service Principal to authorize your access to resources is always a good approach and security wise, enabling Certificate-Based authentication is even better.

The following script will ask parameters for your App ID, Subscription ID, your certificate location and password for it.

Then it will create a Reader role for that Application ID, the reader role has the following permissions.

*/readRead resources of all types, except secrets.

If you want to give it more permissions, you could use contributor. Contributor doesn’t give ability to add Role-Based Access to anyone, so you cannot add new users.

*Create and manage resources of all types
Microsoft.Authorization/*/DeleteDelete roles, policy assignments, policy definitions and policy set definitions
Microsoft.Authorization/*/WriteCreate roles, role assignments, policy assignments, policy definitions and policy set definitions
Microsoft.Authorization/elevateAccess/ActionGrants the caller User Access Administrator access at the tenant scope
Microsoft.Blueprint/blueprintAssignments/writeCreate or update any blueprint assignments
Microsoft.Blueprint/blueprintAssignments/deleteDelete any blueprint assignments
Microsoft.Compute/galleries/share/actionShares a Gallery to different scopes

Use Conditional access for workloads

You can use CA for protecting your Workload identities, workload identity is an identity that allows an application or service principal access to resources, sometimes in the context of a user. These workload identities differ from traditional user accounts as they:

  • Can’t perform multi-factor authentication.
  • Often have no formal lifecycle process.
  • Need to store their credentials or secrets somewhere.

So you need to treat them differently.

Block is the only options as the access is blocked when a token request is made from outside the allowed range.

Some things to remember when create the policy:

  • Individual cloud apps cannot be selected due to ‘Workload identities (preview)’ selection in policy assignment.
  • Policy only applies to single tenant service principals owned by your organization.
  • Risk level is mandatory to Enforce service principal risk the policy.
  • Block is the only control available due to ‘Workload identities (preview)’ selection in policy assignment.


Graph query examples to enable policy

The query will be against and ID is your conditional access policy ID, that you can check with and it will show all CA policies that you have.

And the built policy seen through Graph API

So it basically allows from your defined location but block from others with and based on the risk level you define.


In this part we discovered how you can use Hybrid Identity Administrator role, Automation accounts and Managed Identities and Service principals with certificates and Conditional access and why they are useful for your environment.

In the next part more Identity do’s and don’ts, Stay tuned!

Hackers don’t break in – they log in.

Author: Harri Jaakkonen

Leave a Reply

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