User Policies

User Policies allow you to define a custom set of account properties and key privileges (from the Account Permissions page) and then save them as a policy for reuse. When you create a user account, you can use the User Policy to quickly apply settings to the new account. This section will show you how to create a user policy.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

What is a User Policy?

In a user policy you can choose to define all the fields in the Account Permissions page or you can choose to define only one or more fields. When you apply the user policy to user accounts, only those fields you defined in the user policy will be applied to the user accounts. For the remaining fields, the user accounts will retain their previous values or use the default values.

User Policies have a dynamic relationship with their member user accounts. You can make a change to a user policy and SL1 will automatically update the account settings for each member account.

For example:

Suppose you create a user account called "John Doe" on the first of the month and use the user policy named "NOC users" to create the user account.
Suppose you create another user account called "Jane Smith" on the fifth of the month and again use the user policy "NOC users".
Suppose on the 15th of the month, you add an additional Key Privilege to the "NOC users" policy.
That additional Key Privilege will appear in the account for John Doe and Jane Smith as soon as the "NOC users" policy is saved.

If you create a user account with a user policy, the fields in the Account Permissions page for that user account are grayed out. If you want to manually edit fields in the Account Permissions page for the user account, you must disassociate the user account from the user policy. Any future changes made to the user policy will not appear in the disassociated user account.

If you want to automatically import user accounts from LDAP or Active Directory, you must create at least one user policy. To use user policies in this way, special configuration is required. For more information, see the section on Using LDAP or Active Directory.

Creating a User Policy

User Policies allow you to define a custom set of account properties and privileges (from the Account Permissions page) and then save them as a policy for reuse. When you create a user account, you can use the User Policy to quickly apply settings to the new account.

To create a new user policy:

Go to the User Policies page (Registry > Accounts > User Policies).
In the User Policies page, click the Create button. The User Policy Properties Editor page appears.

NOTE: If you have disabled fields in the User Policy, you must manually define these fields in the Account Permissions page for each aligned user account.

In the User Policy Properties Editor page, supply a value in each field:

NOTE: If you don't want a field included in a User Policy, click on the field name. The field will become grayed out. SL1 does not apply the grayed-out fields to any aligned user accounts; the corresponding field in the user account retains its original value (either a default value or a custom value that was defined when the account was created).

Policy Name. Name of the user policy. Can be any combination of alphanumeric characters, up to 64 characters in length.
Login State. Specifies whether user accounts created with the policy can log in to SL1. Choices are:

Active. Means user accounts created with this policy are active and can log in to SL1.
Suspended. Means that user accounts created with this policy are not active and cannot log in to SL1.

Account Type. This drop-down contains an entry for each standard account type. These account types affect the list of Key Privileges for the user. The choices are:

Administrator. This type of user has unlimited permissions in SL1.
User. This type of user must be assigned permissions in SL1.

Password Strength. When defining or editing a user account, the administrator can define the required password strength. The user must then always use a password that meets or exceeds that specified password strength. SL1 will not allow the user to save changes to his/her password that do not meet the password strength requirement. Choices are:

Good. Password must be at least eight characters long and contain at least one number or one symbol.
Strong. Password must be at least eight characters long and contain at least one number and at least one symbol.
Very Strong. Password must be at least 13 characters long, contain no repeated characters, and contain at least one number and at least one symbol.

Password Expiration. Specifies whether or not the password for this account will expire and if so, when the password will expire. Choices are:

Disabled. Password does not expire.
30 Days. When the current password is 30 days old, during login the user will be prompted to change the password.
60 Days. When the current password is 60 days old, during login the user will be prompted to change the password.

90 Days. When the current password is 90 days old, during login the user will be prompted to change the password.
180 Days. When the current password is 180 days old, during login the user will be prompted to change the password.

If the password is set to expire, on the expiration date, the user will be prompted to change the password at the Login page. The user will be required to enter his/her old password and then enter a new password twice. If the user incorrectly enters the previous password or enters an invalid new password, the user will not be allowed to log in to SL1.

The new password must meet the requirements of the Password Strength field and the Password Shadowing field. SL1 will prompt the user to meet these requirements and display a description of those requirements.

NOTE: The value in the Password Expiration field in this page (the Create New Account page) overrides the value in the Behavior Settings page (System > Settings > Behavior).

Password Shadowing. Specifies requirements for password reuse. By default, when a user defines a new password, he/she cannot reuse any passwords that he/she has used in the last 12 months. The choices in this field are:

Default - cannot reuse passwords from past year
1 - Cannot reuse last password
2 - Cannot reuse last 2 passwords
3 - Cannot reuse last 3 passwords
4 - Cannot reuse last 4 passwords
5 - Cannot reuse last 5 passwords
6 - Cannot reuse last 6 passwords
7 - Cannot reuse last 7 passwords
8 - Cannot reuse last 8 passwords
9 - Cannot reuse last 9 passwords
10 - Cannot reuse last 10 passwords

Require Password Reset. If selected, the user will be prompted to change his/her password at the next login. When creating a new user account, this option is selected by default. After the user's first login, when he/she is prompted to change his/her password, this option is then unselected.

NOTE: The Re-Apply All Settings to All Policy Members checkbox affects the behavior of the Require Password Reset field.

Authentication Method. Specifies how the user will be authenticated. The choices are:

EM7 Session. User's username and password are authenticated by the ScienceLogic database.
LDAP/Active Directory. User's username and password are authenticated by an LDAP server or Active Directory server. For details on configuring SL1 to use LDAP or Active Directory authentication, see the manual Using LDAP or Active Directory.

NOTE: For users who are authenticated with SSO, you must set the Authentication Method field to "LDAP/Active Directory" to support automatic user policy alignment updates in case attributes change. For details on configuring SL1 to use SSO authentication, see the section on using Using Single Sign-On (SSO).

Restrict to IP. The user will be allowed to access SL1 only from the specified IP. Specify the IP address in standard dotted-decimal notation.
Ticket Queue Memberships. Highlight one or more ticket queues of which users will be members.
Primary Organization. Specifies the primary organization. This will be the default organization for user accounts created with this policy. You can select from a list of all organizations in SL1.
Theme. Backgrounds, colors, fonts, and graphics that will appear when a user logs in. Themes are defined in the Theme Management page (System > Customize > Themes). You can select from a list of all themes in SL1.
Time Zone. The time zone to associate with each user account created with this user policy. Dates and times in SL1 will be displayed for the selected time zone.
Additional Organization Memberships. User accounts created with this user policy will be members of each selected organization. This allows users to view and access elements from multiple organizations. To select, highlight one or more organizations.
Privilege Keys. The Privilege Keys pane displays a list of Access Keys that can be assigned to the user's account. Access Keys define the tabs and pages users have access to and the actions that a user may perform. These key privileges are defined by the system administrator from the Access Keys page (System > Manage > Access Keys).

SL1 includes the default access key "Grant All". For accounts of type "user", this key always appears. The Grant All Key allows a user to access all pages and actions in SL1, except the user cannot create new access keys or edit existing access keys.
To assign an access key to a user, click the checkbox. A checkmark appears.
To deny an access key to a user, do not select it.
After clicking the Save button, all selected access keys will appear in red.

NOTE: Users of type "Administrator" automatically have access to all pages and actions in SL1. The Privilege Keys pane is grayed-out for "Administrator" policies.

Re-Apply All Settings to All Policy Members. When you save the policy and select this checkbox, all settings are reapplied to all policy members. If you have selected the Require Password Reset field, each user who is a member of this policy will have to reset their passwords on login, even if they have previously done so and toggled off that setting. Selecting this checkbox turns back on the Require Password Reset field again.

Click the Save button to save your new user policy.
You can now apply this user policy to new user accounts and existing user accounts. For details, see the following sections.

Creating a User Account with a User Policy

There are two ways to apply a user policy to a user account:

When creating a new account, you can apply a user policy to simplify the creation process.
You can apply a user policy to an existing user account. The previous settings will be deleted and the settings from the user policy will be applied.

To apply a user policy when manually creating a new account:

Go to the User Accounts page (Registry > Accounts > User Accounts).
In the User Accounts page, click the Create button. The Create New Account page appears.

In the Create New Account page, in the Account Type field, select Policy Membership.
In the Policy Membership pane, select a user policy.
Click the Save button to save the new user account. The Account Permissions page appears, with the permissions from the user policy applied. All fields that are included in the user policy are grayed out.

NOTE: To remove the user from the user policy, in the Account Type field, select Individual.

To apply a user policy to an existing account:

Go to the User Accounts page (Registry > Accounts > User Accounts).
In the User Accounts page, find the user account you want to edit. Click its wrench icon ().

In the Account Permissions page, in the Account Type field, select Policy Membership.
A field appears below the Account Type field. From this new field, select the user policy to apply.
Click the Save button.
All permissions from the user policy are applied to the user account. All fields that are included in the user policy are now grayed out.

Applying a User Policy to Multiple User Accounts

To apply a user policy to multiple existing user accounts, perform the following:

Go to the User Accounts page (Registry > Accounts > User Accounts).
For each user account to which you want to apply a user policy, select the checkbox () for the user account.
In the Select Action drop-down list (in the lower right), select a user policy (under Change User Policy to).
Click the Go button. The selected user policy is now applied to each selected user account.

Viewing Members of a User Policy

If you have created or edited user accounts using a user policy, those user accounts will appear as members of the user policy.

To view a list of members in a user policy:

Go to the User Policy Membership page (Registry > Accounts > User Policies).
Find the user policy for which you want to view members. Click its user icon () in the Members column.
The User Policy Membership appears and displays the list of user accounts associated with the user policy.

Removing Members from a User Policy

You can disassociate one or more user accounts (members) from a user policy. When you do this, each disassociated user account will retain the settings in the Account Permissions page from the user policy, but the user account is no longer associated with the user policy. Any future changes made to the user policy will not appear in the disassociated user account.

For each disassociated user account, in the Account Permissions page, the Account Type field will contain the value "Individual" instead of "Policy Member" and none of the fields will be grayed-out. For each disassociated user account, you can now manually edit each field in the Account Permissions page.

To remove one or more members from a user policy:

Go to the User Policy Membership page (Registry > Accounts > User Policies).
Find the user policy for which you want to view members. Click its user icon ().
The User Policy Membership page displays the list of user accounts associated with the user policy.
Select the checkbox for each user account that you want to remove from the user policy.
In the Select Action field, select REMOVE Policy Membership. Click the Go button.
The selected user account(s) will now be "Individual" accounts, rather than members of the user policy.

Removing a Single User Account from a User Policy

You can remove a single user account from a user policy, directly from the Account Permissions page.

The user account will retain the current settings from the user policy in the Account Permissions page, but the user account is no longer associated with the user policy. Any future changes made to the user policy will not appear in the disassociated user account. None of the fields in the Account Permissions page will be grayed out anymore; you can now manually edit each field in the Account Permissions page.

To remove a single user account from a user policy:

Go to the User Accounts page (Registry > Accounts > User Accounts).
In the User Accounts page, find the user account you want to edit. Click its wrench icon ().
The Account Permissions page appears:
In the Account Permissions page:

In the Account Type field, select Individual (instead of Policy Membership).
When prompted, choose to remove the user account from the user policy.

Click the Save button to save your changes.

Deleting a User Policy

When you delete a user policy, the user accounts that are members of the user policy are not deleted. Each member user account will retain its previous settings, but in the Account Permissions page, the Account Type field will contain the value "Individual" instead of "Policy Member" and none of the fields will be grayed out.

To delete a user policy:

Go to the User Policies page (Registry > Accounts > User Policies).
In the User Policies page, find the user policy you want to delete. Select its checkbox ().
For each user policy you want to delete, select its checkbox.
In the Select Action drop-down field (in the lower right), choose DELETE User Policies.
Click the [Go] button.
Each selected user policy will be deleted. For each member account that was previously aligned with the deleted policies, in the Account Permissions page, SL1 sets the Account Type field to Individual.

Example of Creating a User Policy

Suppose we want to create all the user accounts for the people in the customer care department at our fictional company.

Suppose the customer care staff is located at headquarters of our fictional company and belong to the "Northeast" organization.

Suppose the customer care staff needs to be able to listen to complaints from customers and then record each complaint in a work ticket. So each member of the customer care staff needs to be able to create tickets and view the status of those tickets.

We could create a user policy that would allow us to "preset" many of these settings, so they can quickly be applied to multiple user accounts.

To create the user policy:

Log in to SL1 as a system administrator. If you have not yet created organizations or user accounts, you can log in as "em7admin", using the password defined during initial configuration.
Go to the User Policies page (Registry > Accounts > User Policies). Click the Create button.
In the User Policy Properties Editor page, enter a value in each of the following fields:

Policy Name. For the name of the user policy, we entered "Customer_Care".
Login State. We selected Active, so that user accounts created with this policy can immediately log in to SL1.
Account Type. We selected User.
Password Strength. We selected Strong.
Password Expiration. We accepted the default setting of Disabled.
Password Shadowing. We accepted the default setting of Default - cannot reuse passwords from past year.
Require Password Reset. We did not select the Next Login checkbox.
Authentication Method. We selected EM7 Session, so that the SL1 database will verify that each user's account name and password are legitimate.
Restrict to IP. We did not supply a value in this field, because this policy will be applied to multiple users, each with his/her own IP address.
Event Console Default Display. We accepted the default setting of Flat events table.
Ticket Queue Memberships. We have left this set to None. If part of your user's responsibility is to file tickets, select all appropriate ticket queues in this field. This allows users created with the user policy to view and access all ticket queues in SL1.
Primary Organization. We select System as the primary organization for all users created with this user policy.
Theme. We accepted the default theme.
Time Zone. We selected the time zone for America/New York. User accounts created with this policy will see date and time values that match the New York time zone.
Additional Organization Memberships. We did not select any additional organizations. Customer care staff does not need to view devices or account information from other organizations in the company.
Privilege Keys. In this pane, we selected several Access Keys. These Access Keys allow users to have basic privileges and to create and view tickets and ticket reports. This allows the user to create tickets and track the status of those tickets.

Click the Save button to save your new user policy.
We can now apply this user policy to new user accounts and existing user accounts.

Example of Creating a User Account with a User Policy

In this example, we'll use the user policy we created previously (Customer_Care) to create a new user account.

The new user is Billy Corgan. He will be a member of the Customer Care group and requires the settings we saved in the user policy named "Customer_Care". Using the Customer_Care user policy will save us time when configuring the user account for Billy Corgan.

To create the new user account using the user policy:

Log in to SL1 as a system administrator. If you have not yet created organizations or user accounts, you can log in as "em7admin", using the password defined during initial configuration.
Go to the User Accounts page (Registry > Accounts > User Accounts).

In the User Accounts page, click the Create button. The Create New Account page appears.

In the Create New Account page, supply the following values in each field:

First Name. The user's name is Billy Corgan, so we supplied "Billy" in this field.
Last Name. We supplied the value "Corgan" in this field.
Generate name based on first and last name. We did not select this checkbox, because our corporate convention is to use first initial and last name as a username. If we have duplicate names, we use first initial, middle initial, and last name as a username.
Account Login Name. We entered "bcorgan" as the user's account login name, as is our corporate convention.
Primary Email. We entered "bcorgan@company.com" as the user's email address.
Password. We entered "Pumpkins1979!!" in this field, to follow best practices when creating a password. This password includes uppercase letters, lowercase letters, numerals, non-alphabetic characters, and cannot be found in a dictionary.
Confirm Password. We entered the user's password again.
Password Strength. We specified the user must have a Strong password.
Password Expiration. We specified that the password will expire in 30 Days.
Password Shadowing. We left this field at its default value - cannot reuse passwords from last year.
Require Password Reset. We did not select this checkbox. The user will not be required to change their password when they first login.
Multi-Factor Auth (MFA) User. We left this field blank, because this user has not enabled Multi-factor authentication.

NOTE: For details on configuring multi-factor authentication, see the section on using multi-factor authentication.

Organization. We selected the organization SILO.
Autosync Time Zone With Local Settings. We selected No.
Account Type. We selected Policy Membership, because we want to use the user policy named "Customer_Care" when creating this user account. After selecting Policy Membership, all the fields in the Individual Properties pane are grayed out, because these fields are among those that are defined in user policies. The fields in the Policy Membership pane became active.
Policy Membership. In this pane, we selected the policy Customer_Care to apply to the new user.

Click the Save button to save the new user account.

The Account Permissions page appears, with all the fields already populated with values from the Create New Account page and the Customer_Care user policy. The fields that are grayed out are those that are inherited from the user policy.