Cybersecurity Architect Expert certification

This weekend I successfully passed the SC-100 certification, with it have now achieved my second Expert level cert, the Cybersecurity Architect certification from Microsoft.

Learned a ton, and looking at the exam score, I overstudied on governance, but that’s what I’m interested in, and yes, it’s helped a ton with furthering my knowledge with Azure security infrastructure and design!

Transitioning to Azure cloud authentication – Part 1

This series of articles is to document steps to be taken to transition from an on-premise Active Directory footprint, and migrate the workloads to Azure AD.

A typical migration has the following stages:

  • Discovery: Find out what is currently in the environment
  • Pilot: Deploy new cloud capabilities to a small subset of users, applications, and devices
  • Scale Out: Expand the pilot to complete the transition
  • Cut-over: Stop using the on-premises authentication

Users and Groups

Microsoft highly recommends a passwordless environment, due to as is depicted in the following graphic, is both highly secure, and convenient.

In my experience, users correctly following secure practices either make or break security initiatives, thus, in my opinion, convenience is crucial

Industry authentication standards rely on one of the following:

  • Something you Know:
    • Passwords are great, but unless a vault is used, it is common to use the same, or variation for many personal accounts. Highly vulnerable in modern times, as environments are often compromised, with credentials getting exposed to public sites. The equivalent of writing credentials down on paper and other people finding it.
  • Something you Have:
    • Removes the problem of forgetting something you know, but is vulnerable to the object being lost or stolen.
  • Something you Are:
    • Much harder to lose a fingerprint than a wallet, however, while this is getting better, historically, biometric sensors can be fairly expensive (cost and support) and have accuracy issues.

Due to the fact each authentication methods have their vulnerabilities, a combination of them is much stronger, hence the modern term “Multi-Factor Authentication” (MFA)

Here’s an example of using the Authenticator App as a convenient multi-factor authentication option in addition to a password.

The Authenticator App turns any iOS or Android phone into a strong, passwordless credential. Users can sign in to any platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one on their phone, and then using their biometric (touch or face) or PIN to confirm.

Passwordless authentication using the Authenticator app follows the same basic pattern as Windows Hello for Business. It’s a little more complicated as the user needs to be identified so that Azure AD can find the Authenticator app version being used:

  1. The user enters their username.
  2. Azure AD detects that the user has a strong credential and starts the Strong Credential flow.
  3. A notification is sent to the app via Apple Push Notification Service (APNS) on iOS devices, or via Firebase Cloud Messaging (FCM) on Android devices.
  4. The user receives the push notification and opens the app.
  5. The app calls Azure AD and receives a proof-of-presence challenge and nonce.
  6. The user completes the challenge by entering their biometric or PIN to unlock private key.
  7. The nonce is signed with the private key and sent back to Azure AD.
  8. Azure AD performs public/private key validation and returns a token.

Password Self-Service

Until an MFA environment is in place, migrating to Azure’s password self-service (SSPR) gives users the capability of managing their own password resets, which not only greatly helps with the “convenience” point I made above, but in most cases, tremendously decreases help desk support calls.

The following authentication methods are available for SSPR:

  • Mobile app notification
  • Mobile app code
  • Email
  • Mobile phone
  • Office phone (available only for tenants with paid subscriptions)
  • Security questions

Users can only reset their password if they have registered an authentication method that the administrator has enabled.

On-premises integration

With a hybrid environment, first install and configure the sync agent to be capable of enabling password writeback, once that is complete, you can configure Azure AD Connect to write password change events back from Azure AD to the on-premises directory.

In addition, the following options are available:

  1. Users can unlock accounts without resetting their password
  2. Password filters for on-premises Active Directory

Specialized role permissions – Locking down standard Azure infrastructure

Possibly due to specific governance needs, or perhaps maintaining a specific infrastructure in your cloud environment, you might want to lock out standard build capability for a group of users.

In the following example, I had a request to remove the ability of creating new Resource Groups in Azure to most users regardless of authorization levels, here is the example of how to do so with Microsoft Graph permission sets.

I created a custom Azure role that defined what can be done, and what can’t be done, looking at a the empty role JSON file, you can see there are “Actions” and “NotActions” sections:

{
  "Name": "",
  "Id":,
  "IsCustom": true,
  "Description": "Base Role file",
  "Actions": [
    ""
  ],
  "NotActions": [
    ""
  ],
  "AssignableScopes": [
    ""
  ]
}

The fields we’re going to pay attention to are the Actions, NotActions, and AssignableScopes.

Step 1: Determine the resource providers that map to Azure services.

With this example, we are targeting Resource Groups, so we will use:

Microsoft.Resources/subscriptions/resourceGroups

Step 2: Find the available permissions. With this case, we want to restrict creating or modifying resource groups, so it makes sense to add to the deny section the “write” permission.

Microsoft.Resources/subscriptions/resourceGroups/write

Step 3: Assign it to the appropriate scope. A Resource Group is created in a subscription, therefore that’s where you’d define the scope:

/subscriptions/bf384112-966c-4eb5-xxxx-b495c90xxxx

Putting it all together, your JSON file will look something like this:

{
  "Name": "Deny RG Create",
  "Id": null,
  "IsCustom": true,
  "Description": "Disable New Resource Group creation",
  "Actions": [
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [
    "Microsoft.Resources/subscriptions/resourceGroups/write"
  ],
  "AssignableScopes": [
    "/subscriptions/bf384112-966c-4eb5-xxxx-b495c90xxxxx"
  ]
}

Once you’ve created the role definition, import it into your Azure subscription and assign the role to the necessary users, they’ll get the “You do not have permissions to create resource groups under subscription” message when trying to create a new group.