Setting Up Users

A user in SBN is three records, not one: a database login, a personnel record, and a user record under that personnel record. Each is created in a different place, and a user who is missing any one of them cannot work. This module builds a user from nothing, sets the password and session rules that govern the login, and maintains the user afterwards. What a user is allowed to do once logged in is decided by action profiles — the Action Profiles module owns that; this module attaches profiles without explaining how they are built.

How the module progresses

1. Read an existing user and identify its three records.
2. Create the database login.
3. Create the personnel record.
4. Turn the personnel record into an SBN user.
5. Set the password and session rules.
6. Maintain a user: rename, deactivate, delete.
7. Diagnose "I cannot log in".

1. Read an existing user and identify its three records

Task: open a user in Users (#1501), read its settings, and name which of the three records each setting lives in.

The three records.

Users (#1501) reads, it does not create. #1501 carries Get, Change, Print and Force Password Change only. There is no New and no Delete in it. A user is created and deleted in Personnel (#1811); #1501 is the screen you return to afterwards to read and adjust one.

What #1501 shows you. The identity fields come from the personnel record — Name, address, Phone, Country. The rest is the user record: User ID, Action (1) to (10), the Profiles block (Branch, Dealer, Terminal, Misc), Skills, Group, Language, Password Changed, Password Change Interval in days, Password Prompt Interval in minutes, and Last Login.

Language on #1501 is not the interface language. It overrides the installation's own Language for Alarm Log Event Name, O/C Status and O/C Type. The language of menus and labels comes from the personnel record's Language field, read at logon.

Worked example (Branch TRAIN): open #1501 and select TRAIN02. Read its Action (1), its Profiles block and its Last Login. State which of the three records each of those four values belongs to.

Guided practice: open the same user in #1811 — find the personnel record in the master pane, then the Users tab beside it. Name two fields visible in #1811 that #1501 does not show, and one field #1501 shows that comes from the personnel record rather than the user record.

Independent practice: compare TRAIN01 and TRAIN02 in #1501. Name every difference you can see, and for each one say whether it would change what the user may do, what the user may see, or only how the screen looks.

2. Create the database login

Task: create a login on the database server with Add User Login (#564), and say what you have and have not created.

What #564 does. It creates the database login and nothing else. Afterwards the name and password are accepted by the server, but the person still has no personnel record and no user record, so SBN has nothing to log them in as.

The form has two pairs of credentials. The upper pair — User Name and Password — is the login the creation runs under. Fill it when your own login is not allowed to create logins and you have a more privileged one to borrow; leave it empty and the creation runs under your own session. The lower group is the login being created: User Name, then Password entered twice.

The rules the name must satisfy.

The two password fields must match, or the form answers "New passwords do not match". The password field accepts fifteen characters.

Steps:

1. Open #564.
2. Leave the upper User Name and Password empty to run as yourself, or fill them with the login you are borrowing.
3. Type the new login in the lower User Name.
4. Type the password in both Password fields.
5. Save. The confirmation is "Saved data successfully."; the form clears itself for the next login.

#564 is unavailable when the system uses Active Directory authentication. It answers "This feature is unavailable when Active Directory authentication is in use." and closes. On such a system the login already exists in the directory and only the SBN records remain to be made.

The wizard alternative. Add User Wizard (#1844) walks the login, the personnel record and the user record in one pass, ending with a choice of opening the new user in #1811 or adding another. It refuses to start unless you hold both New and Update on Personnel (#1811). Use the wizard for a routine new starter; use #564 with #1811 when you need fields the wizard does not ask for.

Worked example (Branch TRAIN): TRAIN03 already has a login on this server, so create TRAIN04 instead — in #564, leaving the upper credential pair empty, with a password you will remember. Read the confirmation, then attempt to log into SBN as TRAIN04. Say what happens and why it is the expected result at this point.

Guided practice: in #564, try to create a login named Train 05. Read what SBN answers, correct the name until it is accepted, and state the three rules you had to satisfy.

Independent practice: open #1844 and step it as far as the personnel question without finishing it. List the fields the wizard asks for that #564 does not, and say which of the three records each of those fields belongs to.

3. Create the personnel record

Task: create the personnel record that carries the person's identity, and set the language their SBN will run in.

The personnel record is the person, not the login. One person has one personnel record and may appear on several of its tabs — an employee can be an Installer, a Technician and a User at once. The tabs are enabled by the checkboxes on the master record: Installer, Sales Person, User, Telemarketer, Manager, Technician. Tick User and the Users tab applies to this person.

The fields that matter for a user.

Language is a property of the person, not of the workstation. A user whose personnel record says French gets a French SBN on any workstation they log into. Date format, screen layout and grid settings are the opposite: they belong to the workstation and stay behind when the user moves.

Steps:

1. Open #1811.
2. New [F3] in the master pane.
3. Enter Emp ID, Name and Branch.
4. Set Language.
5. Tick User.
6. Save.

Worked example (Branch TRAIN): TRAIN03 has a database login and nothing else. Create its personnel record — Emp ID TRN03, a name of your choosing, Branch TRAIN, Language French, User ticked. Save and confirm the Users tab is now available. Say which of the three records is still missing.

Guided practice: create a second personnel record for TRAIN04 — Emp ID TRN04 — with Language English, and tick User and Technician both. Say what ticking the second box changed on the screen and what it did not change about the login.

Independent practice: without saving anything, open an existing personnel record and work out from the ticked boxes alone which roles that person holds. Then say which single field you would change to give them a French SBN, and where that change takes effect — immediately, at their next login, or at their next password change.

4. Turn the personnel record into an SBN user

Task: create the user record on the Users tab of #1811, attach the action profiles, and set the access restrictions.

This is the record that makes the login work. Until it exists, the database accepts the name and password and SBN has nothing to open.

The fields, by what they do.

Two families of profile, and they answer different complaints. Action profiles decide which buttons and programs exist for the user. Restriction profiles decide which installations, dealers and alarms appear inside them. "The button is greyed out" is an action profile; "the installation is not in the search results" is a restriction profile.

Creating a user requires the Change right on this tab. SBN checks that one of your own action profiles carries Personnel 1811/032 before it will save a new user, and Personnel 1811/034 before it will delete one. Without it the answer is "Sorry, you are not authorized to execute this command."

Steps:

1. In #1811, select the personnel record and open the Users tab.
2. New [F3].
3. Enter User ID — exactly the login name created in #564 — then Emp ID and Name.
4. Set Action (1) to the user's primary action profile; add further profiles in Action (2) onwards only if the role needs them.
5. Set the Branch, Dealer, Terminal and Misc profiles the user is to be restricted by; leave blank for no restriction.
6. Add Skills if the user is to receive alarms.
7. Save.

Worked example (Branch TRAIN): on the TRN03 personnel record, create the user TRAIN03 — Action (1) AC OPER, and the Branch profile covering Branch TRAIN. Save, then log into SBN as TRAIN03 and read the menu you are given.

Guided practice: create the user TRAIN04 on the TRN04 record with Action (1) AC DATA instead. Log in as TRAIN04 on a second session, and name three things TRAIN03 can reach that TRAIN04 cannot, or the reverse.

Independent practice: a colleague reports that a newly created user is refused at the login box with an unknown-login error, while another newly created user gets in but finds every installation search empty. Name which of the three records is wrong in each case, and which program you would open to prove it.

5. Set the password and session rules

Task: set the password intervals, force a password change, and say what the user experiences for each setting.

The two intervals are unrelated.

The prompt interval is a re-authentication at the desk, not a password expiry: the user retypes the password they already have. Set it low on a shared workstation, -1 on a single-occupant one.

Force Password Change. Ticking it on the Users tab makes SBN demand a new password at the user's next login. On systems where the option for it is switched on, every newly created user gets it automatically. Use it whenever you have handed a password to someone in person or over the telephone.

Users change their own password in Change Password (#544). Password Changed on the Users tab and on #1501 is the date they last did, and is the field to read when someone claims they have just changed it.

Concurrent sessions are capped by the Misc profile. The Misc access profile (#1745) carries the maximum number of simultaneous logins for the users assigned to it. Exceed it and the next login is refused with "Max. logins exceeded." — the fix is in #1745 or in getting the user's other session closed, never in the password.

Worked example (Branch TRAIN): on TRAIN03, set Password Change Interval to 1 day and tick Force Password Change. Save, log in as TRAIN03, and complete the change SBN demands. Then read Password Changed on the Users tab.

Guided practice: set TRAIN04's Password Prompt Interval to 0, log in as TRAIN04, and open two programs from the menu. Describe exactly what happened, then set it to -1 and say what a user on a shared desk loses by that change.

Independent practice: a user telephones to say SBN keeps asking for their password although they changed it this morning. Name the two settings that could produce that, the field that tells you whether the change actually happened, and how you would tell the two causes apart without changing anything.

6. Maintain a user: rename, deactivate, delete

Task: rename a user, take one out of service, and know what SBN refuses to delete and why.

Renaming. The Users tab carries New User ID and the personnel master carries New ID. Enter the new name there and save; SBN renames the record and carries its history with it. A new name that is already in use is refused with "New ID in use."

Deactivating is the normal way to remove access. Tick Inactive on the Users tab and the login is refused at the door with "This SBN User login is disabled." The database login, the personnel record and the user's history all survive; tick the box back and the user works again. This is what you do for a leaver, a suspension, or a login that must be parked.

Deleting is the exception, and SBN guards it.

A deleted user leaves its history behind, which is why its name can never be issued to a different person. Undelete restores a deleted user from that history.

Unlock does not work the same way on every server. The Unlock action on the Users tab releases a login that the database server has locked after repeated bad passwords. On a Microsoft SQL Server system the button returns without doing anything, and the unlock has to be done on the database server itself. Establish which kind of server you are on before you promise a user that the button will fix them.

Worked example (Branch TRAIN): tick Inactive on TRAIN03 and save. Attempt to log in as TRAIN03 and read the message. Untick it, save, and log in successfully.

Guided practice: rename TRAIN04 to TRAIN05 using New User ID — the login for that name already exists — then try to rename TRAIN03 to TRAIN05 as well. Read the refusal and say what it tells you about how SBN treats user names over time.

Independent practice: an operator has left the company. Decide whether to deactivate or delete, and defend the decision by naming two things that would be lost or made impossible by the other choice. Then say what you would do differently if the same name had to be given to their replacement.

7. Diagnose "I cannot log in"

Task: given a user who cannot get in, find which record refused, before touching any profile.

Work outwards from the door. Each layer refuses at a different moment and with a different symptom:

1. The database login. Refused at the login box with an unknown-login or bad-password error, before SBN appears. Either #564 was never run, or the name on the Users tab is spelled differently from the login.
2. The user record. The login is accepted and SBN does not open a session. There is no Users tab record for the name, so SBN has no user to be.
3. Inactive. "This SBN User login is disabled." — the box on the Users tab is ticked.
4. Password rules. SBN demands a new password (Force Password Change, or the change interval has elapsed), or re-prompts during the session (prompt interval). The user is in; they are being asked, not refused.
5. Concurrent sessions. "Max. logins exceeded." — the Misc profile cap, not the password. Look for their other session.
6. Everything after this point is not a login problem. The user is in and SBN is refusing something inside it. That is the Action Profiles module's five layers.

The two things to rule out first. A user who has never logged off does not have your change: profiles and menus are read at login. And Last Login on #1501 tells you whether they have logged in since you made the change — read it before you change anything else.

Worked example (Branch TRAIN): create the personnel record and Users-tab record for a user whose database login you have not created, attempt to log in as them, and read where the attempt fails. Then create the login in #564 and log in successfully. Name the layer that refused each time.

Guided practice: tick Inactive on one user and misspell the User ID on another. Attempt both logins, and match each symptom to its layer without looking at the records first.

Independent practice: a user reports "it let me in yesterday and today it says my password is wrong." Walk the layers aloud, name the two that fit the report, and state the single field you would read first to tell them apart — and why that field and not the password.

8. Quick reference

Programs

One-liners: a user is three records and any one of them missing stops them · #1501 cannot create a user · the User ID must equal the database login exactly · logins are upper case, eight characters, letters digits _ and - · a user name is never reused after deletion · deactivate rather than delete · action profiles hide buttons, restriction profiles hide records · Language on the personnel record is the interface, Language on #1501 is alarm and O/C text · the change interval is in days, the prompt interval in minutes and 0 means every program · profiles and menus are read at login.