Showing posts with label ADFS. Show all posts
Showing posts with label ADFS. Show all posts

Wednesday, February 18, 2015

Self Service Password Reset

There was a second announcement made today by the Office 365 identify team that the self-service password reset capability had been added. This feature had actually only be available to Azure Active Directory (AD) Premium customers however this feature will now be available to Office 365 customers.

The main caveat of this release is that it will work with customers using Cloud Based IDs. If you are a federated authentication with Office 365, and you want to have this feature, you need to purchase Azure Active Directory Premium to support the write back of the password to the on-premises Active Directory that is federated with Office 365.

Announcement is located here - http://blogs.office.com/2015/02/17/sign-page-branding-cloud-user-self-service-password-reset-office-365/. Additionally in this blog, there is a really good table in here that accurately explains the Azure AD Features that come with Office 365 and which features require Azure AD Premium.

There is good detailed information located off of here on how to configure and manage the Self0service password reset feature of Azure AD - https://msdn.microsoft.com/en-us/library/azure/dn510386.aspx.

Office 365 Custom Branded Log-in Pages

One of my favorite Office 365 teams had a really cool announcement yesterday I have been waiting on.

Over the years, many customers have wanted to have custom branded page when a user logs-in. This was important for branding but even more important because I had customers wanting to put custom disclaimers to users when logging in to Office 365.

In the past the only way to achieve this was through making modifications in ADFS to introduce a new page as part of the log-in process. This was commonly done to add-in other form factors for authentication. The drawback of this approach was that it first required federation and not all Office 365 customers are using federation; they use cloud based IDs. Second, this required additional custom work on the organization’s ADFS deployment. This new change removes this requirement.

This new sign in page is actually a feature that has been available to customers who are Azure Active Direct (AD) Premium customers and now this feature is being provided directly to Office 365 customers without requiring a purchase of Azure Active Direct (AD) Premium.

Now this solution is available to all Office 365 customers, regardless if you are federated or using cloud based IDs. The configuration of this will be available off of the Office 365 Admin portal.

The user experience will be that user will see the Office 365 standard log-in screen, however once they enter their UPN, the user will be directed to the custom branded page.

clip_image002

The announcement was made here - http://blogs.office.com/2015/02/17/sign-page-branding-cloud-user-self-service-password-reset-office-365/

Here are the details adding a custom branded Sign In and Access Panel Page - https://msdn.microsoft.com/en-us/library/azure/dn532270.aspx. All the technical details are locating here to give you an understanding of the page elements you can edit and how to apply those changes.

Another note they made in this bog, which is good is this log-in branding can be coordinated with the recent announcement for theming here - http://blogs.office.com/2014/09/02/personalize-office-365-experience-selecting-themes/.

Saturday, November 15, 2014

Office 365 ProPlus Adding Passive Authentication

There has been a change I have been waiting on that. On the Office 365 Public roadmap it is called “Office 2013 client update to support passive authentication using SAML” - http://office.microsoft.com/en-us/products/office-365-roadmap-FX104343353.aspx.

What is this announcement?

Office 365 ProPlus / Office 2013 will be getting a modification to support 2FA authentication scenarios. This is enabled through the Active Direct Authentication Library (ADAL).

Why is it so important?

There are many customers who require 2FA to authenticate to the Office 365 service. For Office, the Outlook rich client typically comes up a lot because customers want to ensure that users using Outlook use 2FA to receive email. With Outlook today there are scenarios that organizations can implement to ensure there is 2FA with Outlook, however the better long-term solution is to have Office modified to support 2FA directly.

Specifically Office 2013 is changing such that is can support “passive authentication” scenarios in the same way a browser does.

This will enable is a cleaner solution with Office 365 MFA. More importantly it allows for additional support scenarios for organizations who use smart cards (PIV, CaC, etc.) to authenticate to the Office 365 service using the Office 2013 rich client.

What are some facts you should know?

Private Preview Release – Office 365 customers who are in the private preview program can have access to this.

ADAL Authentication – As I mentioned earlier, Office 2013 will be adopting passive authentication in the same way a browser authenticates. If you have AD FS implemented with Office 365, the user will authenticate through that federated trust relationship with Office 365. If you organization requires a second form factor (2FA) for authentication, the user will be required to provide it. A nice side effect of this is Outlook no longer needs to have direct access to the user’s password. Please read this blog for more details on the authentication process - http://office.microsoft.com/en-us/products/office-365-roadmap-FX104343353.aspx.

What Clients are impacted? - Word 2013, Excel 2013, PowerPoint 2013, Lync 2013, Outlook 2013, Publisher 2013, Visio 2013, Access 2013, Project 2013 and OneDrive for Business Sync Client.

Will this work with AD FS Only? – Please review information about other STS providers: http://blogs.office.com/2014/01/30/the-works-with-office-365-identity-program-now-streamlined/ and http://technet.microsoft.com/en-us/library/jj679342.aspx

Office 2010 Support? – No. This solution is for Office 2013 and Office 365 ProPlus.

References

New Announcement – Office 2013 update for SAML and 2FA Auth - http://blogs.office.com/2014/11/12/office-2013-updated-authentication-enabling-multi-factor-authentication-saml-identity-providers/

Original Announcement - http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/

SAML 2.0 Announcement - http://blogs.office.com/2014/03/06/announcing-support-for-saml-2-0-federation-with-office-365/

Outlook Connectivity with MAPI over HTTP Announcement - http://blogs.technet.com/b/exchange/archive/2014/05/09/outlook-connectivity-with-mapi-over-http.aspx

Saturday, March 29, 2014

Office 365 Federation Updates

There was some good information in this blog that really cleared the air on a few topics which I talk a lot about with customers - http://blogs.office.com/2014/03/06/announcing-support-for-saml-2-0-federation-with-office-365/

A lot of times I am asked, can authentication federation with Office 365 can be done with something other than Active Directory Federation Services (ADFS) and Active Directory (AD)? The answer has always been yes as there are other third-party STS servers that have been supported plus other LDAP directories are supported.

However with this recent announcement this story has been cleaned up a bit. Here are the high level facts you need to know:

  • Active Directory (AD) can be used to synchronize your directories to Office 365. You can use DirSync to do this. Everyone knows this. If you have multiple AD forests, you will need to use Forefront Identity Manager (FIM).
  • LDAP directories can also be synchronized with Office 365. Again you will need to use FIM to support this. Recommend that you talk with your licensing person at Microsoft. Remember a full FIM CAL is not needed when all you are using is the FIM synchronization service. I am not a licensing expert on FIM so I recommend you double check.
  • SAML 2.0 is now offered as an authentication federation option now with Office 365. This allows a whole host of STS identity providers to authenticate with Office 365. The important note is that SAML 2.0 support is for “passive authentication” scenarios which as you may know is used for browser based authentication.
  • Office 365 has supported and will continue to support WS-Federation and WS-Trust to support ADFS and other WS-* identity providers.
  • So what about the Rich Clients? When we are talking rich clients we are talking such client applications as Lync client, Office Desktop clients (Word, Excel, PowerPoint, Outlook, etc.), etc. In the Microsoft Office 365 world, it is not just browser only, there are tons of other clients that can to connect to Office 365 service. Authentication using these rich clients is referred to as “active authentication” which currently requires WS-Trust. If you want to have federated authentication and you need to support rich clients, you will need to use an STS identity provider that supports WS-Federation and WS-Trust. You will need to use either Active Directory Federation Services (ADFS) or a qualified solutions partner that can support this level of authentication. A list of third-party approved providers is listed here - http://technet.microsoft.com/en-us/library/jj679342.aspx and information about the program for getting third-party qualified is listed here - http://blogs.office.com/2014/01/30/the-works-with-office-365-identity-program-now-streamlined/.
  • So is the Rich Client scenario ever going to support SAML 2.0 and Passive Authentication? The answer is YES. It is reflected in the public roadmap of these two blogs http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/ and http://blogs.office.com/2014/03/06/announcing-support-for-saml-2-0-federation-with-office-365/. There will be an update to Office 2013 client applications, in the year 2014, which will allow Office 2013 client applications to support SAML 2.0 (or Shibboleth) passive authentication.

These changes in Office 365 federation authentication are great changes to supporting more enterprise scenarios.

Saturday, February 15, 2014

Office 365 and Third-Party STS Providers

I have been asked a lot lately how other STS providers could be used to federate authentication with Office 365 instead of using ADFS.

Additionally there was an announcement about a new program to get third-party identity providers (STS providers) tested and approved with Office 365 quicker. If you want to get one that you are working approved, recommend to them to read this - http://blogs.office.com/2014/01/30/the-works-with-office-365-identity-program-now-streamlined/.

New Office 265 Multi-Factor Authentication and Roadmap Announcement

There as a big announcement that was publically disclosed recently that Multi-Factor Authentication (MFA) was added to the Office 365 service - http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/. Here is a detailed article about it - http://technet.microsoft.com/en-us/library/dn383636.aspx. This is a really exciting announcement about for MFA, two-factor authentication, 2FA, etc.

However I like to make clear that Office 365 has always been able to support 2FA and this was achievable through configuration of federation with ADFS (or other STS servers). So it is possible to integrated RSA, smart cards, etc. but the policy for third-party 2FA is managed by the customer and enforced through ADFS (or other STS servers). The new Office 365 MFA offering discussed here will be immensely valuable to customers who do not have federated authentication and are using Cloud Based IDs. If you do not know much about Office 365 authentication, I recommend you start with the Service Description and read some of the linked articles - http://technet.microsoft.com/en-us/library/office-365-user-account-management.aspx.

Another important announcement discussed is that Office 2013 client applications “native multi-factor authentication for applications such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, and OneDrive for Business, with a release date planned for later in 2014”. This will work with this new solution Office 365 MFA as well as third-party 2FA solutions that have been implemented on-premise (i.e. RSA, smart cards, etc.).

Friday, January 25, 2013

Windows Azure AD Whitepaper

Here is a new Whitepaper on entitled “Active Directory from on-premises to the cloud” - http://www.microsoft.com/en-us/download/details.aspx?id=36391

This is a great whitepaper if you want to learn more about Windows Azure AD. Additionally you will find out that Windows Azure AD is the AD solution that is used for Office 365. This whitepaper gives insightful information on:

  • How AD Authentication actually works inside of Office 365.
  • There is some great information in here that explains how once you get it set up, it can be utilized across Office 365 and Azure services.
  • There is information in here that will shed light on how Office 365 is support non-AD directories. This is because you can sync your corporate LDPA directors up to Windows Azure AD and Office 365 will utilize it.

Monday, October 29, 2012

Office 365 for Enterprise Service Description Updates

The Office 365 Services Descriptions have been updated in October 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=13602
If you want to get further details of the changes since you last read them – please read this - http://community.office365.com/en-us/wikis/office_365_service_updates/974.aspx
Some ones you should be aware of are:
  • New Office Web Apps features in SharePoint are being released!
  • Dirsync Scoping and Filtering is now supported – this is great so you do have to sync up your entire directory.
  • There is new Interop to work with Third Party Identity Solutions (or STS servers)
  • New PDF Viewing through browser.
There are a few other things as well. I highly recommend adding an RSS feed to this wikipage.

Wednesday, August 15, 2012

Office 365 ADFS Whitepaper

I have had a few customers ask me recently about low level details around how authentication works for Office 365 and Active Directory Federation Services (ADFS). There is a great whitepaper located here that I highly recommend that you read - http://www.microsoft.com/en-us/download/details.aspx?id=28971
I recommend reviewing sections:
  • Section 5.2 covers Web Client for SharePoint/OWA authentication flow.
  • Section 5.3 covers the Lync authentication flow.
  • Section 5.4 covers the Outlook authentication flow.
All are a little different because clients are active vs. passive which determines the flow of how the claim is ultimately sent to Office 365.

Monday, April 23, 2012

Office 365 Federation Overview

Background
I keep on neglecting to finish this blog post, so I am going to crank this out. I recently federated a lab environment with Office 365 and I wanted to share the resources and some of my lessons learned. Actually federating with Office 365 is a pretty straight forward task.
In this blog I will capture the major steps I took, capture some lessons learned, and give you the resources you need to get there.
Authentication Options
With Office 365 you have a few authentication options:
  • Microsoft Online IDs – These are cloud based IDs. They are best for small organizations. Users will have a different log-in a different username and password; so there is no Single Sign On experience for the user accessing cloud services. If there is a two factor authentication requirement, that cannot be supported using this authentication method. You do have the option to bring in your corporate GAL that is managed through on-premise Exchange with the synchronization tool.
  • Federated IDs – This is when you decide you want to provide a Single Sign-On (SSO) experience with Office 365. This is enabled through Active Directory Federation Services 2.0 (AD FS 2.0) to be installed on premise. Implementing federations provides the ability to support two-factor authentication and enables co-existence/hybrid scenarios.
  • External User Authentication – It is worth mentioning on the side that organizations want to bring in external users and partners to collaborate with them. SharePoint Online supports the ability to create a partner cloud account that is within Office 365 or allow users to authenticate to SharePoint Online with Windows Live ID. The Windows Live ID is very appealing because external users can use whatever email address and password they have to access SharePoint Online.
Major Steps for Federation
This is all actually very well documented in the references I am providing at the end blog. The steps for federating with Office 365 are:
  • Plan and Prepare
  • Deploy Active Directory Federation Services
  • Establish a Relying Party Trust with office 365
  • Set Up Active Directory Synchronization
  • Activation of Services for Users
image
Plan and Prepare
First thing you really need to sit down, read the materials and come up with execution plan. It is not brain science however knowing your requirements and how people will access Office 365 services will directly affect how you deploy your federation services.
Here are some things to think about:
  • Multiple Domains - If you have multiple domains and sub domains you should spend some extra time planning trusts with AD FS.
  • Multiple Forests - If you have multiple active directory forests, synchronization and authentication is not currently supported today with Office 365 Multi-tenant. To get around this you can consider consolidating forests or only deploy Office 365 with a primary login forest.
  • Deployment Readiness Tool – As part of running the Deployment Readiness Tool, you may have some changes as it will check email domains, AD (required attributes, remove special characters, etc.), networks, DNS, etc.
  • DNS – Part of the configuration will require DNS configuration and you need to make sure you are working with a person in your company or organization that can make these configuration changes.
  • Access Outside Corporate Network – Need to understand how users will need to get access to your environment. If they will be accessing from home, public areas, etc. you will need to need to deploy proxy servers in your DMZ (will discuss later).
  • Two-Factor Authentication – If you need to support two-factor authentication some additional configurations (will discuss later).
  • Certificates – You will need SSL and Token Signing Certificates. I highly recommend getting all of this worked out from a logistics perspective before you start, otherwise you will be waiting for people to get things for you.
  • Administration Rights – Note that many of the configuration steps require domain administrator rights. You will need to get this person involved and they need to participate as part of the configuration and installation of the service.
Approach
Honestly every plan to implement this will differ to some degree based on the current state of your current infrastructure. The link below entitled “Office 365 Single sign-on: Roadmap” along with the “Office 365 Deployment Guide” are your best resources for configuring federation with Office 365.
Federation
Initially there are a couple resources that will need to be added such as:
  • AD FS 2.0 – Must be installed on-premise to support federation. It is recommended that you add more than AD FS 2.0 server for redundancy purposes and load balance them.
  • Directory Synchronization Tool – This tool will synchronization active directory information to Office 365 to support the GAL. The reason why you need to do this is because AD FS only helps with the ability to authenticate, it will not actually allow you to find other users in your organization like in Exchange or SharePoint Online. This cannot be installed on a Domain Controller or AD FS server.
So minimally you will need something like this.
image
If you need to be able to support users to access Office 365 services when outside the corporate network, you will need to add some additional resources to support the federated authentication.
Federation with External Network Access
The most common documented one is to install AD FS 2.0 Proxy Server(s) in the DMZ (depicted below). Requests come in externally to the proxy servers and then sent through to corporate network to authenticate against AD.
image
An alternative is to use something like Microsoft Forefront Unified Access Gateway (UAG) for supporting users to access federated Office 365 services when outside the corporate network.
Strong / Two-Factor Authentication
Another common requirement is the need to support two-factor authentication along with federation. If a user is logging in on the corporate network or with a domain joined machine, you can utilize the existing infrastructure to meet this requirement and no further deployment is required except for AD FS 2.0 (which provides the single-sign on experience to Office 365). However if need to extend support of two-factor authentication for users accessing Office 365 services from non-domain joined machines additional configuration is required.
One solution is to use Microsoft Forefront Unified Access Gateway (UAG) SP1 to provide two-factor authentication for these users whom need to access Office 365 services from non-domain joined machines. UAG provides several solutions for two-factor authentication and direct access. One thing to be aware of is UAG supports two-factor authentication for passive federation endpoints (i.e. web clients such as SharePoint Online and OWA). UAG cannot support two-factor authentication for active federation and basic authentication endpoints (i.e. Outlook client, Lync client, ActiveSync). This means providing strong authentication with UAG will be limited to using Office 365 web clients. In my opinion this is not a major limitation for businesses utilizing Office 365 services because typically the only thing that IT will for non-domain joined machines are browsers. Even with bring your own device policies, organizations will typically not support down to the rich client; nor do they really need to.
Another potential solution is to use AD FS 2.0 to enforce strong authentication by modifying the AD FS 2.0 proxy logon page to add two-factor support. This would entail adding extra fields for the users to enter extra factors for authentication. Doing this would require integration with whatever two-factor authentication servers/services that is in place.
In summary, UAG is a good solution for accessing Office 365 service when supporting two-factor authentication for external, non-domain joined machines.
Pilot Single Sign On
Additionally you may be interested in piloting users with single sign-on authentication. There is a great article in the references in this blog that explains how to do this. It is really straight forward. First you will notice that you can always add single sign-on later. You have the ability to create your Office 365 tenant using cloud IDs and when you are ready you can transition over to federated authentication with active directory. Second thing to note is you can even create scenarios where some users authenticate to Office 365 services using a federated account while other users only use cloud based IDs. This can provide you some flexibility in potentially how you want to manage accounts.
References/Resources

Thursday, January 5, 2012

Pilot Office 365 References

Are you looking into doing a quick pilot on Office 365? If so, here are some links, documents and references that I have organized will help you get started. Note this is geared for the Office 365 Multitenant offering; not Office 365 Dedicated.
Trial Guide - Office 365 from Microsoft Online Services
This is a really good guide that covers the services and capabilities. Then it provides you detailed step-by-step instructions to get Office 365 initially configured. Download - http://www.microsoft.com/download/en/details.aspx?id=26123
Now once you have done this – there are probably things that you may want to dive deeper on. Here is some good information that will help you. I will try to update this with new stuff as a find it.
Microsoft Office 365 Deployment Guide for Enterprises
This is the Microsoft Office 365 Deployment Guide for the Multi-tenant Environment. This is an optional reference document that provides detailed information on how to do the real production deployment. Reviewing this will give you context before you make the decision to go to production. Download - http://www.microsoft.com/download/en/details.aspx?id=26509
Identity and Authentication
For a trial or pilot, the best approach is to use Cloud IDs as discussed in the Trial Guide. However one of the more advanced capabilities you may want to pilot Single Sign On with Active Directory Federation Services (ADFS). Here are some references:
Exchange Online
The following is some good information for testing out Exchange Online:
  • User Email Help - http://help.outlook.com/en-us/140/cc325690.aspx - Covers ton of stuff such as Email, Calendar / Reminders, Contacts and Groups, Voice Mail, Email Set Up, Mobile Phones, and Options and Videos.
  • Email Administration - http://help.outlook.com/en-us/140/ff657678.aspx - This covers tons of things such as configuration, user management, roles, permissions, security (SPAM, etc.), compliance (archive, retention, holds, audit, journals, rights management, etc.), unified messaging configuration, Exchange ActiveSync, PowerShell, mailbox migration, hybrid mail and some help videos.
  • Exchange Online Administration - http://technet.microsoft.com/en-us/exchange/hh127068.aspx - Here is another site that will help you with finding administration information for Exchange Online.
SharePoint Online
The following is some good information for testing out SharePoint Online:
Lync Online
The following is some good information for testing out Lync Online:
Office Professional Plus for Office 365
Miscellaneous
  • Virtual labs - http://technet.microsoft.com/en-us/office365#tab=1 - Some labs on various topics.
  • Microsoft Office 365 Multi-tenant Service Descriptions - http://www.microsoft.com/download/en/details.aspx?id=13602 - There are numerous Office 365 Multi-tenant Service Descriptions available covering such topics as: Exchange Online Archiving, Exchange Online Enterprise Services, Lync Online Enterprise Services, SharePoint Online Services, Identity Services, etc. These documents can be used as supplementary information resources while doing a pilot.