office 365 for centrify identity services · office 365 for centrify identity services ... how the...

Office 365 for Centrify Identity Services

With Centrify Identity Services, you can deploy Office 365 so that you don’t need to install ADFS in your local network. The Centrify Directory Service handles the authentication and communication with your Active Directory system automatically. You can provide single sign-on to users in Active Directory, LDAP, the Centrify Directory, or any combination of those sources.

You can also provision users and assign them Office 365 licenses. For details, see Office 365 provisioning.

After you’ve configured the application in the Admin Portal, your users can launch Office 365 from the user portal either from a web browser or a mobile device. Also, your users can use Outlook and Lync/Skype for Business using their Office 365 credentials. For details about configuring desktop and mobile clients, see Office 365: Configuring thick clients.

64

Office 365 SSO deployment overview

Office 365 SSO deployment overviewNote You do not need to install ADFS to configure SSO for Office 365. The Centrify Directory Service handles the federated identities for you.

To configure and deploy Office 365 for web browser access:

1 Review the Requirements and installation information and perform any tasks needed to prepare your computers.

2 Prepare your account, domain, and user accounts; see Preparing Office 365 for SSO.

a Create an Office 365 account.

b Create and verify a domain. For more information, see Creating and verifying a domain in Office 365.

3 Configure the application settings in the Admin Portal. For details, see Configuring Office 365 in Admin Portal.

After these steps, you’re ready to launch Office 365 from the user portal.

4 (Optional) You can configure Microsoft desktop applications or mobile devices to use Office 365 credentials. For details, see Office 365: Configuring thick clients and see http://help.outlook.com/en-us/140/dd936215.aspx.

Understanding desktop application authentication with Office 365

If you’re curious as to how Office 365 and the Centrify Directory Service authenticate users using Active Directory, this section is for you.

Office 365 is Microsoft’s offering of Microsoft Office applications available by way of a Centrify Directory Service, so that customers don’t have to manage on-premise servers. Office 365 does provide their own Single Sign-on solution, but it requires customers to install an Active Directory Federation Services (ADFS) server on-premise.

The benefit of using Centrify for Office 365 is that you can still provide single sign-on access to your users, you won’t have to manage many on-premise servers for Exchange and other applications, and you won’t have to install an ADFS server. Centrify for Office 365 takes care of authenticating user identities for access to web-based applications.

Note For your information, Centrify for Office 365 generates SAML tokens and uses the WS-Federation protocol.

The figure below illustrates how Centrify Identity Services works with Office 365 to authenticate a user by way of a desktop application such as Outlook.

Admin Portal user’s guide 65

http://help.outlook.com/en-us/140/dd936215.aspx

http://help.outlook.com/en-us/140/dd936215.aspx

Office 365 SSO deployment overview

The following information describes each step in the Centrify for Office 365 authentication process for use with desktop applications such as Outlook or Lync/Skype for Business.

Note The information below refers to Outlook specifically, but the same process occurs for Lync/Skype for Business.

• 66

Migrating an existing Centrify for Office 365 deployment

The Centrify Directory Service sends authentication meta data to Office 365

What happens when the Centrify Directory Service administrator adds the Office 365 application:

1 You, the Centrify Directory Service administrator, add and deploy the Office 365 application.

You add the Office 365 application in the Admin Portal, enter your organization’s unique Office 365 details, and you deploy the application so that users can launch it from the user portal.

2 After you deploy the Office 365 application, the Centrify Directory Service sends authentication meta data to Office 365 and federates the Office 365 account.

This meta data contains information that tells Office 365 how to contact the directory service for user authentication.

How the directory service and Office 365 authenticate users with Outlook or Lync/Skype for Business

How the directory service and Office 365 authenticate users from the Microsoft desktop client (such as Microsoft Outlook):

1 When the user opens Microsoft Outlook on the computer, Outlook requests the authentication meta data from Office 365.

2 Office 365 returns the authentication information to Outlook.

3 Next, based on the information in Step 2, Outlook requests an authentication token from the directory service.

4 The directory service requests the connector to identify and authenticate the user.

5 The connector reads the relevant information from Active Directory and identifies and authenticates the user.

The connector uses a read-only connection to Active Directory.

6 The connector returns the authentication information back to the directory service through a standard HTTPS encrypted tunnel.

7 The directory service sends the requested authentication token from Step 3 back to Outlook.

8 Outlook uses the authentication token to get emails for the user.

Migrating an existing Centrify for Office 365 deploymentThere is no way to migrate deployment settings from the deprecated Centrify for Office 365 application to the Office 365 + Provisioning application. However, it is easy to


Requirements and installation information

configure which application instance owns which domain; you can transfer domain ownership to the new Centrify for Office 365 + Provisioning application when you’re ready to do so.

If you’re already using Office 365, we recommend that you upgrade your Office 365 deployment as listed below.

Note In Admin Portal, be sure to delete your existing Office 365 application before you take ownership and federate the domain using the new Office 365 + Provisioning application. If you delete the existing Office 365 application later, you unfederate the domain (even if you’ve already federated it using the Office 365 + Provisioning application).

Here are some things that you need to know if you have an existing Centrify for Office 365 deployment: We recommend that you first configure provisioning with a test domain.

If you have existing users who have already been assigned licenses in Office 365, be sure to assign their respective roles the same kind of license. For automatic user provisioning, the Centrify directory service overwrites the user’s license assignments if you specify to merge duplicate user accounts.

To upgrade an existing Centrify for Office 365 deployment

1 Make sure that your existing deployment is set up and ready to use Centrify for Office 365. For details, see the Office 365 deployment checklists section.

Note Even if you’re going to use provisioning instead of DirSync, you still need to enable synchronization in the Office 365 administrator portal.

2 In Admin Portal, delete your existing Office 365 application.

3 Disable Microsoft DirSync.

4 Add and configure the Office 365 + Provisioning application, and transfer the domain ownership to this application.

Requirements and installation informationTo install and deploy Office 365 using Centrify Identity Services, do the following: WARNING: Before continuing, it’s very important that you have at least one user with

administrative privileges in Office 365 and you make sure that the user is not in Active Directory. This administrative account is in case you need to revert your Office 365 account back to user password authentication or if you need to make any configuration changes, such as changing your certificate or Issuer name. Otherwise, you could lock yourself out of your Office 365 administrative account.

• 68

Supported Office 365 account types

For new Office 365 accounts only: You or someone in your IT department needs access to the DNS registrar that hosts the domain you register to use with Office 365. You’ll need to add in some DNS records to verify domain ownership.

Access and port requirements:

The server that hosts the Microsoft Directory Synchronization tool must have Internet access, and it also needs just the inbound port 443 in order to communicate with the connector.

The server that runs the Active Directory domain controller doesn’t require Internet access.

Be sure that local networking is configured for the servers in use - the domain controller computer, the server that hosts the Directory Synchronization tool (if separate from the domain controller), and the servers running the connector.

Configure your firewall to allow the following port traffic:

Supported Office 365 account typesCentrify typically supports all types of Office 365 accounts available at the time of release. Microsoft may change available account types without notice, so in rare instances the account types available in the Admin Portal might not match the account types listed by Microsoft. Refer to http://office.microsoft.com/en-us/business/compare-office-for-business-plans-FX102918419.aspx for more information about Office 365 account types.

Note If you intend for your users to use desktop applications such as Outlook, Lync/Skype for Business, and others, be sure that your Office 365 license provides desktop versions or that your organization provides the desktop installation files to your users.

Traffic Port numbers Domains

Outbound 80/443 *.cloudapp.net

Outbound 80/443 *.centrify.com

Outbound 80/443

or 9350–9354 TCP ports

Azure Data Centers

Outbound 80/443 www.public-trust.com

Outbound 80/443 mscrl.microsoft.com


http://office.microsoft.com/en-us/business/compare-office-for-business-plans-FX102918419.aspx




Preparing Office 365 for SSO

Preparing Office 365 for SSOThis section applies to you if you are creating a new Office 365 account, or if your Office 365 accounts aren’t already federated using ADFS or another identity provider

Before you can configure Office 365 for SSO, you need to first add your custom domain, get the domain verified, and add your Office 365 user accounts. Use the Office 365 administrative portal to perform these tasks.

To prepare Office 365 for SSO

1 Create and verify a custom domain for use with Office 365. For more information, see Creating and verifying a domain in Office 365.

2 Synchronize AD user accounts with Exchange Online.

If you’re using Active Directory, use the Microsoft Active Directory Synchronization tool to synchronize your Active Directory user accounts into Office 365.

If you’re not using Active Directory, create the user accounts manually in Office 365. Edit each user account in order to assign Office 365 feature licenses to the user.

Creating and verifying a domain in Office 365

In order to use SSO with Office 365, you need a unique Office 365 domain. This domain must be an externally accessible domain that resolves to an IP address that belongs to your

After you synchronize your Active Directory users to Office 365, view and them in Users.

Add and manage your custom domain in Domains.

Administer Office 365 licenses to your users in Licenses.

Click your company name to open your organization settings and specify the default domain—to something other than your custom Office 365 domain.

• 70


organization. The IP address must be routable to the server where the you’ve installed the connectors (and the Microsoft Directory Synchronization tool, if you’re still using it). Your Office 365 domain must also be different than the one provided by Microsoft with the onmicrosoft.com domain.

Expect that the process of creating and verifying a domain may take anywhere from a day to a week or so to complete, depending on the time it takes to register a domain with a domain provider, editing the DNS entries to verify ownership, and having Microsoft verify the domain ownership.

Microsoft outlines the steps for adding and verifying your domain here:

https://support.office.com/en-za/article/Verify-your-domain-in-Office-365-6383f56d-3d09-4dcb-9b41-b5f5a5efd611?ui=en-US&rs=en-ZA&ad=ZA

In general, the process of registering and verifying your domain is as follows:

1 You or someone in your IT department creates and registers the domain with a domain registrar. For example, acme.net.

2 Log on to the Microsoft Office 365 Admin Portal at the following URL and Enter your administrator user name (an email address) and password. https://portal.microsoftonline.com

3 Click Domains to view your domains or add a new domain to Office 365.

If you don’t already have a domain listed here, you need to add it here and verify ownership of the domain according to the instructions on the Office 365 web site.

4 Click Add domain to add the domain to Office 365.









Note Be sure that the domain that you add is not specified as the default domain. Otherwise, single sign-on may not work. For details, see Setting the default domain.

5 From Office 365, get the DNS text records to insert for domain verification. For details, see the following Microsoft information:

https://support.office.com/en-US/Article/Add-your-domain-to-Office-365-ffdb2216-330d-4d73-832b-3e31bcb5b2a7?ui=en-US&rs=en-US&ad=US

6 You (or someone in your IT department) goes to the domain registrar and enters the DNS text records.

Be sure to enter the text records based on the services you’ll be using. For example, if you’re only using Office 365 web access, you don’t need to specify Exchange and Lync/Skype for Business settings.

7 In the Domains area of Office 365, check the status of the domain.

Tip While viewing your domain’s settings, click the link to troubleshoot your domain. The troubleshooting page shows if your DNS settings are correct.

The Office 365 site says that you should wait up to 72 hours after inserting the DNS text record before you try to verify the domain. After Office 365 lists the domain as verified, you’re ready to continue. If your domain doesn’t verify, the domain that you’re trying to use may be in use already by another employee or entity (or try a different domain).

Setting the default domain

Be sure that your custom, externally accessible domain is not specified as the default domain. Otherwise, single sign-on may not work. Instead, set the default domain to the one that has the company.onmicrosoft.com format.

To set the Office 365 default domain

1 Log in to the Office 365 administrative portal.

2 In the upper-right corner of the administration dashboard, click your company name.

Your organization’s settings display.

• 72






3 In the Default Domain list box, select your domain that has the company.onmicrosoft.com format.

4 Click Save.

For more information about setting a default domain, see https://support.office.com/en-us/article/Change-your-default-domain-for-email-in-Office-365-1bd69e1c-9598-49ce-b341-9ac895dbe681.

Enabling directory synchronization

Whether you’re synchronizing Centrify Directory users or Active Directory users, you need to enable synchronization in Office 365.


https://support.office.com/en-us/article/Change-your-default-domain-for-email-in-Office-365-1bd69e1c-9598-49ce-b341-9ac895dbe681







To enable synchronization in the Office 365 administrator portal

1 In the Office 365 administrative portal, select USERS > Active Users, then click Set Up next to Active Directory synchronization.

2 Click Activate in the Activate Directory Synchronization step, then click through the prompts until Active Directory Synchronization is activated.

Activating the Active Directory synchronization enables you to synchronize your Centrify Directory and Active Directory users into Office 365.

• 74

Configuring Office 365 in Admin Portal

Configuring Office 365 in Admin PortalThe following steps are specific to the Office 365 application and are required in order to enable SSO for Office 365. For information on optional Centrify Admin Portal configuration settings that you may wish to customize for your app, see Optional configuration settings.

When you add the Office 365 application, be aware of the following: When you add the Office 365 application and specify the application settings, this

process federates your Office 365 account.

If you delete the Office 365 application after adding it (whether or not you’ve deployed the application), your Office 365 account reverts to user name and password authentication.

In order for the Outlook desktop application to work with Office 365, do not rename the Office 365 application. The application must be named Office 365 and there can be only one application deployed with that name.

Adding the Office 365 application

To add the Office 365 application in Admin Portal

1 In Admin Portal, click Apps, then click Add Web Apps.

The Add Web Apps screen appears.

2 On the Search tab, enter the partial or full application name in the Search field and click the search icon.

3 Next to the application, click Add.



4 In the Add Web App screen, click Yes to confirm.

Admin Portal adds the application.

5 Click Close to exit the Application Catalog.

The application that you just added opens to the Settings page.

6 Click the Trust page to begin configuring the application.

The UI is evolving in order to simplify application configuration. For example, many of the settings previously found on the Application Settings page are now on the Trust page. You might have to select Manual Configuration to expose those settings, as shown in the following example.

Any previously configured applications retain their configuration and do not require reconfiguration. If you are configuring an application for the first time, refer to the Trust page for any settings previously found on the Application Settings page.

In addition, the description of how to choose and download a signing certificate in this document might differ slightly from your experience. See Choose a certificate file for the latest information.

• 76


Note If you have multiple Office 365 accounts or domains, you can add an application for each account or domain.

Configuring the Office 365 application

To configure the Office 365 application for SSO

1 Make sure that your existing deployment is set up and ready to use Centrify for Office 365. For details, see the Office 365 deployment checklists section.

Note To synchronize with Office 365, you use provisioning. If you’re not going to enable provisioning, you use Microsoft DirSync to synchronize your user accounts with Office 365.

2 Open the Office 365 application.

Entering and verifying your Office 365 administrator credentials

3 On the Application Settings page, enter the user name and password for your Office 365 administrator account of the default domain company.onmicrosoft.com, then click Verify.

The directory service verifies the credentials and connects to your account. Once the verification succeeds, the Application Settings page displays the Office 365 domains section.

Federating or owning the Office 365 domain

4 Select the domain that you want to federate or take ownership of with Centrify for Office 365, then click Actions.



If the domain is in Managed state, you federate it. If the domain is already federated, you take ownership of it and federate it with Centrify for Office 365. If you change the security certificate used with Centrify for Office 365, you will need to refederate the domain. Refer to Choose a certificate file for more information about changing the certificate file.

Tip Taking ownership of a domain is useful in cases where you’ve already federated your account using another system or another instance of the Office 365 + Provisioning application.

Note If you have multiple Office 365 domains, you create a separate application in Admin Portal for each domain.

In the pop-up menu that displays:

If you selected a managed domain, click Federate Domain.

If you selected a federated domain, click Take Ownership.

If you changed the security certificate on the Application Settings page, click Refederate Domain.

• 78


The domain must be owned by the Office 365 application to refederate the domain.

A message displays that prompts you for confirmation.

5 Click Yes to continue.

If you selected to federate a managed domain, the directory service changes the selected domain in Office 365 to federated status.

If you selected to take ownership of a federated domain, the directory service changes the selected domain in Office 365 to use your current directory service tenant as the identity provider.

Future logins will be handled by the directory service.

Note If your Office 365 domain was previously federated by using Microsoft DirSync or DirSync and ADFS, then you should go stop those services from running. The directory service takes ownership of the federated domain, but it doesn’t stop your previous tools, such as DirSync, from running. You must disable DirSync manually, and you may notice synchronization issues if you do not disable DirSync after switching to Centrify for Office 365 for SSO.

6 (Optional) On the Settings page, click Enable Derived Credentials for this app on enrolled devices (opens in built-in browser) to use derived credentials on enrolled mobile devices to authenticate with this application.

For more information, see Derived Credentials.

Configuring the application additional options and description


https://docs.centrify.com/en/centrify/adminref/index.html#context/cloudhelp/derivedCreds

https://docs.centrify.com/en/centrify/adminref/index.html#context/cloudhelp/derivedCreds


7 On the Application Settings page, expand the Additional Options section and specify the following settings.

Note Once you provision users to this application, changing the application ID in any way will prevent users from launching the application. If you change the application ID, you will have to save the application, then unfederate and take ownership of your domain to restore access.

Option Description

Application ID If you’re also deploying a native mobile version of this application into a Samsung KNOX container, enter the Application ID.

The directory service uses the Application ID to provide single sign-on to the native Samsung KNOX mobile application. The Application ID must match the SAML Target referenced inside the Samsung KNOX container.

The Application ID is case-sensitive and can be any combination of letters, numbers, spaces, and special characters up to 256 characters.

Show in User app list Select Show in User app list so that this web application displays in the user portal. (By default, this option is selected.)

If this web application is only needed in order to provide SAML for a corresponding mobile application, deselect this option. This web application won’t display for users in the user portal.

• 80


8 (Optional) On the Settings page, you can change the name, description, and logo for the application. For some applications, the name cannot be modified.

The Category field specifies the default grouping for the application in the user portal. Users have the option to create a tag that overrides the default grouping in the user portal.

Configuring the user access and installation type

9 On the User Access page, select the role(s) that represent the users and groups that have access to the application.

When assigning an application to a role, select either Automatic Install or Optional Install:

Select Automatic Install for applications that you want to appear automatically for users.

If you select Optional Install, the application doesn’t automatically appear in the user portal and users have the option to add the application.

Configuring the authentication policy



10 (Optional) On the Policy page, specify additional authentication controls for this application.

a Click Add Rule.The Authentication Rule window displays.

• 82


b Click Add Filter on the Authentication Rule window.

c Define the filter and condition using the drop-down boxes.For example, you can create a rule that requires a specific authentication method when users access the Centrify Directory Service from an IP address that is outside of your corporate IP range. Supported filters are:

Filter Description

IP Address The authentication factor is the computer’s IP address when the user logs in. This option requires that you have configured the IP address range in Settings, Network, Corporate IP Range.

Identity Cookie The authentication factor is the cookie that is embedded in the current browser by the directory service after the user has successfully logged in.

Day of Week The authentication factor is the specific days of the week (Sunday through Saturday) when the user logs in.

Date The authentication factor is a date before or after which the user logs in that triggers the specified authentication requirement.

Date Range The authentication factor is a specific date range.

Time Range The authentication factor is a specific time range in hours and minutes.

Device OS The authentication factor is the device operating system.

Browser The authentication factor is the browser used for opening the Centrify Identity Services user portal.



d Click the Add button associated with the filter and condition.

e Select the profile you want applied if all filters/conditions are met in the Authentication Profile drop-down.The authentication profile is where you define the authentication methods. If you have not created the necessary authentication profile, select the Add New Profile option. See Creating authentication profiles.

f Click OK.

g (Optional) In the Default Profile (used if no conditions matched) drop-down, you can select a default profile to be applied if a user does not match any of the configured conditions.If you have no authentication rules configured and you select Not Allowed in the Default Profile dropdown, users will not be able to log in to the service.

h Click Save.If you have more than one authentication rule, you can prioritize them on the Policy page. You can also include JavaScript code to identify specific circumstances when you want to block an application or you want to require

Country The authentication factor is the country based on the IP address of the user computer.

Risk Level The authentication factor is the risk level of the user logging on to user portal. For example, a user attempting to log in to Centrify Identity Services from an unfamiliar location can be prompted to enter a password and text message (SMS) confirmation code because the external firewall condition correlates with a medium risk level. This Risk Level filter, requires additional licenses. If you do not see this filter, contact Centrify Identity Services support. The supported risk levels are:

• Non Detected -- No abnormal activities are detected.

• Low -- Some aspects of the requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on the policy setup.

• Medium -- Many aspects of the requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on the policy setup.

• High -- Strong indicators that the requested identity activity is anomaly and the user's identity has been compromised. Immediate remediation action, such as MFA, should be enforced.

• Unknown -- Not enough user behavior activities (frequency of system use by the user and length of time user has been in the system) have been collected.

Managed Devices The authentication factor is the designation of the device as “managed” or not. A device is considered “managed” if it is managed by Centrify Identity Services, or if it has a trusted certificate authority (CA has been uploaded to tenant).

For the Day/Date/Time related conditions, you can choose between the user’s local time and Universal Time Coordinated (UTC) time.

Filter Description

• 84

https://docs.centrify.com/en/centrify/adminref/index.html#context/cloudhelp/authentication-profiles

https://docs.centrify.com/en/centrify/adminref/index.html#context/cloudhelp/authentication-profiles


additional authentication methods. For details, see Application access policies with JavaScript.

Note If you left the Apps section of Admin Portal to specify additional authentication control, you will need to return to the Apps section before continuing by clicking Apps at the top of the page in Admin Portal.

Note Office 2013 and 2016 rich client applications using Active Directory Authentication Library (ADAL) do not support the ability to use policy scripts to block external access to them.

Configuring the account mapping (for initial testing)

Note If you are continuing to use the Microsoft Directory Synchronization tool, make sure that you configure the account mapping details. If you’re going to use automatic user provisioning, it’s a good idea to configure the account mapping information for initial testing and verification before you add provisioning.

11 On the Account Mapping page, configure how the login information is mapped to the application’s user accounts. The options are as follows:

Use the following Active Directory field to supply the user name: Use this option if the user accounts are based on Active Directory user attributes. Specify the Active Directory field userPrincipalName.

Everybody shares a single user name: Use this option if you want to share access to an account but not share the user name and password. For example, some people share an application developer account.

Use this script: You can customize the user account mapping here by supplying a custom script. For example, you could use the following line as a script:LoginUser.Username = LoginUser.Get('mail')+'.ad';

The above script instructs the Admin Portal to set the login user name to the user’s mail attribute value in Active Directory and add ‘.ad’ to the end. So, if the user’s mail attribute value is [email protected] then the Admin Portal uses [email protected].

12 (Optional) On the SAML Response page, you can edit the script that generates the SAML assertion, if needed. In most cases, you don’t need to edit this script. For more information, see the SAML application scripting.

13 (Optional) On the Changelog page, you can see recent changes that have been made to the application settings, by date, user, and the type of change that was made.

14 (Optional) Click Workflow to set up a request and approval work flow for this application.



The Workflow feature is a premium feature and is available only in the Centrify Identity Services App+ Edition. See Configuring Workflow for more information.

15 Click Save.

After federating a domain and taking ownership of it, the sign in experience changes for your users. Instead of entering user credentials on the Office 365 sign-in page, users will see their identity listed as a possible account to sign in to. For example:

After users click their identity, they are redirected to the Centrify User Portal if they are not currently signed in to the Centrify User Portal. If they are signed in to the Centrify User Portal, they are automatically signed in to Office 365.

For example, users see the following message after clicking their identity on the Office 365 sign-in page.

Refer to SAML and WS-Federation SSO options for additional information about how single sign-on works.

16 (Optional) To configure the Office 365 application for automatic provisioning, see Office 365 provisioning.

• 86


Office 365 linked applications (preview)With Office 365 you can use the Linked Applications page to add and configure links directly to Office 365 applications such as Excel or SharePoint. Linked applications inherit user access information from their parent application. You can even link directly specific SharePoint sites; just enter the site URL when you add SharePoint as a linked application.

Note Adding SharePoint sites as linked apps requires enabling auto acceleration for the federated domain using Microsoft Powershell. Refer to To enable auto acceleration for the federated domain for to learn how to enable auto acceleration, and https://blogs.technet.microsoft.com/sposupport/2016/11/07/auto-acceleration-in-sharepoint-online/ for more information about auto acceleration.

You can delete linked applications either from the Linked Applications page of their parent app, or directly from the list of apps in the Admin Portal.

To enable auto acceleration for the federated domain

1 Download and install the SharePoint Online Management Shell, found here: https://www.microsoft.com/en-us/download/details.aspx?id=35588.

2 Open the SharePoint Online Management Shell.

3 Connect to SharePoint Online with the following command, replacing <MyDomain> with your domain and entering credentials when prompted.Connect-SPOService -URL https://<MyDomain>-admin.sharepoint.com

4 Enable auto acceleration with the following command, typing Y to confirm when prompted.Set-SPOTenant -SignInAccelerationDomain "<Federated Domain>"

Auto acceleration is now enabled for your federated domain. Refer to the following image for an example of SharePoint Online Management Shell session enabling auto acceleration. Note that Centrify domains are hidden.

5 (Optional) If your SharePoint sites are shared with external users, enable guest sign in acceleration with the following command, typing Y to confirm when prompted.Set-SPOTenant -EnableGuestSignInAcceleration $true


https://blogs.technet.microsoft.com/sposupport/2016/11/07/auto-acceleration-in-sharepoint-online/



https://www.microsoft.com/en-us/download/details.aspx?id=35588








To add a linked application

1 Click Linked Applications in the Admin Portal for your app.

2 Click Add.

You will see a list of apps to choose from. For example:

3 Select an app to add, then click Finish.

Note For SharePoint Online, you will need to click Next to enter the site URL before you can click Finish.

4 Click Save.

• 88


5 Click on the app you just added in the list of Linked Applications. A new tab opens in your browser and navigates to the Application Settings page for your new linked app.

6 Review the settings for the app. You can keep all the default settings for the app, or you can:

Change any of the fields on the Description tab.

Deselect Inherit Access Roles from Parent on the User Access tab and then select only the roles you want. See Allow access to the application for more information.

Change the URL for any app that you previously specified the URL for. Note: you cannot change the URL for pre-formatted apps (any app you selected from a list).

To delete linked applications:

1 Click the Linked Applications tab on the parent of the app you want to delete.

2 Select the app you want to delete from the list.

3 Click Actions, then click Delete.

4 Click Save.

Note This deletes the app, not just the link between apps.

Office 365 provisioningCentrify for Office 365 + Provisioning can synchronize and provision users from Active Directory, LDAP, and the Centrify Directory. In addition, Centrify can provision AD contacts, groups, and resources to Office 365.

Before configuring the Office 365 application for provisioning, you must install, configure, and deploy the app.

Complete the following tasks before configuring provisioning for Office 365: Make sure that your existing Office 365 deployment meets or exceeds the requirements

and recommendations listed in the Office 365 deployment checklists

add and configure the Office 365 + Provisioning application

verify administrator credentials of the default <yourdomain>.onmicrosoft.com domain

take ownership of your federated domain

See Office 365 for Centrify Identity Services for details on adding and configuring the application, verifying administrator credentials, and federating and taking ownership of your domain.



Provisioning AD objects and licensing users to Office 365

You can provision specific users by adding a role mapping instead of selecting user objects for the domain, or can you provision all users in a domain/login suffix by selecting that object type in the provisioning grid. Licensing users in Office 365 requires mapping roles to licenses. In addition to users, you can provision other AD objects (contacts, resources, and groups) by selecting the object types that you want to provision for each domain/login suffix. Selecting object types provisions all objects of the selected type for that domain/login suffix (unless you reject specified objects with a script).

When you change a Admin Portal role membership or a user’s AD group membership for an AD group that is a member of a role, the Centrify Identity Services synchronizes these changes automatically.

When you provision an Active Directory group that contains a child group, Centrify Identity Services creates a group object in Office 365 for the child group, but does not provision the child group’s members as part of provisioning the parent group’s members. However, the child group’s members would be provisioned separately by Centrify Identity Services if you chose to provision groups. If you want to prevent an AD group from being provisioned to Office 365, see Excluding AD objects from synchronizing.

Refer to Setting up app-specific provisioning for more information about how the Centrify Directory Service handles provisioning.

To automatically provision users with Office 365 accounts

1 On the Application Settings page, make sure that you’ve already entered and verified your Office 365 administrator credentials and taken ownership of the domain.

2 Select Enable provisioning for this application.

A warning appears prompting you to disable the Microsoft DirSync tool before using Centrify for provisioning

3 Disable the Microsoft DirSync tool if you haven't already done so, otherwise click Close to continue.

4 Select either Preview Mode or Live Mode.

• 90


Preview Mode: Use Preview Mode when you’re initially testing the application provisioning or making configuration changes. The identity platform does a test run to show you what changes it would make but the changes aren’t saved.

Live Mode: Use Live mode when you want to use application provisioning in your production system. The identity platform does the provisioning run and saves the changes to both the identity platform and the application’s account information.

5 Select objects to provision.

If your deployment uses a hybrid deployment where you have on-premise Exchange servers in addition to Office 365 Exchange Online, you can select the login suffixes and domains, as well as objects in Active Directory domains, that you want to sync with Office 365.

Tip User objects from the Centrify Directory are synced when you create or delete Centrify Directory users. Active Directory objects are synced when the object’s Active Directory attributes are changed. If you want to sync existing Centrify Directory or AD objects without making changes in the source directory, manually start a sync. Otherwise, objects will sync during the next daily sync. Refer to Provisioned account synchronization options for more information about manually syncing source directory objects.

Note To sync objects from on-premise Exchange servers, make sure you have configured the connectors joined to those domains.

6 Specify duplicate or existing account handling

Select either Overwrite or Keep to specify how the Centrify Directory Service handles situations when it determines that the user already has an account in the target application (same userPrincipalName).

overwrite: Updates and overwrite the target application user account information with the Centrify Directory user account information. This includes removing data if



the target account has a value for a user attribute that is not available from the Centrify Directory

no overwrite: Keeps the target user account as it is; the Centrify Directory Service skips and doesn’t update the duplicate user account in the application.

do not deprovision: The user's account in the target application is not de-provisioned when a role membership change that would trigger a de-provisioning event occurs.

7 Add the role mappings and licenses.

Select whether you want to assign licenses mapped to each role a user is a member of, or if you want to assign a single license based on role mapping order.

For example:

Licenses for all mapped roles: If a user is a member of two roles mapped to separate licenses, the user is assigned both licenses.

Single license based on order: If a user is a member of two roles mapped to separate licenses, the user is assigned the license mapped to the role that is higher in the role mapping list.

8 To add role mappings and specify which users get provisioned to this application, click Add.

• 92


The License and Attributes dialog box opens. The Centrify Directory Service connects to your account and lists the license profiles that are available for your account, including how many licenses have been used and how many are available.

9 From the Role list, select the desired role.

The Centrify Directory Service uses this role to synchronize the users that belong to this role.

10 Select one or more license profiles that the users in the specified roles will have.

If you select a license profile that has additional options, select or deselect those additional options as needed. For example, you can specify a specific software within an E1 license, if you need to do so.

Note If you don’t specify a license, the Centrify Directory Service synchronizes the user but the user isn’t licensed to use any Office 365 features. The user can log in to Office 365, but the user cannot access Office 365 features.

Note If you have local users that do not have Office 365 access but you still need to see the user accounts in Office 365, you can assign those users to a role that you do not assign a license to in the role mappings section. For example, this can be helpful if you want your Office 365 users to be able to email these local users.

11 Click Save to save the role mapping and return to the Provisioning page.

12 Continue adding roles and license profiles, as needed.

To change a mapping, select the role mapping and click Modify.

To remove a mapping, select the role mapping and click Delete.

To change the order of the role mappings, select the role mapping that you want to move higher in the list and click Move Up.



13 (Optional) Update the provisioning script to exclude AD objects from synchronizing.

See Excluding AD objects from synchronizing for more information.

Note The provisioning script is intended for advanced users who are familiar with editing server-side JavaScript code. However, if you need to map users from different domains, you can make a simple edit to accommodate these users. For details, see Synchronizing users with a different login suffix.

14 When you’re done, click Save to save the provisioning details.

You are now ready to synchronize users.

Deprovisioning users and other objects

The Centrify Directory Service deprovisions users and non-user objects based on deprovisioning rules that you define. You define a deprovisioning rule by selecting an event and mapping it to a deprovisioning action.

Deprovisioning events include the following. Disabling or deleting users in Active Directory

Deleting non-user objects in Active Directory

Changing a user’s role membership

Note To deprovision users by changing the user’s role membership, you must deselect Users from the Objects to provision grid. If Users is selected, the Centrify Identity Services will provision the user object at the next sync.

Deselecting the object type in the Objects to provision table

Deprovisioning actions are described in the following table.

Deprovisioning Action Behavior

Remove User Licenses Removes licenses from a user, but does not delete the user account from the application when you deprovision the user. Remove User Licenses is the default deprovisioning action.

You can restore licenses to the selected users (if the licenses are still available) by returning the user to the role, or adding the role mapping.

Select Remove User licenses if the user no longer requires a certain license, but you want to keep the user account in Office 365.

Delete Office 365 Account Deletes the user account and all associated data. The data associated with those user accounts is held for a period of time defined by Exchange Online’s Messaging records management (MRM) retention policies and tags, then permanently deleted. Refer to https://technet.microsoft.com/en-us/library/dd297955(v=exchg.150).aspx for more information about Exchange Online’s retention policy.

You can find deleted users that have not been permanently deleted in the Office 365 admin center under Users > Deleted Users.

Select Delete Office 365 Account only if you are completely sure you do not need the user account

• 94

https://technet.microsoft.com/en-us/library/dd297955(v=exchg.150).aspx

https://technet.microsoft.com/en-us/library/dd297955(v=exchg.150).aspx


Note To prevent conflicting rules, each deprovisioning event can only be mapped to a deprovisioning action once. For example, you can’t create the following two rules.

To add a deprovisioning rule

1 Click Add Rule under Deprovisioning Rules.

Leave User Unmodified Leaves the user account and associated licenses unchanged in the application.

Select Leave User Unmodified if you need to make changes in Active Directory without impacting Office 365 users. If you leave users unmodified but later decide that you want to delete the user accounts in the application, you have to manually delete them with Powershell scripts.

Delete Office 365 Object Account

Deletes the non-user object account in the application. Non-user objects are deleted immediately and are not recoverable.

Examples of non-user objects are contacts, groups, and resources. Select Delete Office 365 Object Account only if you are completely sure you do not need the object account.

Leave Object Unmodified Leaves the non-user object unchanged in the application.

Select Leave User Unmodified if you need to make changes in Active Directory without impacting Office 365 objects. If you leave non-user objects unmodified but later decide that you want to delete the objects in the application, you have to manually delete them with Powershell scripts.

Event Deprovisioning Action

User Disabled in Active Directory Delete Office 365 Account

User Disabled in Active Directory Remove User Licenses

Deprovisioning Action Behavior



2 Select a deprovisioning event from the Event drop-down menu.

3 Select an action from the Deprovisioning Action drop-down menu, then click Add.

4 Click Save when you are finished adding deprovisioning events.

The Centrify Identity Services syncs source directory information with the application either immediately or during the next incremental sync, depending on the event. See Provisioned account synchronization options for more information.

You can also manually start a synchronization job. See Synchronizing user accounts with provisioned applications for more information.

5 Verify your users were successfully provisioned by logging in to the Office 365 Admin Portal, expanding the Users tree, then clicking Active Users.

You can then select any provisioned user to view licensing information for that user.

Excluding AD objects from synchronizing

The provisioning script features a method that you can use to exclude AD objects from synchronizing. You can use this method to prevent objects from appearing in the Global Address List, or prevent a set of objects from appearing in Office 365.

To configure the provisioning script to exclude AD objects from synchronizing

1 In Admin Portal, go to the Apps page and open your Office 365 application.

2 On the Provisioning page, scroll to the Provisioning script section at the bottom, then click the downward arrow in the heading.

The Provisioning Script Editor appears.

• 96


3 Modify the provisioning script to exclude an object from synchronization by calling the reject statement. For example, if you want to exclude groups with SharePoint in the DisplayName, you could use the following script:if (isGroup()) {

trace("CommonName=" + destination.CommonName);

trace("DisplayName=" + destination.DisplayName);var displayName = String(destination.DisplayName).toLowerCase();

if (displayName.indexOf("sharepoint")>=0)

{ reject("We are not syncing SharePoint groups"); }}

Explanation

The section of the script shown in this example only executes when syncing AD groups.

The trace statements are a way to show some logging in the sync report or for troubleshooting purposes.

The script converts the DisplayName to lowercase since the method that determines if an object should be excluded does so by finding lowercase occurrences of sharepoint in the display name.

The reject statement causes O365 provisioning to exclude the group object from syncing. The reject statement takes a string to indicate a reason for the exclusion that appears in the sync report or logs. In this example, the string is We are not syncing SharePoint groups.

Note Excluding a group does not exclude the group’s members.

4 Click Save.

Modifying the provisioning script to link AD objects

You can use the provisioning script to link one AD object to another by creating a source anchor. For example, you might want to link a user’s Manager field to the manager’s user object. The Office 365 provisioning script supports the following methods to link AD objects.

The following example shows the usage of these two methods to create a source anchor.var adObject = getObjectByPath("CN=Manager,CN=Users,DC=mydomain,DC=com");

if (adObject != null) {

var objectGuid = test5["objectguid"][0];

Method Description

getObjectByPath Searches the source AD for an object at the specified LDAP path.

Arguments: ldap path (string)

Returns: Domain Services object

guidToBase64 Converts a guid (string) to a base64-encoded string

Arguments: guid (string)

Returns: string (base64-encoded byte array)



trace("adObject.objectguid " + objectGuid);

var sourceAnchor = guidToBase64(objectGuid);

trace(sourceAnchor);

destination.Manager = sourceAnchor;

trace("destination.Manager" + destination.Manager);

}

Explanation

The previous script performs the following tasks.

1 Passes the manager’s user object LDAP path to the getobjectByPath method, returning a Domain Services object (the manager’s user object).

2 Passes the manager’s user object’s objectGUID property to the guidToBase64 method, which encodes the GUID as a base64 byte array (required for Office 365).

3 Sets the Manager attribute in the destination to the base64 encoded GUID.

Synchronizing users with a different login suffix

If your Active Directory domain or your login suffix (for use with Centrify User Service) is not the same as your domain that you’ve verified in Office 365, then you need to modify the provisioning script to use your Active Directory domain (or login suffix) in the destination UPN (UserPrincipalName).

For example, if some users in the “Sales” role are in a domain called acmetester.com, then you’d need to modify the provisioning script to adjust for users with emails such as [email protected].

To modify the Office 365 provisioning script for users from a different domain

1 In Admin Portal, go to the Apps page and open your Office 365 application.

2 On the Provisioning page, scroll to the Provisioning script section, and click the downward arrow in the heading.

3 Find the following line in the Office 365 provisioning script:destination.UserPrincipalName = destination.UserPrincipalName.split("@")[0] +

"@" + "yourO365domain.com";

4 Modify the provisioning script to include the desired domain.

Using the example mentioned above, you would modify the line as follows:destination.UserPrincipalName = destination.UserPrincipalName.split("@")[0] +

"@" + "acmetester.com";

5 Click Save.

Best practices for synchronizing (migrating) users and mailboxes

If an Office 365 domain is federated with Centrify then Office 365 redirects the user to Centrify for authentication. The resulting token given back to Office 365 is required to have

• 98


both the UPN and an Immutable ID which must match with the corresponding UPN and Immutable ID saved in Office 365. This section discusses recommended best practices to ensure your users retain all of their data and can successfully authenticate through Centrify after migration.

Note This section is for advanced users who are comfortable administering Active Directory and Azure Active Directory using PowerShell cmdlets.

The following points are the basis for the recommended best practices. Refer to Terminology for migrating users and mailboxes for more information about the terms used below. The Immutable ID in the token must match the Immutable IDs in Office 365 for the

same UPN.

If the Immutable ID in the source (Active Directory or Centrify Directory) is different from the one set in Office 365 for the same UPN, Office 365 rejects the token.

Both AD and Centrify Directory users always have an Immutable ID.

Federated users in Office 365 must have an Immutable ID.

Microsoft does not support login if the Immutable ID is not set on a federated user in Office 365. This can happen if users were created in a managed domain, and the domain was later federated.

The Immutable ID can be changed only for a managed user.

The Immutable ID for a federated user is the base64-encoded value of the GUID of the source attribute.

For AD the default source attribute is objectGUID. For Centrify Directory, it's the internal ObjectId.

Once the Immutable ID is set on a federated user, it cannot be set again.

To set it, we'll have to convert the user to a managed user first.

Terminology for migrating users and mailboxes

The following table defines terminology and acronyms used in the discussion of synchronizing users and mailboxes between Active Directory and Office 365.

Term Definition

AD Active Directory

AAD Azure Active Directory. This is the directory service for Office 365. We’ll refer to it as Office 365 for convenience, except where discussing installation of the related PowerShell cmdlets.

Centrify Directory User Users created in the Admin Portal.

DC Domain Controller



Prerequisites for migrating users and mailboxes

Many migration procedures require the Azure AD PowerShell module. Refer to https://msdn.microsoft.com/en-us/library/azure/jj151815(v=azure.98).aspx for download links and more information about Azure AD PowerShell.

In addition, procedures requiring PowerShell cmdlets assume you have authenticated with the relevant directory (AD or Azure AD) so you can run the cmdlets.

Mailbox migration best practice

We recommend combining on-premise and online mailboxes in a hybrid environment if you plan to use both on-premise Exchange and Exchange Online.

It’s important to combine on-premise and online environments before syncing your users to Office 365 and assigning them Exchange Online licenses, otherwise your users will have a split mailboxes and might not receive mail. The only solution for split mailboxes is to delete one of the mailboxes, which might result in data loss.

An organization can combine both the on premise and online Exchange environment by running Exchange Hybrid Configuration wizard. In the Exchange hybrid case, the user will not have a split mailbox and Exchange will configure itself automatically. Refer to the following links for more information about Hybrid deployments and Microsoft’s Hybrid Configuration Wizard. https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx

https://technet.microsoft.com/en-us/library/hh529921(v=exchg.150).aspx

If you are only using Exchange Online and do not have an on-premise Exchange environment, refer to https://support.office.com/en-us/article/How-to-migrate-mailboxes-from-one-Office-365-tenant-to-another-65af7d77-3e79-44d4-9173-

Federated users Users synced into Office 365 from AD or Centrify Directory. Once an Immutable ID is set for a federated user, it cannot be set again.; we’ll have to convert the user to a managed user first.

Federated domain The Office 365 domain which is configured to redirect to an external identity provider for authentication.

Immutable ID An attribute for Office 365 users. The value is the base64-encoded value of objectGUID for AD and ObjectID for Centrify Directory users.

Managed users Users in Office 365 which are not synced from AD (created via UI or PowerShell) .

Managed domain The Office 365 domain which is not federated.

Office 365 User Users created in Office 365.

UPN UserPrincipalName.

Term Definition

• 100

https://msdn.microsoft.com/en-us/library/azure/jj151815(v=azure.98).aspx


https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx


https://support.office.com/en-us/article/How-to-migrate-mailboxes-from-one-Office-365-tenant-to-another-65af7d77-3e79-44d4-9173-04fd991358b7




https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx





04fd991358b7 for more information about migrating mailboxes from one Office 365 domain to another.

User migration scenarios

The following table illustrates the recommended solutions to migrating users for common scenarios.

Overwrite empty Immutable IDs in Office 365 by provisioning

If your matching UPN users in Office 365 do not have an Immutable ID and therefore can’t authenticate, you can use provisioning to overwrite the empty Immutable ID attribute with the Immutable ID from the source directory (either AD or Centrify Directory).

You do not have to worry about overwriting existing Immutable IDs; only empty Immutable IDs can be overwritten.

This approach to migrating users does not require scripting; however, the time required for a full sync is proportional to the number of users.

If this approach is not desirable, you can Manually set the Immutable ID in Office 365 as an alternative.

To overwrite the Immutable ID in Office 365 by provisioning

1 Enable and configure Office 365 provisioning.

No matching users in target Office 365

Matching users in target Office 365 with an Immutable ID

Matching users in target Office 365 without an Immutable ID

AD to Office 365 no conflict Save the Immutable ID from Office 365 in a different attribute in active directory

Overwrite empty Immutable IDs in Office 365 by provisioning

One Office 365 domain to another Office 365 domain

migrate mailboxes Save the Immutable ID from Office 365 in a different attribute in active directory, then migrate mailboxes.

Save the Immutable ID from Office 365 in a different attribute in active directory, then migrate mailboxes.

One AD domain to another AD domain

no conflict Save the Immutable ID from Office 365 in a different attribute in active directory

Save the Immutable ID from Office 365 in a different attribute in active directory

Centrify Directory User to AD to Office 365

Migrate Centrify Directory users to AD

Migrate Centrify Directory users to AD, then Save the Immutable ID from Office 365 in a different attribute in active directory

Migrate Centrify Directory users to AD, then Overwrite empty Immutable IDs in Office 365 by provisioning





2 In the Admin Portal, click Settings > Users > Outbound Provisioning.

3 Select Office 365 in the Provisioning Enabled Applications drop-down menu, then click Start Sync.


4 Select bypass caching and re-sync all objects, then click Yes.

5 Validate that one of the affected users is able to successfully login to Office 365 by clicking on the Office 365 app in the Centrify user portal.

Manually set the Immutable ID in Office 365

If you have a small number of matching users in Office 365 that need an Immutable ID attribute and you don’t want to touch provisioning settings or wait for a full provisioning

• 102


sync as described in Overwrite empty Immutable IDs in Office 365 by provisioning, you can manually set Immutable IDs for Office 365 users.

You have to do this one by one, so it can become time consuming.

To manually set the Immutable ID in Office 365

1 Get the Immutable ID for your source directory users (either AD or Centrify Directory).

AD users

a On a Domain Controller, or on a machine with Active Directory Powershell cmdlets installed, open PowerShell.

b Run the following command to see the immutable of a single user.Get-ADUser <name> | select UserPrincipalName,ObjectGuid, @{e={[system.convert]::ToBase64String($_.ObjectGuid.ToByteArray())};l="ImmutableId" }

Centrify Directory users

a Contact Centrify support and request the ObjectID value for the users you want to migrate.

b Convert the ObjectID (which is the user’s GUID) into an Immutable ID using the following PowerShell example.

$guid = [GUID]"ba2f9dce-2a8d-44ef-8c88-ae8d98393431";

$base64 = [system.convert]::ToBase64String($guid.ToByteArray());

2 Use the following cmdlet to set the Immutable ID of the target user in Office 365. Set-MsolUser -UserPrincipalName <upn> -ImmutableId <immutableId>

Note Note that you can only set the Immutable ID once in a federated domain (and only if it was empty).

Save the Immutable ID from Office 365 in a different attribute in active directory

If you have Office 365 users that match the UPN of users in your source directory, but have different Immutable IDs set, those users will not be able to authenticate. You can work around this by saving the Immutable ID from Office 365 in a different AD attribute and later using the Admin Portal provisioning script to replace the AD user’s Immutable ID with the Office 365 Immutable ID saved in a different attribute.

This solution reduces migration downtime and is easily reversible; however, it can be time consuming.

If updating AD users is not desirable. Change the Immutable ID in Office 365.

If you don’t want to update AD or Office 365 users, you can Delete the Office 365 users.

To save the Immutable ID from Office 365 in a different attribute in AD

1 In Active Directory, choose an attribute on the User object of type string where the Immutable ID from the Office 365 user will be saved.



We recommend using the extensionAttribute1 attribute; however, any attribute of type string can be used.

If the attribute extensionAttribute1 doesn't exist or there are no appropriate attributes on the User object in AD, then create a new single-valued attribute of type string.

Do not name the attribute extensionAttribute* as these names are used by the Exchange server.

Refer to http://social.technet.microsoft.com/wiki/contents/articles/20319.how-to-create-a-custom-attribute-in-active-directory.aspx for instructions on creating attributes.

2 Find the Immutable ID(s) of your Office 365 user(s).

The following command saves the UserPrincipalName and ImmutableId attributes of all Office 365 users in a csv file.Get-MsolUser -All | Sort UserPrincipalName | Select UserPrincipalName,

ImmutableId | Export-Csv "O365Users.csv" -NoTypeInformation

The following command gets the UserPrincipalName and ImmutableId attributes of a single Office 365 user.Get-MsolUser -UserPrincipalName <upn> | Select UserPrincipalName, ImmutableId

3 (Optional) Remove from the CSV file any users that do not need their Office 365 Immutable ID saved in AD.

4 Find the users in AD that match the UserPrincipalName values from Office 365 and update the desired attribute with the Immutable ID from Office 365.

For many Office 365 users

On the Domain Controller or a machine with the PowerShell Active Directory module installed, run the following script (copy/paste, then press Enter twice) to read the CSV file with the Office 365 users and update the attribute you specified (we recommend extensionAttribute1) on the user objects in AD.

Tip Update the attrName variable below with the correct attribute name if it is not extensionAttribute1.$attrName = "extensionAttribute1";

Import-Csv .\O365Users.csv | %{

$upn = $_.UserPrincipalName;

$id = $_.ImmutableId;

$users = Get-ADUser -Filter {UserPrincipalName -eq $upn};

if($users.Length -eq 0) {

Write-Host "No users were found in AD with the UPN: $upn";

}

• 104

http://social.technet.microsoft.com/wiki/contents/articles/20319.how-to-create-a-custom-attribute-in-active-directory.aspx





elseif($users.Length -gt 1) {

Write-Host "More than one user is found in AD with the UPN: $upn";

$users | Select DistinguishedName;

}

else {

Set-ADUser $users.ObjectGuid -Replace @{$attrName=$id};

Write-Host "$attrName= '$id' UPN= $upn";

}

}

Tip Review the output of the previous step to verify no errors were reported.

For a single Office 365 user

On the Domain Controller or a machine with the PowerShell Active Directory module installed, run the following command.Set-ADUser <username> -Replace @{extensionAttribute1=<immutableid>}

5 Verify that the Immutable IDs in AD match the ones from Office 365.

For many Office 365 users

The following PowerShell script saves the UserPrincipalName and extensionAttribute1 (or specified attribute) attributes of all the users from AD in a CSV file. Compare the two CSV files for verification.

Tip Modify the following script if the attribute in use is not extensionAttribute1Get-ADUser -Filter * -Properties extensionAttribute1 | Sort UserPrincipalName |

Select UserPrincipalName, ExtensionAttribute1 | Export-Csv "ADUsers.txt" -

NoTypeInformation

For a single Office 365 user

On the Domain Controller or a machine with the PowerShell Active Directory module installed, run the following command.Get-ADUser <username> -Properties extensionAttribute1

6 Contact Centrify support to enable the following tenant level configuration flags.

Flag Name: Office365V2.GetImmutableIdViaProvScript

Flag Value: true

Note Both the flag name and value are case sensitive and must be set exactly the way they are typed.

7 In the Admin Portal, modify the provisioning script in the Office 365 app to replace the AD user Immutable ID with the modified attribute.

The following example of the provisioning script reads the immutable id from the attribute extensionAttribute1, if it is set. Ensure that the snippet is added to the isPerson() block.



if (isPerson()) {

var iGUID = getSourcePropertyByName("extensionAttribute1");

if (iGUID && iGUID.Length && iGUID[0]) {

destination.SourceAnchor = iGUID[0];

trace("Updating the target with new immutable id: " + iGUID[0]);

}

}

8 In the Admin Portal, click Settings > Users > Outbound Provisioning.

9 Select Office 365 in the Provisioning Enabled Applications drop-down menu, then click Start Sync.

• 106



10 Select bypass caching and re-sync all objects, then click Yes.

11 Validate that one of the affected users is able to successfully login to Office 365 by clicking on the Office 365 app in the Centrify user portal.

Change the Immutable ID in Office 365

If you have Office 365 users that match the UPN of users in your source directory, but have different Immutable IDs set, those users will not be able to authenticate. You can change the Immutable ID in Office 365 to resolve the situation.

Changing Immutable IDs in Office 365 offers the following advantages: allows for a clean migration

easier to manage after migration

does not require a full provisioning sync

Changing Immutable IDs in Office 365 has the following disadvantages: tedious due to need to change the Immutable IDs for each user one at a time

requires a long maintenance window for Office 365 to update its federation status

hard to revert

To change the Immutable ID in Office 365

1 Confirm that all existing Office 365 users are synced by Centrify.

You can do this by using PowerShell cmdlets to get the Office 365 domain status.get-msoldomainfederationsettings -domain <domain-name>



The FederationBrandName attribute value should include Centrify, similar to the following image.

2 Unfederate the Office 365 domain.

Refer to Unfederating your Office 365 domain in Admin Portal for more information.

It might take up to 72 hours for Office 365 to update its status from Federated to Managed. You can use the following PowerShell cmdlet to check the domain status.Get-MsolDomain -DomainName <domain-name> | FL

Whether the domain is Managed or Federated is indicated in the value of the Authentication attribute.

3 Modify the affected user UPN domain suffixes in Office 365 and change it to an unfederated domain.

The following PowerShell cmdlets change the UPN for all the users in Office 365.Get-MsolUser -All | Set-MsolUserPrincipalName -NewUserPrincipalName

[email protected].

• 108


4 Get the ObjectGUID value for your AD users and convert it to Immutable IDs by running the following PowerShell script from the DC.

This script gets the UserPrincipalName and ObjectGUID, converts the ObjectGUIDs to Immutable IDs, then saves these values in a CSV file named ADUsers.txt located in the current directory.Get-ADUser -Filter * | select UserPrincipalName,ObjectGuid,

@{e={[system.convert]::ToBase64String($_.ObjectGuid.ToByteArray())};l="Immutab

leId" } | Export-Csv "ADUsers.txt"

5 Set the Immutable ID of the corresponding users in Office 365 with the ones from AD using the following PowerShell script in the PowerShell Azure AD module.

This script reads the ADUsers.txt CSV file and updates the corresponding users in Office 365 with the new Immutable ID.Import-Csv "ADUsers.txt" | %{

$upn = $_.UserPrincipalName;

$id = $_.ImmutableId;

$user = Get-MsolUser -UserPrincipalName $upn;

if($users.Length -eq 0) {

Write-Host "No users were found in O365 with the UPN: $upn";

}

else {

Set-MsolUser -UserPrincipalName $upn -ImmutableId $id;

Write-Host "ImmutableId = '$id' UPN= $upn";

}

}

Tip Review the output of the previous script thoroughly to ensure all Office 365 were found and updated correctly.

6 Change the UPN domain suffix for the affected users back to the federated domain with the following command.

The following PowerShell cmdlets change the UPN for all the users in Office 365.Get-MsolUser -All | Set-MsolUserPrincipalName -NewUserPrincipalName

[email protected]

7 In the Admin Portal, federate the domain.

a Select Apps > Office 365 > Application Settings, then select your target domain under Office 365 Domains.

b Click Actions > Federate Domain.

8 Validate that one of the affected user is able to successfully login to Office 365 by clicking on the Office 365 app in the Centrify user portal.

Delete the Office 365 users



If you have a split mailbox situation (happens when you have licenses for Exchange and Exchange Online and you sync users before configuring a hybrid environment), you will have to delete the Office 365 to be able to migrate users.

Deleting Office 365 eliminates issues with Immutable IDs and avoids making provisioning changes; however, user data might be lost.

To delete Office 365 users

1 Backup Office 365 user data.

Refer to https://technet.microsoft.com/en-us/library/dn440734(v=exchg.150).aspx for more information about backing up Office 365 user data.

2 Delete the users from Office 365 and then from the Office 365 recycle bin using the following AAD PowerShell cmdlets.Remove-MsolUser -UserPrincipalName <upn> -Force

Remove-MsolUser -UserPrincipalName <upn> -Force -RemoveFromRecycleBin

3 Use the following two cmdlets to confirm that the users are deleted.

These cmdlets should not return any users.Get-MsolUser -UserPrincipalName <upn>

Get-MsolUser -UserPrincipalName <upn> -ReturnDeletedUsers

Migrate Centrify Directory users to AD

If you have Centrify Directory users that have already been migrated to Office 365, you might want to also have those users in AD while keeping their Office 365 data. You will have to manually recreate the Centrify Directory users in AD, then resolve Immutable ID conflicts when you sync the new AD users to Office 365.

Note You will only have Immutable ID conflicts if you have already synced Centrify Directory users to Office 365.

To migrate Centrify Directory users to AD

1 Contact Centrify support for a list of Centrify Directory users’ UPNs.

2 Create the users in AD using the same UPN.

3 On the Office 365 provisioning page in Admin Portal, create a deprovisioning rule where the event User Deleted in Active Directory results in the action Leave User Unmodified.

Refer to To add a deprovisioning rule for more information.

Note Deprovisioning events apply to Centrify Directory in addition to Active Directory.

4 Delete the Centrify Directory user.

You now have AD users and Office 365 users with matching UPNs, but conflicting Immutable IDs.

• 110

https://technet.microsoft.com/en-us/library/dn440734(v=exchg.150).aspx

https://technet.microsoft.com/en-us/library/dn440734(v=exchg.150).aspx


Note The deprovisioning rule to leave users deleted in the source directory unmodified in Office 365 prevents the user from being deleted in Office 365.

5 Refer to User migration scenarios for recommended solutions to the conflicting Immutable IDs.

6 When you are finished, remove the deprovisioning rule to leave users unmodified in Office 365 when the user is deleted from the source directory.

Quick Reference for user migration tasks

The following tasks are frequently used to resolve conflicts with Immutable IDs that prevent successful user migrations. These tasks rely on PowerShell modules for the appropriate directory (AD or AAD) and assume you have already authenticated with that directory.

How to: convert a GUID into Immutable ID $guid = [GUID]“ba2f9dce-2a8d-44ef-8c88-ae8d98393431";$base64 = [system.convert]::ToBase64String($guid.ToByteArray());

How to: convert Immutable ID into a GUID $b = [system.convert]::FromBase64String("uMjntePRV0qghxfRy+/PvA==");new-object -TypeName System.Guid -ArgumentList(,$b);

How to: get Office 365 domain status (federated vs. unfederated) Get-MsolDomain -DomainName <domain-name> | FL

How to: get the Immutable ID of an AAD user

For a single userGet-MsolUser -UserPrincipalName <upn> | select UserPrincipalName,ImmutableId

For all usersGet-MsolUser -All | select UserPrincipalName,ImmutableId

For all users with the corresponding GUIDGet-MsolUser -All | select UserPrincipalName,ImmutableId, @{e={new-object -TypeName System.Guid -ArgumentList(,([system.convert]::FromBase64String($_.ImmutableId)))};l="ObjectGuid" }

How to: get the Immutable ID of an AD user

For a single userGet-ADUser <name> | select UserPrincipalName,ObjectGuid, @{e={[system.convert]::ToBase64String($_.ObjectGuid.ToByteArray())};l="ImmutableId" }

For all usersGet-ADUser -Filter * | select UserPrincipalName,ObjectGuid, @{e={[system.convert]::ToBase64String($_.ObjectGuid.ToByteArray())};l="ImmutableId" }

How to: migrate mailboxes from one Office 365 domain to another Office 365 domain


Reverting your Office 365 account back to ADFS

Refer to https://support.office.com/en-us/article/How-to-migrate-mailboxes-from-one-Office-365-tenant-to-another-65af7d77-3e79-44d4-9173-04fd991358b7 for more information on how to migrate mailboxes.

Reverting your Office 365 account back to ADFSIf you previously used ADFS with Office 365 before you converted to Centrify for Office 365, the information in this section applies to you if you need to revert back to using ADFS. The procedure below includes removing the Office 365 application, and by removing the application it automatically converts your Office 365 account from federated to managed state. Then, you run some PowerShell commands to convert the account back to federated state using ADFS.

After the account reverts to managed state, here’s how to handle passwords for user accounts: If users had Office 365 passwords before you migrated to the directory service, your

users can continue to use their Office 365 passwords after you revert the account back to managed state.

If you used Centrify for Office 365 from the beginning, before users set or entered a password, then you need to reset passwords for your users. You can reset them manually in Office 365, or you can use DirSync to synchronize the passwords in Office 365 to match the passwords set in Active Directory. For details on setting up password synchronization, see http://community.office365.com/en-us/forums/613/t/195782.aspx.

To revert your Office 365 account back to ADFS:

1 On the computer where your ADFS service is installed, open Windows Azure Active Directory Module for Windows PowerShell.

2 In the PowerShell window, run the following command:Connect-MsolService

3 In the dialog box that opens, enter your Office 365 administrator user name and password and click OK.

4 Run the following two commands:get-msolFederationProperty -domain <domainname>

get-msolDomainFederationSettings -domain <domainname>

where <domainname> is your domain, such as acme.com. You run more PowerShell scripts in later steps, so keep it open if that’s easier for you.

5 Save the outputs of these commands for reference.

• 112

http://community.office365.com/en-us/forums/613/t/195782.aspx








Reverting your Office 365 account back to Managed mode

6 In the Apps page in Admin Portal, select your Office 365 application and click Delete in the pop-up menu.

7 In the confirmation dialog box, click Yes to continue.

The directory service removes the application from the list of applications in Admin Portal and the user portal and unfederates your Office 365 domain. Your Office 365 domain now is in Managed mode.

8 In the PowerShell window, run the following command to verify the domain status:get-msoldomain -domain <domainname>

If the Authentication status displays as Managed, the operation was successful.

9 In the PowerShell window, run the following command to convert the domain to Federated. convert-msoldomaintofederated -domainname <domainname> -supportmultipledomain

10 In the PowerShell window, run the following command to verify the domain status:get-msoldomain -domain <domainname>

If the Authentication status displays as Federated, the operation was successful.

Note If you were previously using another identity provider, stop here and refer to their documentation for further details.

11 In the PowerShell window, run the following command to verify that the ADFS settings are the same as when you first configured Office 365:Update-MsolFederatedDomain -DomainName <domainname>

Wait about 30 minutes to an hour for the settings to take effect across all Office 365 servers.

Reverting your Office 365 account back to Managed modeIf you need to revert your Office 365 account back to Managed mode, this section applies to you.

Note Managed mode refers to how you can set up Office 365 so that it authenticates your users based on their Office 365 user name and password.

Reverting your Office 365 account back to Managed mode involves simply removing the application from Admin Portal. Afterwards, you can use the Microsoft Directory Synchronization Tool to synchronize user passwords, if desired.

If your users had separate Office 365 passwords before you converted to Centrify for Office 365, your users can continue to use those passwords after you revert your account back to Managed mode.


Unfederating your Office 365 domain in Admin Portal

To revert your Office 365 account back to Managed mode:

1 In the Apps page, select your Office 365 application and click Delete in the pop-up menu.

2 In the confirmation dialog box, click Yes to continue.

The directory service removes the application from the list of applications in Admin Portal and the user portal and unfederates your Office 365 domain. Your Office 365 domain now is in Managed mode.

3 Wait about 30 minutes to an hour for the settings to take effect across all Office 365 servers.

If your users had their own Office 365 passwords before you had converted the account to Centrify for Office 365, your users can now log in using their old password and you’re done.

However, if you had migrated your account to Centrify for Office 365 without having users set or enter their passwords, then you need to go reset the passwords for your users. You can do so manually or use the Microsoft Directory Synchronization tool to synchronize passwords from Active Directory.

Note For details on setting up password synchronization, see http://community.office365.com/en-us/forums/613/t/195782.aspx.

Unfederating your Office 365 domain in Admin PortalIf you need to unfederate your Office 365 domain and return it to managed state for any reason, you can do so quickly and easily in Admin Portal.

After you unfederate your Office 365 domain, your users need to log in to Office 365 using their Office 365 credentials. If the domain is in managed state, Centrify Directory Service no longer provides authentication or provisioning for Office 365.

To unfederate your Office 365 domain:

1 In Admin Portal, open your Office 365 application.

2 On the Application Settings tab, scroll down to the Domains section.

3 Select the federated domains that you need to unfederate.

4 In the pop-up menu, click Unfederate Domain.

A warning message displays that prompts you for confirmation.

5 Click Yes to continue.

A message displays that the directory service has sent the unfederation request to Office 365.

• 114



Unfederating your Office 365 domain in Admin Portal

6 Click OK to close the notification message.

The directory service releases ownership and unfederates the specified Office 365 domain.


For more information about Office 365

For more information about Office 365For more information about configuring Office 365 for SSO, see the following Microsoft help pages. Preparing for single sign-on

http://onlinehelp.microsoft.com/en-us/Office 365-enterprises/ff652540.aspx

Verifying and managing single sign-on


Locating your domain registrar or buying a domain


Domain names and Office 365


Synchronizing Active Directory


• 116

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652540.aspx










office 365 for centrify identity services · office 365 for centrify identity services ... how the...

Documents