When installing against an Identity Panel SaaS environment, much of the installation effort is prep-work and gathering of prerequisites.
NOTE: Items marked with * have dependencies on licensing and support purchasing decisions.
1. Choose deployment Instance
Based on data homing requirements, version availability, etc. choose which instance of Identity Panel you will deploy on. Instances are defined based on geographical location (e.g. EU, UK, USA...) and version (identified by name, e.g. Eagle-US, Falcon-US).
2. Choose Production URLs
Most SaaS deployments use custom URLs for production and standard URLs for non-prod. Production URLs will be chosen for each purchased product: Identity Panel, Service Panel, Access Panel. There are two options when choosing URLs:
- Names controlled by SoftwareIDM. For example:
- Names controlled by you. For example:
- Names controlled by SoftwareIDM. For example:
If you choose a name that you control you will need to create CNAME records pointed at the designated Azure Frontdoor service URL corresponding to your instance, and a _dnsauth TXT record for issuing an SSL certificate.
3. Create Security Roles
To prepare for installing Identity Panel create two security groups in Azure Active directory corresponding to the Admin and User roles respectively in Identity Panel. Populate the Admin group with the intended identity admin team members.
These groups must be security groups or mail enabled security groups. O365 groups are not supported.
Additional groups may be created if other roles are planned, based on deployment requirements (e.g. Report Readers, Schedule Managers, Service Desk).
4. Plan Email Settings
Email and Notification workflows are executed on-premises via Panel Service. Choose whether a local SMTP server will be used for email, or the Azure Graph API (Recommend). If SMS messages are planned obtain a Twilio subscription and API key.
- If using SMTP determine server and port names, planned FROM address, authentication credentials if needed, and whether security updates are required from the messaging team (e.g. to send messages with attachments)
- If using Azure Graph API create an Azure App Registration (See below for more information)
- Create or choose a mailbox for Identity Panel notifications.
- If using Graph API for Service Panel and/or Access Panel notifications it may be desirable to configure multiple mailboxes to reduce contention for a rate-limited resource.
- Graph API allows 30 messages per minute per mailbox.
Panel Check will send out alerts if there are any issues with Panel Service on the server. To get these alerts, create or choose an existing distribution group which users who require these alerts can be added to.
5. Azure Application Registration
As part of the installation, Identity Panel will connect to Azure. This requires an Azure Application to be registered. This allows Identity Panel to read users and groups in Azure, and support auto-complete on the forms.
This same application can be used for the Azure Graph Provider and sending email notifications.
- Log in to portal.azure.com.
- If required, activate Application Administrator role or Cloud Application Administrator role (You can also use the Global Administrator role).
- Go to Application Registration and click New Registration.
- We recommend the following name, but you can use your own naming standards:
- "Identity Panel Graph Access"
- Once the application is created, you can add the following roles:
- Group.Read.All or Group.ReadWrite.All if you are updating groups
- GroupMember.Read.All or GroupMember.ReadWrite.All if you are updating group membership
- User.Read.All or User.ReadWrite.All if you are updating users
- Mail.Send if you are using the Graph API to send notifications
- Click Admin Consent to apply the permissions.
- Create a Password vault to store Application ID and Tenant ID.
- Create a secret, using your standards, and add secret to Password Vault for use during installation.
- Ensure you have a process in place to remind you when the secret is due to expire, so it can be replaced under change without causing a loss of service.
6. Design Panel Services
The number and scale of Panel Service instances required depends on number and type of providers and requirements for high availability. A common deployment scenario is to install Panel Service on each MIM server, and on two additional dedicated Panel Service servers.
- All Panel Service instances must have outbound access to the selected Identity Panel instance.
- Create service accounts for Panel Service. Decide whether a shared service account will be used, or separate accounts per server (recommended).
- Grant permissions to Panel Service account to perform planned data collection and provider operations (e.g. MIMSynchronizationService / db_datareader, and MIMSyncAdmins rights for MIM scanning, AD rights for directory provider, etc.).
- Log on as batch is required for the Panel Service account, if this is managed by GPO, please assign the correct policy to the service accounts.
Performing the installations will require local admin privileges on the servers, as well as admin privileges in Identity Panel
See Panel Service section of Identity Panel Prerequisites for server sizing information
7. Plan Provider Settings
Depending on providers, additional service accounts and permissions may be required.
- MIM Provider: MIMSyncAdmins, db_datareader on MIM databases.
- Directory Provider (read only): regular user account in each AD forest to be scanned.
- Directory Provider (read/write, e.g. for Service Panel): elevated account in each AD forest to receive writeback.
- Graph/Entra Provider (read only): App registration with Directory.Read.All and Reports.Read permissions.
- Graph/Entra Provider (read/write): App registration with desired write permissions, Service Principal with roles in Entra.
- SQL Provider (read only): db_datareader for desired databases.
- SQL Provider (write): db_datawriter and/or db_owner for desired databases.
- ServiceNow: Service account with permissions and listing of desired TableAPI scans and writeback operations.
8. Data Retention
There are four data retention policies within Identity Panel, and these are worth considering during the deployment of Identity Panel. These values can be changed after installation. By default, all objects are kept Indefinitely in the database. The four data retention policies are:
- Deleted Object - How long an object is kept after it has been deleted in the silo.
- Run History - How long the run history is kept in the database.
- Request History - How long requests are kept in the database.
9. Plan Branding Settings
If deploying Service Panel and/or Access Panel obtain corporate branding guide and file assets including hex values for corporate colors, and logo and favicon files in .gif, .jpg, .svg, or .png formats
The installation should be coordinated in advance with SoftwareIDM as support is required to bind custom URLs.
Initial app registration of the installation must be performed by an Azure Global Admin