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

Continuing with the do’s of Identity and supposing that you are in part of your journey that you have either Hybrid or fully cloud-based identities.

In the last part I covered how you can use Hybrid Identity Administrator role, Automation accounts and Managed Identities and Service principals with certificates and Conditional access.

In this part we will see more or less dynamic approach to activate your full cloud powers.

Use dynamic groups

Azure AD has a feature called dynamic groups and it’s often overlooked for creating, well dynamic groups and assigning rules, licenses, permissions, basically everything with them.

Use case 1

In my example I covered the scenario of migrating user from on-premises Exchange to EXO and assigning the user a Exchange Online license when TargetAddress attribute has been populated (After the last 5% is done from migration)

This only one real-life example, other could be using conditional access policies for External users with Terms of Use enforced.

Use case 2

Open Entra admin center

Create terms and create a policy with it or after it manually, I will choose manually.

Go to Conditional access and create a new policy

Graph

And you can view it through Graph, I will explain a bit what is there.

Now you can also have Group membership in a dynamic group which is still in preview.

Or even better …

Use Authentication strengths

Depending on whether the user is completing MFA in their home tenant or the resource tenant, different authentication techniques can fulfill authentication strength in external user scenarios. The permitted ways for each renter are listed in the following table. Only the claims indicated in the “Home tenant” column below will be accepted by the resource tenant for MFA if a resource tenant has chosen to trust claims from external Azure AD organizations. The external user must complete MFA in the resource tenant using one of the procedures provided in the “Resource tenant” column if the resource tenant has disabled MFA trust.

Authentication methodHome tenantResource tenant
SMS as second factor
Voice call
Microsoft Authenticator push notification
Microsoft Authenticator phone sign-in
OATH software token
OATH hardware token
FIDO2 security key
Windows Hello for Business

Create a strength

Graph

And use them with …

Cross-tenant access settings

Connect to a organization

And add settings for MFA trust or don’t but then you have to register MFA in the destination tenant.

Note! Enabling MFA trust is optional for B2B collaboration but is required for B2B direct connect.

Graph

Let’s see it with Graph with this query https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/crossTenantAccessPolicyConfigurationPartner-tenantId

Just replace the last part with your resource tenant’s ID that can be found with the following:

https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView and copy Tenant ID

Or with command line tools.

Once you get it, you will see the policy attached with Graph.

Add it to a CA policy

You can choose only the B2B direct connect users.

More on this feature here.

And then the tenant you want to attach to the policy.

Choose strengths and Terms of Use

Graph

If you want to query it with Graph, you have use the beta version of Graph API https://graph.microsoft.com/beta/identity/conditionalAccess/policies

When it applies?

  • If MFA trust is enabled, Azure AD checks the user’s authentication session for a claim indicating that MFA has been fulfilled in the user’s home tenant. See the preceding table for authentication methods that are acceptable for MFA when completed in an external user’s home tenant. If the session contains a claim indicating that MFA policies have already been met in the user’s home tenant, and the methods satisfy the authentication strength requirements, the user is allowed access. Otherwise, Azure AD presents the user with a challenge to complete MFA in the home tenant using an acceptable authentication method.
  • If MFA trust is disabled, Azure AD presents the user with a challenge to complete MFA in the resource tenant using an acceptable authentication method. (See the table above for authentication methods that are acceptable for MFA by an external user.)

Scout your Guests

Here and excellent script. It will find any external users that have no static group membership or application assignments and makes a clear report from the findings.

And after the discovery you can change the game with …

Using Access reviews

With access review you can do a lot of things but one excellent way is to handle groups.

Send notifications and reminders.

Require reviewing monthly

And you can automatically remove access if reviewer doesn’t answer.

Disable KMSI (Keep Me Signed In)

First we have to understand in what circumstances KMSI won’t be displayed for users.

  • User is signed in via seamless SSO and integrated Windows authentication (IWA)
  • User is signed in via Active Directory Federation Services and IWA
  • User is a guest in the tenant
  • User’s risk score is high
  • Sign-in occurs during user or admin consent flow
  • Persistent browser session control is configured in a conditional access policy

You can disable KMSI from Company branding or from User settings, under Azure AD management plane.

Microsoft had warning that this setting will give unexpected prompts for users but I think it’s not a biggie compared to the security it provides.

Or under User settings.

Or better yet, you could create an Conditional access policy that will force all users or context of your choosing. This setting works correctly when “All cloud apps” are selected and in my example I will use it for high-privileged admin roles. There is several ways to achieve this, this is only one of them.

What happens when Never persistent is enabled?

  • This does not affect token lifetimes or the sign-in frequency setting.
  • This will override the “Show option to stay signed in” policy in Company Branding.
  • “Never persistent” will override any persistent SSO claims passed in from federated authentication services.
  • “Never persistent” will prevent SSO on mobile devices across applications and between applications and the user’s mobile browser.

Enable group expiration

If an owner leaves an Microsoft 365 group, email contact will be notified.

Use Life-cycle process

Life-cycle Workflows is a new Identity Governance service that enables organizations to manage Azure AD users by automating these three basic life-cycle processes:

  • Joiner – When an individual comes into scope of needing access. An example is a new employee joining a company or organization.
  • Mover – When an individual moves between boundaries within an organization. This movement may require more access or authorization. An example would be a user who was in marketing is now a member of the sales organization.
  • Leaver – When an individual leaves the scope of needing access, access may need to be removed. Examples would be an employee who is retiring or an employee who has been terminated.

There is different scenarios ready for you to choose

On-boarding template

In example for pre-hire on-boarding you will have the following. Enabling TAP for the user and send email, attach a category of Joiner and the attribute to trigger at the specified days before. The example rule will trigger if user has department as Marketing

And finally sending the email with TAP to the user that will be on-boarded.

Off-boarding template

And the off-boarding tasks.

Closure

In this part we discovered how you can use dynamic groups, authentication strengths with B2B direct connections (Cross-tenant access settings) do access reviews and handle life-cycles for identities.

These are all important part of keeping your environments in order and therefore secure from obsolete external and internal users and the risks their unneeded access will posses.

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 *