Set up the initial user IDs

From RiskWiki
Revision as of 13:37, 10 September 2019 by Bishopj (talk | contribs) (Created page with "=Introduction= The final step to setting up a new risk database is to create the initial accounts in the database for system administrators and optionally for selected users....")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

The final step to setting up a new risk database is to create the initial accounts in the database for system administrators and optionally for selected users. Typically a single account is created in the database and this user then creates accounts using the application for all other system users.


If you are installing the single user version of BPC RiskManager in its default configuration, you do not need to do anything in this step and you can therefore skip these instructions.


For BPC RiskManager Enterprise users, there are three ways to do this. We will cover two of them. It is stressed that this information relates ONLY to the initial user(s) or initial bulk user creation. There are far easier ways to create users both in bulk and individually once the initial administration account is installed. For securtiy reasons, BPC RiskManager is shipped without accounts.


OPTION 1 (COMPLEX) – Direct Database Table Update

Versions 6.1.8 and earlier should follow this procedure to create the initial administration acount, or if you are going to create accounts in bulk you may also use this procedure. There is a MUCH simple procedure available for users of V6.1.9 and above (so those users should NOT use this method).

To create an account in the database add a record to tables:

RESOURCES and USERS.

Instructions:

For each database system user replace all text items in angle brackets with user information:
<UserDescription>		User description field.  EG: Jack Smith
<EmailAddress>		Email field; must be unique
<DomainName\Username>	User's Windows account if format:  DomainName\NetworkUsername.  Must be unique.  EG:  domain1\jsmith.
<FirstName>			Optional field
<LastName>			Optional field
INSERT INTO RESOURCES(DESCRIPT, EMAIL, USER_NAME, FIRST_NAME, LAST_NAME)
VALUES('<UserDescription>', '<EmailAddress>', '<DomainName\UserName>', '<FirstName>', '<LastName>');
INSERT INTO USERS(USER_NAME, ACCESS_ALL_AREAS, ASSIGNED_ROLE, AUDITOR_FLAG, ACCESS_ALL_RISK_TYPES)
VALUES('<DomainName\Username>', 1, 'ADMINISTRATOR', 1, 1);


OPTION 2 (SIMPLE) – RootAdmin creation account

If you are following these instructions through step by step...Do nothing at this time! This is the recommended approach.


We do it later during the application server install using a special administration account called "rootadmin". The rootadmin approach will involve creating a dedicated account directly from the application server control interface that can access the system using a normal client and then create other administrators normally within the application. Those new administrators can then revoke the rootadmin's access rights if desired.


If you are using any security model that relies on the operating system security (eg. LDAP or NT Groups) you will need to dedicate an operating systems level user id to be the rootadmin user. The account could be Administrator under windows – as this should never be used to access the application anyway, or some throw-away low level user account.


Security modes "Application Managed Access" (where the application requires its own login and handles security) or "Always Use Selected Group" do not require an operating systems account to be assigned to the rootadmin role.


Within the operating system, the rootadmin account does not need to have any special rights other than access to the BPC RiskManager client once (to create the real application administrators). Once other application administrators have been created, you can revoke the access rights of the rootadmin from within the application. Of course, you can also use an account that is intended to be the real SurveyManager administrator account as the rootadmin - there is no security implication from doing this as the rootadmin is no different from any other riskmanager administrator, with the exception that it can be created directly from the application server.


If you aren’t sure – leave it for the moment as we can always fix it later.


If you got to this page other than by following the installation process and are trying to find out how to create user accounts (or you want to see the alternative method of creating initial user id's) follow this link:


BackLinks