User Accounts

   


User Accounts

It is important for the system manager to understand how the user account mechanism functions under the Solaris operating environment. It is also important that the files associated with it are suitably protected and backed up. Poor management of these files can leave the system wide open for an unauthorized intruder. If there is a system security policy governing user access to the system, it is the responsibility of the system manager to ensure that it is being implemented in line with this document. This policy should include details about usernames, the password aging strategy, expiration of accounts, and so on. Armed with sufficient information about the user account management files, the system manager is better able to verify compliance with the security procedures.

The following subsections describe the files related to the administration of user accounts, tell how to lock a specific account, and, finally, give an example of how proper use of groups can be used to the system manager's advantage.

Which Files Are Involved?

Three files are used as part of account management: /etc/passwd, /etc/shadow, and /etc/ group . Collectively, they identify a user, the groups that user belongs to, and details about password management. Listing 9.2 shows an example of each of these files.

Listing 9.2 Examples of the Files /etc/passwd, /etc/shadow, and /etc/group
 #cat  /etc/passwd  root:x:0:1:Super-User:/:/sbin/sh  daemon:x:1:1::/:  bin:x:2:2::/usr/bin:  sys:x:3:3::/:  adm:x:4:4:Admin:/var/adm:  lp:x:71:8:Line  Printer  Admin:/usr/spool/lp:  uucp:x:5:5:uucp  Admin:/usr/lib/uucp:  nuucp:x:9:9:uucp  Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico  listen:x:37:4:Network Admin:/usr/net/nls:  nobody:x:60001:60001:Nobody:/:  noaccess:x:60002:60002:No Access User:/:  nobody4:x:65534:65534:SunOS 4.x Nobody:/:  oracle:x:500:500:Oracle:/u01/app/oracle:/bin/ksh  logger:x:511:1:Log Files:/home/logfiles:/opt/bin/bash  amanda:x:513:1:AMANDA  Backup Utility:/home/amanda:/usr/bin/ksh  backup:x:515:1:Backup  User:/home/backup:/usr/bin/ksh  john:x:120:14:John Philcox:/export/home/john:/usr/bin/ksh  #   # cat  /etc/shadow   root:7mZuQjRKy8syU:11208::::::  daemon:NP:6445::::::  bin:NP:6445::::::  sys:NP:6445::::::  adm:NP:6445::::::  lp:NP:6445::::::  uucp:NP:6445::::::  nuucp:NP:6445::::::  listen:*LK*:::::::  nobody:NP:6445::::::  noaccess:NP:6445::::::  nobody4:NP:6445::::::  oracle:rAXbO74IDUBE.:11018::::::  logger:cY1S4X8uhZESY:11212::::::  amanda:*LK*:::::::  backup:*LK*:::::::  john:kyQC3jrIC8EtY:11267::::::  #   #cat  /etc/group   root::0:root  other::1:  bin::2:root,bin,daemon  sys::3:root,bin,sys,adm,backup,amanda  adm::4:root,adm,daemon  uucp::5:root,uucp  mail::6:root  tty::7:root,tty,adm  lp::8:root,lp,adm  nuucp::9:root,nuucp  staff::10:  daemon::12:root,daemon  sysadmin::14:john  nobody::60001:  noaccess::60002:  nogroup::65534:  dba::100:oracle,john  amanda::105: 

The most important of the three files is /etc/shadow because it contains the encrypted password for the user, including the superuser account. The file permissions should be the absolute minimum ”that is, read permission for the superuser only. The shadow file also contains details of password aging. The passwd and shadow files should not be edited manually ”use admintool or vipw to make consistent changes.

Locking an Account

When a user leaves the company, that account should be removed from the system to prevent unauthorized access. This is not always done immediately, however, because the files and directories belonging to the user are often archived before being deleted. If this is the case, it is good practice to lock the account during the intervening period so that only the superuser can access it. An account is locked by replacing the encrypted password field of the /etc/shadow entry for the specified user with *LK*. Use vipw to do this rather than editing the file manually. In Listing 9.2, the users backup and amanda are both locked.

If the system manager finds any user accounts with no password assigned (these can be easily found by running login -p as user root), then these should be locked at the earliest opportunity. Some organizations run an automatic task that removes any user accounts with no password, requiring the offending user to reapply for a user ID.

Making Better Use of Groups

It is not uncommon for organizations to create users who all have a primary group of Staff instead of assigning them to, say, Sales or Human Resources. The security implications should be sufficient to justify the proper use of primary groups, but they often aren't. The manipulation of groups can be an effective administration tool, particularly in large applications where users log in using captive accounts to access a specific software application or database. In this instance, they will not have access to a command-line prompt (the shell), and they will all execute a common startup file to initiate the application. By using the primary group, it becomes easy to move large numbers of users to, for example, a new version of the software, leaving the remainder on the current version. The startup file simply tests which group the user belongs to and takes a defined action, such as the command to start the application. Changing the user's primary group automatically changes the command that is run when that user next logs in to the system.


   
Top


Solaris System Management
Solaris System Management (New Riders Professional Library)
ISBN: 073571018X
EAN: 2147483647
Year: 2001
Pages: 101
Authors: John Philcox

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net