Office 365

All posts relating to Office 365 including tenant setup and administration as well as products and services including Exchange Online, SharePoint Online, Lync Online and more as I delve further into Office 365.

Understanding Office 365 and AAD Federated Identity Types

Recently, I’ve undertaken a number of customer chalk and talk sessions on Office 365 to discuss with them some of the benifits they can expect to see from moving from on-premise services to Office 365 hybrid and cloud services. Amongst the myriad of topics that get covered in these sessions, one of the biggest areas for discussion and contention is identify federation from the on-premise environment to Office 365 which uses Azure Active Directory (AAD) as it’s identity management system.

I thought I would take this oppourtunity to cover off some of the high-level points of the trade-offs and differences between the ways of achieving identity federation with Office 365 and Azure Active Directory. Please remember that this isn’t an exhaustive list of things to consider but a good taster.

In some future posts, I will be covering deployment scenarios for the two methods of identity federation and also the software we need to configure and deploy in order to make it work.

What is Identity Federation

Simply put, identity federation is the means of allowing your users to logon to both on-premise services and Office 365 and Azure Active Directory authentication based services with a single identity, the identity they know and love that resides currently in your on-premise Active Directory and to most people is simply the username and password that they use to logon to your internal PCs and other systems.

Without identity federation, we have a scenario where users have split personas resulting in them having one logon for your on-premise services and another for their cloud services with Office 365 and Azure Active Directory. If you work in a highly secure, militry level environment, perhaps this is actually what you want and you don’t want to potentially expose your internal identies to the cloud but for 99% of people looking at Office 365, you want the simplified experience for your end-users of having just one credential to rule them all.

Single Sign-On vs. Same Sign-On

Single Sign-On and Same Sign-On are the same yet different. Single Sign-On refers to the ability to logon once such as to a domain joined Windows desktop PC and then not have to re-enter credentials for any of the services you consume during that session and this is the holy grail of integration scenarios where the user experience is totally seamless and the user doesn’t need to think about anything other than which app or product they want to work with next.

Same Sign-On refers to using a single identity, provided by our identity federation solution however instead of the user seamlessly being logged into these systems, the user may be prompted at various stages to re-enter their credentials in order to authenticate to a web service or an application such as with the Lync Client or a SharePoint team site.

Both of these scenarios are achievable with Office 365 and Azure Active Directory however in order to achieve one over the other increases the amount of work and effort required upfront in order to achieve success. I will explain in more detail further on the technical differences but for now, know that Same Sign-On is the easiest to implement and requires nothing more than one server to run the syncrohisation software. Single Sign-On requires more servers to be deployed and it requires some firewall reconfiguration in order to allow the services to be properly accessible.

Deciding Which Identity Type is Right for You

In this section, I will talk about some of the determining factors for deciding betwween same and single sign-on.

User Experience

The end-user experience is obviously high on the agenda when it comes to deciding between the two identity federation modes. Same sign-on means users can login to services with the same username and password whilst single sign-on allows users to seamlessly move between applications and services without the need to re-authenticate.

The winner here is clearly single sign-on however this comes with a caveat that Outlook does not behave in a truely singluar fashion like the other applications do.

Due to the way that Office 365 uses the RPC over HTTPS protocol with Basic Authentication, Outlook users will still be prompted to enter their credentials even when single sign-on is deployed and properly configured. This is a common misconception and people see it as a problem with their single sign-on configuration or deployment but sadly it is just the way that Outlook behaves. The workaround to this issue is for users to select the Remember My Credentials option and their password will be cached in the Windows Credential Manager until such a time that the user changes their password.

Password Security

Password security is in my opinion, the number one reason that people consider the single sign-on deployment over same sign-on.

With a same sign-on deployment, the authentication to Office 365 and Azure Active Directory service is performed within AAD. The syncronisation software that is run within your organisation syncs both the users and their passwords to the cloud AAD directory. When a user requests access to a service, the password entered by the user is sent to AAD for verification and authorization. All this means that there are copies of your passwords stored in AAD.

With single sign-on, your passwords are not stored in the cloud AAD directory but instead, only the usernames and a few other attributes of the users. When a user requests a login to a service, the authentication request is forwarded to servers within your organisation known as proxies which then forward the request to your internal Active Directory domain controllers. Once authorized, a token is sent back to Office 365 and Azure Active Directory to approve the login. In a nutshell, the passwords never leave your environment, only tokens approving or denying the connection.

The winner for password security is likely to be single sign-on. The idea of having passwords stored in the cloud is too much for some organisations whereas for others, the idea of the authentication tokens flying back and forth is equally bad coupled with the exposure a single sign-on solution potentially adds to your internal directory environment.

Password Changes

Users need to be able to change their passwords in accordance with your organisations security policy. Typically, in order for a user to make that change, they need to be either on-premise or connected to the on-premise environment via a VPN or such if they are working remotely. Windows Server DirectAccess helps with password changes amongst many other scenarios where the users need to be connected to the corporate network.

If you opt for a same sign-on implementation then by enabling the Password Write-Back feature in the sync application, we can enable users to change their passwords without requiring a connection back to the corporate environment. This password change can be performed via one of the Office 365 application websites such as Outlook Web App. Once the password is changed by the user, it is written to the cloud Azure Active Directory and is synchronised back to the corporate directory when the nextx synchronisation occurs.

If you deploy a single sign-on model then you do not have the flexibility of enabling users to perform password changes via the portals because there is no cloud storage of the password and the cloud environment is not aware of the users password but only that they were authenticated from your environment.

If you are looking for ways to reduce the user reliance on VPN technologies and enable them to do more of their work remotely using cloud based applications then same sign-on could provide an added benifit here. Companies which use single sign-on will need to maintain these VPN technologies even if simply to allow users to change their passwords as required. As I have mentioned previously, DirectAccess if not already deployed could be a real answer here as it provides always-on connectivity back to the corporate environment and does not require the user to interact with a VPN client improving the user experience.

Access Revokation

In a scenario where you need to revoke somebodies access very quickly either due to a confidentiality issue or an employee has gone rogue, single sign-on is the clear winner. Same sign-on works by syncronising the stage of user objects periodically based on a scheduled job from on-premise to the Azure Active Directory. If a user account is disabled on-premise then it could take sometime for that change to make it’s way to the AAD directory and further damage could be done in the scenario as a result.

If you are using single sign-on, when a user account is disabled, that user account will no longer be able to authenticate to Office 365 and AAD federated applications as soon as the account is disabled because those services will no longer be able to authorize that user based on the fact that, that authentication request is sent directly into your environment.

Availability and Reliability

This point is closely linked to the password security requirement, as is configuration complexity. In order for users to be able to sign-in to Office 365 and AAD linked services, there needs to be an authentication service available to process the request. For same sign-on where the passwords are stored in the cloud directory, the availability and reliability is provided by Microsoft Azure.

As we understand from the Microsoft Azure SLA page at http://azure.microsoft.com/en-gb/support/legal/sla/ Azure Active Directory Free provides no guarantee of uptime or SLA although through my personal experience and use of it, I have never seen a problem with it being available and working. Azure Active Directory Basic and Premium both offer a 99.9% enterprise SLA along with a slew of other features but at a cost.

For deployments using single sign-on, because the authentication requests are redireted to servers which are maintained by you as the customer, the availability and reliability of the authentication service is dependant on you and is born of a number of factors: we have authentication proxies, authentication servers and domain controllers all of which need to be available for the solution to work and not to mention any firewalls, load balancers, networks and internet connections, service providers, power sources, you name it, all of which are consumed by these servers.

I’ll be covering some deployment scenarios for both same and single sign-on in a future post however for now, we’ll assume all of this resides in your on-premise datacenters. If you have reliable on-premise servers and infrastructure services and you can provide a highly available solution for single sign-on then you will have no problems however if any of the components in the single sign-on server chain fail, users will be unable to authenticate to Office 365 or AAD federated applications which will cause a user experience and an IT support issue for you.

Configuration Complexity

Taking what we learn from the reliability and availability information above, it is fairly apparent that there are more moving parts and complexities to the single sign-on implementation. If you as an organisation are looking to reduce your configuration complexity because you want to unlock time from your internal IT resources or you are looking to improve your uptimes to provide a higher level of user satisfaction then you should consider whether the complexity of a single sign-on implemention is right for you? In theory, once the solution is deployed it should be no hassle at all but all know that servers go bad from time to time and even when things are working right there is still things to contend with like software updates, security patching, backups and so forth.

The same sign-on implemention requires only one server to implement, requires no firewall changes to allow inbound traffic to your network (all communication is based on an outbound connection from the server) and if you wanted to, you could even omit the backups because the installation of the software is very simple and can be recovered from scratch is little time at all.

Same sign-on is definately the winner in the complexity category so if you have a small or over-worked IT department then this could be an assist in the war against time spent on support issues however single sign-on clearly provides a richer user experience so it needs to be a balanced debate about the benifits of avoiding the configuration complexity.

Software Implementation

In this section I am going to quickly cover off the software we use for these scenarios but I am not going to go into configuration of them or the deployment scenarios as I want to save that for another post at the risk of this post dragging on too long. The other reason I want to cover these here is that throughout this post I have talked of same sign-on and single sign-on but I want to translate that into a software term for later reference.

Same Sign-On using DirSync, AADSync or FIM

Same sign-on is implemented using the Directory Synchronisation (DirSync), the Azure Active Directory Sync (AADSync) tools or using Forefront Identity Manager with the Azure AD Connector.

The DirSync tool has been around for quite some time now and has been improved with new features from one iteration to the next. For example, initial versions of DirSync didn’t support Password Sync to the cloud environment which meant users had different passwords for on-premise and cloud which was a reason a lot of early Office 365 adopters didn’t adopt DirSync. With more recent additions to DirSync to support Password Sync and Write Back from the AAD cloud environment, DirSync has become a lot more popular and I find that the majority of customers seeking a fast track adoption of Office 365 going for DirSync. DirSync has a limitation of only working for environments with a single Active Directory forest which made it a non-starter for customers with more complex internal environments.

Forefront Identity Manager (FIM) with the Azure AD Connector is DirSync on steroids or rather, DirSync is a watered down version of FIM. DirSync is a pre-packaged and pre-configured version of FIM. Using the full FIM application instead of DirSync enables support for multi-forest environments and also for environments where identity sources include non-Active Directory environmnets such as LDAP or SQL based authentication sources. For customers wanting a same sign-on experience but with a complex identity solution internally, FIM was the only option. If you have FIM deployed in your environment already then you may want to take this route in order to help you sweat the asset.

AADSync is a relatively new tool and only came out of beta in September 2014. The AADSync tool is designed to replace DirSync as it provides additional features and functionality over DirSync for example, AADSync has support for multi-forest environments (although still only Active Directory based) making it much more viable for larger, complex customer environments. It also allows customers to control which attributes and user properties are synchronised to the cloud environment making it better for the more security concious amongst us.

Single Sign-On using ADFS

Single sign-on is implemented using Active Directory Federation Services (ADFS). ADFS is deployed in many different configurations according to the requirements of the organisation but in it’s simplest form, it requires an ADFS Proxy which is a server residing in your DMZ responsible for accepting the incoming request for authorization from Office 365 and AAD to your environment. This is passed to an ADFS Server which resides on the internal network and communicates with the Active Directory environment to perform the actual authorization.

There is an additional component in the mix and that is the requirement for either a DirSync or an AADSync server however this is deployed to push the user objects into AAD however there is no password sync or write back of attributes occuring here, this server is there just to allow AAD to know what users you have so that AAD knows whether a valid username has been entered in order to pass it down to your environment for authorization.

Because of the public nature of ADFS, it requires you to have public IP addresses available, certificates for the URLs used by ADFS and also requires you to have a DMZ segment exposed to the internet.

Deployment Scenarios

In a future post which I hope won’t take me too long to make available, I will talk about some of the deployment scenarios and options for deploying both same sign-on and also single sign-on. I will also cover how the release of AADSync effects existing deployments of DirSync or FIM.

Office 365 Management Pack for SCOM

Yesterday I got a chance to play with the Office 365 Management Pack for SCOM. Usual rules apply, read the release notes, import the Management Pack and then configure it, the same rules for all Management Packs you import into SCOM.

The installation was simple by downloading the .msi file from the Microsoft Download page at http://www.microsoft.com/en-us/download/details.aspx?id=43708 however in that this is a Microsoft Management Pack for a Microsoft product, I would have expected this to be published to the Management Pack Catalog in SCOM not a separate .msi file download as it would have certainly streamlined the installation process a little.

Once installed, the configuration of the Management Pack is really simple as an Office 365 configuration link is added to the Administration view. It gets added to the very bottom of the list so if you think you don’t have it visible, make sure you’ve scrolled all the way to the bottom. From the configuration wizard, you simply feed it a friendly name for your tenant and give it the email address for a user in Office 365 or configured through your Azure Active Directory.

The reason for this post, other than to explain how simple the Management Pack is to deploy is to have a little gripe. The user which you create in Office 365 needs to be configured as a Global Administrator on your tenant. To compare things to on-premises, that’s like using an account which is a member of Enterprise Admins to monitor Exchange On-Premises, a bit of a sledgehammer to crack a nut. I personally like things to be least privileged so the idea of having a Global Administrator account for this purpose is an annoyance. In that the Management Pack is testing the health of services within your tenant, I personally don’t see any reason that this account couldn’t be a Service Administrator to still give it some administrative powers but lessen them or failing that, a standard user. I suspect the need for being an administrator comes from the need to query a service API which is only available to accounts authenticated with administrative rights.

The upside of course to my gripe about the account being a Global Administrator however is that you do not need to assign any Office 365 service licenses to the account so it means you don’t need to shell out £20 a month for your E3 license per user in order to be able to monitor Office 365 from SCOM.

Windows Live Outlook Domains Termination

I’ve been using Windows Live Domains, now known as Outlook.com domains for a number of years. It’s a free service that allows you to consume Outlook.com and other services usually associated with Outlook.com such as OneDrive but using your own custom domain name and email addresses instead of using a default domain.

I’ve seen this coming on the cards frankly, but today the penny dropped when I received an email from the Outlook.com team advising of the termination of the service. As of today, no new domains will be accepted for registration in Windows Live Domains. As of July 31st 2014, just under 60 days from now, the Windows Live Domains management site will be stopped preventing the addition or removal of accounts from any existing domains also, essentially shutting you out.

As a token of goodwill, Microsoft are offering 90 days free Office 365 Small Business Premium for up to five users which is a nice offer but I think it’s badly pitched. I think that offering Office 365 Small Business Premium as carrot to move to Office 365 is the wrong kind of carrot. A much better solution would be to have offered people a service credit to the value of 5 users on Office 365 Small Business Premium and here’s why.

Replacing Windows Live Domains with Office 365

Windows Live Domains offered email as a service for free and allowed you to create up to 500 accounts per domain plus an option to create move if you contacted support to request an extension. Office 365 Small Business Premium is £8.40 per user per month excluding VAT and supports up to 25 users.

Office 365 Small Business Premium also includes Lync conferencing, a SharePoint Online Public Website and licenses for Office 2013 desktop application suite and Office for iPad. Giving people an offer which includes a bunch of extra (although note also that it is excellent) functionality is nice but if someone is using Windows Live Domains for email they will no doubt have in place, other services for conferencing and a public website already so these features are not relevant to these users. Licenses for desktop versions of Office and Office for iPad is also nice, but small businesses will have already gone out and purchased their licensing through a local License Reseller or via Retail channel.

Office 365 Small Business at £3.30 per user per month is a better carrot because it doesn’t include the Office licenses which as I mentioned, is likely something people will already have acquired through other sources but it’s still not ideal as it still includes Lync conferencing and the SharePoint Online Public Website and it still has the limit for 25 users. Opening up Lync conferencing certainly could be viewed as a way to expand business opportunities and the SharePoint Online Public Website could be viewed as a way to get yourself a new, modern looking site with a simple to manage and design interface but they are all extras to less.

If you are using Windows Live Domains with a high user count then Office 365 Midsize Business is a better option as it supports up to 300 users, still 200 short of the default limit in Windows Live Domains but at £9.80 per user per month excluding VAT and requiring an annual commitment as opposed to a pay as you go model in the other Small Business plans, that’s getting quite expensive. Anything beyond 300 seats and you are looking at Enterprise level plans which I’ll let you look at for yourself.

Exchange Online a Better and Cheaper Option

So what is the best option? Well I think that the best option for someone looking for a move from Windows Live Domains to Office 365 is actually not an Office 365 Plan but an Exchange Online Plan, Exchange Online Plan 1 to be specific.

Exchange Online Plan 1 is only £2.60 per user per month (excluding VAT) and gives you a direct replacement for services offered by Windows Live Domains. It gives you the Office 365 Exchange Online based messaging solution, far more powerful than the messaging solution of Windows Live Domains but it doesn’t try to be a bigger service, it’s there solely to be a replacement for your email service but a vastly improved one at that.

Exchange Online is managed through the same interface as Office 365 and it is classed as an Office 365 SKU in the licensing section of the portal which means adding Lync, SharePoint or other SKU services later on down the road is a viable option and you can even switch over to Office 365 full product SKUs if you desire later on.

Time is Tight

This is another area that I think Microsoft haven’t been very considerate to people using the service currently. With less than 60 days notice before the whole thing goes belly up, that isn’t a lot of time for Small Businesses or home users of the service to consider their options wisely, evaluate possible paid for alternatives and to migrate out. Many small businesses are going to need to bring in outside services to help them understand this move and perhaps even manage and complete the move for them if they don’t have the skills internally to understand setting up an Office 365 tenant or configuring MX records to reconfigure email delivery.

Even if these businesses do have the skills internally, do they have the resources? Everybody has a day job and somebody having to take the time out to orchestrate this email platform move is no doubt going to be letting other areas of their job slip in the process.

The time is tight aspect is made worse by the next point.

Manual Migrations All the Way

I knew this was going to be the case. The reason I knew this is because on the Windows Live Domains forums for some time, people have been asking for a method to move seamlessly between Windows Live Domains and Office 365 and there has been no good answer and it’s been confirmed today that the answer is manual migrations.

The email gives a link to a Microsoft article at http://windows.microsoft.com/en-gb/outlook/migrate-custom-domain which describes the migration process but simply put, you cut over your DNS MX records to Office 365 if that is where you elect to go and then you have to manually export and re-import all of your mail, calendar and contacts using a.PST files or such.

If 60 days was the timeline but it was a push-button migration where you could elect to invoke the move at a time appropriate for you, login to a portal and click move me to Office 365 now and two or more hours later, your service was back online but using Office 365 now instead, 60 days wouldn’t be an issue but to manually re-configure the service and move mail and all your personal information over in that time too if a bit much to ask.

A problem that I’ve read a number of occurrences about on the Windows Live Domains forum is that when people de-provision their Windows Live Domains service to move to Office 365 it can sometimes take a long time for Office 365 to accept the domain as Windows Live Domains does not sometimes fully release it, causing Office 365 to report that it is currently tied to another Microsoft messaging service. Microsoft really need to have ironed out the bugs in this if people’s stories migrating to Office 365 from Windows Live Domains is going to be a good one. I personally moved a domain over without any issues and the whole thing took no more than an hour including DNS propagation but that’s just one story in a few hundred thousand I’m sure.

The other problem is the competitors. You can almost bet your boots that Google and company will start a marketing campaign targeted at small business off the back of this termination of service and the fact that the migration to Office 365 is manual means it’s no harder to pick yourself up and move to another company for email than it is to upgrade to Microsoft’s premium Office 365 service.

The Outward Push

I want to sound positive here because I really like what Office 365 is about and the services it provides. I’ve been using Exchange Online Plan 1 for one of my own personal domains for about a year now and I keep toying with the idea of bolting on some extra SKUs to it to get more from it but I’m struggling here in this context.

Windows Live Domains, although there is no count that I know of, likely has a lot of users right now. Some of these people may be home users with just a one or two addresses to move, others could be businesses which started out small and have naturally grown and evolved over time but have become dependant on Windows Live Domains to make their business success with many, many accounts.

I think that the everything is free culture that the Internet has generated over slightly yester years is certainly to blame for a percentage of this and I think that if people want a high quality email service or other additional services then you have to pay for that and that’s why I am personally happy to pay for Office 365 services. You don’t get uptime and availability warranties with your free Gmail account now do you?

What I do think is that the placement of this 90 day five user promotional deal to encourage people to Office 365 is pitched at the wrong level and I think that coupled with the tight sub 60 day timeline and the proposal of a manual migration is probably going to generate a degree of Microsoft hesitation rather than happiness and will probably make some of these people look to move to other such services as it would be no more difficult to do so.

I’d quite like to see an updated communication from Microsoft that they realised they pitched the Office 365 deal at the wrong level and that they are changing it to offer service credits for any tier instead but I can’t see it happening in reality. I hope for Microsoft’s sake that they know more than I do in this case and that this move doesn’t backfire on them.

Hide Quick Launch in SharePoint 2013

In SharePoint 2010, we had a method for hiding the Quick Launch on a SharePoint site to clean the interface look and feel if you are building out a site which doesn’t benefit from having a quick launch.

In SharePoint 2010, we did this using a Content Editor Web Part and editing the source HTML code of the Web Part to include some custom CSS however in SharePoint 2013, those same CSS Selectors don’t work because Microsoft have changed the names of some of the CSS Selectors. In SharePoint 2013 to hide the Quick Launch we now do it using the following approach.

Add a Script Edit Web Part from the Media and Content category.

Once you’ve added the Web Part, Edit the Web Part and add the following code snippet.

<style>
#contentBox {margin-left:0px}
#contentRow {margin-left:19px}
</style>

If you want to take this a step further and hide the top navigation links, you can add an additional line of inline CSS code to achieve this. Edit the Web Part and add the following line in addition to the code already specified for the Quick Launch.

.ms-core-navigation {display:none}