Skip to content

Azure AD Blog Posts

In case you were not aware of the following couple blogs, want to bring them to your attention. Great source of information on what happening with Windows Azure Active Directory.

All of the recent developments with Azure AD are very exciting. The central application access panel I think is going to be used a lot and will provide very convenient way to publish and access hundreds of different applications. As of today it provides access to 926 applications. When it was first introduced back in the summer of 2013, I think it had only about 30 applications. At some point it will probably provide access to most known apps out there in the wild, and I’m hoping that it will allow to put your own LOB apps on the same page as well.

About these ads

Work Place Join Adventures

I’ve been working in my lab with Windows 2012 R2 AD FS and decided to test Work Place join functionality.

I configured my AD FS with device registration. You can read it here on how to do that.

I installed Web Application Proxy (WAP) and made it available via network to my Surface with Windows 8.1. You can read it here on how to do that.

Also, I configured proper DNS resolution so the device can resolve WAP via proper name. One of the above links talks about it as well.

Then I tried to workplace join my Surface device. It failed. I tried all kind of things to fix it, to no avail. So finally I contacted Microsoft Support and after a few hours of troubleshooting we figured out why it was not working and how to make it work.

What we discovered is that WAP and ADFS servers didn’t have SSL binding for the following name:

EnterpriseRegistration.myfeddomain.com:443

Tip: To see current bindings run this command:

netsh http show sslcert

So when Surface device tried to connect to registration URL, the connection was terminated by the WAP server.

I have four different test ADFS environments and decided to see if all of them had the same issue or not. So I ran that command in all four implementations and saw an interesting pattern.

When ADDS name of the domain where ADFS was installed matched Federation Service name, then the required binding was present. When ADDS name did not match the Federation Service name then the required binding was not there and work place did not work. Ok, if you not follow me, lets take a look at some examples.

Let’s say, my ADDS name is CONTOSO.COM and when I install ADFS, I give it the following name FS1.CONTOSO.COM. Name space of the ADDS and Fed Service is the same. If you look at SSL binding you will find EnterpriseRegistration.contoso.com:443

If we look at a different design, with the same ADDS Domain (CONTOSO.COM), but we install ADFS with different name, such as FS1.MYFEDDOMAIN.COM. If you look at SSL bindings you will not find required name for device registration.

When ADFS is installed with different name then the ADDS name, it does not create required SSL binding.

But, no worries. It is actually easy to add this binding and enable device registration to work. All you have to do is to run two PowerShell commands.

To make it work, first I had to run this on ADFS server:

Add-AdfsDeviceRegistrationUpnSuffix -UpnSuffix “myfeddomain.com”

It added EnterpriseRegistration.myfeddomain.com SSL binding to ADFS server.

Then I had to run this on WAP server to get the same binding registered as well:

Update-WebApplicationProxyDeviceRegistration

In my test environment I have my users in the following naming convention User@myfeddomain.com, and device registration started to work as expected.

Let me know if you got any questions.

Access O365 on Demand, Part 3

This is the third installment, please read the prior two posts (Part1 and Part2) to get up to date on what this is all about.

So while the following solution will likely work as described, as far as I know it is not officially supported. So if you implement it and have some issues and contact Microsoft support services, you’ll more likely be asked to reproduce the same issue without external federation.

The following concept design will allow to extend authentication to the external identity providers.

1. First, we federate our O365 Tenant. To do this we will need to have ADDS where we implement DirSync and synchronize accounts from ADDS into Windows Azure Active Directory tenant. Then we install ADFS and federate it with the same tenant.

Now when users try to use accounts for this O365 tenant they will be redirected to the ADFS for authentication.

2. Next, create accounts for external users in ADDS. Link external accounts to their corresponding accounts in ADDS. In this example I’m taking UPN of the external account and put it the “comment” attribute of the ADDS account. This step is obviously the most difficult one in this whole solution. You can do it by hand or come up with some type of Identity Management solution that automates it. As accounts get created in ADDS they will get synchronized into Azure Active Directory via DirSync that was implemented in first step. By default DirSync runs every three hours. If it needs to be more often then you’ll have to trigger it on more frequent schedule.

3. You have to figure out how you are going to activate accounts in O365, as DirSync does not do that for you. You can do it by hand or via PowerShell script.

So far nothing different from any other basic implementation of the O365 and federated ADDS.

4. Next we are going to extend this solution with external Identity Providers. We create normal trust with ADFS acting as RP and external Identity Provider as IdP. One of the super important things to know is that external IdP must be able to provide Authentication Information to the ADFS – ie it must provide information on how user authenticated to IdP and the time stamp of the authentication,  AuthenticationMethod and AuthenticationInstant. For example, none of the Social IdPs are providing such info. Without these assertions it will not work, as O365 requires these assertions.

5. On the incoming trust claims rule of the IdP in ADFS, create the following three rules:

Rule 1:

image

Rule 2:

image

Rule 3:

image

These rules will use incoming UPN from the external IDP and lookup corresponding account in ADDS, and fetch its samAccountName. The result of these rules is the windowsaccountname claim that contains value of the linked user. This claim is used as input claim by the default ADFS O365 claims rules to lookup user UPN and ObjectGUID in ADDS.

That is pretty much all to it.

After implementing above steps, here is how authentication should work:

image

  1. User goes to the https://portal.microsoftonline.com and type their ID for the O365 SharePoint portal (for example, MikeJonesFabrikam@contoso.com)
  2. Since O365 tenant is federated, it redirects user to AD FS. Instead of authenticating directly to AD FS they are redirected to their home IdP – Fabrikam.
  3. They authenticate to their IDP, for example with smart card.
  4. Their home IdP issues required claims and sends user back to AD FS.
  5. AD FS does AD DS account lookup, does all the claim transformations and issue outgoing claims for O365.
  6. User authenticates into O365 with token issued by AD FS.

 

Give it a try and see if it works!

Access O365 on Demand, Part 2

This is the second installment on extending access to O365, read the first installment to get a better idea of what I’m discussing here. In the first part I shared what type of functionality this customer wanted and asked if there are any ways to do it.

So before we dig deep into any type of solution solving their needs we need to examine how O365 authenticates users and see if we can use it in our solution.

Probably the main thing to understand about authentication into O365 SharePoint is that it must start at O365 site: https://portal.microsoftonline.com and you must have an account with O365. You can’t start authentication into it from other portals or identity providers (if you know how I’m all ears!).

So the most basic configuration to access the site is to have an account in it and authenticate with this account into the site. The O365 subscription administrator would create such account for the user and provide initial password. The account can be in two different formats:

  1. <yourname>@<tenantid>.onmicrosoft.com
  2. <yourname>@<customerdomainname>

Most customers would add their <customerdomainname> as the suffix in the account name. This is what my customer is doing with their O365 at this moment as well. They create accounts for external users and communicate account information to them. As I discussed in the first part, they would like to get out of manual account creation and account management.

The next possible authentication solution for O365 is the integration with customer on-premises AD DS via DirSync. The DirSync is installed on one of the on-premises servers and it is used to synchronize accounts from on-premises AD DS into the Azure Active Directory. The latest version of the DirSync even can synchronize passwords. User is still authenticating into O365 via O365 based accounts, by typing their user account and password. The good part here is that those users use the same user account (their UPN) and password as they would use on their internal network. With this option, account must be in the form of yourname>@<customerdomainname>, this is required for DirSync functionality.

As you can see, it does not provide any benefit to the problem that my customer is trying to solve. They would still have to create accounts manually and deal with password management.

The third possible authentication solution is to enable federation between O365 and the customer on-premises environment. This is probably most used option in enterprise environments. Federation is added to the configuration with DirSync already in place (in large environments FIM 2010 R2 is used often as well). After federation is added, when user types their user account at O365 logon page, they are redirected to the Identity Provider STS implemented at on-premises customer environment. If user is connected to the internal on-premises environment then they’ll more likely get single sign on (SSO) experience. If they are outside, then they will be prompted to authenticate to their company Identity STS and then they’ll get into O365. The most commonly used STS is AD FS 2.0, but other vendor products supported as well (like Shibboleth).

So we have three options to authenticate into O365. The first option is what my customer is using right now. The second option will not solve their problem. The third option might provide a foundation for what they are trying to do with their strategy to provide access to their O365 SharePoint environment.

The question is, can we do another hop in federation and extend the third option to external trusted Identity providers?

In the next installment I’ll share what I have learned so far in my trial and errors of extending federated O365 to second level Identity Providers.

Access O365 On Demand, Part 1

Recently one of my customers posed the following problem.

They have O365 SharePoint Online and they need to provide access to this site to many of their external customers.

They want to ensure high level of assurance of those users and it requires some type of multi factor authentication. One of their requirements is that external users should be able to access to their O365 SharePoint site on demand, without a long verification process for account creation.

The customers would come from a known set of e-mail domains or from a set of the trusted Identity Providers.

With O365 there is really no build in process to automate any of it so right now they have to create accounts in O365 for each of the new users by hand and provide full account management to these users, such as password management.

They are not happy about all of this overhead for multiple reasons:

  1. Account creation for external users takes too long. They have to verify the identity of the user via some type of out of bound process.
  2. They don’t want to get into business of managing passwords and other account management issues.
  3. They would have to pay premium for multifactor authentication with O365 for all those external users.

So they posed a question – is there any type of solution that would allow some type of automated account creation in O365 for external users, as long as they are coming from trusted known Identity Provider or they belong to organization with trusted known e-mail domain name?

While the requirements might sound not very complicated, in reality it is actually fairly hard problem to solve. I started thinking about possible solutions to this problem, trying to figure out if some of other integration solutions would allow us to provide a solution to this customer.

To satisfy the first requirement we’d have to come up with self registration solution. This is actually have been done and we can create accounts for external users based on their e-mail domain or register them if they are coming from trusted Identity Provider.

The second problem can be addressed by implementing SSPR solution with the account creation system or it can be fully outsourced to the trusted Identity Provider who manages accounts for those users.

The third problem can be addressed if the trusted Identity Provider can assure that they use some type of multifactor authentication.

And of course on top of all of this we have to figure out all the technical details and see if any of the possible solutions will actually work with O365.

Stay tuned for the next installment. I’ll share some details on how it can be done and some limitations.

Deploying AD DS in Azure IaaS

If you want to see and learn how to deploy new AD DS Forest into Azure IaaS then check out my new video demonstration. Make sure to watch it in HD.

Deploying AD DS in Azure IaaS from Dmitrii on Vimeo.

WAAD AS IdP

In my prior two posts I demonstrated how WAAD can be configured as IdP. In this post we document this on paper. The configuration is very simple, but so far I could not find it documented anywhere, so here it is for anyone interested.

In first scenario we will configure WAAD as IdP for Azure ACS. Like shown on this diagram:

image

To configure ACS as relying party in WAAD you need to do the following:

  1. Add new application in your WAAD tenant
  2. Name it whatever you like it
  3. For App URL:, put the following URL https://<your-acs-name>.accesscontrol.windows.net/ , where <your-acs-name> is the name of the ACS you created in your Azure subscription.
  4. For App ID URI:, put the same URL as in previous step.
  5. Save configuration.

Of course you’ll need to add WAAD in ACS as IdP as well.

In second scenario we will configure WAAD as IdP for AD FS. Like shown on this diagram:

image

To configure AD FS as relying party in WAAD you need to do the following:

  1. Add new application in your WAAD tenant
  2. Name it whatever you like it
  3. For App URL:, put the following URL https://<your-sts-dns-name>/adfs/ls/ , where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com)
  4. For App ID URI:, put the following http://<your-sts-dns-name>/adfs/services/trust, where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com).
  5. Save configuration.

Of course you’ll need to add WAAD in AD FS as IdP as well.

There is no mechanism to configure WAAD as to what type of claims it will provide to RP. It is hard coded to provide half a dozen claims for the user. If you need to get information about the user that is not passed via claims you’ll have to use Graph API to query WAAD and find that information programmatically (your app will have to do this).

Follow

Get every new post delivered to your Inbox.