Zulfiqar's weblog

Architecture, security & random .Net

Federating Office 365 (Azure Active Directory) with a Custom STS

Posted by zamd on February 8, 2013

Let’s start of with a clarification: As of today, federating Office 365 (Azure AD) with a Custom STS is NOT supported by Microsoft.  Today the only supported STSs are AD FS 2.0, Shibboleth 2, Optimal IDM Federation Services and PingFederate 6.10.

With that cleared, Office 365 STS supports both WS-Federation & SAML protocols for user authentication which means technically any compatible STS can be used as the Identity Provider STS for Office 365 services or other Relying Parties with a trust relationship with Azure Active Directory.

Azure AD supports In-cloud & Federated Identities.

With In-Cloud identities all user information, including the passwords, are stored in the online directory.

With Federating identities, only basic information is stored in online directory (as shadow accounts) and user identities are mastered in on-premise directories. Passwords are never copied to online directory and Azure AD relies on federation for user sign in.

A key prerequisite for Office 365 SSO is to create federated identities (shadow accounts) in Azure AD and there are different options/tools to do this.

  1. DirSync is the recommended tool but it only supports Active Directory as the identity source. DirSync & AD FS 2.0 are the primary tools to enable federation between an on-premises AD and Azure AD.
  2. Graph API is a new RESTful API to manage online directory and looks very promising for creating cloud-only identities. Graph API today doesn’t support creating Federated identities.
  3. MSOL PowerShell cmdlets: These cmdlets use the SOAP based Provisioning Service and are functionally quite rich. They support most of the operations including the creation of federated identities. I have used these cmdlet for my scenairo. Few commerical tools also wrap these cmdlets to perform various Office 365 provisioning operations.
  4. Forfront Identity Manager (FIM) is another potential option which can create Federated accounts from source directories other than AD but I haven’t explored that in detail.

Now once you have the federated identities provisioned (or synced from your on-premises user identity store) in Azure AD, the next step is to establish a trust relationship between Azure AD and your custom STS. This is assuming you have already done the domain verification etc.

I have used Set-MsolDomainAuthentication cmdlet for this.

Set-MsolDomainAuthentication –DomainName bccoss.com –federationBrandName bccoss.com -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logoutUrl -PreferredAuthenticationProtocol WSFed


At this stage, if I browse to the Microsoft Online Services portal (http://portal.microsoftonline.com/) and choose to login using my federated domain (@bccoss.com) – I got redirected to my custom STS.

In this case, I’m using Thinktecture STS but that doesn’t work out of box with Office 365 / Azure AD so I have to modify the STS to make it compatible with Azure AD. I’ll explain the Office 365 compatibility requirements of an STS in a future post.

I’ll also try to contribute my Thinktecture modification to code back to git at some point.

image image

image image

image image


11 Responses to “Federating Office 365 (Azure Active Directory) with a Custom STS”

  1. Andreas said


    I am triying to set up the same thing. Could you explain what modifications need to be done to identityserver v2?
    Have you been able to set it upp for multiple tenants?


  2. Andreas said

    I get this error message when i get redirected to the login-page of identityServer.
    Invalid realm: urn:federation:MicrosoftOnline

    What changes did you have to do?

  3. Job Vermeulen said

    Are the changes already online somewhere?

  4. BK said

    I’ll explain the Office 365 compatibility requirements of an STS in a future post — What are Office 365 compatibility requirements? plz let me know.

  5. Martin said

    I’m trying to do a similar thing, using thinktecture exactly as shown above, can you detail the changes & configs that i need to make so the correct values get posted back to login.microsoftonline.com ?

    I keep getting error 80045C17 which is not very helpful.



  6. RP said

    Hi Martin,

    Even we tried to configure SSO into Office365 using our Custom STS but we always getting the 80045C17 error. Were you able to fix this issue? Your help is very much appreciated

  7. SK said

    I managed to generate claims with proper namespaces by customizing the IdSrv code. Only difference compared to ADFS generated token is RSTRCollection in IdSrv vs just RSTR in ADFS. Still the SSO is not working. No error or O365 login page. But I can see MSPPError=-2147216599 code on browser. Please let me know if I am missing some thing.

  8. zamd said

    Hi Guys,
    There are few small differences in the SAML token required by Azure AD so make sure you generated SAML token matches following assertion. Note difference in Signature algorithm, NameIdentifier and few other bits…










Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: