Overview
Practice Protect delivers team members a single set of login credentials (SSO) across cloud apps, online portals, client apps and email/file systems. We refer to the process of integrating SSO into email and files systems as Email Integration.
From a technical standpoint there are several deployment types on enabling this security integration depending on your firm’s current tech stack configuration. The following guide provides an overview of our standard deployment options for mail integration, and which will suit your firm.
We will identify the relevant deployment type ahead of, or early in the onboarding process. It can also be the technical personnel in the firm to select the best option.
For current deployments that would like to migrate to a difference directory source, please contact our support team to scope a migration with the project team. support@practiceprotect.com
Cloud & SMB Firm Deployment Types (two options)
1. Practice Protect as Source Identity (Office 365 or Google Workspace)
This deployment suits full cloud firms using Microsoft 365 or Google Workspace (G-Suite) that don’t currently have Multi Factor Authentication or conditional access security over their mail system. Typically adopted by firms with 15 or less team members that manage user setups internally.
In this Identity Architecture, Practice Protect is the Source Identity of the User accounts meaning users are managed from within Practice Protect and User Account Changes/Modifications are synchronised to Office 365 from Practice Protect.
Pros:
- Policies Set in Practice Protect Govern all Cloud App Logins and Email Authentication
- Email Authentication Policy Protection (WS-Federation)
- Central Identity Management & User Provisioning
- Azure AD Joined Computers should use their Practice Protect Account for Sign-In
Cons:
- No Local Active Directory – Users will have a separate login account to their computers.
- Managed Services Providers are required to modify users inside Practice Protect (not via Azure AD or Google Workspace)
More Information: Setup Office 365 Federation & Provisioning
2. Office 365/Google Workspace/Azure AD as Source Identity
This deployment suits firms that already have Conditional Access Polices in place and Email Authentication is already restricted by Multi Factor Authentication. Typically adopted by firms with 15 or more team members that work closely with a proactive outsourced managed services provider for user setups.
In this Identity Architecture, Azure AD/Office 365 is the source of Identity of Users. The Azure AD accounts are used to authenticate into Practice Protect and is managed by the firm’s Office 365/Azure AD Administrator from the 365/Azure AD console.
Pros:
- Same Username/Password across Computer/Practice Protect/Office 365 (If Computer is Azure AD joined)
- Decommissioning of Local Active Directory doesn’t require a Re-onboarding of User in Practice Protect. (Source of Identity would move to Azure AD directory).
Cons:
- Email Integration is not possible (Conditional Access Require for email login Control)
- Practice Protect Support cannot assist with User Account Changes/Modifications.
More Information: Add Azure Active Directory as a Directory Source
Other Identity Deployment Options
In Cloud Only
Preferred deployment types for non-firmwide rollouts of Practice Protect such as offshore team member only or for firms with non-business grade email systems. This deployment does not provide Single Sign On between email, files and cloud apps meaning a lower level of security therefore is not typically recommended.
In this Identity Architecture, Practice Protect is the Source Identity of the User accounts and is not connected to Office 365/Azure AD, Google Workspace, or any other directory systems for Email Integration. Only Web Apps stored in the Practice Protect portal will be governed by Practice Protect Polices
Source/Account Control: Practice Protect – User Account Changes/Modifications local to Practice Protect
Medium and Large Firm Deployment Methods (less common)
4. Practice Protect Connector + Azure AD Connect + Email Integration (typically only for firms with 25+ users)
In this Identity Architecture, local Active Directory is the source of Identity of Users. The Identify of the users is replicated from local Active Directory to both Practice Protect and Azure AD/Office 365. All user account changes are made in local Active Directory by the Administrator.
Best suited for Firms that plan to stay on local Active Directory and have Local Active Directory already syncing to Azure AD/Office 365.
Not suitable to Companies looking to move to the Cloud in the near term.
Source/Account Control: local Active Directory
- User Account Changes/Modifications managed by Active Directory Administrator
Pros:
- Same Username/Password across Computer/Practice Protect/Office 365
- Easier Onboarding of User Accounts
- Email Integration is very straight forward as GUID/SID of Account is already synced between all systems.
- AD Joined Computers can use Practice Protect MFA
Cons:
- Requires re-onboarding of Users in the Event of Active Directory decommissioning
- Requires a Domain Controller online to access Practice Protect/Office 365
- Advise to run connector on two Domain Controllers hosted at different locations
More Information: Configure Practice Protect Active Directory connector
5. Azure AD Connect + Azure AD Source Directory (typically only for firms with 25+ users)
In this Identity Architecture, local Active Directory is the source of Identity of Users. The identity of the users is replicated from local Active Directory to Azure AD. The Azure AD accounts are used to authenticate into Practice Protect.
Best suited for firms that sync local Active Directory to Office 365 and already have Conditional Access Polices in place.
Source/Account Control: Local Active Directory
- User Account Changes/Modifications managed by Active Directory Administrator
Pros:
- Same Username/Password across Computer/Practice Protect/Office 365
- Easier onboarding of User Accounts
- Email Integration is very straight forward as GUID/SID of Account is already synced between all systems.
- Decommissioning of local Active Directory does not require re-onboarding of User in Practice Protect. (Source of Identity would move to Azure AD directory).
Cons:
- Email Integration is not Possible (Conditional Access Require for email login control)
- Practice Protect support cannot assist with User Account changes/modifications.
More Information: Add Azure Active Directory as a Directory Source
6. Practice Protect Connector + Email Integration + Provisioning (typically only for firms with 25+ users)
In this Identity Architecture, local Active Directory is the source of Identity of Users accounts. The Identity of the users is replicated from local Active Directory to Practice Protect and then to Azure AD/Office 365.
Best suited for companies that are already syncing Local Active Directory to Office 365 and plan to stay on local Active Directory for the foreseeable future. Not suitable for companies looking to move to the Cloud and migrate away from local Active Directory.
Source/Account Control: Local Active Directory
- User Account changes/modifications managed by Active Directory Administrator
Pros:
- Requires only Practice Protect Connector to be installed in local Active Directory in order to sync accounts to Office 365.
- Same Username/Password across Computer/Practice Protect/Office 365
- User Accounts pre-populate in Practice Protect from Active Directory
- Email Integration is very straight forward as GUID/SID of Account is already synced between all systems.
- AD Joined Computers can use Practice Protect MFA
Cons:
- Requires re-onboarding of Users in the event of Active Directory decommissioning.
- Requires a Domain Controller online to access Practice Protect/Office 365
- Advise to run connector on two Domain Controllers hosted at different locations
More Information: Configure Practice Protect Active Directory connector