Earlier this week, I had a need to produce a list of Guest users in an Azure AD tenant who had not yet redeemed invitations that had been sent to them. It took me a little while to figure out the Powershell query for this, so I thought I would share it here.

The state of the Guest user is buried in the ExtensionProperty attribute that is returned from the Get-AzureADUser cmdlet.

For Guest users that have redeemed their invitations, the value returned is ‘Accepted’, while for those who have yet to accept the invitations the value is ‘PendingAcceptance’.

The query to find all Guest users who have not yet redeemed their invitations looks for the ‘PendingAcceptance’ value as follows:

The other day I tried (and failed) to find an easy way to query which applications were assigned to a specific Azure AD Application Proxy Connector Group. Of course if you only have a few applications, you can simply grind through each application in the Azure Portal and view the assignment (see screenshot below).

If, on the other hand, you have a large number of applications, grinding through each application individually will be more than a little frustrating. As always, Powershell offers a simpler way to get the result you need.

There are a couple of cmdlets that at first look appear to be very helpful: Get-AzureADApplicationProxyApplication and AzureADApplicationProxyApplicationConnectorGroup. Unfortunately, these are quite limited in their scope. What I was looking for was a cmdlet that would give me all the applications that use the Azure AD Application Proxy and include the relevant connector in the output. Those two cmdlets can’t do that. This is the closest I could get.

If you’re working as part of a team in Azure AD Identity Protection and want to know who dismissed a risk event (e.g. a risky sign-in), it’s not obvious where to find the information. This article explains how to do it.

Let’s take an example. You go into the Azure AD Identity Protection blade of the Azure portal and find a risky sign-in event.

At this point I’ve assessed that the risk is something I know about and am comfortable with dismissing it. I go ahead and dismiss the event. Now, if another administrator comes along, how can they find out who dismissed the event? The answer lies in the Azure AD audit log.

Go to the Azure AD blade within the Azure portal and select the Audit Logs option under the Monitoring section.

In the right-hand pane, change the Category to “Other” and the Activity to “Admin dismisses/resolves/reactivates risk event”.

From here you can determine who dismised the event as shown in the screenshot below.

Last week I spent a fair amount of time trying to integrate the Trend Micro Deep Security as a Service product with Azure AD using SAML. Unlike most of the SAML work I’ve done with Azure AD this one was not entirely straightforward. At the time of writing Trend Micro had no documentation specific to using Azure AD as the SAML Identity Provider. They also haven’t thought to work with Microsoft on getting their product into the App Gallery.

If you have to go through the process hopefully this will save you some time.

I’m going to assume you already have some experience with Azure AD and SAML.

Step 1. Download the Service Provider (SP) metadata XML

On the Administration tab of the Deep Security portal look for SAMLbelow the User Management->Identity Providers node in the left hand pane.

Select the Download option and save the XML file locally. Open in an XML editor (I use Notepad ++) to view the contents. You will need this to extract certain values for use with Azure AD.

Step 2. Create a new Enterprise Application in Azure AD

In the Azure Portal, select Azure Active Directory and choose Enterprise Applications blade. From there create a new non-gallery application and name it, e.g. Trend Micro Deep Security as a Service.

On the Single Sign-on blade select SAML-based Sign-on.

Copy the Entity ID value from the metadata XML file you downloaded in Step 1 and enter it into the Identifier (Entity ID) field.

Copy the AssertionConsumerService Location value from the metadata XML file and enter it into the Reply URL field.

The values should appear the same as (or similar to) the screenshot below.

Save the configuration and download the AAD Identity Provider metadata XML. You will need this for upload into the Deep Security portal.

Step 3. Add a new SAML Identity Provider in Deep Security

Back in the Deep Security portal, select the option to add a new Identity Provider. You will find this option in the Administration tab below User Management->Identity Providers->SAML.

Browse to the Identity Provider metadata XML file you downloaded at the end of Step 2.

Once it is uploaded, provide a name and description for the Identity Provider. I recommend you use AzureAD as the name (make a note as you will need this later).

Finish the wizard.

Step 4. Create a new Full Access role in Deep Security.

At the time of writing, Azure AD can’t cope with a space in the roles claim value, so you will need to create a new Full Access role in Deep Security that has a name with no space (e.g. FullAccess).

Modify the values in the wizard so that the permissions for the new FullAccess role match those of the built-in Full Access role.

Save the changes.

Make a note of the URN value for the newly created role.

Step 5. Add attributes to the Azure AD Enterprise Application

Deep Security requires specific attributes to be present in the SAML response token. You will need to add two new attributes named RoleSessionName and Role to the Enterprise Application you created previously. The reason for adding them now, as opposed to when you created the application is because the Role attribute requires the URN elements generated in the Deep Security portal after the import of the AAD Identity Provider metadata.

You add new attributes on the Single Sign-On page of the Enterprise Application in the AAD section of the Azure Portal.

Let’s take the RoleSessionName attribute first as this is the simplest.

Each Enterprise Application that you create in Azure AD creates its own Application Registration. In order to create role definitions that match those you’ve created in the Deep Security portal, you will need to edit the manifest associated with the application you have created in Azure AD.

To find your application registration in the Azure Portal, open up the Azure Active Directory node and select App Registrations. Change the default view from My Apps to All Apps and search based on the name of the application you created for Trend Micro Deep Security. Select Manifest to open the Manifest editor.

Under the appRoles node within the JSON file, select and copy the definition of the “User” role. Be sure to copy the entire definition including the start and finish braces and paste below the “User” role definition. In the part you have copied, replace the displayName, id, description and value definitions so that you have a new role named FullAccess. For the id you simply need a unique GUID (you can generate one from www.guidgenerator.com). Your edit should look similar to the screenshot below.

Save your changes to the manifest.

Note that spaces are not currently permitted in the “value” part of the role definition, which is why we had to create our FullAccess role based on the the built-in FullAccess role in Deep Security.

Step 7. Assign users and/or groups to the new role

Once your FullAccess role has been defined in the manifest, you should be able to assign users and/or groups to the Enterprise Application you have defined in Azure AD. You do this by selecting the Users and groups option within the application.

Step 8. Test your sign-in

Now that you have assigned the FullAccess role to a user in Azure AD you are ready to test the sign-in. The application should be visible in the myapps.microsoft.com portal. If the configuration is successful, you should be able to access the Deep Security application portal.

And that’s it! Of course you are free to define extra roles by following the steps shown to define the role both in Deep Security and Azure AD.

As you can see this is slightly trickier than most SAML integrations. Hopefully it saves you some time if you have to do it. With a bit of luck Microsoft will add Deep Security as a Gallery application the near future and you won’t need to go through the pain.

OK, the title has a whole bunch of acronyms which may not be entirely familiar. Actually…if we’re being really picky I should probably say a whole bunch of initialisms, but that would digress into a whole different article when a perfectly good Wikipedia article already exists for that.

Anyway, PTA is the accepted short form of Pass-Through Authentication – one of the range of authentication options available with Azure Active Directory.

AADJ stands for Azure Active Directory Domain Join(ed). This is a state for a Windows 10 machine in which it is joined to Azure Active Directory for a given tenant organisation. It is materially different to Azure AD Device Registration and Hybrid Azure AD Join, as neatly described here.

If you’re already set up with Azure AD Connect, have AADJ devices and are using PTA for your user sign-ins then you should be aware of an important limitation with respect to the “User must change password at next log on” flag. The flag itself is set on the user object in on-premises Active Directory. If you’ve been around a while, you’ll already be familiar with the setting - it looks like this:

The setting is used in a number of organisations to deal with the following situations:

User has forgotten their password and the Service Desk assigns them a temporary password to get them going again

New hires who are assigned a temporary password to start them off

So what’s the problem with setting this flag in our PTA, AADJ scenario? Well, quite simply the user won’t be able to sign-in to their Windows 10 machine. Instead of the user being prompted to change their password when entering the credentials that include the temporary password, the user sees the generic, “The user name or password is incorrect. Try again”.

Hopefully Microsoft will provide a resolution to this in the near future. At the time of writing the behaviour is seen as “by design” in so far as the error generated on the DC to which the credentials have been passed cannot be successfully translated back to the point where the sign in attempt occurs.

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:

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.

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.

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.

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.

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!

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

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.

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).

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:

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.

Select the option to add a new attribute.

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.

The net result should look like this:

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:

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.

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.

But when I checked my execution policy things looked OK.

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.

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.

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

I could now dot source the script.

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

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: