Zoho Banner September 2011

Archive for March, 2018

Configurable token lifetimes for Azure Active Directory (AAD) have been available for while now, although the feature is still in public preview.  This article provides details of how to create an access token lifetime policy and how to apply it to an application federated with AAD using SAML 2.0.

Before we get started with this, we need to ensure you have the correct (i.e. Preview) version of the AAD Powershell Module.  The current link for this is:

https://www.powershellgallery.com/packages/AzureADPreview/2.0.0.17

Note that the module is subject to change, so search for the latest version.

The default Access Token Lifetime Policy that applies to SAML2 tokens is one hour as described in this article.

3

Ok, let’s go ahead and create a new Token Lifetime Policy.  To do this we are going to use the New-AzureADPolicy cmdlet, as shown in the example below.

New-AzureADPolicy-Definition @(‘{“TokenLifetimePolicy”:{“Version”:1,”AccessTokenLifetime”:”12:00:00″}}’) -DisplayName“12HourTLP”-IsOrganizationDefault$false-Type“TokenLifetimePolicy”

In this example, I have set the token lifetime to 12 hours.  Now this is just an example, you will need to consider the security implications of whatever policy you create.  Here’s the output.

1

We will need to make a note of the Id (GUID value) of the new policy as we will need this later.

The next step if to identify the service principal associated with your SAML-enabled application.  This uses the Get-AzureADServicePrincipal cmdlet, as follows:

Get-AzureADServicePrincipal-SearchString“My”

We can run the cmdlet without the searchstring parameter, but that tends to return a lot of results for us to pick our way through. Here’s what the output looks like.  Again, we should make a note of the ObjectID value as we will need this later.

2

Now you check which policies currently apply to your service principal.  We use the Get-AzureADServicePrincipalPolicy cmdlet to do this using the ObjectID of the service principal for our application.

Get-AzureADServicePrincipalPolicy-Id1911f64f-9d76-4ebf-9fcb-b3814e2e5e21

In this example, the output shows that a TokenIssuancePolicy is applied, but no TokenLifeTimePolicy – so we can assume that the default TokenLifeTimePolicy of 1 hour is in play.

4

Now we can go ahead and apply our newly created TokenLifeTimePolicy to the service principal representing our application.  This uses the Add-AzureADServicePrincipalPolicy cmdlet. The “Id” parameter needs to the ObjectID of our service principal, while the “RefObjectId” parameter needs the GUID of the Token Lifetime Policy we created earlier. And, yes, it can be confusing!

 

Add-AzureADServicePrincipalPolicy-Id1911f64f-9d76-4ebf-9fcb-b3814e2e5e21-RefObjectId74f4296d-fcdb-4c72-b434-b1628adef47b

Note that, if successful, this cmdlet returns no output.

5

We can now re-run the cmdlet to check which policies have been applied to our service principal.

6

As you can see, our 12HourTLP policy is now applied.

This is all very well, but how can we determine whether the policy is actually in effect or not?  One option is to sign-in to the application and wait for 12 hours to roll over.  If you have luxury of time for this then you clearly aren’t as busy as I am!  A better option is to examine the SAML Response XML using a SAML inspection tool such as the SAML Chrome Panel extension for the Chrome browser. Once you have the Response XML, look at the Conditions node and confirm that the NotBefore and NotOnOrAfter values show a 12 hour difference – see example below.

7

That’s it really.  In this article you have hopefully learned how to create a new Access Token Lifetime Policy as well as how to apply it to an existing SAML 2.0 application that is leveraging AAD as the Identity Provider (IdP).

Until next time!

Tony

This article describes how to configure Azure Active Directory as the SAML Identity Provider (IdP) to change the default AWS Console timeout from 1 hour to a different value.

It seems there has been a lot of discussion about how to change the timeout and there is no clear documentation from AWS how to achieve this with Azure AD.  As an example of the confusion, have a look at this discussion thread:

https://forums.aws.amazon.com/message.jspa?messageID=733264

Some good guidance is provided on how to achieve this with ADFS, as described here, but I haven’t yet seen any guidance for Azure AD.

OK, here’s how to do it.  (Note that this assumes you have already configured the AWS Console to work with Azure AD via SAML)

Go to your Azure Portal and open the Single Sign-On blade for your Amazon Web Services Console application.  Under the User Attributes section, select the checkbox to expose other user attributes, as shown below.

1

 

Select the option to add a new attribute.

2

In the Add attribute blade, set the Name value to “SessionDuration” (note that this tag is case sensitive), the Value to the timeout in seconds that you want, and the Namespace to “https://aws.amazon.com/SAML/Attributes“. Then click OK.

3

The net result should look like this:

4

Save the changes and you are ready to go and test the new timeout.

For more information on the SessionDuration attribute, please see the AWS documentation here:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html

Tony

 

I’ll get to the problem with Powershell Execution Policy shortly, but first a bit of background…

If your AAD/O365 admin accounts are configured for multi-factor authentication (which they should be, because it’s free), you will likely be familiar with the Exchange Online PowerShell Module, which is designed to work with MFA.  Getting to the Module download is not blindingly obvious.  Go to the Hybrid menu option in the Exchange Admin Center and select the second option as shown below.

ps0

 

Once it is downloaded you can launch it and sign-in using the Connect-EXOPSSession command.

OK, that’s all the background.  On with the meat of this article…

Once you’re up an running you might, like me, want to run a script within the session.  This is where things got tricky.  In my case I wanted to run the AnalyzeMoveRequestStats.ps1 script to, well, analyse my mailbox move request statistics as described here.  When I tired to dot source the script as described in the article, I received the standard error you often see when you haven’t got your execution policy set correctly.

ps1

But when I checked my execution policy things looked OK.

ps2

So, what was going on?  After a bit of research, I found there are several different types of execution policy that come into play, as described here.  You can list the current policies by adding the “-list” parameter to the Get-ExecutionPolicy cmdlet.  In my case the current session (Process) was set to RemoteSigned.

ps3

 

The RemoteSigned option was clearly insufficient for my needs, so I had to set it to Unrestricted using the command, Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted.

ps4

 

After running the command, the ExecutionPolicy for Process now showed as Unrestricted.

ps5

I could now dot source the script.

ps6

Note that you will need to change the execution policy each once per session if you are running scripts in this way with the Exchange Online Powershell Module (MFA version).  There is likely a simpler way to set this permanently, but I quite like the fact that the module re-sets the security each time in this way.  Setting the execution policy to Unrestricted permanently is not a good practice.

Please leave a comment if you know of a different way of achieving the same result – especially if easier ;-)

Tony

I got caught by surprise earlier today when I was looking at some of my older blog posts. It turns out my first entry was on the 10th March 2008. Happy 10th birthday Open a Socket!

Thanks to all of you who have supported me over the years with comments, words of encouragement, and for keeping the verbal abuse to a bare minimum.

Tony

Actually, this is more of a question than answer – although I have an answer of sorts, albeit far from elegant.

I’ve been scheduling some batch onboarding mailbox migrations from a hybrid environment with Exchange 2010 to Exchange Online.  The batch process is pretty straightforward, but I haven’t found an easy way to dump the list of users within the batch after it has been created.  Of course if you are using the CSV import method of populating the batch this is a bit of a non-issue.  However, if you’re creating the batch manually you might want to check back in at some point and remind yourself who is in the batch – or you might want to export the list to send to someone else.  Now I’m not entirely new to Powershell, but I can’t see any obvious way to do this easily.  Here’s what I ended up with:

(Get-MigrationBatch -Identity “MyBatchName” -IncludeReport | select -ExpandProperty report).entries.message.formatparameters | ?{$_ -like “*@*”}

Ugly, isn’t it?  The above command will provide a list of email addresses of the mailboxes within the batch.

If you have found an easier way of doing this, please post a comment below.