Full IGA using Azure AD – Getting app role assignments using PowerShell

In this post I will quickly demo how to use PowerShell to get app role assignments for all application using the Microsoft Graph.

You should have followed my previous post in order to have created an application, added some appRoles to the manifest and granted access to the Graph.

Continue reading “Full IGA using Azure AD – Getting app role assignments using PowerShell”

Full IGA using Azure AD – App roles in OAuth ID token or SAML claim

In the last post we transferred to user information and roles to the application through Azure AD outbound provisioning with SCIM. This requires the application to either have or to implement a SCIM API, which might some times be unnecessary. Also, many applications does not have an internal user database, but relies on session information when doing access control.

In this blog post I will show you how applications can get user roles through the user’s ID token, demoed with OAuth 2.0 authorization code flow.

Continue reading “Full IGA using Azure AD – App roles in OAuth ID token or SAML claim”

Full IGA using Azure AD – Provisioning using SCIM

Continuing my series on how to achieve a full “Identity Governance and Administration” (IGA) solution using Azure AD, the topic this time and for the next few posts will be provisioning, with focus on actually transferring the app roles from my previous post into the application itself.

Continue reading “Full IGA using Azure AD – Provisioning using SCIM”

Full IGA using Azure AD – Custom app roles

Well, it’s been three years since my last post, and now I will try to start posting again. I will do a mini series on Azure AD governance features, and how to achieve a full “Identity Governance and Administration” (IGA) solution using Azure AD.

The end goal will be to handle entitlements inside Office 365 as well as third party applications. This post will focus on 3rd party apps, and will lay the foundation for handling these entitlements with the Azure AD Entitlement Management feature, as well as actually populating these entitlements inside the app using SCIM, Claims or other means, all of which will be covered in later posts.

Continue reading “Full IGA using Azure AD – Custom app roles”

AAD Identity Protection – End-user behavior

Microsoft is moving from a “force Multi-Factor Authentication for all users” model to a risk based model where users are requested to do Multi-Factor Authentication when their sign-in has a risk assigned to it. This could happen for example by an impossible travel, the user logging in from an IP address which has been in contact with a botnet or other “signals” as Microsoft calls them.

First of all, with AAD Identity Protection, instead of doing manual or scripted assigning of MFA, this is now done with an MFA registration policy. Here is an example on what this can look like:

snip_20160321095252

This will let organizations start with a group of users and expand to more and more users. What will happen is that the user will be prompted to register for MFA when they log on with a browser (or Office with ADAL etc.), but their next logon will not require MFA.

snip_20160321095400

When we look at StrongAuthenticationRequirements of the user, it will be empty, meaning that MFA is not enforced, but the user is still ready to use MFA whenever Azure AD requires it.

Now let us look at the Sign-in risk policy:

snip_20160321100036

Here I have configured the policy to be invoked when the machine learning system in Azure AD find my sign-in a low or medium risk. If a high risk is detected, it is blocked completely.

When I sign in from my regular computer, nothing happens. No MFA; everything is like it has always been. This is perfect, and exactly how this should work. Azure AD detects that everything is safe, no risk at all, so I am not prompted for MFA.

Now, let us try signing in through a RDP session from a computer about 2 hours away by air.

snip_20160321095306

 

snip_2016032110100

Suddenly my sign-in requires Multi-Factor Authentication, because I made an impossible travel.

 

How Active Directory vNext and the PAM feature works under the hood

So, i decided to figure out how the new PAM feature in MIM worked as a POC for a customer. I configured two forests (red.goodworkaround.com and blue.goodworkaround.com), where RED was the Privileged Access Management forest.

I got MIM PAM up and running in a matter of minutes using the TechNet Configuring the MIM Environment for Privileged Access Managment. As PAM is still very new, I figure it would be a good idea to follow a guide for once.

I imported some groups using the code below, so far so good. The groups was created in the RED forest with sidHistory from the BLUE forest.

$cred = get-credential -UserName RED\marius -Message "RED forest domain admin credentials"
New-PAMGroup -SourceGroupName "Service Admin - Service G" -SourceDomain blue.goodworkaround.com -Credentials $cred  -SourceDC blue-pc.blue.goodworkaround.com

I tested with the Domain Admins group, and it failed with the error message about limitations in sidHistory not allowing this type of group. I already knew this going in, but I figured I wanted to try.

My customer really want to control their Domain Admins group, so we digged further into the new functionality in Windows Server vNext / Threshold. Here there is a new feature which they sometimes call “Foreign Principal Groups” and sometimes “Shadow Groups”. Searching around the web gave very, very few answers, but I found a few interesting sites:

What’s New and Changed (Windows Server vNext)
A pdf with some details
3.1.1.13.5 ExpandShadowPrincipal
2.453 Attribute msDS-ShadowPrincipalSid

From these sites I was able to deduce that what the MIM PAM feature is actually doing is creating msDS-ShadowPrincipal objects, which are basically groups with an additional attribute msDS-ShadowPrincipalSID. These are created in the “Shadow Principal Configuration” container (which is actually a msDs-ShadowPrincipalContainer) under the Services node in AD Sites and Services.

The following PowerShell however, yielded an error “New-ADObject : The specified method is not supported”:

$g = Get-ADGroup -Identity "Domain Admins" -Server blue.goodworkaround.com
New-ADObject -Type msDS-ShadowPrincipal -OtherAttributes @{
    "msDS-ShadowPrincipalSid" = $g.SID
} -Path "CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=red,DC=goodworkaround,DC=com" -Name "BLUE.Domain Admins"
$g = Get-ADGroup -Identity "My Global Group" -Server blue.goodworkaround.com
New-ADObject -Type msDS-ShadowPrincipal -OtherAttributes @{
    "msDS-ShadowPrincipalSid" = $g.SID
} -Path "CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=red,DC=goodworkaround,DC=com" -Name "BLUE.My Global Group"

Digging a bit more around I found that this PAM feature is an optional feature that has to be enabled, just as the AD Recycle Bin. Enabling the feature was easy:


Get-ADOptionalFeature -Filter {Name -eq "Privileged Access Management Feature"} | Enable-ADOptionalFeature -Scope ForestOrConfigurationSet -Target red.goodworkaround.com

Now, the PowerShell above worked and the shadow principals was created:

I have not added any members though. So I did that through the GUI:

So what I have now is the following code


Get-ADObject -Filter {objectClass -eq "msDS-ShadowPrincipal"} -SearchBase "CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=red,DC=goodworkaround,DC=com" -Properties member

That returns the following shadow principals (with member as you can see):

And when logging on as this user and running whoami /groups, you will see these as added groups:

As you can imagine, this will also completely remove the requirement to use ADMT (or the library of ADMT) to migrate SIDs for groups

Now, one heads up that I have asked Microsoft is about: Domain Admins does not work over the trust with this method (the SID is probably filtered away on the other side). I will update the article when I have more info.

Update: So, I talked to Mark Wahl about this and it turns out that it is planned a QFE for older Windows Server versions to allow for built-in groups over trusts, but this will probably not happen until Windows Server vNext is released. This means that the PAM feature will not work for built-in groups until this QFE is released.