Identities And Governance

Overview Takeaways

• Entra ID is NOT Active Directory in the cloud
• It is an identity management solution for cloud resources (HTTP(s))
• Other systems lean on Entra ID for identity management (i.e. Intune) but Intune =/= Entra ID
• Watch your licenses as a lot of features are locked behind various tiers
• Even Microsoft is confused their branding…. Entra ID, Azure AD, Azure accounts, etc. is everywhere

Authentication Methods

Customizing the authentication methods is very straight forward. However, there was an bug/issue I ran into when setting up the MFA authentication methods for the organization.

During the Authentication methods step, the administrator is presented with various options grouped by their security level. The "Email One-time password" option was selected and greyed out with the following disclaimer:

“The following authentication methods could be vulnerable to SIM or other hacking methods, which could leave your organization vulnerable to attack. We recommend using stronger security than the methods below.”

A manage link lead to the Microsoft Entra admin center document which pointed to a policy in the Entra portal - simple enough. This is where the bug comes in.

You cannot save your changes after using the toggle switch in the Email OTP settings blade without making other changes. You must first select a target of All users and THEN the “Save” button is available. Once those settings are saved you can navigate back to the 365 Admin panel and complete the MFA settings there.

User And Group Accounts

1. Account types in this deployment will all be cloud native
   • There will be some temporary guest accounts to test various security settings around those
2. I’m already familiar with Hybrid deployments
   • Entra Cloud Sync but still has a lot of references to the old Azure AD Connect branding.

Managing ACcounts

I suspect the bulk of user management will be via the Entra ID process and should be covered in more detail as I consume that content. However, I noticed some default settings that I definitely don’t agree with. In a typical organization these would be set and then controlled via RBAC rules and role memberships.

These settings are/were configured via the Azure Portal > Users > User settings blade.

1. Disable users registering applications
2. Restrict non-admin users from creating tenants
3. Disable users from creating security groups
4. Restrict access to the Microsoft Entra ID admin center

Group Type Notes

• Security = Access control mechanism for security policies and resource access lists
• Microsoft 365 = Collaboration access for items like shared mailboxes, files, Sharepoint, Teams, etc.
  • External/guest access
• Membership assignment
  • Assigned = deliberately and specifically assigned
  • Dynamic user = users added base on certain user attributes - department, city, title, etc.
    • Members of the Marketing department would then automatically add them to the marketing group
      • If the user leaves Marketing and goes to the Operations department, they would be removed from the Marketing group automatically
    • A lot of potential here but I could see how management could get convoluted
    • Security or 365 groups
  • Dynamic device - Assigned automatically based on device attributes
    • OS: Windows 10 vs Windows 11 vs MacOS
    • Location: Geographic locations
    • Device Compliance Policy

Dynamic Group Membership Lab

1. Any user with the Cloud Administrator job title should be assigned to the “IT Cloud Administrator” group.
2. Any user with the System Administrator job title should be assigned to the “IT System Administrator” group.
3. Any user that is a member of the “IT Cloud Administrator” group or the “IT System Administrator” group should be assigned to the IT Lab Administrators group.
4. A System Administrator in another Active Directory tenant should be invited as guest user with limited permissions.

• Task 1: Create and configure Microsoft Entra users.
  • User AZ104-01a-aaduser1 will be a Cloud Administrator assigned the User Administrator role.
  • User AZ104-01a-aaduser2 will be a System Administrator.
• Task 2: Create AD groups with assigned and dynamic membership.
  • The IT Cloud Administrator group should include any user with the Cloud Administrator job title.
  • The IT System Administrator group should include any user with the System Administrator job title.
  • The IT Lab Administrator group should include any user in the IT Cloud Administrator group or the IT System Administrator group.
• Task 3: Create a Microsoft Entra tenant. This tenant will be used to demonstrate guest users.
• Task 4: Manage Microsoft Entra guest users.
  • In the new Microsoft Entra tenant create a System Administrator user, az104-01b-aaduser1.
  • Invite the new user as a guest user to your subscription.

This “exercise” was incredibly disappointing. It consisted of a glorified powerpoint presentation where you simply click on areas of the screen to populate all of the values. Sort of nice I guess for showing the navigational features but it really doesn’t stick when I go through exercises like that.

SO I instead decided to stretch my legs and script it. Fun fact: The AzureAD module doesn’t handle dynamic groups! I ended up consulting ChatGPT and we came up with the following Microsoft Graph code:

# Connect to Graph
$scopes = "User.Read.All","Group.ReadWrite.All"
Connect-MgGraph -scopes $scopes

# Define an array of group parameters
$groups = @(
    @{
        DisplayName = "IT Cloud Administrator"
        Description = "Cloud Admins"
        mailNickname = "ITCloudAdmins"
        MailEnabled = $false
        SecurityEnabled = $true
        GroupTypes = @("DynamicMembership")
        MembershipRule = '(user.jobTitle -eq "Cloud Administrator")'
        MembershipRuleProcessingState = "On"
    },
    @{
        DisplayName = "IT System Administrators"
        Description = "System Admins"
        mailNickname = "ITSystemAdmins"
        MailEnabled = $false
        SecurityEnabled = $true
        GroupTypes = @("DynamicMembership")
        MembershipRule = '(user.jobTitle -eq "System Administrator")'
        MembershipRuleProcessingState = "On"
    },
    @{
        DisplayName = "IT Lab Administrator"
        Description = "Lab Admins"
        mailNickname = "LabAdmins"
        MailEnabled = $false
        SecurityEnabled = $true
        GroupTypes = @("DynamicMembership")
        $membershipRule = '(user.memberOf -any (group.objectId -in ['objectId', 'objectId']))'
        MembershipRuleProcessingState = "on"
    }
    # Add more group definitions as needed
)

# Loop through each group definition and create the dynamic group
foreach ($groupParams in $groups) {
    New-MgGroup -BodyParameter $groupParams
}

Now, I’m using the user.memberOf for dynamic groups based off of membership to another dynamic group - It’s dynamic groups all the day down! Just replace the ‘objectId’ values with the group values and it’s done.

Maybe I could query the groups, get their Id, assign the ID to a value, then pass that into the rule but I probably wouldn’t crete the groups via a script anyways. It just doesn’t feel like a scenario where the quick, repeated/generative advantages of scripting would come into play.

Region Notes

Main region page

• Region paris are incredibly important for data/service resiliency
  • Make sure to take advantage of replication when appropriate and watch out for defaults
  • Compliance requirements would also need to take the paired region into play. The bulk of your standard stuff is most likely 1:1, but oddball, customer specific contractual items may need to be taken into consideration
• Feature sets can be unique per region
• Cross Region details can be found here
• Azure Site Recovery is pretty slick
  • Past experience in DR compliance testing was incredibly positive with great RTO and RPO capabilities
    • RTO is basically how long can a service be down
      • If a system goes down, how long does the restoration take? If it takes 45 minutes to detect -> act -> restore to live then the RTO is 45 minutes.
    • RPO is how much data in “X” time can be lost
      • If backups are only taken every 24 hours, and the system fails 1 minute before the next backup, your RPO is 23 Hours and 59 Minutes.
        • Software and design choices (like a robust journaling system) could theoretically replay everything from that 23 Hour 59 Minute gap and get you to a 1 minute RPO but I digress

Subscription notes

• user account:subscription is a 1:n relationship
• Their page says you should “consider these things” but doesn’t really expand in any meaningful way
  • Scoping subscriptions to job roles, company silos, etc.

Cost Management

This is some interesting stuff and the granularity can be mind boggling. If it’s in the cloud, you’re paying for every minute of uptime, every KB of data stored and transmitted.

• Use reservations on anything up 24/7 and running for any meaningful stretch of time
  • They don’t report as nice in the Cost Management portal but they can add up
• Watch your storage accounts, file shares, etc. as they typically default to more costly SKUs than what is really needed
  • User licensing and the amount of SharePoint storage provided could be a great argument for splurging a bit on user licenses to avoiding file hosting costs?
• Budget your Test and Dev teams
  • Helps make them responsible for spend
  • Many resources can be automated to come up/down (e.g. auto-stop and auto-start VMs)
• Tag items so you can report on it and track cost appropriately (and try to maintain them)

• The hierarchy is a little weird with the wording Initiative Definition > Many Policy Definitions > Applied to resources
• Start with the policy definitions, add them to initiative definitions, apply them to resources
• Prebuilt list can be found here
• Oh hey… Azure Automanage combined with their CIS policies? looks promising

A lot of promising policies and automation potential here. Inheriting specific tags from the resource group with an automation account to resolve is pretty slick. Require tags on new items going forward is also great.

More time is definitely warranted in the Policy items, how to apply, configure and review compliance status and how it may integrate with Automanage. If it doesn’t go well then there is Chef, Puppet, Ansible, etc. along with various PowerShell scripts mentioned in the tools page.

Not a whole lot of new information around this. Previous experience utilized RBAC across different environments, user roles, etc. due to compliance policies. Deep diving into custom Azure roles and assignments could be incredibly interesting but is outside the scope of this AZ-104 content.

• It’s not just user permissions but also applications and other objects.
• Watch out for inheritance.
• Custom rules should be documented with a source of truth, reasoning, approval requests, etc. for adding or modifying any custom roles.
• It’s probably a good idea to add in additional, restricted test users as more resources are deployed to get a feel for the customization options and implementing the principle of least privilege.
• Entra ID RBAC is scoped to the tenant level for users, groups and domains
  • Azure RBAC can be scoped from entire subscriptions down to a single resource.

Create And Use RBAC Role

The lab on this one was another point-and-click adventure which just… doesn’t do the trick. Management groups had already been created in my lab environment and I just needed to step through creating and uploading a custom roll.

One item I’ve encountered in the past was access to storage account keys in order to read blob/VHD vm disk information. Access to the key vault was restricted and the following custom role should resolve that.

Note that the “assignableScopes” property needs to be set appropriately. The custom role will only appear (in the Portal) or validate (scripted assignments) for the specified value.

Other objects to scope an assignment to may be:

• Management groups: “/providers/Microsoft.Management/managementGroups/{management_group_id}”
• Resource groups: “/subscriptions/{subscription_id}/resourceGroups/{resource_group_name}”
• Network resource under resource group: “/subscriptions/{subscriptionId1}/resourceGroups/Network”

Or multiple options:

"AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"

{
  "IsCustom": true,
  "Name": "Extended Storage Reader",
  "Description": "Allow reading data about Blob Containers and VHDs via access to the Storage Account keys. The default role Reader does not provide API access to these keys.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/extensions/read",
    "Microsoft.Storage/storageAccounts/listKeys/action"
  ],
  "notActions": [],
  "assignableScopes": [
    "/subscriptions/{subscription_id}"
  ]
}

1. Access the cloud shell via a browser at portal.azure.com or from the vsCode Azure Cloud Shell (PowerShell)
2. code ./custom_extended_storage.json
3. Paste the content and replace {subscription_id} with the real subscription ID
4. Click the code bar and select Save - save to the same file name
5. Close the code window
   1. Sanity check it saved by re-running Get-Content ./custom_extended_storage.json
      • Or less custom_extended_storage.json if in the Bash shell
6. Run New-AzRoleDefinition -InputFile ./custom_extended_storage.json
   1. Bash would be az role definition create --role-definition @custom_extended_storage.json
7. Assign the role to a user/group as appropriate.

There’s not a whole lot to really add around self service password resets outside of the licensing requirements. Locking this behind a fee seems pretty odd but at least the Business Standard is, well, pretty standard and/or the P1 is cheap.

An interesting call out around some license features may be available to users who aren’t actually licensed for the benefit. This is the first time I’ve seen acknowledgement around the flow where, when a un-qualified user is added to a group with qualified users, they gain access to the benefit. Obviously something that should not be abused, but this does finally make sense around some instances I’ve seen where users had features that shouldn’t have been available (i.e. impossible travel alerts, SSPR, etc. on bog standard E1 users.)

There’s quite a bit of content around enabling the feature and how to scope a rollout. Rollouts can be a little tricky if unused to performing them, the key is to let your users collaborate on the process. If they buy into what’s going on and get to feel unique or empowered, it’s simply human nature to be a good sport about things if/when any hiccups happen. Keep things simple, implement in small steps, and really listen to user feedback.