Zoho Banner September 2011

Archive for the ‘Azure Active Directory’ Category

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.

AAD Identity Protection 7

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

AAD Identity Protection 10

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

AAD Identity Protection 9

And that’s it!

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 SAML below 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.

Name=RoleSessionName, Value = user.userprincipalname,  Namespace=https://deepsecurity.trendmicro.com/SAML/Attributes



The Role value is the tricky on as it has a very specific syntax as defined here.

Name=Role, Value = urn:tmds:identity:[pod ID]:[tenant ID]:saml-provider/[IDP name], urn:tmds:identity:[pod ID]:[tenant ID]:role/[role name] , Namespace=https://deepsecurity.trendmicro.com/SAML/Attributes

In my example, the Value becomes: urn:tmds:identity:us-east-ds-1:55151:saml-provider/AzureAD,urn:tmds:identity:us-east-ds-1:55151:role/user.assignedroles

The URN values are derived from those generated inside the Deep Security SAML configuration.  The AzureAD in bold above is the IdP name we used when defining the Identity Provider in Deep Security.

Creating the correct syntax when adding the attribute involves using the Join() function as shown below.   This is to separate the URN sequence from the built-in user.assignedroles definition.


This was the value I put into the first part of the join (as it may not be clear from the screenshot above):


Note that the trailing forward slash is required.

Save the updates to the enterprise application.

Step 6.  Manually edit the Manifest associated with the application

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:


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.


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.


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:


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!



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


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

Until next time!


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:




Here’s something I discovered recently and would like to share with you.  If you are using Skype for Business Online and want to control access to it using Conditional Access policy, you should be aware that under certain circumstances the control can be completely bypassed.

The problem has to do with the fact that Conditional Access only kicks-in when the authentication attempt is from the following:

-A web browser
-A client app that uses modern authentication
-Exchange ActiveSync

Conditional Access is not processed by legacy clients, i.e. those that do not support modern authentication.  For example, the Skype for Business 2015 client (the one that ships with Office 2013, and without modern authentication enabled) cannot interpret the Conditional Access policy and as such will bypass the controls.

Let’s look at this in more detail.

In this example, I have created a new Conditional Access policy specifically for Skype for Business Online.

I want all users to be included in the policy.


I only want the policy to apply to Skype for Business Online.


And finally, I only want access to be permitted from Hybrid Azure AD devices (i.e. those that are joined to on-premises AD and device registered in AAD).


I’ve left all of the other settings within the policy at their defaults.  Once I’ve enabled and saved the policy the next thing to do is test whether it works as expected.

The first test is to determine whether the policy blocks access from the Skype for Business 2016 client (click-to-run version) running on a device that does not meet the Hybrid Azure AD condition.  As expected, the access is denied along with a friendly and reasonably helpful error message (shown below).



The second test is run from a machine that also doesn’t meet the Hybrid Azure AD condition, but this time the sign-in attempt is from the Skype for Business 2015 client.  In this test, the user is able to sign-in without any problems.


The Skype for Business 2015 client is effectively able to completely bypass the Conditional Access control, thereby rendering it effectively useless.  Your Skype for Business Online instance can be accessed from any device from anyone who has valid credentials.  The question is then what you can do about it?  There’s currently no silver bullet to handle this scenario.  Microsoft makes provision to block legacy client apps for SharePoint Online and, to an extent Exchange Online, but there is nothing obviously available for Skype for Business Online.

One workaround is to force MFA (at the Azure AD level) for the users that need to access Skype for Business.  With MFA enabled the user sees the following (spectacularly unhelpful) error when trying to sign-in from the Skype for Business 2015 client.


I understand that Microsoft are (as of November 2017) looking a method – currently in private preview – to address issues with legacy clients and Conditional Access, not just for Skype for Business, but across the board.  Watch this space.




I recently had a challenge with a customer that had on-premises Skype for Business (SfB) and were looking to migrate to SfB Online. They did not want to federate the two infrastructures, but instead wanted to undertake a re-pointing of users at a given point in time by modifying the DNS records. When they introduced AAD Connect the default synchronisation included the SfB attributes, which is standard behaviour when AAD Connect detects that the schema extensions for SfB are present in on-premises AD. The presence of SfB-related user attribute values in the synchronisation flow caused SfB Online to detect all existing SfB on-premises users as hybrid. It meant my customer could not assign SfB Online access to synchronised users, which would have been a problem for testing the cut-over. The workaround for this was to modify the AAD Connect synchronisation rules to set the SfB attribute values to null.  The steps implemented to achieve this are shown below.

1. Stop the AAD Connect sync scheduler. 

From an elevated Powershell prompt run the following command

Set-ADSyncScheduler -SyncCycleEnabled $false

2. Open the Synchronisation Rules Editor and create an editable copy of the ‘In from AD – User Lync’ inbound synchronisation rule.



3. Set the new rule to have a higher precedence (lower numeric value) than the original rule. 



4. Leave the scoping filter as is, i.e. no change.



5. Leave the join rules as is, i.e. no change.



6. Edit the transformation for each of the shown values.  Change the flow type to Expression and the source to Authoritative Null.



7. Save the rule.

8. Start the AAD Connect Sync scheduler and run a full (initial) synchronisation by running the following Powershell commands:

Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Intial

9. Confirm that the synchronised users no longer appear as hybrid users in SfB Online.  Run the following Powershell command:

Get-CsOnlineUser | ft userprincipalname, interpretedusertype -AutoSize

Note. This command requires the Skype for Business Online Windows Powershell Module, available here.

The output should show your synchronised users with an InterpretedUserType of  ‘NoService’.  If any appear as ‘HybridOnPrem’ then the custom synchronisation rule has not taken effect.

The synchronised users should now be available to enable for Skype for Business Online.


Hopefully, this has been useful to you.  Let me know if you have any corrections or suggestions for improvements by adding a comment.


Last week I came across an issue when attempting to create a new custom synchronisation rule in Azure AD Connect. When I tried to finish the wizard and add the rule, I received the error: “Object reference not set to an instance of an object”.


The workaround is to add a tag to the rule on the Description page, as shown below.  The tag doesn’t need to be meaningful.


The issue appears to be specific to version 1.1.561.0 (July 2017) of AAD Connect. It wasn’t a problem in previous versions and it has been addressed in version 1.1.614.0 (September 2017).

For the latest of AAD Connect versions and version history, see https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history


I hit this problem while working with Azure AD Connect at a customer earlier this week.  The situation was that AAD Connect had already been configured with Pass-Through Authentication, which was working as expected.  The next step was to enable Seamless Single Sign-On, but this failed with the following: ‘Failed to create single sign-on secret for True’.


The trace log file showed this:

[ 18] [ERROR] EnableDesktopSsoTask: Failed to create desktopsso secret for myadds.org. Exception message: System.Management.Automation.CmdletInvocationException: Exception has been thrown by the target of an invocation. —> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

I immediately thought this was probably an issue with the firewall between the server running AAD Connect and the on-premises AD Domain Controllers.  The difficulty I had was that my customer’s environment was really locked down and I didn’t have access to the firewall or to the tools I would normally use to troubleshoot something like this. So, basically I decided to try and reproduce it with my own Azure AD environment.

As expected, the problem came down to a missing firewall port (TCP 445).  This port is (as of 3rd August 2017) not listed in the port requirements on this web site (Table 1):


In my first test, I configured the firewall rules a per Table 1, i.e. without port 445 and attempted to enable SSO via AAD Connect.  I received the same ‘The RPC server is unavailable’ error.

I then removed SSO manually using the Powershell method.


In my second test, I tried to enable SSO using the Powershell method.  Again, I see the RPC error.


Looking at the firewall logs, I see a failed connection attempt to the ADDS DC on port 445.

2017-08-02 13:09:47 DROP TCP 50423 445 0 – 0 0 0 – - – SEND

After adding port 445 to the allowed firewall ports, I re-attempted disabling + enabling SSO using the Powershell method.  This time the cmdlet completes successfully.


The status now looked good and confirms that the missing firewall rule allowing traffic from the AAD Connect server to the DCs on port 445 (TCP) was the culprit.


Interestingly, it looks like I would have hit the missing TCP 445 problem when enabling Pass-Through Authentication (i.e. prior to enabling Seamless SSO), but for the fact that I chose to use an existing AD Forest Account.  If I had tried to let the Wizard create the account required for PTA it would also have failed due to TCP 445 not being available.

Hopefully this should give you enough to go on if you come across a similar issue.

This post provides a quick introduction to the features available with Azure Active Directory Business to Business (B2B) Collaboration – currently in Public Preview.  I’ll cover how to add someone outside your organisation to your Azure AD instance, as well  as how to assign administrative privilege over the Azure subscription to the external partner through RBAC delegation.

Let’s kick things off by adding the external partner via the new Azure Portal. In this example the external partner is named Badger Lafarge and has an Gmail account.  My Azure tenant is named Fish Eagle.

Once logged into the Azure Portal, select Azure Active Directory from the left hand menu.


Select Users and Groups from the presented options.


Select All Users


The full list of existing users will appear.  Select the Add option.


Complete all the required information for the users and any additional profile and group in formation. Note that you have the ability to enter the text that will be sent into the body of the invitation email sent to the user.


You will see that in this example I have chosen to add the user to a group named MSDN Subscription Admins. This group has been delegated the Owner role to the Fish Eagle MSDN subscription.  I’ll show where this is configured later in the article.


After completing the setup, select Create.  At this point an invitation will be sent to the user, as shown in the example (Gmail) below.


The user then clicks on Get Started.  At this point Azure will determine whether an account (either in a different Azure AD or a Microsoft Account) already exists for the user based on the email address.  In my example, the user Badger Lafarge does not have any account, so one needs to be setup.  This is the normal Microsoft Account process and as such I don’t need to show it here.


Note that the welcome message indicates the invitation relates to access to myapps.microsoft.com.  While assigning access to apps within an Azure tenant to partners is probably the most common scenario, it is not the use case here and can be ignored.

After completing the account setup, the external partner (Badger Lafarge) is presented with the MyApps portal.  This shows the B2B setup workflow has completed successfully.  You can then see the partner account present in Azure AD.  Note the globe icon that indicates the external status.


Now that Badger Lafarge has been set up correctly, he can log into the Azure Portal using the credentials he configured as part of the Microsoft Account creation.  You can see from the following screenshot that once logged into the Azure Portal the external account (Badger) has access to the resources available in my tenant within my MSDN subscription (Fish Eagle).


With the Owner role assigned to my MSDN subscription, Badger can now do pretty much anything he wants to with my Azure resources.  He can stop and start machines, delete storage accounts, create new resource groups, generally do a lot of damage and spend up large!  This is by way of a warning – with great power comes great responsibility – be careful how you assign permissions and use the principle of ‘least privilege’ as you would normally.

In case you missed it earlier, not all external partners you add are automatically assign Owner rights over your subscription.  That would be madness!  Instead, when I created Badger as an external partner in my Azure AD I chose to add him to the MSDN Subscription Admins group.  This is not a built in group.  Instead it is a group I manually created within my Azure AD with the specific purpose of assigning Owner permissions over my subscription using Azure’s RBAC features.  Of course I could have assigned him the Owner role directly (i.e. not using an Azure AD group), but where is the fun in that?  The screenshot below shows where the Owner role assignment is configured within the Azure Portal.


That’s basically it.  Once you have the external partner in your Azure AD you can do other tasks such as assignment to your Apps (exposed via the MyApps portal) and delegation within our Azure AD instance.

What I really like about the B2B feature is how easy it is to set up within the Portal.  Hopefully that is clear from this blog post.