By default, all roles have the adminvi(1M) editor and the dtterm terminal assigned by default.
The default profile(4) file in the home directories for all roles has the following function to alias vi to adminvi:
vi() { adminvi $1 ; }
However, the alias does not by defaults since the .profile file is not sourced by default. For more information about startup files in the Trusted Solaris environment, see the discussion in Chapter 3, Managing User Accounts under "Managing Initialization Files".
Assume the System Administrator role and go to an ADMIN_LOW
workspace.
Create an .Xdefaults file for each hostname the role uses.
For example, when the role works on computers named tern and toucan, create a $HOME/.Xdefaults-toucan and a $HOME/.Xdefaults-tern.
Add the following entry to the $HOME/.Xdefaults-hostname file in the SLD at each label at which the role works:
Dtterm*LoginShell: true |
Make sure that a copy of the file is in every SLD at which the role works.
See "Using .copy_files and .link_files" for how to copy or link files into every SLD.
The /usr/dt/bin/trusted_edit script is a wrapper that launches an editing window using the $EDITOR
environment variable. The wrapper audits all changes.
Assume the Security Administrator role and go to an ADMIN_LOW
workspace.
If the trusted_edit command is not in one of the role's profiles, use the SMC Rights tool to add the trusted_edit command to the Custom rolename profile.
Refer to the online help when modifying the rights profile.
Make sure that the role has the Custom rolename profile assigned to it or subsumed in one of its assigned rights.
Because trusted_edit launches a window, it cannot be used for command line editing. Command line editing may be the only option available in a remote login session, so for this reason, do not assign trusted_edit as the only editor for a role, unless the role never needs to do remote editing on the command line.
Search for the vi function in the .profile file in the role's home directory:
vi() {adminvi $1;} |
Replace adminvi with trusted_edit:
vi() {trusted_edit $1;} |
Make sure the following entry is also made in the $HOME/.Xdefaults-hostname file in the SLD at each label at which the role works:
Dtterm*LoginShell: true |
Make a file for each hostname the role uses. For example, when the role works on computers named tern and toucan, create a $HOME/.Xdefaults-toucan and a $HOME/.Xdefaults-tern in each SLD.
Once the SMC is initialized, users or roles can use the smrole(1M) command described below to see a list of all roles.
Assume the Security or System Administrator role.
To list the roles in a name service domain, use the smrole list command with the -D option to specify the name_service_type:/server_name/domain_name. Provide a password when prompted.
The following screen example lists the roles that are defined in the NIS+ domain tropics.example.com whose NIS+ master server is toucan. The command is being executed on the tern system:
$ /usr/sadm/bin/smrole list -D nisplus:/toucan/tropics.example.com -- Authenticating as user: admin Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password :: rolePassword Loading Tool: usermgr.cli.role.UserMgrRoleCli from tern Login to tern as user janez, role admin was successful. Download of usermgr.cli.role.UserMgrRoleCli from tern was successful. admin 100 System Admin secadmin 101 Security Admin oper 102 Operator primaryadmin 104 Primary Administrator Role root 0 Super-User |
To list the roles defined in the local system, use the smrole list command followed by the double dash --.
$ /usr/sadm/bin/smrole list -- |
To list all roles defined in local files on a system named tern:
/usr/sadm/bin/smrole list -- -h tern |
Assume the Security Administrator role and go to an ADMIN_LOW
workspace.
If the role requires authorizations that the Security Administrator cannot grant, the Primary Administrator role must change the role.
Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.
Double-click the Rights tool, then select the Custom rolename Role.
To modify a role, you modify the contents of one or more of its rights profiles.
Make any needed modifications to the Custom rolename profile.
Add or change any of the following security attributes in the Custom rolename profile:
Commands or actions with security attributes
Authorizations
Profile
Double-click the Administrative Roles tool, select the role, and choose Action->Assign Rights.
If you modified an existing Custom rolename Role profile, make sure that it is assigned to the role. The rights profile should be ordered before the All profile.
For example, if you are changing the System Administrator role, and the Custom Admin Role profile is not assigned to the role, you would use the Administrative Roles tool to add the Custom Admin Role to the list of Rights for the role. You would also move the Custom Admin Role before the All profile in the list.
Define the role's responsibilities, and decide what commands, actions, security attributes, and authorizations the role needs to do its work.
Decide whether any of the commands or actions need privileges or other security attributes to do their work, and, if so, decide whether the role and the command or action can use these security attributes in a trustworthy manner.
Assume the Security Administrator role and go to an ADMIN_LOW
workspace.
Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.
If the role needs to have a new or modified rights profile, double-click the Rights tool to create or modify the rights profile.
See "To Create a Help File for a Rights Profile" and "To Create a Rights Profile" if you need to create a new rights profile.
To modify a right, select it and follow the online help.
Double-click the Administrative Roles tool, and choose Action->Add Role.
Refer to the online help when naming and describing the role.
Order the Custom rolename Role profile before other profiles you assign to the role.
For example, you would order a Custom Auditadmin Role before the All profile.
If you are running the NIS+ naming service, make an entry for the new role in the NIS+ admin group.
See "To Enable a Role to Administer NIS+", if needed.
Log into the NIS+ master and assume the Security Administrator role.
Double-click the Add to NIS+ Administrative Group action in the System_Admin folder in the Application Manager.
To enable a new role to administer NIS+, add the role to the NIS+ admin group.
Use your domain name with the format subdomain.domain.suffix.. For example:
Group Name: admin Principal Name: rolename.security.example.com. |
Remember to type a period (.) at the end of the the domain name.
Close the Add to NIS+ Group dialog box.
For example:
Group "rolename.security.example.com." created. *** Select Close or Exit from the window menu to close this window *** |
Untrusted systems are computers running an operating environment other than the Trusted Solaris operating environment.
Do this procedure on the Trusted Solaris machine where you want to be able to log in remotely.
Assume the Security Administrator role and go to an ADMIN_LOW
workspace.
Stop the init.wbem program if it is running.
$ /etc/init.d/init.wbem stop |
Use the Admin Editor action to open the /usr/sadm/lib/smc/bin/smcwbemserver file for editing.
Modify the following line to include the -u option
com.sun.management.viperimpl.server.ViperWbemServer "$@" |& > com.sun.management.viperimpl.server.ViperWbemServer -u "$@" |& |
When the -u option is specified, after being authenticated the user is presented with a list of the roles that user can assume that are available on the server. The user can then choose a role, enter the role's password, and select the Login as Role button.
Save and quit the file.
Restart init.wbem.
$ /etc/init.d/init.wbem start |