Directory requirements
Please note the following considerations:
Each 1E user requires an account in Azure Active Directory. Azure Active Directory accounts must have their userPrincipalName (UPN) attribute populated, which is normal but may be missing if user accounts have been created using scripts.
1E users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-Factor Authentication (2FA) is enabled.
Azure Active Directory groups are recommended for role-based access control (RBAC) but are not mandatory. Azure Active Directory groups can be assigned to 1E roles after installation, they are not required during installation. Groups are not mandatory because users can be assigned to roles and managed within 1E instead of Azure Active Directory.
1E Setup assigns a limited set of permissions to the Setup user account (specified during installation/updates), as described on the Roles page which cannot be edited. It is possible to increase this user account to have Full Administrator access during installation/upgrade, 1E recommends that this user account is viewed as a service account and kept with the minimum permission.
An Azure Active Directory group is useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog .
Identity Provider requirements
Prerequisites
To follow this guide you will need the following:
A tenant in one of the following IdP:
Azure Active Directory (AAD)
Okta
Note
1E is only supported on the Workforce Identity version. The Customer Identity version - which is Auth0 under the hood - is not supported.
To create new App Registrations and assign and grant permissions in your IdP. This can be done as a Global Administrator in AAD or a Company Administrator in Okta.
An IdP account that will be set as the Principal 1E user (the first user of the 1E platform, assigned the Full Administrator role, and a System principal - which means that they cannot be deleted or modified). You should create this user specifically for this purpose, treat it like a service account, and disable it after first use.
A user who can log on using the principal user account will need to be available at a certain stage of the upgrade or new instance provisioning to test the 1E instance.
For new 1E instances, you will need to request from your certificate administrator:
A Base-64 encoded certificate (.PEM) file which contains the whole chain of trust including the Root CA(s) and any intermediate CA(s) that provide certificates to the clients you want to manage.
The provided PEM has Certificate Revocation List Distribution Point(s) referenced
The Certificate Revocation List Distribution Point(s) are reachable from the Internet.
For both new instances and upgrades from non-IdP versions of the platform, you will be configuring:
3 new App Registrations in your IdP.
You will then need to provide to 1E:
The application IDs for the new applications you will create
The OpenID Connect (OIDC) metadata document for your IdP
Your Tenant ID
The name of the IdP account that will be used as the Principal 1E user
The name for your new instance (upgrades will keep the previous name).
Note
Due to restrictions in Azure, the name for your new instance cannot start with a number. The actual pattern definition used for names is:
^[a-z][a-z0-9-]{1,58}[a-z0-9]$
Post-provisioning 1E will provide you with a URL that contains the DNS name for your 1E portal. You will need to whitelist this portal so that it is accessible from your network.
Server installation account
This is the account used to run 1E Setup (and the MSI installer) when installing or upgrading a 1E Server. The account is automatically defined as a 1E admin user with limited rights which cannot be edited (called a system principal).
Local admin rights
The server installation account has the following requirements on the server.
Local admin rights on the 1E Server. It must be an Azure Active Directory domain user account that is a direct or indirect member of the Administrators local group on the server where 1E Server will be installed.
Can be disabled (not deleted) in Azure Active Directory after additional admin users have been created in 1E, and installation has been verified.
1E user permissions
The installation account only has sufficient rights to add other 1E users, assign them to 1E roles, and install 1E applications. The users and roles created by the installation account are then used for ongoing use and management of 1E.
If you need the installation account to have additional roles or be a Full Administrator, then the recommended approach is:
First create a role-based AD Security group, and add the installation and other accounts to this group
Then, the installation account:
Logs into 1E and navigates to Settings → Permissions → Users and Groups
Creates a new 1E user for the role-based AD Security Group
Assigns the relevant system role(s) to the new 1E user - this can be Full Administrator.
Tip
You can disable the installation account in AD after the system is operational and other 1E users have been set up. You can then re-enable it whenever required for ongoing configuration changes and upgrades.
Note
Do not delete the server installation account from 1E after installation.
The server installation account is granted the following permissions as a 1E user, configured during installation of the 1E Server.
It is the first 1E user account and is a System Principal, which means it cannot be deleted or assigned any other rights
It is assigned to the 1E system role of Installer
It should be used to add additional 1E users and administrators, assign them to 1E roles, which should then be used for ongoing use and management of 1E.
It may be included in any AD security group assigned to a 1E system or custom role.
Refer to Roles and Securables for a complete reference of 1E system roles, custom roles, securables and operations.
SQL Logins for the server installation account
The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions required by the installation account depends on which 1E components it is installing.
Master Stacks
For master stacks sysadmin is required as follows, to:
Install 1E Catalog
Create Linked Servers for SLA, which requires sysadmin for the SQL database instances for both SLA and 1E Catalog databases
Create Linked Servers for BI, which requires sysadmin for the SQL database instances for both SLA and BI databases, and the SSAS instance for the BI cube (required only by Patch Success).
Response Stacks
Sysadmin availability on SQL instance(s) | SQL Login permissions | ||||||
|---|---|---|---|---|---|---|---|
sysadmin SQL Server role is permitted | The server installation account requires the sysadmin SQL Server role on the SQL Server instance(s) that host the TachyonMaster and/or TachyonResponses database(s). This can be used for a new installation, or for an upgrade. | ||||||
sysadmin SQL Server role is not permitted | The SQL Login permissions required by the server installation account vary depending on which choice is implemented, as described in the following table:
NoteIn addition to the permissions given in the table above, the server installation account also needs to ALTER ANY LOGIN Securables permission in order to allow the creation of the Example SQL scripts for creating a SQL Login and granting roles, used by the 1E Server web applications and services. During installation, the 1E Server installer will always attempt to grant db_owner permission to the server installation account on each of the 1E databases. NoteDatabases must be configured in multi-user mode. |
Service accounts
All 1E web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE, except for the BI SSAS User account which must be a domain user account.
The BI SSAS User account has the following requirements:
The account name and its password will be specified in the 1E Server Setup screen.
Must be a domain user account
Configured with Password never expires
Although this user might be referred to as a service account, it does not require Logon as a service on the server.
During installation, the SLA BI installer (used by 1E Setup) does the following with the user account:
Stores its credentials encrypted in the following places:
A linked server connection for the BI database to access the BI cube
In the configuration file used by the MDX API to query the BI cube.
Creates a SQL Login, with rights on the SLA-BI database.
SQL Login for the Network Service account
The SQL Login that is used by the 1E Server web applications and services depends on whether the SQL Server is remote from the 1E Server or is local, as described in the following table:
Installation scenario | Service account SQL Login |
|---|---|
1E Server is remote from SQL | The computer account of the remote 1E Server. For example ACME\ACME-TCN01$ |
1E Server and SQL are local | The local network service account, NT AUTHORITY\NETWORK SERVICE |
Note
Before upgrading 1E, or installing or upgrading Consumer applications like Application Migration or AppClarity, the SQL Login must be granted the following rights to support Database Snapshot of the 1E Catalog and SLA databases, to restore them if an error occurs:
dbcreator rights on the SQL database instance hosting the 1E Catalog database.
dbcreator rights on the SQL database instance hosting the SLA databases.
During installation, the 1E Setup will always:
Attempt to create the SQL Login
Grant it db_owner permission on each of the Tachyon databases
Remove the db_owner permissions when installation is completed.
User accounts
Please note the following:
Each 1E user requires an account in Azure Active Directory. AAD accounts must have their userPrincipalName (UPN) attribute populated, which is normal, but may be missing if users accounts have been created using scripts.
1E users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.
Users are added to the 1E system and assigned roles by any 1E user assigned to the Full Administrator system role. A Full administrator manages 1E users and roles using the Permissions Menu in the 1E Portal Settings application.
1E is supported in multi-domain, multi-forest environments. You have a choice of how 1E queries Azure Active Directory, specified during installation.
1E services locate users and computers and membership of security groups by querying a semi-colon delimited list of Azure Active Directory GC and/or LDAP URLs.
GC URL | This is the quickest and simplest method of resolving users and group membership. A single GC URL will normally resolve all users and groups within a single forest. Supports only Universal security groups. |
LDAP URL | A single LDAP URL will normally resolve all users and groups within a single domain. Supports Universal and Global security groups. Required if a Global Catalog (GC) server does not exist in a trusted forest, or if Global security groups must be used. |
Any domain which contains 1E servers, users or groups must:
Be resolvable from the 1E Server using DNS - that is, the server must be able to resolve domain names using DNS
Have a two-way trust with the domain in which the 1E (Master Stack) Server exists - so that users trust the server, and the server trusts users
Allow the 1E Server to read computer, user and security group objects in each domain.
The default GC:// is sufficient for a 1E Server in a simple Active Directory environment of one forest which has a Global Catalog. You can include, but it is not required, the name of the server's local domain or root domain, for example: GC://acme.local
To add support for a remote forest which has its own GC, you would for example have GC://acme.local;GC://nadir.local and so forth adding the root domain of any other forests to the list of GC URLs.
If you prefer to use LDAP, or there are difficulties with trusts between forest domains, then you would create a list of LDAP URLs including all domains that have 1E users and groups, as well as domains in which a 1E server resides. For example:
LDAP://acme.local;LDAP://pop.acme.local;LDAP://rock.acme.local;LDAP://country.acme.local;LDAP://nadir.local;LDAP://disco.nadir.local
You can mix GC and LDAP URLs, but you should avoid mixing LDAP URLs that are also resolved by a GC URL. For example: GC://;LDAP://nadir.local;LDAP://disco.nadir.local
Active Directory Security Groups
Active Directory security groups are strongly recommended for role-based access control (RBAC) but are not mandatory. AD security groups can be assigned to 1E roles after installation, they are not required during installation. They are added as 1E users and configured in the same way as AD user accounts. A 1E user can therefore be a domain user account or a security group. Groups are not mandatory because users can be assigned to roles and managed within 1E instead of AD, or a combination.
1E Setup assigns a limited set of permissions to the server installation account, as described in 1E user permissions, which cannot be edited. However, the installation account's permissions can be extended if the account is a member of one or more AD Groups configured as 1E users.
An AD security group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog .
Note
AD distribution groups are not supported.
If AD security groups are nested (groups within groups), they can slow down the performance of the 1E Portal for administrators. Therefore, we recommend nesting is not used, and each administrator and approver account is a member of a group used in 1E . You can improve performance further by disabling the recursive search used by 1E , bearing in mind this will not support nested groups. Please refer to the Post Installation page.
Domain Local security groups are not supported.
1E sends emails to users and approvers of 1E instructions, which requires user AD accounts to be email-enabled. However, 1E allows you to permission instruction sets with AD users or groups, roles that Permissions are assigned to instruction sets, and AD security groups can be assigned permissions. 1E will use the email address of an AD security group if it has been configured, and relies on the Mail system to forward emails to the members of the AD security group. If the AD security group is not configured with an email address, then 1E sends an email to each member that has an email address. AD distribution groups are not supported.
Active Directory in the cloud
The 1E software must be installed on a Windows Server that is part of an Active Directory domain. Companies do not always have their on-premises Active Directory extended into their cloud environment - there are security concerns that must be taken into account and there must be some mechanism for either a secure network connection between the customer's on-premises systems and the cloud environment (usually via VPN connection) or a way of synchronizing the cloud based Active Directory implementation with the on-premises one (through a directory synchronization of some sort).
Both AWS and Azure provide the following 'cloud' based versions of Active Directory:
AWS Directory Service for Microsoft Active Directory (Enterprise Edition) - This is a full implementation of Active Directory, but it requires a VPN and a trust relationship set up with any existing on-premises Active Directory to be able to use on-premises based accounts. This makes it quite a complex solution to implement and maintain.
Note
1E have not yet tested any 1E platform implementation using this solution, and as such it is only supported by 1E on a best-efforts basis.
Also known as AWS Managed Microsoft Active Directory (AD).
AWS AD Connector - This is a mechanism for redirecting domain queries from the local network to an on-premises Domain Controller using a VPN instead of needing a domain controller in the cloud.
Note
1E have not yet tested any 1E platform implementation using this solution, and as such it is only supported by 1E on a best-efforts basis.
AWS Simple AD - This is an implementation of Active Directory based upon Samba 4 and provides a limited subset of a full Active Directory.
Warning
1E do not support the 1E platform running in this environment.
Azure Active Directory - Although this provides cloud based identity, it cannot be used for direct directory connectivity from an Azure virtual machine, for that you need Azure Active Directory Services (see next).
Azure Active Directory Services - This provides the ability to domain join Azure Virtual Machines to your Azure Active Directory, however, it is not a full AD as you cannot have domain admin or enterprise admin privileges.
Warning
1E do not support the 1E platform running in this environment.
The following is the only cloud solution that is fully supported by 1E, and is what we call Extended AD. It doesn't use any of the above, but has the following requirements, which provide an Active Directory presence in the cloud and brings the full capabilities of Active Directory to bear.
Virtual machines located in the customer's cloud network installed with Windows Server as hosts for:
Domain Controller(s) in the existing enterprise domain, which can be Read-Only domain controllers (RODC).
Other member server(s) which host the 1E Server components, including Microsoft SQL Server, must be joined to the same enterprise domain.
A permanent site-to-site VPN connection from cloud to the corporate on-premises network.
Note
1E fully support the Extended AD solution for AWS and Azure, which do not change any of the Active Directory requirements described above.