From an earlier step, you should have gathered the location information for the Certificate Sharing Container. We will now use that information to manually remove the container from AD by following these steps:
1. From a Windows 2008 or later Server that has the Active Directory Domain Services role installed, click Start. Click Run, and then type ADSIEdit.msc, as shown in Figure 3-51.
If you need to install ADSIEdit on a server that is not running Windows 2008 or on a workstation, see “ADSI Edit (adsiedit.msc)” at http://technet.microsoft.com/en-us/library/cc773354.aspx.
Figure 3-51. Run ADSIEdit.msc.
2. Right-click ADSI Edit and select Connect to, as shown in Figure 3-52.
Figure 3-52. Right-click ADSI Edit and select Connect to.
3. Under Connection Point, click Select a well-known Naming Context, as shown in Figure 3-53. Then click OK.
Figure 3-53. Select the default naming context.
4. Refer to the location information of the Certificate Sharing Container you collected at the very
beginning. In our example, we noted that the container is at CN=ADFS,CN=Microsoft,CN=Program Data,DC=thomsonhills,DC=com.
Applying this information to our example, and reading backward starting from
DC=thomsonhills,DC=com, expand CN=Program Data, followed by CN=Microsoft, and finally CN=ADFS. Navigate in that order, as shown in Figure 3-54.
Figure 3-54. Locating the Certificate Sharing Container in ADSIEdit.msc.
5. Look for the GUID of the farm. You should already have that information from an earlier step. In our example, the GUID we are looking for is 2e9a65b9-3a14-43e1-b9ec-d965fb6272c5, as shown in Figure 3-55. Right-click the appropriate GUID and select Delete.
Figure 3-55. Locate, right-click, and delete the GUID that matches the AD FS farm.
You have now completely uninstalled AD FS and manually cleaned up all the objects and settings that were not removed by the uninstallation process.
Summary
In this chapter, we undertook and implemented SSO, a key component that is unique to enterprises and available only in the Office 365 Enterprise (A1/G1/E1, A3/G3/E3, or A4/G4/E4) suite offerings. There
are many technologies that made this possible, the most important of which is a healthy Active Directory.
With most enterprise Office 365 deployments, we advocate an Active Directory health assessment. As a reminder, the Microsoft Office 365 Deployment Readiness Toolkit will analyze your AD for Office 365 readiness. The most important thing is to ensure that your forest has a routable UPN suffix that you will assign to the users in the forest. This is also a requirement for directory synchronization (Directory Sync), which we will cover Chapter 4. The planning work you did in Chapter 2, should have prepared your environment and made the tasks in this chapter less daunting.
It is also important to stress that when you turn on SSO, you are in fact deferring authentication to your on-premises AD FS farm. Therefore, if the AD FS farm is unreachable for whatever reason, Office 365
services will be unavailable for users who are not yet authenticated. Invest in the time and architecture to build a robust AD FS farm and consider alternative and redundant options such as Windows Azure IaaS to supplement your AD FS farm.
Chapter 4. Directory Synchronization
Directory synchronization process Activating directory synchronization
Installing Windows Azure Active Directory Sync Verifying directory synchronization
Forcing an unscheduled directory synchronization Changing the directory synchronization schedule
Troubleshooting common directory synchronization errors
ALL user accounts in Office 365 use the User Principal Name (UPN) format. In the preceding chapter, we set up Active Directory Federation Services (AD FS) and SSO so that when users are authenticated by Active Directory (AD), they will be granted access. If they have not been authenticated by AD, they will be presented with the Office 365 portal logon screen, and they will need to supply a user name in UPN format.
If a federated UPN suffix is supplied, Office 365 automatically redirects the authentication request to your AD FS service. If it is not a federated UPN suffix or if the suffix is *.onmicrosoft.com, then Office 365 is responsible for the authentication. Collectively, this addresses the authentication process for Office 365.
However, we still need to address how accounts are created in the Office 365 tenant. A corresponding Office 365 account needs to exist for each user needing access to Office 365.
The theme throughout this book is automation. As an enterprise, the last thing we want to do is manually maintain a second set of user accounts in Office 365. Office 365 user account automation comes in the form of directory synchronization.
During the directory synchronization process, a corresponding Office 365 account is created for each user account in AD, as shown in Figure 4-1.
Figure 4-1. Directory synchronization with the Directory Sync tool.
Directory synchronization is accomplished through a free piece of software known as the Windows Azure Active Directory Sync tool, which is supplied by Microsoft specifically for use with Office 365
subscriptions. Under the covers, directory synchronization is really a customized distribution of Microsoft Forefront Identity Manager (FIM) 2010. FIM is used for more advanced directory synchronization
scenarios that we will cover in Chapter 16. You will hear the terms directory synchronization, DirSync, and Windows Azure Active Directory Sync used interchangeably. DirSync is used more frequently because of its brevity. We will generally reference it as directory synchronization throughout the book.
Directory synchronization is provided as a software tool, which means minimal configuration is required for directory synchronization to work. The important facts to know about directory synchronization are the following:
Directory synchronization creates a copy of AD accounts in Office 365.
A new directory synchronization option allows you to configure directory synchronization to synchronize AD passwords to Office 365. This is sometimes known as same sign on.
Without implementing AD FS, directory synchronized accounts will require their own passwords in Office 365. This is accomplished by manually administering passwords in Office 365 or by using the new password sync option in directory synchronization.
Accounts that are directory synchronized in Office 365 are not automatically granted access to Office 365 services. A separate action, manual or automated, must occur to assign Office 365 licenses to accounts. So, it is not uncommon to have more accounts in Office 365 than what you have licenses for because not all accounts require Office 365 access.
Directory synchronization is a required prerequisite for SSO, Lync Online and Lync on-premises coexistence, and Exchange hybrid deployments.
Directory synchronization is also responsible for the synchronization of other AD objects, such as distribution lists (DLs), photos, and security groups.
For the most part, directory synchronization is a one-way push of information from AD to Office 365.
However, if you require a hybrid scenario for Exchange, a two-way synchronization needs to occur because directory synchronization needs to write some information back to AD to facilitate mail flow for a hybrid environment, where some mailboxes reside in Office 365 while others reside on-premises. We will take a deeper look at all the two-way synchronization occurrences in Chapter 11, “Incorporating Exchange Online in the Enterprise,” which focuses on Exchange Online.
Directory synchronization synchronizes a number of AD attributes into Office 365, and you can configure it to include other attributes. At a minimum, directory synchronization requires the following attributes to contain values before the account can be synchronized:
CN
Members (if the object is a group)
samAccountName (if the object is a user account) Alias (if the object is a group or contact)
DisplayName (if the object is a group with a mail or proxyAddress attribute populated)
NOTE
For a full list of attributes that directory synchronization synchronizes to Office 365, see KB article 2256198 at http://support.microsoft.com/kb/2256198/en-us.
INSIDE OUT: LEVERAGE BOT H IDENT IT IES
You might think you must choose to use either cloud identities or federated identities, but be aware there is no reason why you cannot use
both. For example, in many enterprise organizations with AD, there might be a reluctance to create and maintain accounts for non-employees because of security and licensing concerns. These non-employee accounts might belong to vendors, business-to-business (B2B) partners, or contractors for whom you want access to Office 365 because you are doing business with them. This is a classic example of an extranet. There is a special class of cloud identity that allows for partner access to Office 365 at no cost. These are called Partner Access Licenses (PALs), and each Office 365 tenant comes with a number of PALs. PALs allow you to invite external users so they can access content stored in SharePoint Online. For more information about PALs, see the SharePoint Online Service Description. On the other hand, if you want to provide non-employees with other Office 365 services but do not want to create an account for them in AD, you can create a cloud identity for the non-employees and assign them access to Office 365. The important thing to note here is that cloud identities can coexist alongside federated identities in the same Office 365 tenant.