Comparison of Communication Manager Administrator Account Management CM3.1 vs. CM4.0

Transcription

1 Comparison of Communication Manager Administrator Account Management CM3.1 vs. CM4.0 Issue 0.0 March 2007

2 Contents 1. Introduction 1 2. Organization 1 3. Reference Material 1 4. CM3.0 and CM4.0 Screen Comparison Adding a Default Super User Login Adding A Default Non-Super-User Login Changing Access Permissions SAT Permissions Web Permissions Changing SAT Access Permissions Comparison Customer Super User Login with Go Shell Permissions Changing Web Access Permission Comparison 7 5. User Account Components 8 6. User Account Creation Overview 9 7. Upgrades Administrator Accounts Primary Group Secondary Group Special Administrator Accounts Remote Logins CDR Logins Eample 13

3 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 eternal service such as LDAP cannot be administered on the CM server. 2. Organization Information is presented in the following order: 1. A side by side comparison is given for screens/forms in CM3.1 and CM4.0 with little background information. 2. Following the side by side comparison, limited background information is provided for logins and profiles. 3. An eample is provided for adding a new login. 3. Reference Material The following white paper describes Communication Manager support for eternal Authentication, Authorization, and Accounting servers such as LDAP. These sections AAA Services SAT Profiles Etended 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, , and Maintenance Commands for Avaya Communication Manager, CM3.0 and CM4.0 Screen Comparison The screens in this document were obtained from R and R 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 maimize information readability on a limited page size. Issue 0.0 Communication Without Boundaries 1

4 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 eactly 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 ecepted. The web page access in both cases is also identical, again with differences due to different releases ecepted. 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

5 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

6 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 eist for the permissions to be configured for the profile within the application 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 may be used; The "list user-profiles" SAT form may be used to see 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 Web Permissions Figure 3. CM4.0 Duplicate User-Profile SAT form Page 1 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

7 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 bo net to the new profile to edit and click change and then edit permissions by unchecking boes as desired. Figure 4. Creating a New Web Access Mask Issue 0.0 Communication Without Boundaries 5

8 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

9 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 eample, reading from the table, an "r" net 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 w Maintenance (m) add busyout campon-busyout cancel change clear disable display duplicate enable erase SAT Command Administration r w Maintenance (m) get go list mark monitor netstat notify ping recycle refresh release SAT Command Administration r w Maintenance (m) remove reset resume rp save set status test trace-route upload wp 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 Linu groups, susers or users. In CM4.0 web access is further constrained by a web access mask as illustrated in section on page 4. Issue 0.0 Communication Without Boundaries 7

10 5. User Account Components A user account on a Communication Manager server requires 4 components: 1. A user name 2. Membership in a primary Linu Group (See section 8.1 on page 10) 3. 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 Linu Group known as a profile group (See section 8.2 on page 11). 4. 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 Linu password and group files contain /etc/passwd /etc/shadow /etc/group Linu PAM user name, role 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 permissions 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

11 called CM, not to be confused with the platform or product which is also called CM. Referring to the figure, a web > swversion USE A CLI COMMAND add station net USE A SAT FORM change user-profile Manage SAT Permissions Shell Application ID, group Linu PAM ID, Profile # profile # Add Login: /etc/passwd /etc/shadow /etc/group ID, group, profile # TS Application permissions XLN ID, Group # Web Application profile # permissions Administrator Logins Web page MANAGE LOGINS Web Mask Page MANAGE WEB MASKS Each Web Page USE A WEB PAGE Figure 7. Applications, Profiles and Logins Overview interface is provided to create logins in Linu 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. 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. 2. Using the business roles defined in step 1, eamine 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 eporting the profiles. The resulting file can be imported into a spread sheet where permissions can be compared side-by-side. Similarly, eamine the web access mask web page and determine which pages each profile needs access to. Issue 0.0 Communication Without Boundaries 9

12 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 tet file in the EXACT format of the eport 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 eample, 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 eternal 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 Linu 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 eamines 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 CM 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 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. A user name: A user name is the same as a login name is the same as an ID or login ID. 2. Primary Group: All logins must be members of at least one Linu 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 Linu CLI "id" command. 3. 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 Linu CLI "id" command. 8.1 Primary Group Membership in a primary Linu group controls access permissions for the account in the Linu 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

13 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 epanded 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 Linu 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 Numbers 0-17 are special profiles that customer logins cannot use. The profile number is obtained from the Linu group number by subtracting 10,000 from the group number. Thus, Linu group numbers 10,000 through 10,069 1 correspond to user profiles (masks) The base number (10,000) can be changed by the customer via the server web pages. Issue 0.0 Communication Without Boundaries 11

14 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 eceptions. 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 eists 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

15 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 eist prior to CM4.0. Figure 10. CDR Login 10. Eample This section contains a specific eample 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 ecept 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

16 1. 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 Linu group number you want, a number between and You choose 10020, because that is the Linu 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. Eecute "tail /etc/group", and you'll something similar to this: init@labsrvr1> tail /etc/group prof0::10000:init prof1::10001:inads prof2::10002:dadmin prof3::10003:craft prof17::10017:acpsnmp prof18::10018:custsuper prof19::10019: prof20::10020: Note that prof20 appears in the /etc/group file but that no logins are members of this group (yet). 2. 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. Eecute "tail /etc/group", and you'll something similar to this: init@labsrvr1> tail /etc/group prof0::10000:init prof1::10001:inads Issue 0.0 Communication Without Boundaries 14

17 prof2::10002:dadmin prof3::10003:craft prof17::10017:acpsnmp prof18::10018:custsuper prof19::10019: prof20::10020:rick Notice that the login "rick" is now a member of group prof20. Now while still in your BASH session, eecute "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 Linu group 555, which is the susers Linu group. You can also grep the /etc/passwd file for rick to see home directory and shell assignment. 3. 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" bo, select "Create by copying values from Access Mask number" radio button and enter 18 in the bo (i.e., customer super user web permissions). Note that profile or role numbers are being entered. The 20 corresponds to profile group 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 eisting web masks, but now mask 20 appears under "User-defined Access Masks and Names". At the moment mask 20 is an eact 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 bo for user defined profile 20, and then click on "change". e. Enter a name for web access mask 20 in the bo to the right of 20 at the top of the page. Enter "Customer Super user Without Server Config or Adjuncts" in the bo; uncheck "Configure Server" and "Restore Defaults" in the column of boes for access mask 20, and then click "submit" at the bottom of the form. This mask gives rick all the super user Web capabilities ecept 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" net 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 ecept 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". 4. Define SAT permissions for rick You now have created a fully-defined Web and BASH login called "rick" which is in Linu group 555 and profile and which has standard super user permissions in the Web, ecept 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 net. 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". Issue 0.0 Communication Without Boundaries 15

18 a. Now login as "init" or a customer super user login in an ssh BASH session, and eecute "SAT". b. Eecute "list user-profiles", and confirm that only the default profiles eist. The SAT display will show information similar to this: list user-profiles USER PROFILES Etended 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. Eecute "add user-profile 20" in the SAT d. In the "User Profile Name" field, enter, "Cust super-user no server config no adjunct". e. Enter "y" in "Facility Test Call Notification?", "Shell Access?", "Acknowledgement Required?". f. Enter "y" in every field in the "Enbl" fields on page 1 of the form ecept the Adjuncts field. Enter a "n" in the Adjuncts field. g. submit the SAT form. h. Eecute "save translations" i. 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. j. Eecute "list user-profiles", and confirm that profile 20 appears: Issue 0.0 Communication Without Boundaries 16

19 Glossary AAA Authentication, Authorization and Accounting CD Compact Disk CM Communication Manager FTP File Transfer Protocol. A non-secure protocol for file transfer (RFC 0959, STD0009) LDAP Lightweight Directory Access Protocol (RFC 2251) Local Host Account A user login account for which all AAA information is maintained on the same server the user is logging in to. Microsoft Active Directory A Microsoft implementation of LDAP PAM Pluggable Authentication Module PAM Application A software module that has been enhanced to interact directly with the Linu PAM subsystem PC Personal Computer PPP Point to Point Protocol RADIUS Remote Authentication Dial In User Service (RFC 2865) RFC Request for Comment. An Internet standard RSA SecurID A token based authentication mechanism from RSA Security SASL Simple Authentication and Security Layer (RFC 2222) SAT Communication Manager System Administration Terminal interface SSH Secure Shell. A protocol for secure remote login and other secured network services over an insecure network. (RFC 4251) SafeWord A token based authentication mechanism from Secure Computing Sun ONE Sun ONE (Sun Open Net Environment) is a marketing strategy and set of products from Sun Microsystems. Telnet A non-secure protocol for interfacing terminal oriented processes to each other (RFC 855, STD0008) ASG Access Security Gateway. A one-time-password implementation proprietary to Avaya. Cron A process provided by Linu to run jobs periodically NSCD Name Service Caching Daemon. A daemon that provides a cache for user variables obtained via name service requests. NSS Name Service Switch. A module to obtain/search-for user authorization variables from an order list of databases. SU Substitute User. A command to allow one to run a shell as another user/group SUDO 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. Tripwire An auditing program that monitors for file changes. VSFTP Very Secure File Transfer Protocol. A secure version of FTP. Issue 0.0 Communication Without Boundaries 17