App Integration to key Cloud Providers

App Integration to key Cloud Providers

App Integration to key Cloud Providers

 

We’re delighted to announce a new addition to our core service lines – a tiered engagement model to help customers integrate applications to their cloud identity providers.  Cloudneo can help you realise the benefits and fully leverage your existing Single-Sign-On investments around OKTA, Microsoft Azure and other key vendors, providing build, operations and automation benefits in short order.

We offer a basic, custom and fully managed service for App Integration, guiding you through PoC, Pilot or full production implementations.  The option to engage Cloudneo’s fully managed service means App on-boarding and ownership are cost-optimised and quick to deploy.  A typical engagement will:

  • Assess the application landscape
  • Define the migration path to a cloud identity provider (Microsoft Azure, OKTA or others)
  • Test, deploy and document one or many applications
  • Up-skill your IT resources around Identity and App integration techniques

Find out more

Start your journey today.  Get in touch to discuss our App Integration services

Azure AD Graph APIs using PowerShell

Azure AD Graph APIs using PowerShell

So you want to use the Graph API to interact with AzureAD or Intune?  Then normally you need to follow these generic steps to execute Graph APIs from your programs or scripts. 

  1. Register Application and Get App Key&ID 
  2. Assign appropriate Permissions  
  3. Request for Authorisation Token 
  4. Execute Graph APIs by passing the token in Request Header  

Let’s find an easier way!  Graph APIs are effective way to interact with Azure Active Directory and whilst the above steps are highly recommended for pragmatic application development, a System Admin can shave some effort off this with some PowerShell magic.   

The following explains how to execute Graph APIs on PowerShell Scripts using Global Admin credentials and WITHOUT registering the Applications on Azure AD (skipping steps 1 and 2 above) 

Note – before you start:  Ensure the Azure Module is installed. To install the Azure Module, execute PowerShell cmdlet install-module azure. 

Step 1:  Get the Authorisation Token for Azure AD PowerShell using well-known Application ID 
“1950a258-227b-4e31-a9cf-717495945fc2” 

You can use the following GetAuthzToken() function in your Script by passing parameters for Tenant Name and Global Admin Credentials 

 

Function GetAuthzToken

{

param

(

[Parameter(Mandatory=$true)]

$Tenant,

$user,

$Passwd

)

Import-Module Azure

$client_Id = “1950a258-227b-4e31-a9cf-717495945fc2”

$redirect_Uri = “urn:ietf:wg:oauth:2.0:oob”

$AppId_URI = “https://graph.microsoft.com”

$authority = “https://login.microsoftonline.com/$Tenant”

$authContext = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext” -ArgumentList $authority

$AADCredential = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential” -ArgumentList $user,$Passwd

$authResult = $authContext.AcquireToken($AppId_URI, $client_Id,$AADCredential)

 

return $authResult

}

 

$token=$null

# Enter Tenant Name

$AzureTenant=“<TenantName>.onmicrosoft.com”

# Enter GA Credentials

$username=“<GA Username >”  

$userPassword=“<Password>” 

$secureStringPwd = $userPassword | ConvertTo-SecureString -AsPlainText -Force

#Get Access token.

$token = GetAuthzToken -Tenant $AzureTenant -user $username -Passwd $secureStringPwd

Here’s the sample token output:

Step 2: Create the Authorization Header by adding Security Token, retrieved from step 1

Use the  CreateAuthorizationHeader() method to build the Authorisation header

 #Create Authorization Header

$authHeader = @{

‘Content-Type’=’application\json’

‘Authorization’=$token.CreateAuthorizationHeader()

}

Here’s the sample Authorization Header:

Step 3: Execute your Azure AD Graph API by passing the Authorization Header 

Use the Invoke-RestMethod cmdlet to execute Graph API. Basic syntax is as follows

Invoke-RestMethod -Uri <Graph API URI> –Headers $authHeader –Method Get

Tip: Use Graph Explorer (https://developer.microsoft.com/en-us/graph/graph-explorer) to test the Graph APIs before adding into your PowerShell Script.

The following retrieves the Group Members of an Azure AD Group. The highlighted part is your choice of  the Azure AD Group ID 

$uri = “https://graph.microsoft.com/v1.0/groups/ed33efc5-70f8-4f87-8276-3ad2513929cc/members”

do

{

#Get Group Members

$Response=Invoke-RestMethod -Uri $uri –Headers $authHeader –Method Get

 

$uri =$Response.’@odata.nextLink’

foreach ($user in $Response.value)

{

 

$user.displayname

}

} while ($Response.’@odata.nextLink’)

Here’s the sample Output:

Putting it all together:  the whole script for you to re-use

To test this script, don’t forget to change the highlighted parameters 

Function GetAuthzToken

{

param

(

[Parameter(Mandatory=$true)]

$Tenant,

$user,

$Passwd

)

Import-Module Azure

$client_Id = “1950a258-227b-4e31-a9cf-717495945fc2”

$redirect_Uri = “urn:ietf:wg:oauth:2.0:oob”

$AppId_URI = “https://graph.microsoft.com”

$authority = “https://login.microsoftonline.com/$Tenant”

$authContext = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext” -ArgumentList $authority

$AADCredential = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential” -ArgumentList $user,$Passwd

$authResult = $authContext.AcquireToken($AppId_URI, $client_Id,$AADCredential)

 

return $authResult

}

 

$token=$null

# Enter Tenant Name

$AzureTenant=”<TenantName>.onmicrosoft.com”

# Enter GA Credentials

$username=”<Username of GA>

$userPassword=”<Password>

$secureStringPwd = $userPassword | ConvertTo-SecureString -AsPlainText -Force

#Get Access token.

$token = GetAuthzToken -Tenant $AzureTenant -user $username -Passwd $secureStringPwd

 

$authHeader = @{

‘Content-Type’=’application\json’

‘Authorization’=$token.CreateAuthorizationHeader()

}

 

#Replace Highlighted part with Group ID

$uri = “https://graph.microsoft.com/v1.0/groups/ed33efc5-70f8-4f87-8276-3ad2513929cc/members”

 

do

{

#Get Group Members

$Response=Invoke-RestMethod -Uri $uri –Headers $authHeader –Method Get

 

$uri =$Response.’@odata.nextLink’

foreach ($user in $Response.value)

{

 

$user.displayname

}

} while ($Response.’@odata.nextLink’)

Want to talk to us about PowerShell and AzureAD and Graph?  Get in touch

Chris Hudson

Chris develops our thinking for Identity Management and Azure AD integration.  He’s developed lots of cool snippets and and tools to help make Identity Sysadmins lives that little bit easier.  You can follow Chris on LinkedIn below

Time to consider Azure B2B lifecycle management

Time to consider Azure B2B lifecycle management

In a growing ‘cloud first-mobile first’ world, data sharing and collaboration with external organisations is becoming one of the key differentiators for successful organisations.  

How does Microsoft provide external users to access to Azure Resources 

Microsoft provide a B2B framework to allow organisations to share data with external users.  It works based on an invitations system where external users are invited via collaboration apps, Azure-native invite cmdlets / UI.  Most of the Microsoft collaboration applications such as SharePoint and Teams also allow an organisation to invite external users.

Note: A new guest account will be provisioned on the inviter’s tenant when an external user is invited.

Why B2B lifecycle Management is important 

When a new Identity is provisioned on Azure AD for each B2B invite, user permissions get grouped based on each collaboration channel that the user is invited to be a part of.  As such, lifecycle Management of these accounts is critical, since organisations can easily lose track of External Users, for scenarios including:

  • When external users are invited from different Azure App platforms this may or may not follow Azure AD Native invite process.  For example, a SharePoint online invitation to the external users using its service account rather than the inviter’s credentials – which is a challenge if you rely on Azure AD Audit logs to accurately track invitations of certain guest Accounts 
  • The Identity lifecycle and access management solutions are limited to on-premises corporate users and will not have visibility on External Azure AD Users, leading to orphaned identities that are are diffcult to manage
  • Sensitive and secure data could be shares with external organisations or users without the implicit controls given by the existing Identity lifecycle solution

Recommendations from the Field

Minimize invitation channels 

Instead of opening B2B invites from all the applications, use only the channels which are easily manageable and provide extensive auditing capabilities. Utilizing Azure AD invitation processes, Guest access is limited only to the users within Directories on application platforms. 

Set a lifetime threshold for B2B users  

Setting an extensible authorised lifetime policy to help organisations to control the number of guest accounts 

Periodic Access Reviews 

To reduce the risk of  granting excessive, cumulative permissions for B2B users, implement Periodic Access reviews. These reviews can be delegated to the guest account sponsors. 

Accountability for Each invite  

It is good practice to keep track of the inviter of the external user and implement      periodic attestation (3 months for example).  As the external users may have access to multiple project files, the guest user sponsor role may not be limited to one person.

Consider whitelisting of organisations 

Restricting B2B invitations based on trusted organisations will let enterprises ensure that only the users from partner organisations have access to Azure/O365 resources.  Utilising an existing Azure AD B2B Allow/Deny list is not followed by all applications. As some of the Applications maintain their own invite process, review the invitation restrictions for each application which has External Guest access enabled.  As of now SharePoint and OneDrive maintain their own Allow/Deny Organisation list.  There is a preview feature available for SharePoint online which honours the Azure AD Domain restrictions.  https://docs.microsoft.com/en-us/microsoftteams/teams-dependencies details how External Access Authorisation is implemented on Teams. 

Consider deleting inactive B2B Users 

Keeping track of B2B user logins by reading Azure AD Audit logs will help to delete inactive B2B Users. 

Consider the deployment of  Azure P2 features

It’s good practice to deploy B2B Identity governance features which are part of the Azure AD P2 license.  For further details see:

 External User Access governance . 

Cloudneo has helped numerous organisations with Identity Management around B2B across the Microsoft application family and other key vendors.  We’ve worked with them to organise, optimise and flex their B2B identity solutions in short order.

To find out more about Azure B2B and how to get going, get in touch with Chris Hudson

Refer to https://docs.microsoft.com/en-us/azure/active-directory/b2b/what-is-b2b for more details on Microsoft’s solutions. 

 

Chris Hudson

Chris is an Identity and Access Management expert and founder of Cloudneo with many years’ vendor and industry experience with clients.