Active Directory, Azure Active Directory and Office 365

Apologies for the absence, I am engaged in a Masters degree as well as my SharePoint Career and being a good mummy! The pressure is on! And I’ve got another Nuts challenge 1st of March. I now realise why I was so happy to be done with my first degree….The requirement for prefect references has come along way since 2006!

I have a new client who has a requirement to move their current Java based intranet to SharePoint online, specifically Office 365.  They have Active Directory (on premise) already in place and do not want to change this as they have other application which are dependant on it. They also have Azure Active Directory (AAD) in place for other application so my solution will need to include these elements. My first question was why they needed AAD as Office 365 can work perfectly without it. Answer is they have several other Cloud applications that require authentication through AAD so this must be used. I needed to do some research into using an on premise Active Directory with AAD and Office 365, to see if they could mesh well together. Someone told me that the primary AD controller would have to be moved to Azure.

My research suggests that the on premise AD works very well with AAD (Azure AD) managing credentials for O365. My question to them would be why they needed it in the first place as O365 and on premise AD will work perfectly well with O365.  To hazard a guess would  be because they have several different types of credentials per user, e.g. Windows Live Account as well as the organisational account. I have both of these for Uni, the windows live account allows me to log on to OWA and access library services. The Organisational account is for when I’m logged in to the online portal or the desktop anywhere application (replicating conditions as if I were on campus)

My understanding of it is as follows:

What Microsoft have done is taken Active Directory, a widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a multitenant service with Internet scale, high availability, and integrated disaster recovery. You are able to have your AD on premise for all domains. Then you can use Windows Azure Active Directory to give users single sign-on to Software as a Service (SaaS) applications, O365 included. Applications running in the cloud or on-premises can use Windows Azure Active Directory Access Control to let users log in using identities from Facebook, Google, Microsoft, and other identity providers. To support this, Microsoft makes it easy to “connect” Windows Azure Active Directory with an existing directory. At the technical level, organizations can enable identity federation and directory synchronization between an existing Active Directory deployment and Windows Azure Active Directory.

When an organization does this, its Active Directory is, in a sense, stretching over both an on-premises and a cloud deployment. The ability for Active Directory to operate across both on-premises and cloud deployments in a hybrid mode enables an organization to easily take advantage of new cloud-based platforms and SaaS applications, while all of its existing identity management processes and application integration can continue unaffected.

In addition, being able to operate in this hybrid mode is critical for some organizations because of business or regulatory requirements that mandate that certain critical information, such as passwords, be maintained in on-premises servers.

If you don’t have your own on premise Active Directory, and you sign up for Office 365, Microsoft automatically create a new Windows Azure Active Directory that is associated with the Office 365 account. No action is required on the part of the individual signing up. This is the most simple approach, involving on premise AD is a more hybrid deployment.

In the diagram above, an organization can federate Windows Server Active Directory with Windows Azure Active Directory to give its users single sign-on to SaaS applications. In this scenario, a user at organization B wishes to access a SaaS application. Before she does this, the organization’s directory administrators must establish a federation relationship with Windows Azure AD using AD FS, as the figure shows. Those admins must also configure data synchronization between the organization’s on-premises Windows Server AD and Windows Azure AD. This automatically copies user and group information from the on-premises directory to Windows Azure AD. Notice what this allows: In effect, the organization is extending its on-premises directory into the cloud. Combining Windows Server AD and Windows Azure AD in this way gives the organization a directory service that can be managed as a single entity, while still having a footprint both on-premises and in the cloud.

To use Windows Azure AD, the user first logs in to her on-premises Active Directory domain as usual (step 1). When she tries to access the SaaS application (step 2), the federation process results in Windows Azure AD issuing her a token for this application (step 3). As before, this token contains information that identifies the user, and it’s digitally signed by Windows Azure AD. This token is then sent to the SaaS application (step 4), which validates the token’s signature and uses its contents (step 5). And is in the previous scenario, the SaaS application can use the Graph API to learn more about this user if necessary (step 6).

Today, Windows Azure AD isn’t a complete replacement for on-premises Windows Server AD. As already mentioned, the cloud directory has a much simpler schema, and it’s also missing things such as group policy, the ability to store information about machines, and support for LDAP. (In fact, a Windows machine can’t be configured to let users log in to it using nothing but Windows Azure AD – this isn’t a supported scenario.) Instead, the initial goals of Windows Azure AD include letting enterprise users access applications in the cloud without maintaining a separate login and freeing on-premises directory administrators from manually synchronizing their on-premises directory with every SaaS application their organization uses. Over time, however, expect this cloud directory service to address a wider range of scenarios.

Since 2011 Microsoft have enhanced Windows Azure Active Directory by adding new, Internet-focused connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms like Amazon Web Services, and technologies like Java. So it doesn’t only have to be Microsoft technologies it utilises, it can be multi-platform.

Azure Active Directory Access Control

Windows Azure Active Directory (WAAD/ AAD) can give an organization’s users single sign-on to multiple SaaS applications, for example. But identity technologies in the cloud can also be used in other ways.

Suppose, for instance, that an application wishes to let its users log in using tokens issued by multiple identity providers (IdPs). Lots of different identity providers exist today, including Facebook, Google, Microsoft, and others, and applications frequently let users sign in using one of these identities. Why should an application bother to maintain its own list of users and passwords when it can instead rely on identities that already exist? Accepting existing identities makes life simpler both for users, who have one less username and password to remember, and for the people who create the application, who no longer need to maintain their own lists of usernames and passwords.

But while every identity provider issues some kind of token, those tokens aren’t standard – each IdP has its own format. Furthermore, the information in those tokens also isn’t standard. An application that wishes to accept tokens issued by, say, Facebook, Google, and Microsoft is faced with the challenge of writing unique code to handle each of these different formats.

But why do this? Why not instead create an intermediary that can generate a single token format with a common representation of identity information? This approach would make life simpler for the developers who create applications, since they now need to handle only one kind of token. Windows Azure Active Directory Access Control does exactly this, providing an intermediary in the cloud for working with diverse tokens.

The image above shows how Windows Azure Active Directory Access Control makes it easier for applications to accept identity tokens issued by different identity providers.The process begins when a user attempts to access the application from a browser. The application redirects her to an IdP of her choice (and that the application also trusts). She authenticates herself to this IdP, such as by entering a username and password (step 1), and the IdP returns a token containing information about her (step 2).As the image shows, Access Control supports a range of different cloud-based IdPs, including accounts created by Google, Yahoo, Facebook, Microsoft (formerly known as Windows Live ID), and any OpenID provider. It also supports identifies created using Windows Azure Active Directory and, through federation with AD FS, Windows Server Active Directory. The goal is to cover the most commonly used identities today, whether they’re issued by IdPs in the cloud or on-premises.

Once the user’s browser has an IdP token from her chosen IdP, it sends this token to Access Control (step 3). Access Control validates the token, making sure that it really was issued by this IdP, then creates a new token according to the rules that have been defined for this application. Like Windows Azure Active Directory, Access Control is a multi-tenant service, but the tenants are applications rather than customer organizations. Each application can get its own namespace, as the figure shows, and can define various rules about authorization and more.These rules let each application’s administrator define how tokens from various IdPs should be transformed into an Access Control token. For example, if different IdPs use different types for representing usernames, Access Control rules can transform all of these into a common username type. Access Control then sends this new token back to the browser (step 4), which submits it to the application (step 5). Once it has the Access Control token, the application verifies that this token really was issued by Access Control, then uses the information it contains (step 6). While this process might seem a little complicated, it actually makes life significantly simpler for the creator of the application. Rather than handle diverse tokens containing different information, the application can accept identities issued by multiple identity providers while still receiving only a single token with familiar information. Also, rather than require each application to be configured to trust various IdPs, these trust relationships are instead maintained by Access Control – an application need only trust it. It’s worth pointing out that nothing about Access Control is tied to Windows – it could just as well be used by a Linux application that accepted only Google and Facebook identities. And even though Access Control is part of the Windows Azure Active Directory family, you can think of it as an entirely distinct service from what was described in the previous section. While both technologies work with identity, they address quite different problems (although Microsoft has said that it expects to integrate the two at some point).Working with identity is important in nearly every application. The goal of Access Control is to make it easier for developers to create applications that accept identities from diverse identity providers. By putting this service in the cloud, Microsoft has made it available to any application running on any platform.

There is no requirement for a Primary AD controller to be moved to Azure, you just ‘connect’ and sync up.


Setting it up involves running a few PowerShell commands to set up a trust between ADFS and AAD. SSO needs to be implemented and the domain must be a top level domain. Full steps here

This is the only recommended implemented approach I have found for this hybrid deployment. If anyone can highlight other approaches I would be most interested to know.

Over and Out

SharePoint Online Limitations



This document details the restrictions involved with SharePoint Online and Office 365. As the technology is ever evolving, there may be improvements to the platform which negate these limitations or work arounds discovered. Every effort is made to ensure information in this article is precise and up to date although there may be anomalies which will initiate a process of updates for it.

Figures for SharePoint Online for enterprises




Storage (pooled)

10 gigabytes (GB) base customer storage plus 500 megabytes (MB) per enterprise user.


Storage per Kiosk Worker

Zero (0). Licensed Kiosk Workers do not bring additional storage allocation.


Maximum number of Active Directory user objects

Up to 500,000 AD user objects


Additional storage (per GB per month); no minimum purchase.

$0.20 USD/GB/month.


Site collection storage quotas

Up to 100 gigabytes (GB) per site collection.


My Site storage allocation (does not count against tenant’s overall storage pool)

500 megabytes (MB) of personal storage per My Site (once provisioned).


Site collections (#) per tenant

Up to 300 (non-My Site site collections).


Total storage per tenant

Up to 25 terabytes (TB) per tenant.


File upload limit

250 megabytes (MB) per file.




Up to 0.5 million AD objects;

2 GB document size limit, default is 50mb


  1. Sandboxed Solutions
    1. Sandboxed solutions are the only form of custom coding supported by SharePoint Online, and can only be deployed at a site collection level scope.
    2. No full trust solutions can be deployed.
    3. Sandboxed solutions can only be deployed at Site collection level not farm level.
    4. Managed code is executed in a separate worker process to full trust code. It is monitored for the resources it consumes via different categories (e.g. number of exceptions thrown and CPU cycles) and stored in resource counters which are reset daily. If one of the resource counter categories for a sandboxed solution reaches its daily quota, sandboxed solutions are disabled within that site collection. So the offending solution will be ‘disabled’. Therefore considerable effort must be put into deciding on customisations by means of sandboxed solutions. Too many solutions could take up unnecessary resources and too many calls for those solutions could also consume resources which reduce the very custom functionality you are trying to implement.
    5. There is no way to increase Quotas as it is in on premise.
    6. Limited Server Object model- Significant classes and methods that are not available:
  2. IIS Limitations
    1. No access to web.config file or any other IIS changeable element. To make changes in IIS you need to have full access to SharePoint’s web site directory in IIS as well as the full SharePoint object model on the server. This level of access is not available in SharePoint Online. Currently the only ways around this are to use a client-side calls in JavaScript/ JQuery (ECMAScript) or Silverlight, or wrap it in an Azure-hosted WCF endpoint and call it using SharePoint Online’s Business Connectivity Services.
  3. Private Site Collections
    1. Private site collections cannot have their own domain names (only for Enterprise) and cannot map a private site collection to a public domain.
    2. Custom managed paths are not allowed in SharePoint Online
  4. Mysites
    1. Mysite collection master page (root.master) cannot be edited using SharePoint Designer, it actually can be changed but the change is not supported by Microsoft and might cause the site to break.
    2. Feature stapling is not supported as of yet as it is a Farm level feature??? Not sure if this is true but Microsoft do not seem to want to confirm or refute this. It is only available in dedicated online Implementations, not on multi tenancy.
    3. It is possible to brand the My Site Host and Individual user My Sites with Custom Sandbox Solutions, but this is not supported by Microsoft. It is important to note that when a user provisions their My Site for the first time, it would take default branding based on the OOTB My Site template. The user must then upload Sandbox solutions to apply branding to their already created My Sites. Individual end-users can use SharePoint Designer to update branding on case by case basis as well. This should be avoided as it is not supported
    4. The Microsoft supported way is to use SharePoint Designer to make branding changes or accept the standard themes available.
  5. Branding
    1. Branding can be done directly via SharePoint Designer or packaged using a Visual Studio project. You start with an empty SharePoint project and add the relevant elements including a feature receiver to apply branding during a feature activated event and retract it during the feature deactivated event.
    2. The master page of a public facing website cannot be changed using SharePoint Designer. Editing of the public website cannot be done using SPD either. All customisations must be done using the site designer tool.
    3. Master pages for SharePoint online are not set up for fixed width sites or layouts.
  6. Document Management
    1. No support for records Center. Only In-line Records management is supported.
    2. Mail enabled document libraries are not supported and will not be supported because of the security and performance risks to multi tenancy implementations.
    3. PDF Documents cannot be opened in the browser. SharePoint online does not have the option to set Browser File Handling = Permissive, thus allowing PDF documents to be viewed in the browser. Microsoft did release a post about this:, which seems to indicate that you can open PDF files directly in Adobe Reader, (Not the browser) – and the PDF file will remain connected to SharePoint Online. You can also edit and save your changes to SharePoint Online from the desktop. There is a workaround I have found but not personally tested myself:
    4. No support for Word Automation Services, inaccessible through Central Administration
  7. Search
    1. No support for FAST Search.
    2. Indexing other content sources from SharePoint Online is also unsupported because the Search Service Application in SharePoint Online has a limited configurable feature set. Crawling content source occurs circa every hour to refresh index. /indexing multiple content sources is also not supported.
    3. Custom IFilters not supported (PDF is the only external IFilter supported).
    4. No federated Search or contextual search.
    5. No query suggestions, ‘Did you mean?’ etc.
    6. Search config elements not available include: Advanced Content Processing, Turnable relevance, Bi indexing, SharePoint 2010 Search Connector framework, relevance tuning, rich web indexing, Enterprise scale search, Windows 7 search, Similar Results, Thumbnails and previews (FAST Search), visual best bets, advanced sorting.
  8. Insights
    1. No support for Business Intelligence Center, Chart Web Parts, Data Connection Library, PerformancePoint Services:
  9. Authentication
    1. 3 types of authentication with Microsoft Online Id (Office 365 Accounts), Single Sign On with Active Directory Credentials via ADFS (Federated Services), or a Windows Live ID.
    2. Anonymous users for public websites.
    3. External Sharing Identities- This Site Collection Level Feature enables you to invite external users to view, share, and collaborate on sites. Microsoft supports ‘invited’ external users sign in using MS Online ID services like Windows Live ID including,, or, Once external user receive their invitation from SharePoint Online, they have to login to the SPO either using Hotmail or MS Online Service ID. External users can use their business email address as long as their email user name associated with Live ID system.
  10. Backups
    1. No control over backups without a service request being sent to Microsoft.
  11. Blocked File Types
    1. With SharePoint online, you cannot add additional blocked file types.
  12. Data Connections
    1. No Data connection library available in SharePoint online.
  13. HIVE 14 Folder
    1. No access to folder except through Service Request which may be rejected.
  14. Site Definitions
    1. These are not supported within the Cloud. Instead Web templates are to be used. These can be packaged in a sandboxed solution and deployed at site collection level.
    2. Microsoft suggests creating a web template by saving a site close to the one you are trying to create as a template and then importing it into Visual Studio and adding the elements needed.
    3. Another blogger suggests it’s easier to convert any existing site definition to a web template simply by copying onet.xml and creating other required elements manually.
  15. Workflows
    1. Microsoft suggests using the workflow capabilities of SharePoint Designer which have been very significant for more purposes in my experience. If these do not suffice, then workflows can be packaged in a sandboxed solution, as well as custom activities for SharePoint Designer itself. These are deployed at site collection level.
    2. I have found that the workflow creation process in SharePoint Designer is excellent at covering most business processes, but if not there is a way to create your workflow in SharePoint designer and then export it into a wsp, which can then be imported into Visual Studio to add the extra functionality as required, although this must be a sandboxed solution.



    Info for Developers:


    SharePoint online Developer Guide

    SharePoint Online Developer Guide for Developers: