Welcome back. Today I will do a high level overview of the the options available for sharing information from within SharePoint Online and OneDrive for Business.

A SharePoint Online/OneDrive for Business subscription is associated with an AAD instance. Users that exist outside of that AAD instance are considered “external” users. Microsoft has configured four primary options for sharing information within SharePoint Online / OneDrive for Business. These options are:

1. Don’t allow sharing outside your organization
2. Allow sharing only with the external users that already exist in your organization’s directory
3. Allow external users who accept sharing invitations and sign in as authenticated users
4. Allow sharing with all external users, and by using anonymous access links

This link has a great explanation of the differences in each option from a functionality perspective, but I’ll spend some time on explaining what these things mean from an Azure AD perspective.

Option 1 is self explanatory if you read the above link so I won’t be covering that one.

Option 2 limits a user to sharing information with users who are directly members of their AAD instance or have already been configured as guest users. When a user attempts to add a user that doesn’t fall into those two categories, he or she observes the following error when attempting to share a SharePoint Online site (wonderfully descriptive by the way MS):

The error when attempting to share a OneDrive for Business folder is much more informative:

Option 3 limits a user to inviting users who have or obtain a Microsoft Live ID or Azure AD identity. When the user receives the invite and authenticates to AAD, the user is provisioned into destination AAD as a guest user. My next post will spend more time talking about guest users.

Option 4 is similar to Option 3 but additionally allows for anonymous access via shared links.

These sharing options can be configured at the subscription and site collection level.

For more information on these options and how to configure them, take a read through the links below.

• Manage External Sharing for your SharePoint Online Environment
• Share Sites or Documents with People Outside your Organization
• OneDrive for Business Access By External Users
• Manage Sharing with External Users in Office 365

In my next post I’ll spend some time examining the different methods to add guest users and how the method of adding the user can affect the ability to share with that guest user. Additionally, I’ll spends some time exploring how a guest user looks from an attribute perspective.

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.

Hello once again and welcome back. This post will conclude my deep dive into Azure Active Directory Connect. Today we will cover how Azure Active Directory Sync (AADS) reaches out to Azure Active Directory (AAD), how the authentication occurs, and what the communication between the two looks like. For this exercise we’ll be using Fiddler to take a deeper look at the traffic.

To capture the traffic between AADS and AAD the machine.config in C:WindowsMicrosoft.NETFramework64v4.0.30319Config needs to be modified to according to this link. After the section below is added, open Fiddler and save the new config and execute a manual initial sync of AADS through PowerShell.

After the sync finishes, we see the sessions captures below.

Let’s break down the process.

1. The application performs an GET for login.windows.net/common/UserRealm/Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com?api-version=1.0. Within the header we are requesting home realm discovery on the identity being used to connect to Azure Active Directory, Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com. This identity is automatically provisioned in your Azure Active Directory instance during the configuration of Azure Active Directory Connect.The browser is returned a JWT that includes the following information:
   1. account_type=Managed – Indicates the account is an Azure AD Managed account
   2. cloud_instance_name=microsoftonline.com
   3. domain_name=journeyofthegeek.com
   4. ver=1.0
2. The application next performs a POST to login.windows.net/journeyofthegeek.onmicrosoft.com/oauth2/token which is the authorization server endpoint for my sample tenant. The following names and values are posted:
   1. Resource = https://graph.windows.net – Access to Azure Graph API is being requested.
   2. client_id Your instance of AADC’s client ID that was automatically created during installation
   3. grant_type = password – Indicates Resource Owner Credentials flow is being requested.
   4. username = Sync_SERVER03_95b83ea05b5b@journeyofthegeek.onmicrosoft.com – UPN of the AADC account
   5. password – This is a 16 character complex password that was automatically configuring during configuration of AADC. Recall that 16 characters is currently the maximum password length for an Azure AD Managed account.
   6. scope = openid – Here we are requesting OpenID Connect 1.0.

   After our account has been successfully authenticated, we are returned a JWT containing a bunch of information. Let’s take some time and break down the data returned.

   1. access_token – Here we receive back a signed bearer access token that has been issued by my tenant’s token endpoint that includes the claims of the IP address of my AADC server, an audience of the graph API, an authentication method reference indicated we authenticated with a password, the name of the account we authenticated with from Azure AD (actual name, not the UPN), the UPN, and a scope of user impersonation.
   2. expires_in = 3600 – This indicates the access token has a lifetime of 60 minutes.
   3. expires_on = some value – The time the token expires. This value is the number of seconds from epoch.
   4. ext_expires_in = 3600 – I’m not sure what this value is indicating the expiration time for.
   5. id_token – This is an id token that contains similar information about the identity as the access token. This is not signed.
   6. not_before = some value The time after which the bearer token can be used. This value is the number of seconds from epoch.
   7. refresh_token – Our apps refresh token.
   8. resource = https://graph.windows.net
   9. scope = user_impersonation – Indicates the scope of the access token we received is user impersonation.
   10. token_type = bearer – Indicates the access token we received is a bearer token.
3. The application next performs a POST to adminwebservice.microsoftonline.com/provisioningservice.svc and begins to communicate with SOAP provisioning API. That’s correct, I said SOAP. I’m unsure as why MS is using the SOAP instead of the REST-based Graph API. Maybe it’s a legacy thing they are still in the progress of migrating? I won’t spend much time digging into what the communication content looks like because I don’t think it lends a ton of value.

The authentication process outlined in steps 1 and 2 are repeated regardless of whether Azure AD Sync is performing an import or an export. There is some interesting differences in the SOAP calls that I want to call out. During the import/export we see the following calls being made to the API:

1. ReadBackAzureADSyncObject
2. GetCompanyConfiguration
3. UpdateDirSyncConfiguration
4. ProvisionAzureADSyncObjects
5. FinalizeExport

My guess is the first two calls are performed during and import run profile and the last three are performed during an export run profile.

Well folks that is it for today. I hope your inner geek has been satisfied by taking a look behind the “magic” Microsoft loves so much these days.

Thanks for reading!