NIC Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Welcome!
  2. /
  3. Technical
  4. /
  5. Service Accounts & Permissions
Edit page

Service Accounts & Permissions

Our discovery engine needs to have access to the systems (aka ‘data sources’) that will be analyzed. Here are instructions on how to create these accounts and permissions.

Azure Service Principal

Prerequisites

You need to have permissions to create App Registrations in Azure Active Directory in order to complete this.

Read more at Microsoft

  1. Login to Azure: portal.azure.com
  2. Open Azure Active Directory
  3. Navigate to App registrations and select New registration
  4. Enter a Name and press Register (leave all else as default)
  5. Navigate to API permissions and select Add a permission
  6. Select tab Microsoft APIs > Microsoft Graph > Application permission
  7. Add the following permissions depending on what system you are giving access to:

Microsoft Permissions 

Directory.Read.All
Domain.Read.All
Files.Read.All
Sites.Read.All

Sites.Read.All

Click here to see documentation on how to only give read access to specific site

Users.Read.All
Calendars.Read
Contacts.Read
Mail.Read
Prerequisites
In order to use the API to access Teams information, a specific request to Microsoft has to be performed. It takes about one to two weeks for Microsoft to process the request.
  1. Add following permissions:
GroupMember.Read.All
Channel.ReadBasic.All
ChannelMessage.Read.All - must be given to both the app and the owner
  1. Getting access to the Microsoft Graph API Teams uses the Microsoft Graph API to retrieve data. Creating an account on the Microsoft Azure portal is required for the Teams connector to retrieve values for Client ID, Client Secret, and Tenant ID. Users must complete this form to get access to Microsoft protected APIs. It takes about one to two weeks for Microsoft to process the request. To enable access to this API:

 

The MIP Labeler SDK requires its own API permissions.

Add the following permissions:

API Permission Access Level Purpose
Azure Rights Management Services Content.Writer Application Create protected content
Azure Rights Management Services User_impersonation Delegated Create and access protected content of users
Microsoft Information Protection (MIP) Sync Service UnifiedPolicy.Tenant.Read Application Read all unified policies of the tenant
Permission types
The MIP Labeler SDK requires both Application and Delegated permissions. Make sure the permissions are added to the correct API and with the access level shown above.

The Tenant & Identity Scan uses Application permissions, not delegated permissions.

Add the following Microsoft Graph permissions:

User.Read.All is required. The remaining permissions provide additional information and improve the coverage of the Tenant & Identity Scan.

Permission Purpose
User.Read.All Read the tenant’s user accounts. Required for the identity inventory.
GroupMember.Read.All Read group membership and determine paths through which accounts can reach privileges.
AuditLog.Read.All Read sign-in information used for stale, dormant, and orphaned account detection.
RoleManagement.Read.Directory Read privileged role assignments, including permanent assignments and assignments made through PIM.
Application.Read.All Read app registrations and service principals, including information used to identify credentials approaching expiration.
Policy.Read.All Read Conditional Access policies and determine which accounts fall outside them.
Reports.Read.All Read MFA registration information. Only authentication method types are used, not phone numbers.
Organization.Read.All Read the tenant name and verified domains so the connected directory can be confirmed.
Important
The application does not require write permissions. If the Microsoft consent screen requests a write permission, an additional permission has been added that is not required by the Tenant & Identity Scan.
App registration requirements

Client secrets can be configured with a maximum lifetime of 24 months in Microsoft Entra ID. The expiration date is recorded during the connection test so that a health warning can be raised before the secret expires. Renewing the secret must be performed by the tenant administrator.

The administrator configuring the integration must be able to create app registrations and grant tenant-wide admin consent.

This can be performed by:

  • Global Administrator, or
  • Privileged Role Administrator together with Application Administrator

Google Service Account

To create a service account:

  1. In the Service accounts page, select the relevant Gmail project
  2. Click + Create service account
  3. Under Service account details, type a name, ID, and description for the service account, then click Create and continue
  4. (Optional): Under Grant this service account access to project, select the IAM roles to grant to the service account*
  5. Click *Continue
  6. (Optional): Under Grant users access to this service account, add the users or groups that are allowed to use and manage the service account
  7. Click Done
  8. Click + Create key, then click Create to add a new service account key Adding a service account key:
    • Select the service account that you created
    • Click the Keys tab
    • Select Create new key from the Add key drop-down list
    • Click Create
  9. Add the following permissions depending on what system you are giving access to:

Google Permissions

To grant service account scopes:

Prerequisites

Contact sharing needs to be enabled:

(https://admin.google.com > Directory > Directory settings > Directory and set Contact sharing > Enabled)

  • Use the client ID as the client name and grant scopes to the service account:

(https://admin.google.com > Security > Access and data control > API controls > Manage domain wide delegation)

  • https://www.googleapis.com/auth/drive for accessing the files of the drive. Grant https://www.googleapis.com/auth/drive.readonly instead, if you’re adding the permission_drive_readonly custom parameter.

  • https://www.googleapis.com/auth/admin.directory.user.readonly for listing the users in the G‑Suite domain to scan all of their files

Prerequisites
You need super administrator access to the relevant Google Workspace account to perform this procedure.

To set up domain-wide delegation of authority for a service account:

  1. In the Google Cloud console*, navigate to Menu > IAM & Admin > Service Accounts

  2. In the Service Accounts window, select your service account and click Show advanced settings

  3. Under Domain-wide delegation, find your service account’s Client ID and copy its value.

  4. In the Google Admin console, navigate to Menu > Security > Access and data control > API controls

  5. In the API controls window, click Manage Domain Wide Delegation

  6. Click Add new

  7. In the Client ID field, paste the client ID you copied previously.

  8. In the OAuth Scopes field, enter a comma-delimited list of the scopes required by your application. These should be the same set of scopes that you defined when configuring the OAuth consent screen. https://www.googleapis.com/auth/gmail.readonly https://www.googleapis.com/auth/admin.directory.user.readonly

  9. Click Authorize

  10. The Admin SDK API needs to be enabled, it can be enabled through this link: https://console.cloud.google.com/apis/library/admin.googleapis.com

    The Gmail API needs to be enabled, it can be enabled through this link: https://console.cloud.google.com/apis/library/admin.googleapis.com

 

Salesforce

Required Permissions

  1. These permissions are required due to the way that data extensions content is requested:
    data_extensions_read
    data_extensions_write
    email_read
    data_extensions_write permissions
  1. To support OAuth connectivity to Salesforce user accounts, set up these permissions in the OAuth configuration:
    Access your basic information
    Access and manage your data
    Perform requests on your behalf at any time

User profile configuration

Prerequisites
Requires Salesforce admin permissions
To enable API access in Salesforce by profile:

  1. Click Setup
  2. Click Manage Users > Profiles
  3. Click Edit against the specific profile
  4. Scroll down to Administrative Permissions and check the API Enabled box
  5. Click Save

To enable API access in Salesforce by permission set:

  1. Click Setup
  2. Click Manage Users > Permission Sets
  3. Select the *specific Permission Set.
  4. Click System > System Permissions > Edit
  5. Check the API Enabled box
  6. Click Save

For additional information on enabling API access in Salesforce, click here

SQL & noSQL

In order to scan any of the below databases, read-only access has to be given. Some can use service accounts or service principals, and some need a basic database user.

Warning
These guides are general guides on how to create database users with read-only access. Make sure that you have experience with the database that you use before performing any actions on it. Always let your database admin assist, or have them perform the actions.

Database Permissions

Create a user in MongoDB with read access to the databases to analyze

Commands for creating a user in the admin database with read access to all databases

Enter mongo shell: mongo -h localhost -authenticationDatabase=admin -u MyUser

Enter the admin database: use admin

Create new user:

db.createUser(
{
user: "MyNewUser",
pwd: passwordPrompt(),  
roles: [
    { role: "readAnyDatabase", db: "admin"}
],
mechanisms: [ "SCRAM-SHA-1", "SCRAM-SHA-256"]
})

This is an example of how to create a readaccess group and add a new user to that group. Any already existing group can be used instead.

-- Create a group
CREATE ROLE readaccess;

-- Grant access to existing tables
GRANT USAGE ON SCHEMA public TO readaccess;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readaccess;

-- Grant access to future tables
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readaccess;

-- Create a final user with password
CREATE USER mynewpsqluser WITH PASSWORD 'secret';
GRANT readaccess TO mynewpsqluser;


SQL> create user user_read_only identified by readonly;
SQL> grant create session to user_read_only;
SQL> grant select any table to user_read_only;

If you wish to grant select on dictionary views then:

grant select any dictionary to user_read_only;
  1. Login to mysql: mysql -u root -p

-- Create a new MySQL user
CREATE USER ‘$user‘@’127.0.0.1’ IDENTIFIED BY ‘$password‘;

-- Grant read-only permission to the MySQL user
GRANT SELECT, SHOW VIEW ON $database_name.* TO $user@’127.0.0.1′ IDENTIFIED BY ‘$password‘;

FLUSH PRIVILEGES;

If you want to use SSL connection, you can use the following instead:

GRANT SELECT, SHOW VIEW ON $database_name.* TO $user@’127.0.0.1′ IDENTIFIED BY ‘$password‘ REQUIRE SSL;

FLUSH PRIVILEGES;

The Microsoft SQL connector supports multiple types of authentication methods:

  • Connecting to Azure SQL using User Credentials authentication
  • Connecting to Azure SQL using ActiveDirectoryMSI (Azure AD)
  • Connecting to Azure SQL using AAD Service Principal authentication
  • Configuring Kerberos-based Windows integrated authentication
  • Configuring Windows Integrated NTLM

The instructions below will only show how to create a read-only database user

To create a read-only database user account for Microsoft SQL Server

  1. Start Microsoft SQL Management Studio

  2. In the Connect to Server window, in the Server name box, select the SQL Server computer on which the database is installed

  3. In the Authentication box, click SQL Server Authentication

  4. In the Login box, type a user name that has permissions to create new accounts

  5. In the Password box, type the password for the user name

  6. Click Connect

  7. On the SQL Server Management Studio window, in the Object Explorer pane, right-click Security, and then click New > Login

  8. In the Login-New dialog box, perform the following tasks in the order in which they appear:

    • In the Select a page pane, click General
    • In the right pane, in the Login name box, type a logon name for the new user
    • Check SQL Server authentication, type a password for the user, and then confirm the password
    • Uncheck User must change password at next login
    • In the Default database box, select the database to be read by this user.

  9. In the Login-New dialog box, in the Select a page pane, click Server Roles

  10. In the right pane, click public

  11. In the Login-New dialog box, in the Select a page pane, click User Mapping

  12. In the right pane, under Users mapped to this login, make sure that you have selected the database to read.

  13. Under Database role membership for the database, click db_datareader This role gives the user read-only data access to the database. The role public is always selected and cannot be cleared.

  14. Click OK