Once again, more best practices for Identity. In the last part I covered how we can protect your applications from leaking content. Keep your Identities secure and how to keep using MFA after on-premises MFA Server will not work anymore.
In this part we will see how to secure your User settings and prepare for future changes with deprecating features.
Table of Contents
Use templates for easier CA policy deployment
Did you know that you can use template for create Conditional access policies, there is templates for Identities and devices.
For Identities
And devices
Do disable Tenant creation from users
Of course there could be use cases that users need to create tenants but maybe it should be disabled by default?
One use case could be creating an Tenant for Power BI as a developer.
Or maybe you need an new Tenant when deploying Azure AD B2C?
Although you need a Subscription also to create an B2C tenant.
Yes means that default users are permitted to create Azure AD tenancies. When set to “No,” only users with the tenant creator or global administrator permissions are permitted to establish Azure AD tenants. Anyone who creates a tenant will also become that tenant’s global administrator.
But if you need to enable them to create those tenant, this is how you do it.
You can also remove the tenant if you “mistakenly” created one. https://entra.microsoft.com/#view/Microsoft_AAD_IAM/DirectorySwitchBlade/subtitle/
But then it becomes a little bit exiting as we didn’t provision any resources.
Allow resource management
And let’s try again and choose Delete
And it’s gone but bare in mind that it will be left in the dumpster for a while.
For me removing user permissions to create tenant took about 5 minutes.
Before this was enabled by default and the user creating the tenant becomes a Global Admin in that tenant, so nice from Microsoft to give us an option to disallow this.
Please could you just make it Disabled by default.
Legacy SSPR and MFA rules
The legacy rules for self-service password reset and multifactor authentication will be phased out in January 2024, and you’ll control all authentication methods here in the authentication methods policy. Manage your transition from the old unified policies to the new ones with this control.
When you open Manage migration, you will see the following options.
If your tenant is using both MFA and SSPR, you’ll need to consider each method:
- If the method is enabled in both legacy policies, enable it for all users in the Authentication methods policy.
- If the method is off in both legacy policies, leave it off for all users in the Authentication methods policy.
- If the method is enabled only in one policy, you’ll need to decide whether or not it should be available in all situations.
More information here,
Enable Email OTP (if not already enabled)
It determines whether external users can use the email one-time password for authentication. Starting in March 2021, tenants in the default state who did not use public preview will automatically have email OTP activated.
Use Third-party software OATH tokens
Software OATH tokens are programs that create 6-digit authentication codes using the OATH TOTP standard and a secret key. The ability to register and use OATH tokens for non-Microsoft software is particularly controlled by this policy setting. The Microsoft Authenticator component of this policy governs Microsoft Authenticator, which can also provide software OATH codes.
Note that they cannot be used as a first-factor authentication mechanism.
And if you still need more points to secure your environment, you could …
Export your defender scores with Graph
To get more insights on what you should fix in your environment, you can use those Secure score controls. This isn’t only limited to Identity based controls but wanted to point this one out.
Native Graph cmdlets
1 2 3 4 5 6 7 8 |
# Connect to Graph with needed permissions Connect-MgGraph -Scopes SecurityEvents.Read.All,SecurityEvents.ReadWrite.All # List all control that you inside the tenant Get-MgSecuritySecureScoreControlProfile # Export all control to JSON file Get-MgSecuritySecureScoreControlProfile | ConvertTo-Json | Out-File myscores.json |
Creating app registration
If you want to use Application authentication, you need to create an app registration.
Here is an excellent article just for that from MVP Liam Cleary.
Or this one from CIAOPS, which is oldish but gives good pointers.
How to capture all Secure scores by CIAOPS
And for the script, I made some modifications, here is the version that works with current API’s.
The working script
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 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 |
<# CIAOPS Script provided as is. Use at own risk. No guarantees or warranty provided. Description - Get all items from tenant secure score Source - https://github.com/directorcia/Office365/blob/master/o365-ssdescpt-get.ps1 Prerequisites = 1 1. Azure AD app setup per - https://blog.ciaops.com/2019/04/17/using-interactive-powershell-to-access-the-microsoft-graph/ 2. Change clientid, tenantid and clientsecret variables below More scripts available by joining http://www.ciaopspatron.com #> ## Variables $systemmessagecolor = "cyan" $processmessagecolor = "green" # Application (client) ID, tenant ID and secret $clientId = "" ## This MUST be changed before the script will run correctly $tenantId = "" ## This MUST be changed before the script will run correctly $clientSecret = '' ## This MUST be changed before the script will run correctly ## If you have running scripts that don't have a certificate, run this command once to disable that level of security ## set-executionpolicy -executionpolicy bypass -scope currentuser -force Clear-Host start-transcript "o365-ssdescpt-get $(get-date -f yyyyMMddHHmmss).txt" ## write output file to parent directory write-host -foregroundcolor $systemmessagecolor "Script started`n" ## Script from - https://www.lee-ford.co.uk/getting-started-with-microsoft-graph-with-powershell/ # Azure AD OAuth Application Token for Graph API # Get OAuth token for a AAD Application (returned as $token) # Construct URI $uri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" # Construct Body $body = @{ client_id = $clientId scope = "https://graph.microsoft.com/.default" client_secret = $clientSecret grant_type = "client_credentials" } write-host -foregroundcolor $processmessagecolor "Get OAuth 2.0 Token" # Get OAuth 2.0 Token $tokenRequest = Invoke-WebRequest -Method Post -Uri $uri -ContentType "application/x-www-form-urlencoded" -Body $body # Access Token $token = ($tokenRequest.Content | ConvertFrom-Json).access_token # Graph API call in PowerShell using obtained OAuth token (see other gists for more details) # Specify the URI to call and method $uri = "https://graph.microsoft.com/v1.0/security/securescores" $method = "GET" write-host -foregroundcolor $processmessagecolor "Run Graph API Query" # Run Graph API query $query = Invoke-WebRequest -Method $method -Uri $uri -ContentType "application/json" -Headers @{Authorization = "Bearer $token" } -ErrorAction Stop write-host -foregroundcolor $processmessagecolor "Parse results" $ConvertedOutput = $query | Select-Object -ExpandProperty content | ConvertFrom-Json write-host -foregroundcolor $processmessagecolor "Display results`n" foreach ($control in $convertedoutput) { $names = $control.value.controlscores.description $item = 0 foreach ($name in $names) { $item++ write-host -foregroundcolor green -BackgroundColor Black "`n*** Item", $item, "***" write-host $name } } write-host -foregroundcolor $systemmessagecolor "`nScript Completed`n" stop-transcript |
Closure
In this part we will see how to secure your User settings with disabling Tenant creation and adding more security using tokens, how to prepare for future changes with MFA and SSPR deprecating features.
But also three different methods for exporting our Security controls from Microsoft security Graph APIs.
In the next part more Identity do’s and don’ts, Stay tuned!
Links to previous parts
Hackers don’t break in – they log in.