Tillgång till system från tredje part

Introduction

This document outlines the level of access Identum requires to customer systems during and after a project implementation. Our policy is to use temporary access with the least privilege necessary to complete the required tasks. Identum does not require permanent access to customer environments.

1. Source Systems

Identum does not need permanent user access to source systems such as HRM/payroll, student information systems, or other personnel databases. Access to data exports from these systems, either via file transfer or API, is sufficient.

Note: On request, we may require temporary access for specific tasks like troubleshooting or training.

2. Dataporten / Feide Customer Portal

We do not require permanent access to Dataporten or the Sikt (formerly Uninett) customer portal. Temporary access can be granted upon request if needed.

3. Microsoft Azure Active Directory (Azure AD)

If our services (eADM/eFeide) will synchronize users, groups, passwords, licenses, memberships, and status to Azure AD, we require an account with permissions equivalent to User Administrator in Microsoft 365.

• This access is only required for the duration of the project.

• The account must be protected with Multi-Factor Authentication (MFA).

• The account must be disabled or removed once the project is complete.

Note: The ongoing communication between eADM/eFeide and Azure AD is managed via an Azure Enterprise Application, not a user account. For configuration details, see our documentation: How to Configure Azure AD for Integration.

4. Google Workspace

If our services will synchronize users, groups, passwords, organizational units (OUs), memberships, and status to Google Workspace, we require a user account with permissions equivalent to User Management Admin.

• This account must be protected with MFA.

• The account can be disabled once the project is complete.

Additionally, the customer's global administrator will need to configure access keys for our API client.

5. On-Premises Active Directory (AD)

For on-premises AD integration, a client application is installed on the customer's internal network. eADM does not require a dedicated server. We do not recommend installing the eADM client application on a Domain Controller.

Client Communication

• The client is a Windows-based .NET console application that runs as a scheduled task using a service account.

• Communication with our cloud solution is initiated by the client over an encrypted connection (TLS 1.2 on port 443 outbound). No inbound firewall openings are necessary.

• Each client uses unique authentication keys to communicate with the cloud service.

Consultant Access (During Project)

During the project, the project manager and/or consultant will need remote access to the on-premises AD environment via VPN or TeamViewer.

• This access must be protected with MFA.

• Access can be to a primary domain controller, but we recommend using a dedicated server for the eADM client.

• The server must have access to:

  • Active Directory Users and Computers

  • Active Directory module for Windows PowerShell

  • Windows Exchange Management Tools for PowerShell (if applicable)

Server Requirements

• Operating System: Windows Server

• .NET Framework: Version 4.0 or newer

• PowerShell: Version 4.0 or newer

• Firewall: Port 443 must be open for outbound SSL traffic.

• Software: Please ensure Notepad++ is installed on the server.

Service Account Permissions

A dedicated service account is required to run the eADM client. This account needs the following permissions:

• AD Rights: Create, delete, and modify users, groups, and OUs.

• Local Rights:

  • Log on as a batch job (for scheduled tasks).

  • Full read/write access to C:\eADM\ and its subfolders.

• Optional Rights (if applicable):

  • Create and set NTFS permissions for user home folders.

  • Create mailboxes (enable-mailbox och enable-remotemailbox).

Warning: Once the system is in production, our personal user accounts must be disabled. All operational tasks will be performed by the service account, and its password should be changed so that Identum no longer has access to it.

Sammanfattning för AI och sök

This Standard Operating Procedure (SOP) defines the access permissions Identum requires for customer third-party systems like Azure AD, Google Workspace, and on-premises Active Directory. It emphasizes that access is temporary, limited to the project period, and follows the principle of least privilege. The document details requirements for service accounts, consultant access, server configuration, and security protocols, including the mandatory use of MFA and disabling of accounts post-project.