Over the past year I’ve spent significant time diving into the weeds of Azure AD and Azure AD Connect. In previous posts I’ve covered what happens behind the scenes when a user authenticates to Azure AD, whether it be a MS Live ID, Azure AD “cloud” identity, or a federated identity. Today I will be beginning a new series exploring how SharePoint Online and OneDrive for business leverage Azure AD for authentication and authorization services as well as an identity data store.

Before I begin the series I want to discuss the setup I will be using.

• Domains: feltonma.com, journeyofthegeek.com, geekintheweeds.com
• Azure AD Tenant 1
  Name: feltonma.onmicrosoft.com
  DNS Domain: feltonma.com
  Subscriptions: Azure AD Premium, Office 365 Business Premium

  We’ll refer to this instance of AAD as the destination AAD.

• Azure AD Tenant 2
  Name: journeyofthegeek.onmicrosoft.com
  DNS Domain: journeyofthegeek.com
  Subscriptions: None

  This is an independent instance of AAD.

• Azure AD Tenant 3
  Name: junkfelton.onmicrosoft.com
  DNS Domain: None
  Subscriptions: None

  This instance of AAD has been provisioned by a global admin of the destination AAD. This means that the global admin has the ability to add users from this instance of AAD to the destination AAD through the Azure Management Portal.

• Azure AD Tenant 4
  Name: geekintheweeds.onmicrosoft.com
  DNS Domain: geeksintheweeds.com
  Subscription: None

  This instance of AAD doesn’t exist yet. It will be provisioned when we leverage the B2B feature to invite a user that has an email address with the geeksintheweeds.com domain name.

The above will provides a good pool of AADs to play with different scenarios. In my next post I will provide a high level overview how AAD comes into play when sharing content in SharePoint Online and OneDrive for Business.