login (AFS version)        AFS Commands     login (AFS version)


NAME

   login (AFS version) -- login to AFS and UNIX file systems.


   login [<user name>]

   Authenticates  the issuer with the AFS Authentication Server
   in the local cell  and  logs  him  or  her  into  the  local
   machine's UNIX file system.  More precisely, AFS login:

      - creates a new "process authentication group" (PAG)
        associated with the issuer and the  command  shell
        where  the  command  is issued.  A PAG is a number
        guaranteed to identify the issuer uniquely to  the
        local  Cache  Manager.  The Cache Manager uses the
        PAG, instead of the issuer's UNIX UID, to identify
        him  or  her  in  the credential structure that it
        creates to track each user.

      - authenticates the user with the AFS Authentication
        Server and obtains a "token"; the other AFS server
        processes in the cell accept the token as  partial
        proof that the user is a legitimate AFS user.  The
        Cache Manager stores the token in  the  credential
        structure  along  with the PAG, and presents it to
        AFS server processes as necessary.

      - logs the user into the local UNIX file system

   The lifetime of the token resulting from this command is the
   smallest of the following:

      - the  "maximum  ticket  lifetime"  recorded  in the
        "afs" entry in the Authentication Database.    The
        default  is 100 hours.  Administrators can inspect
        this value using kas examine, and change it  using
        kas setfields.

      - the  "maximum  ticket  lifetime"  recorded  in the
        issuer's  Authentication  Database  entry.     The
        default  is  25  hours for user entries created by
        the AFS 3.1 or later version of the Authentication
        Server,  and 100 hours for user entries created by
        the AFS 3.0 version of the Authentication  Server.
        Administrators  and  the  user himself/herself can
        inspect  this   value   using   kas examine,   and
        administrators can change it using kas setfields.

      - the  "maximum  ticket  lifetime"  recorded  in the
        "krbtgt.CELLNAME"  entry  in  the   Authentication
        Database;  this  entry  corresponds to the ticket-
        granting ticket used internally in generating  the
        token.  The default is 720 hours (30 days).

   If  none  of  these  defaults  have  been  changed, then the
   standard  token  lifetime  is  25  hours  for  users   whose
   Authentication  Database entries were created by the AFS 3.1
   or later version of the Authentication Server, and 100 hours
   for users whose Authentication Database entries were created
   by the AFS 3.0 version of the Authentication  Server.    The



   user  can  issue  klog  to  request a token with a different
   lifetime.

   Using a PAG instead of the UNIX UID to distinguish users has
   two advantages.

      - It  means  that  processes  spawned  by  the  user
        inherit the PAG and so share the token; thus  they
        gain  access  to  AFS  as  the authenticated user.
        This is important in many environments where,  for
        example,  printer  and  other  daemons  run  under
        identities (such as "root") that  the  AFS  server
        processes  recognize  only  as  anonymous.  Unless
        PAGs  are  used,  such   daemons   cannot   access
        information   in   directories  protected  against
        system:anyuser.

      - It closes  a  potential  security  loophole:  UNIX
        allows  anyone  already  logged  in as "root" on a
        machine to assume any other  identity  by  issuing
        su.    If the credential structure were identified
        by a UNIX UID rather than a PAG, then assuming the
        same  UID  would mean being able to use the token,
        too.  Use of a PAG  as  an  identifier  eliminates
        that possibility.

   The  process  of  authenticating with the AFS Authentication
   Server is as follows:

      1. The login program checks the user's entry in  the
         local /etc/passwd file.

         If  no  entry  exists,  or  if  an asterisk ( * )
         appears in the password field, the login  attempt
         fails.

         If the entry exists, the attempt proceeds to step
         LOGIN.PAG.

      2. The  login  program  invokes  the  command   that
         creates a PAG.

      3. The  login program converts the password provided
         by the user into an encryption key and encrypts a
         packet of data with the key.  It sends the packet
         to   an   AFS   Authentication   Server.      The
         Authentication  Server  decrypts  the packet and,
         depending  on  the  success  of  the  decryption,
         judges  the  password to be correct or incorrect.
         (Consult the AFS System Administrator's Guide for
         more  information  on the "mutual authentication"
         procedure used to verify  the  password  in  this
         step.)

         If  the Authentication Server judges the password
         incorrect, the  user  does  not  receive  an  AFS
         token.  The attempt proceeds to step LOGIN.LOCAL.
         If the Authentication Server judges the  password
         correct,  it  issues a token to the user as proof
         of AFS authentication.  The  login  program  also
         logs  the  user  into the local UNIX file system.



         Step LOGIN.LOCAL is skipped.

      4. If no AFS token was granted in step 3, the  login
         programattempts  to  log  the user into the local
         UNIX  file  system,  by  comparing  the  password
         provided to the local password file (/etc/passwd,
         for instance).

         If the provided password  is  incorrect,  or  the
         password   field   in  the  local  password  file
         contains  anything  other  than  a   13-character
         UNIX-encrypted  password  string,  then the login
         attempt fails.

         If the password is correct, the  user  is  logged
         into  the  local  UNIX  file  system  only.  (The
         success of this attempt and the  failure  of  the
         AFS authentication implies that the AFS and local
         passwords  are  different  and  that  the  issuer
         provided the latter.)

WARNINGS

   Each  PAG  uses two of the memory slots that the kernel uses
   to record the UNIX groups associated with a user.   If  none
   of  these  slots are available, the PAG creation fails.  The
   use of two group slots per PAG does not  present  a  problem
   with  most  operating  systems, which make at least 16 slots
   available.

   The AFS version of  login  is  based  on  the  Berkeley  4.3
   Distribution  and  does  not  include  the modified features
   included in some proprietary versions of login.

   The AFS version of login works only on  machines  that  have
   run afsd.

ARGUMENTS

   See  the  UNIX  manual page for login.  The AFS version does
   not impose any  stronger  restrictions  on  acceptable  user
   names than does the UNIX file system.

OUTPUT

   To distinguish the AFS version of login from other versions,
   one  of  the  following  banners  appears  on  standard  out
   (stdout) when the command executes successfully.

      AFS 3.0 Login

   or

      AFS 3.2 (R) Login

   Various  error  messages  appear if the login attempt is not
   successful.  The "login:" prompt normally returns  following
   the  error  messages, giving the user another chance to type
   the password correctly.

PRIVILEGE REQUIRED



   None.



MORE INFORMATION

   rlogind (AFS version)

   UNIX manual page for login
