|
|
The AA database stores authentication and authorization information about each user that is allowed access to the network. User configuration information is typically similar between groups of users, so the AA database includes the concept, or feature, of groups. There is also an unknown_user, one that defines the parameters for any user who is not specifically listed in the database. Properly configured, the unknown-user feature can be used to allow users to automatically register themselves on the network.
The AA database implements the following concepts to identify users and enforce restrictions on services:
When authorized users log into your network, they are immediately identified by the AA database as users of a service or a set of services. If you are administering the activity of many users on your network, however, the task of individually assigning all the necessary attributes to each user would be unmanageable.
One way to manage large numbers of users is to group them together according to the services they will use. Using the AA database, you can define each group and authorize it to use the appropriate set of services. You can then add each new user to the appropriate group.
You could restrict access to account information with explicit and implicit group assignments--for example, as follows:
With this kind of implicit and explicit grouping, you can also control the access of users to mission-critical network services. For example, rather than controlling the access to a database, you could control the ability of a user to log into a specified machine.
To further simplify the process of assigning access privileges to users, each group can be a member of some other group. In the above example, the complete sales information group might be a member of another larger group that has access to other services and accounting information.
Such hierarchical grouping can significantly simplify the task of ensuring a secure network in which users have easy access to necessary services and information, but no access to other services, which are unrelated to their jobs. Moreover, you can reliably and easily ensure the security of the entire network regardless of its size or complexity.
As an organization grows, hierarchical grouping of users becomes invaluable to system administrators. This hierarchy has very little value, however, unless it uses inheritance. Inheritance is the ability to assign attributes (such as the authorization to access specific services on a network) to a group or a user by copying attributes from another group or user.
Users and groups inherit attributes from their immediate parent entity, which means that they have the same attributes as the group from which they were derived. Members of the district information group, in the example in the previous section, "Users and Groups," each have all the attributes assigned to that group. If they are not locally known users, they inherit the attributes of the unknown_user group.
The AA database provides a default user from which all users implicitly inherit attributes. Thus, if a user is not explicitly assigned to a particular group, the user inherits the attributes assigned to the default user. Where you explicitly specify attributes for a group, all members of that group inherit those attributes. Where attributes are specified for a user, these attributes supersede any settings that might have been inherited from either a group to which the user belongs or from the default user.
To achieve inheritance, CiscoSecure UNIX Server software first searches the specified user or group. If it does not find the attribute in question, it searches the parent entity. The search continues up the inheritance chain until the attribute is found. If the attribute is not found in the topmost parent, the default values are used (see the section "Implicit Declarations" later in this chapter).
To explicitly define an attribute, you must assign a value to it using an attribute-value pair. An attribute-value pair is a pair of strings of the form attribute=value , for example:
timeout=180
This attribute-value pair specifies a time-out period of three minutes.
The availability of inherited service values can be overridden by prefixing the service specification with the keywords prohibit or permit. Although default permissions exist, you can explicitly prohibit or enable particular services using the prohibit or permit keywords. The permit keyword allows specified services; the prohibit keyword disallows specified services. Using these keywords together, you can construct "everything except" configurations. For example, the following configuration allows access from all services except X.25:
default service = permit prohibit service = x25
One technique you can use to ensure the security of your network is to qualify users when they attempt to log in or request a service. For example, you might know that your organization intends to employ several new people beginning on a particular date. Depending on your needs, you can immediately add these new users to the AA database and specify that they cannot log in until a specified date.
Qualification attributes can be associated with users, groups, and services. If a qualification attribute is found, then its condition must be matched or the operation in progress will fail. The following defined qualification conditions are supported:
See the section The AA Database File later in this chapter for specific examples of using these qualifiers.
Authentication attributes are attributes that are designed specifically to help you modify the network environment of users when they log in. The network environment includes access lists, IP address assignment pools, AppleTalk zone lists, specific route entries, and so forth. Some of the authentication attributes that are available are as follows:
If you set these attributes, their values are returned to the NAS on successful completion of an authentication exchange. These attributes allow system-wide controls to be administered from a central server.
This section describes the format of the AA database. See the appendix "CiscoSecure UNIX Server File Formats and Syntax" for the database grammar and sample files.
Four basic components are defined in the AA database, as follows:
The task of administering a large number of users is simplified by the features of default services and attributes for user and user groups. User groups are useful where many users share the same or similar configuration information.
The format of the AA database is generally name = value. Some values allow additional subparameters to be specified and, in these cases, the subparameters are enclosed in curly braces ({}). Below is a simple example of an AA database showing the default user, one group, two users who belong to the group, and one user who does not:
# Sample AA Database 1
unknown_user = {
password = system #Use the system's password file (/etc/passwd)
}
group = staff {
# password for staff who do not have their own
password = des "sefjkAlM7zybE"
service = shell {
# allow any commands with any attributes
default cmd = permit
default attribute = permit
}
}
user = joe { # joe uses the group password
member = "staff"
}
user = pete { # pete has his own password
member = "staff"
password = des "alkd9Ujiqp2y"
}
user = anita {
# Use the "default" user password mechanism defined above.
service = shell {
cmd = telnet { # allow telnet to any destination
}
}
}
The Unknown _user configuration element specifies the use of the system's password-checking mechanism for authorization verification of any user who is not specifically listed in the AA database. For SunOS, this would involve checking passwords against those in the /etc/passwd file. A group staff has been defined, with a group DES-based password and authorization to use any commands with any arguments. Users joe and pete are both members of the staff group, although pete has his own password. The user anita is not a member of any group and is only authorized to use the Telnet command.
In the absence of a default declaration, the following conditions apply:
In the absence of a specification at the appropriate level, the following default conditions apply:
Circular declarations are not supported and only a single default declaration is allowed.
The most fundamental functions supported by the AA database are those that enable you to group specific authorizations inside relevant service authorizations. For example, the authorization of a Telnet command is expressed as follows:
service = shell {
cmd = telnet {
...
}
}
...
Similarly, protocol authorizations for the Point-to-Point Protocol (PPP) service are explicitly enclosed in the PPP service authorization, as shown in the following example:
service = ppp {
protocol = ip {
...
}
protocol = ncp {
...
}
}
You can set default permissions for services, protocols, and commands. Explicit restrictions are also permitted, allowing the creation of "everything except" configurations, for example:
default service = permit prohibit service = x25 ...
Also, because populations of users and groups are volatile, you can restrict such declarations with start dates and end dates, using a variety of formats, for example:
user = john {
password = file /etc/passwd
valid = "1 Sep 1995"
expires = "September 30 95"
}
When a user or group has expired or is not yet valid, it is as though the relevant declarations were absent. The only exception is that declarations such as the following will not be faulted even when the administrator's group is no longer valid:
member = administrators
Finally, unknown users (in other words, those not specifically listed in the AA database) are managed separately, which allows you to identically administer services and functions for all users, for example as follows:
unknown_user = {
service = shell {
....
}
member = others
default service = deny
}
The AA database allows for mandatory and optional attributes to be defined. You declare attributes as in the following example:
service = shell {
cmd = telnet {
set addr = "192.168.151.20"
set optional timeout = 1200
}
In cases where the AA database is null (because the file is not specified, does not exist, or the database contains no valid declarations), the previously specified authentication and authorization defaults apply.
The following is an example display of an AA database:
# CiscoSecure Example AA Database File
# October 2 1996
#
# Unless otherwise specified, the following are applied:
# default service = deny
# default protocol = deny
# default attribute = deny
# default cmd = deny
#
unknown_user = {
# The default password is the one used by the system (i.e. /etc/passwd)
password = system
set autocmd = "telnet registration-server"
}
group = staff {
password = des "sefjKaLm7zybE"
privilege = clear "operator" 2
}
# The admin group is also a member of 'staff' and can enable to
# privilege level 15 with a DES password (a UNIX encrypted password.)
group = admin {
member = staff
password = des "Aj2pwjbnZlsoh"
privilege = des "sefjKaLm7zybE" 15
}
# Fred uses an 'skey' password, is a member of 'admin', and can do anything.
user = fred {
member = admin
password = skey
password = chap "fred-chap" # Fred's CHAP password
default service = permit
default protocol = permit
default cmd = permit
default attribute = permit
}
# Joy can use any PPP protocol except IPX and can issue any exec command
# except the 'enable' command.
user = joy {
member = staff
password = clear "My ClearText Password"
service = ppp {
default protocol = permit
prohibit protocol = ipx
}
service = shell {
default cmd = permit
prohibit cmd = enable
}
}
# Tom can only run PPP/IP on NAS0 - NAS9, any tty port.
# However, he cannot run IPX on NAS12, any tty port.
user = tom {
service = ppp {
protocol = ip {
allow "nas[0-9]" "tty.*"
}
protocol = ipx {
refuse "nas12" "tty.*"
allow ".*" ".*"
}
# Ralph can run an EXEC, but he falls into the 'default' above,
# which specifies an autocommand. His account is valid after 1 January 1996,
# and expires on 31 December 1996.
user = ralph {
service = shell {
}
valid = "1 Jan 96"
expires = "31 Dec 96"
}
# Frank can only start an EXEC session at night and on weekends.
user = frank {
service = shell {
default cmd = permit
default attribute = permit
time = Any 2300 - 0559
time = Sa, Su 0000 - 2359
}
}
# Joe can run an EXEC, but only for the one year period specified.
user = joe {
service = shell {
# No cmd defaults to EXEC
} from "1 Jan 96" until "31 Dec 96"
}
# Robert can start PPP/IP, but only if his machine uses IP address
# 131.108.12.3, and with the input and output access lists specified.
user = robert {
service = ppp {
protocol = ip {
set addr = 131.108.13.3
set inacl = 103
set outacl = 105
}
}
}
# Anita can run PPP/IP, but gets an address from an IP address
# pool named 'alternet' on the NAS. She may only connect on NAS1,
# any tty port.
user = anita {
service = ppp {
protocol = ip {
set addr-pool = alternet
allow "nas1" "tty.*"
}
}
}
# Sam can use ARAP, which may have an Appletalk access list 601
# applied.
user = sam {
service = arap {
set optional acl = 601
}
}
# Bob can only issue the exec command "show users"
user = bob {
service = shell {
cmd = show {
permit "users"
}
}
}
# Rob can only telnet only to hosts with IP addresses from
# 131.101.13.2 - 131.101.13.254 and issue any 'show' commands.
user = rob {
service = shell {
cmd = telnet {
deny "131\.101\.13\.1"
permit "131\.101\.13\.[0-9]+"
}
cmd = show {
permit ".*"
}
}
}
When users log in, they are identified first on the network access server and then by the CiscoSecure UNIX Server software.
The authentication function uses two keywords, password and privilege. The password keyword specifies the login password for a specific user. In the AA database, there is an entry for each user that contains the user's password, for example as follows:
password = des "sefjKaLm7zybE"
The quoted string is a DES-encrypted password that users must provide before they can log into the network. A previous entry in the AA database identifies users by name. See the section "AA Database" in the appendix "CiscoSecure UNIX Server File Formats and Syntax" for a complete example.
The CiscoSecure UNIX Server software supports 16 privilege levels, which are numbered from 0 through15. The most privileged user, root for example, is a level 15 user; user EXEC is a level 1 user, and level 0 might be reserved for a guest who is only allowed to connect or disconnect.
Privilege levels offer a range of access from guest users to system administrators who are responsible for the network.
Both the password and privilege keywords allow an extensible range of authentication methods, and you can install additional authentication methods by reconfiguring the CiscoSecure server even while the server is running. In addition, authentication methods for PAP, CHAP, and ARA protocol can use the CiscoSecure server.
CiscoSecure UNIX Server software includes the following password support:
You can also configure support for the following recognized authentication methods:
For example, skey is used here as the authentication method for attempts to enable services at level 4:
user = fred {
password = des "sHki4ylq9"
privilege = skey 4
password = arap "my ara secret"
privilege = no_password 1
privilege = clear "it's a secret" 15
password = chap chap.secret
....
}
The privilege keyword specifies the password that users must provide in order to use services of a specified security level, for example as follows:
privilege = des "sefjKaLm7zybE" 3
The quoted string specifies the password that allows this user to enable and use any service that requires a level 3 authorization. The password specified by the privilege keyword is often referred to as the enable password, which means that users must enter this password when they use the enable command to enable a service.
In some cases, you might want to specify a login password that is different from the privilege or enable password. Using different passwords for different security levels is an additional security measure to prevent unauthorized access to mission-critical information.
You can also use inheritance to restrict access to the privilege-level password by making it an attribute of a group and restrict the number of users who can use the privilege password, even if it is widely known. (See the section "Inheritance" earlier in the chapter.)
You can configure password and privilege attributes to expire. For example, the following DES-encrypted password is valid from March 1, 1996 until October 31, 1996:
user = tom {
member = staff
password = des "sefjKaLm7zybE" from "1 March 96" until "31 Oct 96"
}
You can also configure a warning period to alert a user of an impending expiration date whenever the user is authenticated. To do this, you need to add or modify the control file variable "config_warning_period." For example, to configure a ten-day warning period, edit the CiscoSecure control file to include this variable:
NUMBER config_warning_period = 10;
When a user changes his or her password, CiscoSecure keeps the changed password in its internal database and also records it in the file specified by the control file variable "config_update_log_filename." Using the -u command line option or the SIGUSR1 signal to update the AA database will cause the until date to be updated for any user who has changed his or her password. For more information, see the chapter "Using CiscoSecure UNIX Server Software. The new until date will be changed to be the date of the password change plus the number of days specified in the control file variable "config_expiry_period."
Users can change their passwords when they log in.
CiscoSecure requires a privilege level of 1 in a specified user's control file to allow that users to change his or her own password. By default, users log in with a privilege level of 1 so they are able to change their own passwords. When users change their own passwords, they must supply as few as 6 and as many as 13 characters. Of those characters, at least one number and one letter are required. However, as a CiscoSecure administrator, you can assign user passwords of any length or even forego a password requirement all together. As a CiscoSecure administrator, you can also prevent users from changing their own passwords by assigning them a password variable level that is greater than the user's. To assign a new password level, modify the config_priv_level_for_own_CHPASS field in the control file. (See Table 3-1, Variables in Software Control Files, found in the chapter, "Configuring CiscoSecure UNIX Server Software" in the CiscoSecure UNIX Server User Guide publication.)
CiscoSecure UNIX Server software checks passwords when they are changed to make sure that easily guessed or deciphered passwords are not used.
Take the following steps to change a password when logging in:
Step 1 Connect to the network access server.
Step 2 Enter your username at the network access server prompt.
Step 3 Press Return at the prompt requesting you to enter a password.
Step 4 Enter yes at the prompt asking if you want to change your password.
Step 5 Enter your existing password at the prompt.
Step 6 Enter your new password at the prompt.
Step 7 Enter your new password a second time to verify that it is correct.
The password retries variable specifies the number of invalid password attempts a user can make before being faulted. The password retries variable is configured per network access server and is located in the 'config_nas_config' configuration section of the CiscoSecure control file.
This variable must be set to a number greater than 1 for the change password function to work. You can only change the password if you enter a return at the password prompt (thus entering a NULL password).
If the retry-count is set to 1, then the NULL password is counted as the one password entry attempt and you will be disconnected. In addition, the config_priv_level_for_own_CHPASS variable in the control file should be set to 1. This number is the privilege level at which a user can change his or her own password. When someone logs into a router, that user's default level is 1, so if this variable is not set to 1, the user will not be able to change his or her password.
The CiscoSecure UNIX Server software /bin directory contains the CiscoSecure executable files, and a "samples" directory that you can use or adjust according to your needs. The /samples directory contains the files specified in Table 4-1.
The sample control file contains sample software license keys (they have already expired). As such, if you use CiscoSecure UNIX Server software with the sample keys, you will get a "license expired" message. The message indicates how many ports you are licensed to use.
| File | Description |
|---|---|
| control.file | CiscoSecure master control file. |
| aa.database | Example AA1 database, referenced by control.file. |
| msg_cat.1 | Very simple message catalog file, referenced by control.file. |
| left.cfg | Example router configuration file that uses CiscoSecure UNIX Server software. |
| right.cfg | Example router configuration file that uses CiscoSecure UNIX Server software. |
| samples/run_script | CiscoSecure UNIX Server software startup file. |
These files have been used together in a Cisco Systems lab for some simple tests and are a good place to begin your examination of CiscoSecure UNIX Server software. The example router configuration files represent two routers connected to each other by a single serial link. The router, "left," shares an ethernet segment with the CiscoSecure server. While the name of the router is "left," its config file is named "left.cfg."
The S/Key one-time password system from Bellcore provides secure authentication over networks that are subject to eavesdropping. S/Key distinguishes itself from other one-time or multi-use authentication systems by preventing the user's secret password from ever crossing the network during authentication.
To help you better understand the benefits of using S/Key with CiscoSecure UNIX Server software, consider the following example of a hypothetical user, Sue, who authenticates to the CiscoSecure network access server by means of the S/Key system.
User Access Verification
Username: sue
s/key 97 fr09072
Password:
The CiscoSecure server observes that Sue needs to supply an S/Key password.
Based on the verification display, the CiscoSecure server instructed the network access server to display the sequence number, 97, and a seed, fr09072, which will be used by a separate program to initiate the encryption process leading to an S/Key password.
Sue notes the sequence number and seed, then pauses from her interaction with the network access server in order to generate a password. She will generate the password by entering the sequence number and seed, along with her secret password, into an S/Key calculator program.
%key 97 fr09072Enter secret password: <secret password>
The secret password is any string of at least 10 alphanumeric characters generated by Sue, for Sue, and known only by Sue.
CRAG BAKE MOLT JEAN JIBE OFT
The one-time S/Key password is always expressed as a sequence of six short English words. Note how the one-time password is generated without any secret information crossing the network.
This second password will be used to authenticate Sue to the CiscoSecure server. Sue now returns to her interaction with the network access server. She enters the S/Key password and is authenticated, as follows:
Password: <CRAG BAKE MOLT JEAN JIBE OFT>
The sequence number is one less than what was used for the previous authentication. In the case of Sue, her last sequence number was 97, so the next required sequence number will be 96. When the sequence number reaches 0, Sue will not be able to log in without reinitializing the S/Key system.
Sue's account could also be configured so that she is required to use S/Key when she enables on the router. In this case, the AA database would be modified to display something like the following:
user = sue {
password = skey
privilege = skey 15
}
In this case, Sue would be required to give a different S/Key password every time she logs in and every time she enables at level 15.
Take the following steps to prepare for S/Key installation and use:
Step 1 Modify your CiscoSecure UNIX server AA database file to set up each S/Key user. For example, to set up a hypothetical user named Sue, you would modify the CiscoSecure server AA database file as follows:
user = sue {
password = skey
}
Step 2 Restart the CiscoSecure server by entering the UNIX kill command as follows:
kill -HUP `cat /etc/CiscoSecure.pid`
Take the following steps to install the S/Key system on a CiscoSecure server:
Step 1 Log in to the CiscoSecure web site at the following location and download the S/Key one-time password system prebuilt distribution:
ftp://userid@www.cisco.com/cisco/netmgmt/ciscosecure/sunos
Step 2 Unpack the skey-cs.tar file, as follows:
# tar -xvf skey-cs.tar
Step 3 Run the enclosed INSTALL.S_Key script, as follows.
# INSTALL.S_Key
In the next step, each S/Key user will run the keyinit program to initialize the S/Key system for that user. (For the purpose of example, a hypothetical user, Sue, will run the keyinit program to initialize the S/Key system. This process enables Sue to use S/Key authentication.)
Step 4 Have CiscoSecure users who will use S/Key enter the keyinit command at the UNIX prompt as follows:
keyinit
UNIX password>
secret password>
When the keyinit program asks Sue for a secret password, she is free to supply any mix of 10 or more alphanumeric characters.
secret password>
Now Sue is ready to use S/Key with CiscoSecure UNIX Server software.
S/Key also accounts for previous iterations of keyinit, providing assurance for the user that someone has not altered the system. As a result, the next time that Sue enters the keyinit command, she will see a display similar to the following:
keyinit
Unix password>
secret password>
secret password>
Next login password: SKI INCA HONE NEE MESS LEAF
You can establish global default settings for the name of the network-access-server and port of the caller, as well as set them up for individual services, commands, and protocols. The following complex example illustrates the flexibility of this approach:
user = fred {
allow ".*" "tty.*"
refuse ".*" "async.*"
service = shell {
cmd = telnet {
allow nas1.* .*
}
refuse nas2.* ".*"
}
Time-of-day and day-of-week qualifications are also supported, allowing system administrators to control access to highly contended or expensive resources during periods of demand. For example, the following declaration allows the Telnet command to be used at any time on weekends and outside normal office hours Monday through Thursday, that is, from 5 p.m. until 9 a.m. the following morning (1700 to 0900):
service = shell {
cmd = telnet {
time = Mo, Th 1700 - 0900
time = Sa, Su 0000 - 2359
}
}
...
The CiscoSecure UNIX Server software also allows for multiple declarations of the same service, protocol, or command. Because each declaration can include different attributes and qualifications, administrators can place restrictions on users at certain times or under certain conditions, but without those restrictions in other circumstances.
You can skip this section unless you want to bypass the CiscoSecure UNIX Server software graphical user interface (GUI), as the means to set authorization value pairs, or unless you need to view a convenient list of service attributes and the corresponding protocol values.
The authorization attribute-value pairs presented here are primarily for reference and to complement the accounting attribute-value pairs shown in the example on page 6 of this chapter.
CiscoSecure supports all four service attributes available to dial-in users, as follows:
service=arap service=shell (for exec startup, and also for command authorizations) service=ppp service=slip
After the network access server has authorized the user for a specified service, the CiscoSecure UNIX server returns to the network access server a list of attribute-value pairs appropriate for that service. For each service, several attribute-value pairs are generally available depending on the configurability of the service.
Each of the following attribute-value pairs is accompanied by a notation that identifies the corresponding, supported service.
cmd=telnet
cmd-arg=archie.sura.net
set acl=2
set inacl=2
set outacl=4
set addr=1.2.3.4
set timeout=60
set autocmd="telnet foo.com"
set noescape=true
set nohangup=true
set priv-lvl=5
set zonelist=5
Use the ip-local pool IOS configuration command to declare local pools, such as those on the network access server, as follows:
ip address-pool localip local pool moo 1.0.0.1 1.0.0.10ip local pool baz 2.0.0.1 2.0.0.20
You can indicate from which address pool you want to get this remote node's address. As shown in the following example, you can use the TACACS+ protocol to return addr-pool=moo or set addr-pool=baz.
user = lol {
service = ppp {
protocol = lcp {
}
protocol = ip {
set addr-pool=moo
}
}
}
service=ppp protocol=ip {set route = "<dst_addr> <mask> [ <gateway> ]"}
set callback-rotary=34
set callback-dialstring=408-555-1212
set nocallback-verify=1
CiscoSecure UNIX Server software can now add a field to each accounting record that will indicate the immediate group membership of the corresponding user as listed in an AA database. In this way, accounting organizations can easily know whether to adjust billing information according to the user's group association.
The ability to display group membership for billing and accounting is achieved by specifying the acct_member attribute in the CiscoSecure UNIX Server software control file, and by specifying the acct_member attribute beside each user's name whose group membership you want to be able to display.
Take the following steps to install the acct_member attribute:
Step 1 Copy the libacctmember.so file from the CiscoSecure UNIX Server 1.0(1) disk to the directory where the CiscoSecure binary image resides.
In most cases, the CiscoSecure binary image will reside in a directory named /bin and is found under /usr/local/CiscoSecure or in a similar location.
Step 2 Add a statement (using vi or similar text editor) to the control file as follows:
ACCT config_external_acct_symbols = {
{
"bin/libacctmember.so",
"acct_member_fn"
}
};
The first string should reflect the location of the libacctmember.so shared library. This pathname can be fully qualified (for example, "/usr/local/CiscoSecure/bin/libacctmember.so") or it can be relative to the directory where CiscoSecure UNIX Server software is started.
Step 3 For each member of the AA database where you would like the immediate group membership displayed, you must supply a statement that indicates that "acct_member_fn" should be called as follows:
user = test {
member = gem
account = acct_member_fn
password = clear "test" # this is just an example
[...] # and so on, and so on
}
The "account = acct_member_fn" statement could be located anywhere above the indicated user in the AA database. For example, the specified AA database file might look as follows:
user = test1 {
member = group1
password = clear "test" # this is just an example
[...] # and so on, and so on
}
user = test2 {
member = testusers
[...] # and so on, and so on
}
group = testusers {
member = allusers
}
group = allusers {
account = acct_member_fn
}
In this case, the record "acct_member_fn" would be called for all users who were in the group "allusers" or any subgroup of same (for example, in the previous display, testusers was such a subgroup).
Step 4 Reload the CiscoSecure server by means of the UNIX kill command as follows:
kill -HUP `cat /etc/CiscoSecure.pid`
When you view your accounting data, you can now identify the group membership of a particular user. For example, the accounting data based on the sample data in this section, would look as follows:
Note that the accounting data now identifies the user "test" as a member of the group "gem."
|
|