Ok let’s say you are building a new PowerShell module or script and you would like to be able to run it on Windows virtual machines locally in your own datacenter, in Azure Functions, in GitHub Actions, in Azure DevOps Pipelines, in Automation Accounts or any other method of running PowerShell – this is perfectly possible, but how can you have it authenticate to Entra ID without a gazillion lines of code? Any how do you test that each scenario actually works? I present to you EntraIDAccessToken – a free and open module for authenticating to Entra ID, both for Microsoft Graph and any other integrated API.
Continue reading “EntraIDAccessToken, our open module for simplifying Entra ID authentication in your PowerShell scripts and modules”Tag: Security
Extracting the results of access reviews in Entra ID
So, you have completed your access reviews for a gazillion groups or access packages in Entra ID, and now would like to show off the result to management? No problem, we can simply dump the results to Excel and do whatever we’d like with them! Let me show you how:
Continue reading “Extracting the results of access reviews in Entra ID”Converting AD groups to Entra ID groups
Finally, the public preview of Group Source of Authority is out! What does this mean for you and me? Well, you can take any number of the groups you are currently synchronizing from Active Directory to Entra ID (which are currently read only in Entra ID), and make them writable in Entra ID. And you can even have turn the solution upside down, having Entra ID update the AD group when members are added/removed!
Let’s dig into this feature!
Continue reading “Converting AD groups to Entra ID groups”Accessing resources cross tenant using managed service identities
Up until now there has been no good way to have a managed service identity on tenant A granted access to resources or graph scopes in tenant B. Finally there is a way to achieve this!
There is a little caveat though, and that is that you will still need another app registration, but by using this new preview, we no longer need client secrets or certificates. Let’s have a look at how this works!
Continue reading “Accessing resources cross tenant using managed service identities”Using PowerShell and Graph to handle access package assignments
The Microsoft Graph is powerful, however it can be a bit daunting at times due to the sheer number of endpoints and parameters. Just for the access package feature of entitlement management, you have endpoints for assignments, approvals, approval stages, resource role scopes, assignment policies, assignment requests, catalogs, resources… you get the point. In this blog post we will be working with assigning existing access packages to users, just because that is a simple process that might be difficult to understand from the documentation.
Continue reading “Using PowerShell and Graph to handle access package assignments”Issuing Custom Security Attributes in Entra ID tokens
Custom security attributes in Entra ID is a feature that allows you to add attribute sets and attributes to your tenant, which you can use on all your user and application objects. A fairly common ask in Entra ID is the ability to store “secret data”, such as social security numbers, and making sure only certain principals can read these values. Here is where custom security attributes come into play. You can add an attribute set “PersonalInformation” to your tenant, and add “SSN” as an attribute to this attribute set. You can then tag each user with values, which only will be readable by those assigned the “Attribute assignment reader” role on tenant level or attribute set level.
However, currently Entra ID does not allow for these to be a part of issued tokens, not part of outbound synchronization rules and not as criteria for criteria based groups. So yeah, not really a first class citizen currently. For issued tokens, we can do something about it though!
Continue reading “Issuing Custom Security Attributes in Entra ID tokens”Outlook AutoDiscover redirect limit (0x800c8206)
Today I encountered something I’ve not seen before, and I am sure more people will encounter this. If a client is in an Active Directory site without an AutoDiscover serviceConnectionPoint (SCP), it will try to connect to all AutoDiscover instances in the organization simultaneously. If the user have been cross-forest migrated, a redirect response will come from each server, and if there are more than 8 of them, Outlook reaches a redirect limit and fails to AutoDiscover.
After a cross-forest migration, the targetAddress of the source Active Directory object will be set to an address in the routing domain. For example when you do migrate to Office 365 / Exchange Online, your user will get a tenant.mail.onmicrosoft.com address, in my case mailNickname@gwrnd.mail.onmicrosoft.com. After the migration, when requesting details from AutoDiscover On-Premise, the response will be a redirect to the Exchange Online autodiscover. The problem is that when SCP is enabled in Outlook, it will count each response On-Premise as a redirect. This means that if it requests from all of your AutoDiscover instances, it will fail (the limit is 10).
If you believe this is your issue, you can look for error code 0x800c8206 in “Test E-mail Autoconfiguration” in Outlook. If you find this error code, here is your solution.
Disable SCP on the client
Instead of having Outlook look for SCPs in AD, you can disable this feature by adding the following to the registry on the client.
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover]
"ExcludeScpLookup"=dword:00000001
With this disabled, Outlook will work more like on the internet. It will look at the UserPrincipalName (UPN), and try autodiscover.goodworkaround.com if your UPN ends with @goodworkaround.com. The reason this helps is that it will only get one response On-premise, not one per AutoDiscover virtual directory.
Configure AutoDiscoverSiteScope
By default a CAS only serves its own site. You can use the cmdlet Set-ClientAccessServer -identity -AutodiscoverSiteScope Oslo,Beijing,Boston,Seattle to configure it to serve more sites. This can help if you for example have 4 datacenters with 3 AutoDiscover instances in each, and some sites in AD does not have an Exchange server. The sites with the Exchange server will try all of the 12 AutoDiscover instances, and fail because it reaches the limit. If you configure the site to only try one of the sites, it will succeed because it will only try 3 servers.
Reduce the number of AutoDiscover instances
Do you really need 12? Remember that this is a lightweight service, and you can have a CAS without AutoDiscover. If you can manage to have 8 or less AutoDiscover instances you are safe.
Hope this helps someone.
Good Workaround! 