Comparison of
Communication Manager
Administrator Account Management
CM3.1 vs. CM4.0
Issue 0.0
March 2007
Contents
1. Introduction
2. Organization
3. Reference Material
4. CM3.0 and CM4.0 Screen Comparison
4.1 Adding a Default Super User Login
4.2 Adding A Default Non-Super-User Login
4.3 Changing Access Permissions
4.3.1 SAT Permissions
4.3.2 Web Permissions
4.4 Changing SAT Access Permissions Comparison
4.5 Customer Super User Login with Go Shell Permissions
4.6 Changing Web Access Permission Comparison
5. User Account Components
6. User Account Creation Overview
7. Upgrades
8. Administrator Accounts
8.1 Primary Group
8.2 Secondary Group
9. Special Administrator Accounts
9.1 Remote Logins
9.2 CDR Logins
10. Example
1
1
1
1
2
3
3
4
4
6
7
7
8
9
10
10
10
11
12
12
12
13
1. Introduction
This document contains an abbreviated comparison of the process for adding a local host administrator login and
setting its access permissions in Communication Manager (CM) Release 4.0 (CM4.0) with adding the same login in
CM3.0.
This material is intended as a sort of "cheat-sheet" only. Full descriptions of screens and fields are provided in the
documents referenced in section 3.
Local host logins are those logins whose entire account profile is maintained on the same server where the login occurs.
Only processes for local host logins are provided; logins authenticated by an external service such as LDAP cannot be
administered on the CM server.
2. Organization
Information is presented in the following order:
1.
2.
3.
A side by side comparison is given for screens/forms in CM3.1 and CM4.0 with little background information.
Following the side by side comparison, limited background information is provided for logins and profiles.
An example is provided for adding a new login.
3. Reference Material
The following white paper describes Communication Manager support for external Authentication, Authorization,
and Accounting servers such as LDAP.
• http://support.avaya.com/elmodocs2/white_papers/CM_Administrator_Logins.pdf
These sections
• AAA Services
• SAT Profiles
• Extended profiles
• Profile access to restricted objects
• Administrative logins
• CDR logins
• Business Partner login: dadmin• Remote logins
• Recommended procedure for adding web profiles
in the following documents provide a much more thorough description of this material.
• Feature Description and Implementation for Avaya Communication Manager, 555-245-205, and
• Maintenance Commands for Avaya Communication Manager, 03-300431
4. CM3.0 and CM4.0 Screen Comparison
The screens in this document were obtained from R013x.01.3.640.2 and R014x.00.0.730.5. Some differences may
appear on other builds. Note also that pictures of web screens were cropped to show only the data portion of the
screen, omitting the menus and frames. This was done to maximize information readability on a limited page size.
Issue 0.0
Communication Without Boundaries
1
4.1 Adding a Default Super User Login
Figure 1 contains a side-by-side comparison for adding a customer super user login taking all default settings in CM3.1 with CM4.0. In CM3.1 this action is done via
the Communication Manager SAT interface. In CM4.0 the same action is done via the server web pages. If the SAT form shown in the figure is submitted with all default
values, the login will have access to all SAT forms that a customer login may have; by default, the login will NOT have access to the "go shell" command in the SAT. If
the web form is submitted as shown, the login will have EXACTLY these same permissions. In both cases, the user will have access to the shell via port 22 (ssh) but not
via the SAT "go shell". That is, the CM3.1 login screen field, "Shell Access ?" only governs the "go shell" command. It does not govern shell access via port 22.
CM 3.1 SAT form
Figure 1. Adding a Super User Login
CM 4.0 web page (cropped)
The permissions for profile 18 in CM4.0 exactly match the default permissions for the customer super user login in CM3.1. The SAT screens available to the login in
CM3.1 are the same screens available to the login in CM4.0 with differences due to different releases excepted. The web page access in both cases is also identical, again
with differences due to different releases excepted.
There is no other administration that needs to be done to add a default super user login; one screen is required in each case. If "go shell" access is desired, a custom
user profile must be created as described section 4.3 on page 3.
Issue 0.0
Communication Without Boundaries
2
4.2 Adding A Default Non-Super-User Login
Figure 2 contains a side-by-side comparison for adding a customer non-super-user login taking all default permissions in CM3.1 with CM4.0. In CM3.1 this action is
done via the Communication Manager SAT interface. In CM4.0 the same action is done via the server web pages. This user will NOT have access to ANY SAT forms
in both cases, but will have access to a subset of the web screens in both cases. See also figure 8 on page 11.
CM3.1 SAT Form
Figure 2. Adding a Default Non-Super-User Login
CM4.0 Web Page (Cropped)
In both cases only one screen is needed to create the login. In both cases additional work is required to give this user SAT access.
4.3 Changing Access Permissions
Beginning in CM4.0, the ability for the customer to specify access permissions for individual logins has increased greatly. As a result, the number of screens involved has
increased from basically a single SAT screen in CM3.1 to over 40 SAT screens plus several web pages in CM4.0. These additional screens are required in order to be
able to specify permissions for every single SAT form and every web form individually. Fortunately, permissions are associated with profiles and not logins; multiple
logins can be assigned the same profile if desired. Additionally, permissions for profiles are generally established to match business process needs and do not change as
Issue 0.0
Communication Without Boundaries
3
frequently as logins. The access permissions for profiles 18 and 19 cannot be changed. A new profile must be created first. This new profile can be duplicated from profile
18 or 19 or created new. This step has no parallel in CM3.1 because CM3.1 does not have as rich a capability for permission administration as does CM4.0 in either
the web interface or the SAT interface.
The permissions associated with a profile are specific to an application. CM4.0 has two such applications, the Communication Manager SAT interface and the server
web interface. Permissions for each application must be defined separately. Permissions can be defined independently from logins -- no login using the profile need
exist for the permissions to be configured for the profile within the application.
4.3.1 SAT Permissions
Since permissions for profiles 18 and 19 cannot be changed, a new profile must first be created if different permissions are desired. Figure 3 illustrates a "duplicate
user-profile 18" SAT command form. When creating a new profile, any unused profile number 20-69 may be used; The "list user-profiles" SAT form may be used to see
Figure 3. CM4.0 Duplicate User-Profile SAT form Page 1
which profiles have permissions assigned for access to the CM SAT. The form shown in figure 3 (41 pages) can then be used to precisely define the permissions for SAT
access for the new profile as described in the Feature Description and Implementation for Avaya Communication Manager Manual.
4.3.2 Web Permissions
Profiles for access to server web pages are named "access masks" rather than profiles to emphasize the fact that there is an interaction with primary group (users, susers)
membership and web pages access. A login with web page access must be assigned to either the users or susers group. A web access mask can only be used to REDUCE
access permissions for users or susers. Because of this, it is best to create new web masks by copying either mask 18 or 19. Copy mask 18 when the access mask will be
used by logins assigned the primary group susers, and copy mask 19 when the access mask will be used by logins assigned to group users. Figure 4 illustrates how to copy
Issue 0.0
Communication Without Boundaries
4
mask 18 to a new mask and then edit its permissions.
Step 1: Click add to
add a new mask
Step 2: Enter new mask number
and mask to copy from, then click
submit.
Step 3:Click the box next
to the new profile to edit
and click change and
then edit permissions by
unchecking boxes as
desired.
Figure 4. Creating a New Web Access Mask
Issue 0.0
Communication Without Boundaries
5
4.4 Changing SAT Access Permissions Comparison
Figure 5 contains a side-by-side comparison for changing access permissions for the Communication Manager SAT in CM3.1 and CM4.0. In CM3.1 permissions are
Change SAT Permissions for a Login in CM3.1
Change Profile Permissions in CM4.0
Figure 5. Changing Access Permissions for the SAT
associated with logins and the ability to change permissions is very limited. If the field, "Additional Restrictions" on the first page of the CM3.1 "change Permissions"
Issue 0.0
Communication Without Boundaries
6
form is set to yes (y), then two additional pages become available to add the names of up to 40 SAT forms that user may NOT use. In CM4.0, permissions are NOT
assigned to logins. Permissions are assigned to a profile and the user is in turn assigned a profile and thus inherits the permissions of the profile. Multiple users may be
assigned the same profile and thus the same access permissions. Permissions must be set for every SAT form in CM. Additionally, permissions are set independently for
read, write and maintenance access. Read/write and maintenance permissions are somewhat new concepts in CM4.0. Table 1 cross references the SAT commands
associated with each operation. For example, reading from the table, an "r" next to a SAT form’s name in figure 5 for CM4.0 means that a user assigned that profile can
use the display, get, list, monitor, notify, status and upload commands AS THEY APPLY to the particular form whose access permissions are being set. A dash (-) in the
permissions field indicates the profile has no access to the corresponding SAT form. Write implies the ability to view and change administration values whereas read
implies the ability to view but not change values.
Table 1. SAT Command Permissions
SAT
Command
Administration
r
add
w
Maintenance
(m)
x
SAT
Command
get
busyout
x
go
campon-busyout
x
list
cancel
x
mark
change
x
clear
x
disable
display
duplicate
x
netstat
x
notify
r
w
Maintenance
(m)
x
x
x
remove
x
reset
x
x
x
x
x
Administration Maintenance
(m)
r
w
x
x
resume
x
rp
x
save
x
x
SAT
Command
x
x
set
x
status
x
x
x
x
ping
x
test
x
x
recycle
x
trace-route
x
enable
erase
monitor
x
Administration
x
x
refresh
release
x
upload
x
wp
x
x
4.5 Customer Super User Login with Go Shell Permissions
SAT profile 18 does not permit access to the "go shell" SAT command in keeping with the default configuration for a "super-user" login. If "go shell" access is desired for
a login that would otherwise be assigned to profile 18, a new profile must be created by copying profile 18 and then enabling "go shell" access.
4.6 Changing Web Access Permission Comparison
In releases prior to CM4.0, web access was controlled simply by membership in one of two Linux groups, susers or users. In CM4.0 web access is further constrained by
a web access mask as illustrated in section 4.3.2 on page 4.
Issue 0.0
Communication Without Boundaries
7
5. User Account Components
A user account on a Communication Manager server requires 4 components:
1.
2.
3.
4.
A user name
Membership in a primary Linux Group (See section 8.1 on page 10)
Optionally, assignment to a role for role based access to server applications such as the SAT
interface or server web pages. A role is assigned by adding the account as a member of an
additional, secondary Linux Group known as a profile group (See section 8.2 on page 11).
If a role is assigned, then permissions associated with a role within each application that
defines role based access.
Figure 6 illustrates the relationship between these components. The standard Linux password and group files contain
Linux PAM
/etc/passwd
/etc/shadow
/etc/group
user name, ro
le
Application’s interface
to use the application
Application’s interface
to administer its
permissions
profile
#
user name, group
membership stored
here.
Identifiers passed to
application on each use
Application
permissio
ns
Figure 6. Account Components
application
permissions
stored here.
the user name and group membership. When an application is started, these parameters are retrieved by the
application. Inside the application, the user’s group membership is used to select a profile within the application; this
profile contains the permissions within the application for that role.
Figure 7 shows a more complete picture with 3 common Communication Manager server applications, the Command
Line Interface (CLI), the Web Interface, and the application that provides telephony services (TS), sometimes also just
Issue 0.0
Communication Without Boundaries
8
called CM, not to be confused with the platform or product which is also called CM. Referring to the figure, a web
add station next
USE A SAT FORM
> swversion
change user-profile
Manage SAT Permissions
USE A CLI COMMAND
Shell Application
ofile #
ID, Pr
ID,
gro
Linux PAM
up
profile
#
/etc/passwd
/etc/shadow
/etc/group
ID
,g
Add Login:
ID, Group #
TS Application
ro
u
p,
pr
of i
le
permissio
ns
XLN
#
Web Application
#
file
pro
issio
perm
Administrator Logins Web page
MANAGE LOGINS
ns
Each Web Page
USE A WEB PAGE
Web Mask Page
MANAGE WEB MASKS
Figure 7. Applications, Profiles and Logins Overview
interface is provided to create logins in Linux and assign those logins to groups. A separate web interface is provided
to assign web permissions within the web application. SAT forms are used to define permissions within the SAT as
already described.
6. User Account Creation Overview
Customer user accounts for a new system are created using the following process:
1.
2.
Issue 0.0
Analyze the business needs and policies of the enterprise and define the access roles that will be necessary.
This is a very important step and omitting it will cause unnecessary changes and likely a good deal of confusion later. One business might be satisfied with a single role that will be able to perform all administration
activities. Another business might require separation of duties such as a station administrator, a trunk administrator, a server administrator, a maintenance role with global access, an auditor, a backup operator, etc.
Using the business roles defined in step 1, examine the user-profile SAT form and assign access to SAT
forms for each role. This might be done by first creating a new SAT user profile by copying profile 18, and
then exporting the profiles. The resulting file can be imported into a spread sheet where permissions can be
compared side-by-side. Similarly, examine the web access mask web page and determine which pages each
profile needs access to.
Communication Without Boundaries
9
3.
Using the super user login created during installation, create new user-profiles in the SAT based on the
above analysis. If a spread sheet was used, it may be saved as a text file in the EXACT format of the export file
and then re-imported to CM. Similarly, create a parallel set of web masks for each SAT profile setting permissions appropriate to the role.
IMPORTANT: A user can be assigned only one user-profile. For example, lets say a user is assigned profile 22. If that
user attempts to access the SAT, that user will be able to access whatever SAT forms are allowed for profile 22. If that
same user attempts to access the server web pages, the user will have access to those pages permitted by web access mask
22. It is important to understand that all applications use the same profile number, but each application must define
its own permissions for that number.
The above steps apply regardless of how or where individual logins are authenticated. These steps apply equally to local
host logins and to logins processed in external AAA servers such as LDAP. What has been accomplished in the first 3
steps is simply to assign permissions to user profiles and web access masks according to the roles defined for the
business.
4.
Using the super user login created during installation, create the needed local host logins using the server
administrator accounts web page, assigning membership in primary and secondary Linux groups as described
in the following sections.
7. Upgrades
When a system is upgraded to CM4.0 from an earlier release, the upgrade software automatically creates user profiles
and web access masks when CM translations are loaded the first time. In releases prior to CM4.0, CM maintained
permissions associated with logins. During the upgrade CM examines the permissions for each login. If the login is a
super user login and has all default permissions, then the login is assigned profile 18 in CM4.0. Similarly, if the login
is a non-super-user login and still has all default permissions, it is assigned profile 19 in CM4.0.1 If a login has
permissions other than defaults, then a new profile is created automatically and its permissions set to match the
permissions in the earlier release. A new web access mask is also created. If the login is a super user login, then the new
web access mask will be a copy of mask 18. If the login is a non-super-user login, the mask will be a copy of mask 19.
8. Administrator Accounts
This section will describe the most frequently used administrator accounts on a Communication Manager server.
There are other special accounts that will be described beginning in section 9 on page 12.
An administrator account requires the following components:
1.
2.
3.
A user name: A user name is the same as a login name is the same as an ID or login ID.
Primary Group: All logins must be members of at least one Linux group, which we note as a primary group.
This group is identified as "login group" on the web page for creating logins. The primary group is identified
as "gid" in the Linux CLI "id" command.
Secondary or Profile Group: Logins which access certain applications (CM or server web pages), must also be
a member of a second group. This group is identified as "other groups" on the web page for creating logins
and is identified as "groups" in the Linux CLI "id" command.
8.1 Primary Group
Membership in a primary Linux group controls access permissions for the account in the Linux shell (bash) and also
influences access to some web pages. Two login groups are important to the most frequently used type of administrator
logins, groups susers and users.
In CM3.1 and earlier releases, membership in susers corresponds to customer-super-user logins and grants as much
access as is possible for a customer login. Membership in users corresponds to a non-super-user login with very
1. This would be very rare since a non-super-user in release prior to CM40 has no SAT access unless permissions are changed.
Issue 0.0
Communication Without Boundaries
10
constrained access. In particular, the number of web pages that an suser login can see is very limited. Figure 8A
illustrates a portion of the web menu for an suser login and figure 8B illustrates the entire menu for a user login. In
(B) users Menu
Figure 8. Web Menus in CM3.1
(B) susers Menu
earlier releases, the users menu was even more restricted, but was expanded to satisfy needs for certain large customers.
In CM4.0 membership in a primary group does not affect SAT access at all. However, underlying code implementation
still restricts access to certain web objects based on this membership. For this reason, the advice is given that when
creating a new web mask, (1) a user is assigned to either group susers or users and then (2) the new mask is formed by
copying either mask 18 (susers) or mask 19 (users) and then REDUCING the permissions in the new mask. Not
following this procedure can result in a web mask that won’t grant the desired access.
8.2 Secondary Group
Membership in a secondary Linux group is not used prior to CM4.0. Beginning in CM4.0, membership in the
secondary or profile group associates the login with a set of permissions in the SAT and in the web pages within the
constraints described in the previous sections.
A user’s profile (or mask) is a number in the range 0-69. Numbers 0-17 are special profiles that customer logins cannot
use. The profile number is obtained from the Linux group number by subtracting 10,000 from the group number.
Thus, Linux group numbers 10,000 through 10,0691 correspond to user profiles (masks) 0-69.
1. The base number (10,000) can be changed by the customer via the server web pages.
Issue 0.0
Communication Without Boundaries
11
Note Carefully! Membership in a profile group is necessary but not sufficient for access to server web pages or the SAT.
Permissions must be assigned to the profile within each application as already illustrated.
9. Special Administrator Accounts
There are two special logins that are not used to access the SAT or the server web pages. The first special type of login
is used to access the server via its modem, and the second is used by CDR collector units to retrieve CDR records
stored on the CM server disk.
9.1 Remote Logins
When the CM server is accessed via its modem, a PPP connection is established between the user’s device and the
Communication Manager server. A separate login must be used to first establish the PPP connection. Once this
connection is established, an SSH or web session can then be established over the PPP connection using one of the
logins described in section 8 on page 10. Remote logins are created in the same way as other logins with the following
exceptions. See figure 9. On the Administrator Logins web page, under shell access, select "remote login". Selecting
this entry will "gray out" the login group and additional groups entry. The primary login group will be forced to be
"remote" and cannot be changed. Other fields on the page, e.g. password, may be entered normally. In releases prior
to CM4.0 this was accomplished in the SAT "add login" form by specifying the service level as "remote" instead of
super-user or non-super-user. This SAT form no longer exists in CM4.0 and the web page must be used.
Figure 9. Remote Logins
9.2 CDR Logins
To create a login used to access CDR records, use the Administrator Logins web page (figure 10) and make entries as
follows:
Issue 0.0
Communication Without Boundaries
12
•
•
•
•
Login Group = CDR_User
Additional Groups =
Shell Access = CDR Access Only.
Other fields may be used normally.
Leave the "Additional Groups" field blank.
The CDR feature using this login did not exist prior to CM4.0.
Figure 10. CDR Login
10. Example
This section contains a specific example to illustrate the mechanics of creating administrator logins.
Suppose that:
• You have just finished installing a new system (This was not an upgrade).
• You want to create a new super user login called "rick", that has a two less Maintenance Web Interface permissions than your typical customer super user login: you don't want rick to be able to do
"Configure Server" or "Restore Defaults" under the Server Configuration menu section.
• You want rick to have all the SAT permissions that a customer super user login may have except you
don’t want rick to be able to access any SAT forms related to adjuncts.
• Also, suppose it's to be the first new profile created after the server install. The first available
user-definable profile (i.e., a profile to implement rick's role) is 20, so you'll create profile 20.
Here's how you add the login:
Issue 0.0
Communication Without Boundaries
13
1.
2.
Issue 0.0
Create the profile group for profile 20.
a. Login to the Maintenance Web Interface as "init" or as a customer super user login, such as the one
created during the system install.
b. Select Administrator Accounts and then fill in the group name "prof20" in the "Enter Login ID or
Group Name " field. You could enter most anything here, e.g., "profile20", "nosrvconfig", "mugclub",
"ricksgroup", etc. The name is just a label, and is pretty much arbitrary. It is primarily used for display or for easy identification by switch administrators. (Note: there is an advantage to the "profXX"
naming convention if you ever want to change the profile base number, i.e., 10,000, to something
else, but that doesn't concern us right now. By choosing prof20, we can use that capability later in
any case.)
c. Now select "Add login group" and click "submit".
d. Enter the Linux group number you want, a number between 10020 and 10069. You choose 10020,
because that is the Linux group number for profile 20. Click on "add", and confirm that the success
completion message appears.
Internal effects: The following procedures can be used to see the internal effect of the above steps:
• Login on the same server to port 22 (ssh) as "init" or a customer super user login.
• Execute "tail /etc/group", and you'll something similar to this:
init@labsrvr1> tail /etc/group
prof0:x:10000:init
prof1:x:10001:inads
prof2:x:10002:dadmin
prof3:x:10003:craft
prof17:x:10017:acpsnmp
prof18:x:10018:custsuper
prof19:x:10019:
prof20:x:10020:
• Note that prof20 appears in the /etc/group file but that no logins are members of this group
(yet).
Create the Login "rick" and assign groups
a. In the Web interface, select Administrator Accounts.
b. Enter "rick" in the "Enter Login ID or Group Name " field, select "Add Login" and click "submit".
c. Fill in fields on the Add Login form as follows:
• login group = susers
• additional groups = prof20 or 10020, either works and is a matter of preference
• shell access = select standard shell access (This allows access to port 22 via SSH. It has no
effect on access to the "go shell" command from the SAT.)
• Select password authentication and enter a password.
d. Click "add".
Internal effects: The following procedures can be used to see the internal effect of the above steps:
• Login on the same server to port 22 (ssh) as "init" or a customer super user login.
• Execute "tail /etc/group", and you'll something similar to this:
init@labsrvr1> tail /etc/group
prof0:x:10000:init
prof1:x:10001:inads
Communication Without Boundaries
14
3.
4.
Issue 0.0
prof2:x:10002:dadmin
prof3:x:10003:craft
prof17:x:10017:acpsnmp
prof18:x:10018:custsuper
prof19:x:10019:
prof20:x:10020:rick
• Notice that the login "rick" is now a member of group prof20.
• Now while still in your BASH session, execute "id rick", and you'll see something similar to
this:
init@labsrvr1> id rick
uid=1002(rick) gid=555(susers) groups=555(susers),10020(prof20)
• Note that rick is in Linux group 555, which is the susers Linux group.
• You can also grep the /etc/passwd file for rick to see home directory and shell assignment.
Define web permissions for login rick
a. In the Web interface, select Web Access Mask.
b. Click on "add". Enter 20 in the "Enter New Access Mask Number" box, select "Create by copying values from Access Mask number" radio button and enter 18 in the box (i.e., customer super user web
permissions). Note that profile or role numbers are being entered. The 20 corresponds to profile
group 10020 or prof20 that was created above.
c. Click "submit". We're creating mask 20 by cloning mask 18, and we'll then remove the desired capabilities selectively from mask 20. You are returned to the web page displaying the existing web masks,
but now mask 20 appears under "User-defined Access Masks and Names". At the moment mask 20 is
an exact copy of mask 18 from which it was copied. This mask is fully usable at this point, but we
want to reduce its permissions.
d. Click on the box for user defined profile 20, and then click on "change".
e. Enter a name for web access mask 20 in the box to the right of 20 at the top of the page. Enter "Customer Super user Without Server Config or Adjuncts" in the box; uncheck "Configure Server" and
"Restore Defaults" in the column of boxes for access mask 20, and then click "submit" at the bottom
of the form.
This mask gives rick all the super user Web capabilities except Configure Server and Restore
Defaults. Those two choices will not be available when the rick login access the Maintenance Web
Interface. Note that Access Mask 20 now has the label, "Customer Super user Without Server Config or Adjuncts" next to it. This tactic makes it easier for administrators to determine what roles profiles actually implement. (We have not defined SAT permissions for rick just yet.)
f. Open a new Maintenance Web Interface session, logging in as rick. Confirm that all the menus
appear on the left side of the frame except for those under "Server Configuration". Only one option
appears there: "Eject CD-ROM". The rick login has no access to "Configure Server" or "Restore
Defaults".
Define SAT permissions for rick
• You now have created a fully-defined Web and BASH login called "rick" which is in Linux group 555
and profile 10020 and which has standard super user permissions in the Web, except for the ability
to configure the server or restore default server configuration. However, the rick login cannot be
used to login to the SAT yet. That comes next.
• Login to port 22 (ssh) as rick and try to use "rick" to login to a SAT, i.e., enter "SAT" in a BASH window, and note that the login attempt immediately fails with the error message, "Access Denied: User
ID/Profile unknown to Communication Manager".
Communication Without Boundaries
15
a.
b.
Now login as "init" or a customer super user login in an ssh BASH session, and execute "SAT".
Execute "list user-profiles", and confirm that only the default profiles exist. The SAT display will
show information similar to this:
list user-profiles
USER PROFILES
Extended
Profile
Profile User Profile Name
0
n
services super-user
1
n
services manager
2
n
business partner
3
n
services
16
n
call center manager
17
n
snmp
18
n
customer super-user
19
n
customer non-super-user
c.
d.
e.
f.
Execute "add user-profile 20" in the SAT
In the "User Profile Name" field, enter, "Cust super-user no server config no adjunct".
Enter "y" in "Facility Test Call Notification?", "Shell Access?", "Acknowledgement Required?".
Enter "y" in every field in the "Enbl" fields on page 1 of the form except the Adjuncts field. Enter a
"n" in the Adjuncts field.
submit the SAT form.
Execute "save translations"
In a new BASH ssh window, login as rick, and launch a SAT session. Confirm that the rick login is
no longer blocked from SAT access.
Execute "list user-profiles", and confirm that profile 20 appears:
g.
h.
i.
j.
Issue 0.0
Communication Without Boundaries
16
Glossary
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
AAA
CD
CM
FTP
LDAP
Local Host Account
Microsoft Active Directory
PAM
PAM Application
PC
PPP
RADIUS
RFC
RSA SecurID®
SASL
SAT
SSH
SafeWord®
Sun ONE
Telnet
ASG
Cron
NSCD
NSS
SU
SUDO
Tripwire
VSFTP
Issue 0.0
Authentication, Authorization and Accounting
Compact Disk
Communication Manager
File Transfer Protocol. A non-secure protocol for file transfer (RFC 0959, STD0009)
Lightweight Directory Access Protocol (RFC 2251)
A user login account for which all AAA information is maintained on the same
server the user is logging in to.
A Microsoft implementation of LDAP
Pluggable Authentication Module
A software module that has been enhanced to interact directly with the Linux PAM
subsystem
Personal Computer
Point to Point Protocol
Remote Authentication Dial In User Service (RFC 2865)
Request for Comment. An Internet standard
A token based authentication mechanism from RSA Security
Simple Authentication and Security Layer (RFC 2222)
Communication Manager System Administration Terminal interface
Secure Shell. A protocol for secure remote login and other secured network services
over an insecure network. (RFC 4251)
A token based authentication mechanism from Secure Computing
Sun ONE (Sun Open Net Environment) is a marketing strategy and set of products
from Sun Microsystems.
A non-secure protocol for interfacing terminal oriented processes to each other (RFC
855, STD0008)
Access Security Gateway. A one-time-password implementation proprietary to Avaya.
A process provided by Linux to run jobs periodically
Name Service Caching Daemon. A daemon that provides a cache for user variables
obtained via name service requests.
Name Service Switch. A module to obtain/search-for user authorization variables
from an order list of databases.
Substitute User. A command to allow one to run a shell as another user/group
Superuser Do. A command to allow a system administrator to give certain users or
groups of users the ability to run some or all commands as root or as another user.
An auditing program that monitors for file changes.
Very Secure File Transfer Protocol. A secure version of FTP.
Communication Without Boundaries
17