Identity Provisioning in Office 365 and Azure AD

Transcription

1 Identity Provisioning in Office 365 and Azure AD Seamless access to Office 365 resources is possible through federation trust and directory synchronization between on-premise AD and Azure AD. Microsoft supports a variety of Office 365 integration options. Organizations have different choices for directory synchronization. With the Azure Active Directory Graph API, identity management solutions can be built to meet complex synchronization requirements. June 5, 2014 Darren Mar-Elia, Microsoft MVP, IT Strategy Consultant, and President of SDM Software, Inc. Pamela Dingle, Senior Technical Architect, Office of the CTO, Ping Identity Sponsored by:

2 Overview Single sign-on is a key part of integrating Microsoft Office 365 into organizations. However, synchronizing identities between on-premise directories and Azure Active Directory is required to implement identity federation. Microsoft offers different mechanisms for synchronizing identities; each approach has strengths and weaknesses. Organizations must determine which solution will best meet their unique circumstances. In instances where synchronization requirements are complex, it may be beneficial to implement a third-party solution based on the Azure Active Directory Graph API. Examples include Ping Identity s PingFederate and PingOne. Context Darren Mar-Elia and Pamela Dingle discussed different ways to handle identity management and provide a complete single sign-on experience for Microsoft Office 365 users. Key Takeaways Seamless access to Office 365 resources is possible through federation trust and directory synchronization between on-premise AD and Azure AD. For identity management, Office 365 requires users to have an Azure Active Directory (AD) ID and to log in with their Azure AD credentials. Azure AD is a cloud-based directory service and lacks features available in onpremise AD, such as Kerberos authentication and group policies. Azure AD isn t designed to replace on-premise AD and is comparable to ADLDS or LDAP in the cloud. To enable seamless user access to Office 365 resources, organizations can implement federation trust and directory synchronization between on-premise AD and Azure AD. Federation is similar to NT/AD domain trust, but it occurs across disparate directories and between companies. Darren Mar-Elia described two key aspects of federation: Federation provides pass-through authentication. No passwords are passed between federation partners but both the on-premise AD and Azure AD must know about the user accounts. To use federation with Office 365, organizations must have a federation server. This server handles the trust between the two sides and complies with one of the federation standards, such as WS-Federation, WS-Trust, Shibboleth, or SAML 2.0. Examples of federation servers include Microsoft s ADFS and PingFederate. Microsoft supports a variety of Office 365 integration options. There are four Office 365 integration alternatives offered by Microsoft. 1. DirSync with federation. Directory synchronization or DirSync synchronizes users account groups in the on-premise AD with Azure AD. The authentication is federated, so user authentication occurs on the on-premise AD through the federation erver. This approach is most popular with larger enterprises. Page 2

3 2. DirSync with password sync. This option is sometimes referred to as simple signon. No federation server is required. Password hashes are synchronized to Azure AD and users authenticate to Azure AD. This approach is most popular with small and medium-sized businesses. 3. Federation with no directory synchronization. Accounts are created and maintained manually in Azure AD. Authentication occurs through federation. 4. Federation with Graph API synchronization. The Graph API is a new programmatic feature that exposes Azure AD via REST. REST is an industry standard web service mechanism for describing resources and performing operations on them using standard HTTP commands. This approach enables organizations to create/update/ delete and search accounts through external code. Organizations have different choices for directory synchronization. Microsoft provides three ways to perform directory synchronization: 1. DirSync. DirSync synchronizes users, groups, and contacts from on-premise AD to Azure AD. However, it can only synchronize from a single on-premise AD forest and the 150 pre-defined attributes that are synchronized are not configurable. This solution requires a SQL Server instance to store synchronization metadata. By default, password hash sync is off. Since there is no failover of the on-premise DirSync server, this can hinder 100% uptime goals. 2. Azure AD Premium. This is a new service that is available to customers with a Microsoft Enterprise Agreement. The cost is $4 per user. Azure AD Premium eliminates the Azure AD limit of 500,000 objects and adds four features to DirSync: -- With password writeback, password changes can originate in Azure AD and then be synchronized back to on-premise AD. --Users have access to self-service password reset functionality in Azure. --Organizations get usage rights for Forefront Identity Manager (FIM) R2 which is Microsoft s identify provisioning platform. --Federation is possible with other SaaS apps. 3. Azure AD Sync. This is the next generation of DirSync and will likely replace DirSync. It is currently available in Community Technology Preview (CTP), but not yet in production. Azure AD Sync can control which attributes are synchronized and provides support for multiple on-premise forests, attribute mapping rules, and other on-premise directories like LDAP, SQL, and CSV. Each approach has advantages and disadvantages, so organizations must decide what will work best for their unique situation. Mr. Mar-Elia made the following recommendations: -- If synchronizing with password hashes is acceptable, DirSync with password sync is a good option. This simple sign-on option is only appropriate, however, for single forest scenarios. Page 3

4 --If multi-factor authentication is needed, organizations must federate authentication with on-premise AD or sync passwords and let Microsoft provide multifactor authentication. --If organizations have multiple forests or complex synchronization requirements, it is advisable to use Azure AD Premium, wait for Azure AD Sync, or look at third-party federation/synchronization solutions. If your organization has multiple AD forests or complex synchronization requirements, you may want to use a third-party federation and synchronization solution to handle identity provisioning in Office 365 and Azure AD. Darren Mar-Elia With the Azure Active Directory Graph API, identity management solutions can be built to meet complex synchronization requirements. Azure Active Directory offers API-driven management of accounts through the Graph API. This is very beneficial for organizations with complex synchronization requirements that still want a seamless experience in the cloud. The Graph API doesn t force organizations down a product path. Instead it relies on loosely coupled REST-based commands that give organizations control over how identities are set up. Companies like Ping Identity have built solutions based on the Graph API to match very specific customer needs. The beauty of the Graph API is that it allows organizations to implement provisioning solutions that meet complex use cases, as well as scale and evolve on top of the Azure platform. Pamela Dingle Pamela Dingle described different scenarios where Ping Identity products could be used: PingFederate. This product is a good solution for organizations that don t use on-premise AD or use Google Apps. They may want functionality equivalent to DirSync, but they don t have the necessary on-premise software. PingFederate can extract identities in the desired format and output in the right format for Office 365. Alternatively, organizations may be provisioning to an infrastructure that includes more applications than just Office 365. As a result, they need a multiplex attribute engine with high compliance requirements. PingFederate can be used to take in Page 4

5 identities, apply the same policies consistently across all identities, and then push the resulting identity pieces to many applications. PingOne. PingOne offers identity as a service functionality. It can take apps from cloud identity bridges like Google. Alternatively, it can use an on-premise bridge that acts as a synchronization and authentication agent, so passwords aren t stored in the cloud. Identity as a service options like PingOne are one-stop shops that are optimized for people who aren t federation or provisioning experts. With Graph API, partner ecosystems have developed provisioning solutions that scale and evolve on top of the Azure platform. With these offerings, it is possible to handle complex identity use cases. If needed, organizations can choose and control every attribute. Third-party solutions, such as those from Ping Identity, integrate easily into security information and event management, provisioning, and multi-factor authentication projects. In addition, single sign-on and provisioning can be completely decoupled or managed in one product rather than two. Page 5

6 Biographies Darren Mar-Elia Microsoft MVP, IT Strategy Consultant, and President of SDM Software, Inc. Darren Mar-Elia is president and CTO of SDM Software, a Group Policy solutions company. He has more than 30 years combined experience in IT and software development. He was senior director of product engineering at DesktopStandard (acquired by Microsoft), and he previously served as CTO for Windows management solutions at Quest Software. He was also a director of distributed systems at Charles Schwab Co. and helped guide that company s use of Microsoft Windows technologies. Darren has written or contributed to 12 books on Windows management topics, is a Microsoft MVP for Group Policy, and is a contributing editor for Windows IT Pro. He also created the popular GPO Guy website for information and utilities related to Group Policy. Pamela Dingle Senior Technical Architect, Office of the CTO, Ping Identity Pamela Dingle is a Senior Technical Architect within the Office of the CTO at Ping Identity. Pamela has a long history with Identity Management, focusing on implementation, architecture and strategy over 10 years of evolution of systems such as directories, application servers, web access management systems, provisioning, and now federation. Pamela serves on the board of directors of the OpenID Foundation, and has in the past run the Pamela Project, an open source project for RP-enabling Information Card websites Penton Media, Inc. All rights Reserved. Page 6