Behind the curtains: Authentication to Azure with a Managed Azure Active Directory Account

Welcome back. Last post we took a look at how Microsoft handles the authentication of a Microsoft Live account to a Microsoft Azure resource. Today we are going to look at the authentication of an Azure Active Directory identity to a Microsoft Azure resource. We’ll follow it up with a post comparing the two authentications. From there, we’ll go into some more advanced scenarios such as synchronized Azure Active Directory identities, both federated and with password synchronization.

For this scenario we will be using an Azure Active Directory account with a username of tempaccount@journeyofthegeek.onmicrosoft.com that is not configured with MFA. The resource at Microsoft Azure we will be attempting to access is the Microsoft Azure Management Portal.

The first step is to navigate the browser to https://manage.windowsazure.com/ which will redirect us to https://login.microsoft.com with an OAuth 2.0 authorization request included in the header. Let’s take a closer look at the authorization request:

  • The response_type parameter is set to code id_token which is requesting the response from the authorization server contain an authorization code and id token for the user after the user authenticates. The id token will be an Open ID Connect 1.0 identity token that will be returned from Open ID Connect Provider.
  • The redirect_uri parameter is set to https://manage.windowsazure.com/ which indicates the endpoint the code and id token should be returned to.
  • The client_id parameter is set to 00000013-0000-0000-c000-000000000000. This is the unique value that will identify the client to the authorization server.
  • The resource parameter is set to https://management.core.windows.net/ . This is used by Microsoft Azure to determine what Azure API the access token will be used for.
  • The scope parameter is set to user_impersonation openid which indicates the client wishes to impersonate the user and be returned an Open ID Connect id token.
  • The nounce parameter is set to bd3cc2f1-db26-4663-937b-fd0ede3e9d76. It is a unique value used to help prevent replay attacks.
  • The site_id is set to 500879 is an identifier which will be used in later authentication and authorization calls.
  • The response_mode is set to form_post which instructs the browser to post back the response in form encoded format.

Screen-Shot-2016-04-03-at-11.23.37-AM (1)

We are then redirected to the home realm discovery URI at https://login.microsoft.com with some queries attached to the URI. Let’s break down the query strings:

  • The user parameter is set to tempaccount@journeyofthegeek.onmicrosoft.com which is the username of the account we are attempting to authenticate with.
  • The api-version is set to 2.1.
    · The stsRequest is set to rQIIAYWQsUvDQBSHvaYW6tIiKurUIZNwSS5pk7a4uFrQXZByyb3YILkLyZVC_4y6uQiOWYRO0qmzU1d1c1Bnp4KCJpYK4uBv-N7jveXjt6cQjbRV4zvEwvlYwFtuyxyWGobRdFrx-lr16qJ7Ot3CnfFNRdv_-KxeopUU1XpSRklb10PK6Rlog4AzMUjosB-D5olQv0VohtArQmlBdZnleaZPMHNNG9dt28Ity3GxzwxgYEGLOfZDoXJ80Jc9M4eIgyE8_bm8Fcq-iMNuJBI5UiqC5l8tpycYjJRNEQEPmCc4B09qAZPiHHiqqL9lQ-Ayc4x_rDUOUh8rpcw7FHyiqE2DgeGSBjYblpUJmwRT4tuYMMpspw7EbNh3yk4_gbgbhBHEieBUBoLXFgazIpoX0fVq1t7J7vyFHk076eNs4_l–31S_re6Lw2.
  • The checkForMicrosoftAccount is set to True. See my previous post on this parameter.

Screen-Shot-2016-04-03-at-12.26.03-PM.png

We are returned the results of the home realm discover in JSON format. Here is a breakdown:

  • The cloudinstancename attribute has a value of login.microsoftonline.com.
  • The DomainName attribute has a value of journeyofthegeek.onmicrosoft.com which is the domain associated to the Azure Active Directory instance in the Journey of the Geek tenant.
  • The FederationBrandName attribute has a value of Journey Of The Geek.
  • The Login attribute has a value of tempaccount@journeyofthegeek.onmicrosoft.com and is the username of the account that needs to authenticate.
  • The MicrosoftAccount has a value of 1.
  • The NameSpaceType has a value of managed.
  • The TenantBrandingInfo has a value of (null)

Screen-Shot-2016-04-03-at-11.31.27-AM (1).png

After home realm discovery our browser’s next step is another URI at Microsoft: https://login.microsoftonline.com/common/login. Here we provide our user name and password and authenticate via forms-based authentication. We are returned an authorization code and id token which are posted to a hidden form which is submitted to https://manage.windowsazure.com/
The browser then posts the authorization code and id token to a hidden form which is submitted to https://manage.windowsazure.com/.

Let’s take a closer look to the id token after translating it through an online JWT decoder.

{
typ: “JWT”,
alg: “RS256”,
x5t: “MnC_VZcATfM5pOYiJHMba9goEKY”,
kid: “MnC_VZcATfM5pOYiJHMba9goEKY”
}.
{
aud: “00000013-0000-0000-c000-000000000000”,
iss: “https://sts.windows.net/80b0dae2-f20b-4799-8f5b-3edea102c1b9/”,
iat: 1459696162,
nbf: 1459696162,
exp: 1459700062,
amr: [  “pwd” ],
c_hash: “4O-PWHH6DWDpynoLAfZONQ”,
family_name: “User”,
given_name: “Temp”,
ipaddr: *IP ADDRESS*,
name: “Temp User”
nonce: “bd3cc2f1-db26-4663-937b-fd0ede3e9d76”,
oid: “4079133e-7ead-4dd7-873c-f9474546b3fd”,
puid: “10033FFF971B6997”,
sub: “k5yesp1huTThDmvsK5D8bn-LPm4EecL3mofBXr20R_Q”,
tid: “80b0dae2-f20b-4799-8f5b-3edea102c1b9″,
unique_name:”TempAccount@journeyofthegeek.onmicrosoft.com”,
upn: “TempAccount@journeyofthegeek.onmicrosoft.com”,
ver: “1.0”
}.
[signature]

Here are the interesting claims:

  • The audience (aud) claim has a value of 00000013-0000-0000-c000-000000000000. This is the clientID of the application.
  • The issuer (iss) claim has a value of https://sts.windows.net/f8cdef31-a31e-4b4a-93e4-5f571e91255a/ which is the STS for the Journey Of The Geek tenant.
  • The authentication methods reference (arm) claim has a value of pwd which indicates the user authenticated with a password.
  • The family_name claim has a value of user which was configured in Azure Active Directory as the user’s last name when the account was setup.
  • The given_name claim has a value of Temp which was configured in Azure Active Directory as the user’s first name when the account was setup.
  • The name claim has a value of Temp User which was configured in Azure Active Directory as the user’s display name when the account was setup.
  • The unique_name claim shows TempAccount@journeyofthegeek.onmicrosoft.com.
  • The upn claim shows TempAccount@journeyofthegeek.onmicrosoft.com.

We are then directed to another URI at https://manage.windowsazure.com, for our Journey Of The Geek tenant. The redirect URI then redirects the browser to an error page at https://manage.windowsazure.com which notes the account is not associated with a Microsoft Azure subscription.

Let’s sum up what we learned:

  1. Azure Active Directory managed accounts authenticate to Azure Active Directory using forms-based authentication.
  2. The identity token for an Azure Active Directory managed account contains additional attributes not present in an identity token created for a Microsoft Live account.

In the next post we spend more time looking at the differences in this authentication in comparison to the authentication of the Microsoft Live account. Moving on from there, we’ll spend some time taking a deeper look at federated Azure Active Directory identities.

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