1E 9.0 (on-premises)

Ensure the following URL is whitelisted:

This URL must be accessible from the 1E Server during the setup and running of 1E.

The 1E license must be validated on a regular basis via internet contact with the 1E license service. The regular validation period is set when the license is requested.

For whitelisting purposes, the 1E Server (specifically the Coordinator Workflow module in Master Stack) requires an Internet connection to the 1E license service, as defined in the license file itself. If activation fails, then the system will install but not be usable until the activation is completed.

You will need your own code signing certificate, and have it registered in your 1E license, if you want to develop your own custom 1E instructions, or modify those of other authors. Instructions that are provided in the 1E platform or downloaded from the 1E Exchange have already been code signed using the Platform and Exchange certificates from 1E. Your license controls whether you can use these instructions.

Ideally, all of your instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your license and associated with your organization's instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your license. This will then automatically activate on your 1E Server (assuming it has connection to the Internet).

For the remote SQL Server requirement, please refer to Configuring a persistent route for SQL traffic. However, please ensure you also consult your server, firewall, and networking teams.

Cloud implementations have special configuration requirements for SQL Server and network interfaces described in Server sizing requirements.

The computername of a 1E Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less.

Microsoft's guidance can be found here: https://docs.microsoft.com/en-us/windows/desktop/SysInfo/computer-names.

Each server that has 1E platform components installed requires its own DNS Name. A DNS Name can be a DNS alias, CNAME or Host (A) record.

The number of DNS Names used by a system depends on the location of 1E and other Platform services. The table below describes the options.

Where possible the 1E Server DNS Name should be a CNAME Alias which references the (A) Host records for each of the Switch network interfaces registered in DNS.

For multiple Switches to share the same DNS Name, the load balancing options include:

1E platform and applications use underlying IIS and SQL Server technology, and only require HTTP or MSSQLSvc class SPNs if your company security policy has configured IIS or SQL Server to use Kerberos authentication.

If your IIS server is using Kerberos, then each DNS Name used to access a 1E Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the relevant service account in Directory, which is computer$ by default. This allows 1E web applications to authenticate clients using Windows Authentication where Kerberos is an authentication provider (primary, fallback, or negotiated).

SPNs are not required for DNS Names used to connect to Switches or Background Channel, because they do not use Windows Authentication. However, bear in mind the same DNS Name might be used to access other web applications.

If an SPN is not created, then you will see "401 Not authenticated" errors in the browser and/or log files.

Service Principal Names (SPN) are attributes of AD accounts. A domain administrator will need to create an HTTP class SPN for the 1E web server service account, by using one of the following methods:

Use each command as follows:

The above example assumes:

To determine which type of record a DNS Name is, run the following command:

nslookup tachyon.acme.local

More complex scenarios can be configured which requires in-depth knowledge of IIS, SPN and DNS configuration and are beyond the scope of this documentation.

The following PowerShell commands can be used to install relevant IIS roles and features and record the server configuration in a file.

RolesInstall.ps1 - Configure IIS using PowerShell

Import-Module ServerManager

Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-1.txt -Append
Install-WindowsFeature Web-Server,
Web-Http-Redirect,
Web-Dyn-Compression,
Web-Basic-Auth,
Web-IP-Security,
Web-Windows-Auth,
Web-Asp-Net45,
Web-Mgmt-Console,
Net-Framework-45-Core,
Net-Framework-45-ASPNET,
Web-WebSockets
Uninstall-WindowsFeature Web-DAV-Publishing
   
Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-2.txt -Append

Required on the 1E Master Stack server if you are installing Content Distribution features.

The Export all feature is described in Exporting data from Endpoint Troubleshooting. To enable 1E users with the appropriate permissions to use the Export all feature you must ensure that Microsoft Bulk Copy Program (BCP) is installed on each 1E Response Stack, specifically the Response server where the Core component is hosted.

You can confirm BCP is installed by starting a command prompt and typing bcp and usage information is displayed. The command bcp -v displays the version.

Install the following components to get BCP working:

To verify the components have been installed, you can use AppWiz.cpl and check for the Product Name.

1E and SLA Platform services, including web application pools, use built-in accounts Local System (SYSTEM) and Network Service (NETWORK SERVICE) by default, and 1E recommends this configuration.

You must ensure these built-in accounts have the necessary NTFS security permissions on the 1E and SLA Platform installation and log folders.

If you are using default installation settings for the 1E server on a default configuration of Windows Server, then Local System has the necessary permissions by default, but Network Service requires some additional steps. The simplest method is to add Network Service to the Administrators localgroup, which allows the default installation and logs folders to be created during installation.

However, adding Network Service to the Administrators localgroup is not considered best practice, therefore alternative methods are described below.

The table below lists the 1E services and their default service accounts.

The table below lists the default folder locations which must have NTFS security permissions configured for all service accounts.

The 1E installation process does not modify permissions, except for the %ProgramData%\1E\Licensing\ folder which does receive full permissions for Network Service.

For a default installation of 1E on a default configuration of Windows Server, Local System (SYSTEM) has the necessary permissions by default, but Network Service requires some additional steps.

You have a choice of how to configure NTFS security for Network Service, using one of the following options, according to your organization's policies.

You can pre-create the 1E installation and logs folders prior to installation and apply NTFS permissions on these instead of their parent folders.

Using a non-default location for the Logs Folder

The accounts used by 1E services and application pools must have a minimum of Full Control permission on the logs folder (folder, subfolders and files.

The example screenshot shows a default installation. For a default installation, the only permissions necessary are SYSTEM and Administrators, both Full Control.

If you allow the installer to create new databases, they each have the following default settings. Databases will grow automatically to the sizes estimated in Server sizing requirements.

You may be required to create databases by hand before installation. This is also known as pre-creating databases. Below are some of the reasons why your SQL administrator may require you to do this:

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.

The following examples assume ACME\TCNinstaller01 is the 1E Server Installation Account.

When the account is not permitted to have the sysadmin SQL Server role, then a sysadmin can use the following script to create a SQL Login and grant it rights.

Create SQL Login and grant ALTER ANY LOGIN Expand source

USE [master]
GO
CREATE LOGIN [ACME\TCNinstaller01] FROM WINDOWS
GO
GRANT ALTER ANY LOGIN TO [ACME\TCNinstaller01]
GO

If the 1E Server Installation Account is permitted to create the databases, then a sysadmin can use the following script to add the SQL Login to the dbcreator role.

Grant dbcreator Expand source

USE [master]
GO
ALTER SERVER ROLE [dbcreator] ADD MEMBER [ACME\TCNinstaller01]
GO

If the databases have been pre-created, then a sysadmin can use the following script to add the SQL Login to the db_owner role on each pre-created database.

Grant db_owner Expand source

USE [TachyonMaster]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO
USE [TachyonResponses]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO

After the databases have been created, best practice is to change the owner of each database to sa, to avoid issues if the owner's Windows account is deleted in future.

The following script can be used to change the owner of each 1E database to sa. This will work even if the sa login has been disabled, which is also best practice.

Change owner to 'sa' Expand source.

ALTER AUTHORIZATION ON DATABASE::TachyonMaster To "sa"
GO
ALTER AUTHORIZATION ON DATABASE::TachyonResponses To "sa"
GO

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:

During installation, the 1E Server Setup will always:

If re-installing or upgrading 1E, you need to decide if you will keep the existing databases or create new ones.

For details about mail server requirements, please refer to SMTP server.

This application is used to read the credentials for each account that logs into the 1E portal.

The 1E Integration app is optional and only required when using non-interactive logons, however you will need to create it if you want to integrate things like:

Once you have configured your applications, you will need to capture the following information for use on the Identity Provider screen in 1E Server Setup.

Information needed during installation

Use the following table to help you complete the Identity Provider section of the 1E platform setup installer.

Note

Where the Metadata endpoint is specified it MUST exactly match in case the URI defined for the platform.

Table 15. Identity Provider installer screen

Identity Provider	Item required
Provider-specific Application Identifiers	PKCE App Id Application Id for directory search operations by platform (PKCE App Id) Client Assertion App Id Application Id for interactive authentication (Client Assertion App Id).
Metadata endpoint	OpenId connect metadata endpoint.
Setup User	Setup user who should be granted full administrator rights during install.
Signing certificate for platform tokens	PKCE certificate - 1E Platform Token certificate thumbprint.
Signing certificate for IdP requests	1E Client Assertion - (Directory search) signing certificate thumbprint.

The Client Assertion Application will be used to perform directory searches in 1E. This will allow a 1E Administrator to add users to the platform and give them assignments for roles and management groups. These instructions show how to register the Client Assertion Application in Okta.

This application will be used to read the credentials for each account that logs into the 1E portal. These instructions show how to register the PKCE Application.

When the applications have been created you then need to grant the permissions.

To use the applications and allow users to be added to 1E you also need to first assign those users to the applications you just created in Okta. We recommend that you create a group for this purpose and add the group to the applications. That way user assignment can be via the group.

This Client Assertion Application is used for non-interactive logins.

Once you have your applications configured, you will need to capture the following information to be used on the Identity Provider screen in 1E Server Setup.

Each 1E user requires an account in the Identity Provider used. All 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.

Groups that are setup in the Identity Provider are recommended for role-based access control (RBAC) within 1E but are not mandatory. Groups can be assigned to 1E roles after installation, they are not required during installation. They are added as 1E groups and configured in the same way as user accounts. A 1E user can therefore be a user account or in a group within the Identity Provider. Groups are not mandatory because users can be assigned to roles and managed within 1E instead of the Identity Provider, or a combination.

1E Server 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 recommend that this user account is viewed as a service account and kept with the minimum permission.

A group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog .

1E platform uses either Network Service or Local system for all its services and web application pools.

Please refer to the following sections regarding any rights these accounts may require:

The Network Service account of the 1E Master Stack server requires a SQL Login, with all the following rights in the Configuration Manager site database.

If you opt to use a specific SQL Login:

To install Content Distribution features, 1E Server Setup requires your server installation account to have the following rights. Please refer to 1E Server Setup.

You must enable certain Configuration Manager site settings if you plan to use the System Center Configuration Manager connector to populate Inventory.

If you have configured 1E Server to require client certificates (Client certificates) then each device requires a certificate with the following properties, so the client can be authenticated by the 1E Switch.

In organizations that have an established PKI, the client devices will probably have a suitable certificate already, along with relevant Trusted Root CA certificates.

For non-Windows devices, the certificate files must be included in the 1E Client installation folder structure, as described below in Configuring the Non-Windows 1E certificate using OpenSSL.

/etc/1E/Client/.sslcerts

/Library/Application Support/1E/Client/.sslcerts