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.
Table of Contents
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. https://admin.microsoft.com/adminportal/home?Q=setupguidance#/modernonboarding/identitywizard
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:
- You can create, read, update, and delete the identities.
- You can use RBAC role assignments to grant permissions.
- User assigned managed identities can be used on more than one resource.
- CRUD operations are available for review in Azure Activity logs.
- View sign in activity in Azure AD sign in logs.
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.
| Property | System-assigned managed identity | User-assigned managed identity |
|---|---|---|
| Creation | Created as part of an Azure resource (for example, Azure Virtual Machines or Azure App Service). | Created as a stand-alone Azure resource. |
| Life cycle | Shared 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 resources | Can’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 cases | Workloads 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.
| Actions | Description |
|---|---|
| */read | Read 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.
| Actions | Description |
|---|---|
| * | Create and manage resources of all types |
| NotActions | |
| Microsoft.Authorization/*/Delete | Delete roles, policy assignments, policy definitions and policy set definitions |
| Microsoft.Authorization/*/Write | Create roles, role assignments, policy assignments, policy definitions and policy set definitions |
| Microsoft.Authorization/elevateAccess/Action | Grants the caller User Access Administrator access at the tenant scope |
| Microsoft.Blueprint/blueprintAssignments/write | Create or update any blueprint assignments |
| Microsoft.Blueprint/blueprintAssignments/delete | Delete any blueprint assignments |
| Microsoft.Compute/galleries/share/action | Shares a Gallery to different scopes |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
Param ( [Parameter(Mandatory=$true)] [String] $ApplicationDisplayName, [Parameter(Mandatory=$true)] [String] $SubscriptionId, [Parameter(Mandatory=$true)] [String] $CertPath, [Parameter(Mandatory=$true)] [String] $CertPlainPassword ) Connect-AzAccount Import-Module Az.Resources Set-AzContext -Subscription $SubscriptionId $CertPassword = ConvertTo-SecureString $CertPlainPassword -AsPlainText -Force $PFXCert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @($CertPath, $CertPassword) $KeyValue = [System.Convert]::ToBase64String($PFXCert.GetRawCertData()) $ServicePrincipal = New-AzADServicePrincipal -DisplayName $ApplicationDisplayName New-AzADSpCredential -ObjectId $ServicePrincipal.Id -CertValue $KeyValue -StartDate $PFXCert.NotBefore -EndDate $PFXCert.NotAfter Get-AzADServicePrincipal -ObjectId $ServicePrincipal.Id $NewRole = $null $Retries = 0; While ($NewRole -eq $null -and $Retries -le 6) { # Sleep here for a few seconds to allow the service principal application to become active (should only take a couple of seconds normally) Sleep 15 New-AzRoleAssignment -RoleDefinitionName Reader -ServicePrincipalName $ServicePrincipal.AppId | Write-Verbose -ErrorAction SilentlyContinue $NewRole = Get-AzRoleAssignment -ObjectId $ServicePrincipal.Id -ErrorAction SilentlyContinue $Retries++; } $NewRole |
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
Graph query examples to enable policy
The query will be against https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/ID and ID is your conditional access policy ID, that you can check with https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/ and it will show all CA policies that you have.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
{ "displayName": "Name", "state": "enabled OR disabled OR enabledForReportingButNotEnforced", "conditions": { "applications": { "includeApplications": [ "All" ] }, "clientApplications": { "includeServicePrincipals": [ "[Service principal Object ID] OR ServicePrincipalsInMyTenant" ], "excludeServicePrincipals": [ "[Service principal Object ID]" ], }, "locations": { "includeLocations": [ "All" ], "excludeLocations": [ "[Named location ID] OR AllTrusted" ] } }, "grantControls": { "operator": "and", "builtInControls": [ "block" ] } } |
And the built policy seen through Graph API
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
{ "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#identity/conditionalAccess/policies/$entity", "id": "039c88c8-38e5-4c63-a0b7-fe7eb714f36f", "displayName": "Workloads", "createdDateTime": "2022-10-23T08:16:49.1009157Z", "modifiedDateTime": "2022-10-23T11:09:48.3712017Z", "state": "enabled", "sessionControls": null, "conditions": { "userRiskLevels": [], "signInRiskLevels": [], "clientAppTypes": [ "all" ], "servicePrincipalRiskLevels": [ "medium" ], "platforms": null, "devices": null, "applications": { "includeApplications": [ "All" ], "excludeApplications": [], "includeUserActions": [], "includeAuthenticationContextClassReferences": [] }, "users": { "includeUsers": [ "None" ], "excludeUsers": [], "includeGroups": [], "excludeGroups": [], "includeRoles": [], "excludeRoles": [] }, "locations": { "includeLocations": [ "AllTrusted" ], "excludeLocations": [ "AllTrusted" ] }, "clientApplications": { "includeServicePrincipals": [ "SuperSecret ID !!" ], "excludeServicePrincipals": [] } }, "grantControls": { "operator": "OR", "builtInControls": [ "block" ], "customAuthenticationFactors": [], "termsOfUse": [] } } |
So it basically allows from your defined location but block from others with and based on the risk level you define.
Closure
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.
RSS - Posts