user man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

user(1m)							      user(1m)

NAME
       user  -	A dcecp task object that manipulates user information in a DCE
       cell

SYNOPSIS
       user create user_name_list -mypwd password  -password  password	-group
       group_name   -organization   organization_name	[-force]   {-attribute
       attribute_list | -attribute value}

       user delete user_name_list

       user help [operation | -verbose]

       user operations

       user show user_name_list

ARGUMENTS
       The name of the user operation for which to display  help  information.
       A  list	of one or more names of principals to act on. Supply the names
       as follows: Fully qualified principal names  in	the  form  /.:/princi‐
       pal_name,  /.../cell_name/principal_name,  or principal_name@cell_name.
       Cell-relative principal names in the form principal_name.  These	 names
       refer  to a principal in the cell identified in the _s(sec) convenience
       variable, or if the _s(sec) convenience variable is  not	 set,  in  the
       local host's default cell.

       Do not mix fully qualified names and cell-relative names in a list.  In
       addition, do not use the names of registry database objects  that  con‐
       tain principal information; in other words, do not use names that begin
       with /.:/sec/principal/.

DESCRIPTION
       The user task object represents all of the data associated with	a  DCE
       user.  This consists only of registry information in the current imple‐
       mentation.  The user task object allows administrators to easily create
       principals and accounts, delete principals and accounts, and view prin‐
       cipal and account information.

       When it creates a principal and an account, the user task  object  adds
       the principal to a group and an organization, if nessesary, and creates
       the group and organization if required.	Only the principal and account
       attributes  are	considered attributes of the user task object, and are
       the only ones displayed by the show operation.

       This object is implemented as a script to allow it  to  be  manipulated
       and  extended  on  a per-site basis.  For example, administrators might
       want to add Global Directory Service (GDS) and Distributed File Service
       (DFS)  information to the object.  Other possible modifications include
       the following: Changing the default ACLs placed on the various objects.
       Setting	certain attributes or policies on all newly created principals
       and accounts to match the site's policies.  Setting  up	site  specific
       defaults for passwords (to be changed by the user later), groups, orga‐
       nizations, principal directories, and so on.  Supporting a modify oper‐
       ation.

ATTRIBUTES
       A  flag	set to determine account validity.  Its value is either yes or
       no.  An account with an acctvalid attribute set to no  is  invalid  and
       cannot  be  logged  in  to.   The default is yes.  Used with the create
       operation.  The value of this attribute must be yes or no.  Each	 prin‐
       cipal  can  have only one name, but may have multiple alias names.  All
       these names refer to the same principal and, therefore, the  same  Uni‐
       versal Unique Identifier (UUID) and UNIX ID (uid).  While aliases refer
       to the same principal, they are separate entries in the registry	 data‐
       base.   Therefore  the  name  supplied  to  a user command can refer to
       either the primary name or an alias name of a principal.	 The value  of
       this attribute determines whether the name is a primary name (alias no)
       or an alias name (alias yes).  The default is no.  A flag set to	 indi‐
       cate  whether  the account is for a principal that can act as a client.
       The value of this attribute must be yes or no.  If you set it  to  yes,
       the  principal is able to log in to the account and acquire tickets for
       authentication.	The default is yes.  A text  string  (limited  to  the
       Portable	 Character  Set	 or PCS) typically used to describe the use of
       the account. The default is the empty  string  ("").   A	 flag  set  to
       determine  if tickets issued to the account's principal can have dupli‐
       cate keys.  The value of this attribute must be yes or no.  The default
       is no.

       In  DCE,	 this attribute is currently only advisory.  However, Kerberos
       clients and servers will use of it when they interact with a DCE	 Secu‐
       rity  server.   The  date  on  which the account expires.  To renew the
       account, change the date in this field.	Specify the time by  using  an
       ISO  compliant  time  format  such as CCYY-MM-DD-hh:mm:ss or the string
       none.  The default is none.  A flag set	to  determine  whether	a  new
       ticket-granting	ticket	with  a	 network address that differs from the
       present ticket-granting ticket network address can  be  issued  to  the
       account's  principal.   The  proxiabletkt  attribute  performs the same
       function for service tickets.  This attribute must have a value of  yes
       or no.  The default is yes.

       In  DCE,	 this attribute is currently only advisory.  However, Kerberos
       clients and servers will use it when they interact with a DCE  Security
       server.	 Used  with the create operation, this attribute specifies the
       full name of the principal.  It is for information purposes  only.   It
       typically describes or expands a primary name to allow easy recognition
       by users.  For example, a principal could have a primary name of jsbach
       and  a full name of Johann S. Bach.  The value is a string.  If it con‐
       tains spaces, it is displayed in quotes, and on entry must be in quota‐
       tions  or  braces (as per Tcl quoting rules).  If not entered, the full
       name defaults to the null string (that is, blank).  The date  and  time
       the  account was last known to be in an uncompromised state.  Any tick‐
       ets granted before this date are invalid.  The value is	an  ISO	 time‐
       stamp.	When  the  account is initially created, the goodsince date is
       set to the current date.	 Control over this date is  especially	useful
       if  you	know that an account's password was compromised.  Changing the
       password can prevent the unauthorized principal from accessing the sys‐
       tem  again  using that password, but the changed password does not pre‐
       vent the principal from accessing the system components for which tick‐
       ets  were  obtained  fraudulently  before the password was changed.  To
       eliminate the principal's access to the system,	the  tickets  must  be
       cancelled.

       The default is the time the account was created.	 The name of the group
       associated with the account.  The value is a single group  name	of  an
       existing	 group	in the registry.  This attribute must be specified for
       the user create command; it does not have a default value.

       If a group is deleted from the registry, all accounts  associated  with
       the  group  are	also  deleted.	The file system directory in which the
       principal is placed in at login.	 The default is the  /	directory.   A
       list  of	 two items.  The first is the principal name of the last modi‐
       fier of the account; the second is an ISO timestamp showing the time of
       the  last  modification.	  This attribute is set by the system whenever
       the account is modified; it cannot be set or  modified  directly.   The
       initial	value  consists	 of  the  principal name of the creator of the
       account and the time the account was created.  The name of the  organi‐
       zation associated with the account.  The value is a single organization
       name of an existing organization in the registry.  This attribute  must
       be  specified  for  the user create command; it does not have a default
       value.

       If an organization is deleted from the registry, all  accounts  associ‐
       ated  with  the	organization  are also deleted.	 The maximum amount of
       time that a ticket can be valid.	 Specify the time by  using  the  Dis‐
       tributed	 Time  Service	(DTS)  relative	 time format ([-]DD-hh:mm:ss).
       When a client requests a ticket to a server, the	 lifetime  granted  to
       the  ticket  takes  into account the maxtktlife set for both the server
       and the client.	In other words, the lifetime cannot exceed the shorter
       of the server's or client's maxtktlife.	If you do not specify a maxtk‐
       tlife for an account, the maxtktlife defined as registry	 authorization
       policy  is used.	 The amount of time before a principal's ticket-grant‐
       ing ticket expires and that principal must log in to the	 system	 again
       to  reauthenticate  and obtain another ticket-granting ticket.  Specify
       the time by using the DTS-relative time format  ([-]DD-hh:mm:ss).   The
       lifetime	 of the principal's service tickets can never exceed the life‐
       time of the principal's ticket-granting ticket.	The shorter  you  make
       maxtktrenew,  the  greater  the security of the system.	However, since
       principals must log in again to renew their ticket-granting ticket, the
       time  needs  to	balance	 user  convenience  against  level of security
       required.  If you do not specify this attribute	for  an	 account,  the
       maxtktrenew lifetime defined as registry authorization policy is used.

       This  feature  is  not currently used by DCE; any use of this option is
       unsupported at the present time.	 The password of  the  account.	  This
       attribute  must	be  specified for the user create command; there is no
       default value.  This attribute is not returned by a user show  command.
       A  flag set to determine whether tickets with a start time some time in
       the future can be issued to the account's  principal.   This  attribute
       must have a value of yes or no.	The default is no.

       In  DCE,	 this attribute is currently only advisory.  However, Kerberos
       clients and servers will use it when they interact with a DCE  Security
       server.	 A flag set to determine whether a new ticket with a different
       network address than the present ticket can be issued to the  account's
       principal.  The forwardabletkt attribute performs the same function for
       ticket-granting tickets.	 This attribute must have a value  of  yes  or
       no.  The default is no.

       In  DCE,	 this attribute is currently only advisory.  However, Kerberos
       clients and servers will use it when they interact with a DCE  Security
       server.	A flag set to determine whether the current password is valid.
       If this flag is set to no, the next time a principal  logs  in  to  the
       account,	 the  system  prompts  the  principal  to change the password.
       (Note that this flag is separate from the pwdexpdate policy, which sets
       time limits on password validity.)  This attribute must have a value of
       yes or no.  The default is yes.	Used  with  the	 create	 operation  to
       specify	the principal's object creation quota, which is the total num‐
       ber of registry objects that can be created by the  principal.	It  is
       either  a  non-negative	number	or the string unlimited.  A value of 0
       prohibits the principal from creating any registry objects.  Each  time
       a  principal  creates  a registry object, this value is decremented for
       that principal.	A flag set to determine if the ticket-granting	ticket
       issued  to the account's principal can be renewed.  If this flag is set
       to yes, the authentication service renews the ticket-granting ticket if
       its  lifetime is valid.	This attribute must have a value of yes or no.
       The default is yes.

       In DCE, this attribute is currently only advisory.   However,  Kerberos
       clients	and servers will use it when they interact with a DCE Security
       server.	Indicates whether the principal object	is  reserved  or  not.
       The  default  is	 no.  This attribute may not be set or modified by the
       user.  A flag set to indicate whether the account is  for  a  principal
       that  can act as a server.  If the account is for a server that engages
       in authenticated communications, set this flag to yes.  This  attribute
       must  have  a value of yes or no.  The default is yes.  The path of the
       shell that is executed when a principal logs in.	 The  legal  value  is
       any  shell  supported by the home cell.	The default value is the empty
       string ("").  A flag set to determine whether service tickets issued to
       the  account's  principal  use  the standard DCE ticket-granting ticket
       authentication mechanism.  This attribute must have a value of  yes  or
       no.   The  default is yes.  Used with the create operation, this speci‐
       fies the UNIX ID (uid) for the principal.  No two principals  can  have
       the  same uid.  However, aliases can share one uid.  It is often called
       the Unix ID and is an integer.  If this attribute is  not  supplied,  a
       UID  is	assigned to the principal automatically.  Used with the create
       operation to specify the internal identifier, known as a UUID, for  the
       principal.   No	two  principals	 can have the same UUID, so do not use
       this option when creating more than one principal with a single	create
       command.

       This  option can also be used to adopt an orphaned UUID.	 Normally, the
       UUID for a new principal is generated by the registry.	When  data  is
       tagged  with  a UUID of a principal that has been deleted from the reg‐
       istry, this option can be used to specify the old UUID for a new	 prin‐
       cipal.	The UUID specified must be an orphan (a UUID for which no name
       exists in the registry).	 An error occurs if you specify a name or UUID
       that is already defined in the registry.

       See the OSF DCE Administration Guide for more information about princi‐
       pal and account attributes.

OPERATIONS
   user create
       Creates a principal name and an account for one or more DCE users.  The
       syntax is as follows: user create user_name_list -mypwd password -pass‐
       word  password  -group	group_name   -organization   organization_name
       [-force] {-attribute attribute_list | -attribute value}

       Options	As  an	alternative  to	 using	the  -attribute option with an
       attribute  list,	 you  can  specify  individual	attribute  options  by
       prepending a hyphen (-) to any attributes listed in the ATTRIBUTES sec‐
       tion of this reference page.  Allows you to specify attributes, includ‐
       ing  ERAs,  by using an attribute list rather than individual attribute
       options. The format of an attribute list	 is  as	 follows:  {{attribute
       value}...{attribute  value}}  Forces creation of the specified group or
       organization if they do not exist.  The name of the group to  associate
       with the account.  See ATTRIBUTES for the format of a group name.  Your
       privileged password.  You must enter your privileged password to create
       an  account.  This check prevents a malicious user from using an exist‐
       ing privileged session to create unauthorized accounts.	You must spec‐
       ify this option on the command line; it cannot be supplied in a script.
       The name of the	organization  to  associate  with  the	account.   See
       ATTRIBUTES  for	the format of an organization name.  The account pass‐
       word.  See ATTRIBUTES for the format of a password.

       The create operation creates a principal name and an account for one or
       more DCE users.	The user_name_list argument is the name of one or more
       principals to be added to the  registry.	  This	operation  returns  an
       empty  string  on  success.   If	 the operation encounters an error, it
       attempts to undo any interim operations that have completed.

       This command creates one or more principals and accounts for them.   If
       a  principal  or	 account  already exists, an error is generated.  Each
       principal is then added to the specified group and organization	(since
       the  principal  has  just been created, it cannot have been a member of
       any group or organization).  If the  group  or  organization  does  not
       exist, an error is generated unless the -force option is used.

       Attributes and policies for the newly created principal and account may
       be specified with the -attributes option and  specifying	 an  attribute
       list as the value, or with attribute options.  This command attempts to
       add any unknown attributes as ERAs on  the  created  principal  object.
       Policies of the organization may not be specified, as they would proba‐
       bly affect more than the created user.  The required group and  organi‐
       zation  names  may be specified either as attributes in the -attributes
       option or via the -group and -organization options.  The required pass‐
       word  attribute	may  be provided as in the account create command, and
       the -mypwd option is also required.

       Privileges Required

       Because the user create command performs several operations,  you  need
       the  permissions	 associated with each operation, as follows: To create
       the principal name, you must have i (insert) permission to  the	direc‐
       tory  in which the principal is to be created.  If the specified groups
       or organizations do not already exist and you use  the  -force  option,
       you  must  have	i  (insert) permission to the directories in which the
       groups and organizations are to be created.  To create the account, you
       must have m (mgmt_info), a (auth_info), and u (user_info) permission to
       the principal named in the account, r (read) permission to the  organi‐
       zation  named in the account, r (read) permission to the group named in
       the account, and r (read) permission on the registry policy object.

       Examples

       The following example creates a principal named K_Parsons and adds  him
       to  a  group  named  users and an organization named users: dcecp> user
       create K_Parsons -mypwd 3kl_JL2 -password change.me \  >	 -group	 users
       -organization users dcecp>

       dcecp>	   group     list     users	/.../my_cell.goodco.com/W_Ross
       /.../my_cell.goodco.com/J_Severance    /.../my_cell.goodco.com/J_Hunter
       /.../my_cell.goodco.com/B_Carr	       /.../my_cell.goodco.com/E_Vliet
       /.../my_cell.goodco.com/J_Egan	      /.../my_cell.goodco.com/F_Willis
       /.../my_cell.goodco.com/K_Parsons dcecp>

       dcecp>  principal  show	K_Parsons  {name K_Parsons} {fullname {}} {uid
       5129} {uuid 00001409-a943-21cd-be00-0000c08adf56} {alias no}  {reserved
       no} {quota unlimited} {groups users} dcecp>

       dcecp>  account	show  K_Parsons	 {acctvalid yes} {client yes} {created
       /.../my_cell.goodco.com/cell_admin 1994-07-27-13:02:51.000+00:00I-----}
       {description  {}}  {dupkey  no}	{expdate  none}	 {forwardabletkt  yes}
       {goodsince 1994-07-27-13:02:51.000+00:00I-----} {group users} {home  /}
       {lastchange			    /.../my_cell.goodco.com/cell_admin
       1994-07-27-13:02:51.000+00:00I-----}  {name  K_Parsons}	 {organization
       users} {postdatedtkt no} {proxiabletkt no} {pwdvalid yes} {renewabletkt
       yes} {server yes} {shell {}} {stdtgtauth yes} dcecp>

       dcecp> user create jimbo@gumby_cell -mypwd beanie -password change.me \
       > -group none -organization none dcecp>

   user delete
       Deletes	 DCE   users.	 The   syntax	is  as	follows:  user	delete
       user_name_list

       The delete operation deletes the DCE users named in user_name_list.  To
       delete a user, the operation procedes as follows: Deletes the principal
       from the registry, which also deletes the account and removes the prin‐
       cipal  from  any	 groups	 and organizations.  This operation returns an
       empty string on success.

       Privileges Required

       Because the user delete command performs several operations,  you  need
       the  permissions	 associated  with  each	 operation:  You  must	have d
       (delete) permission to the directory  in	 which	the  target  principal
       exists.	You must have r (read) and D (Delete_object) permission on the
       principal to be deleted.	 You must have r (read)	 and  M	 (Member_list)
       permission  on the target groups and organizations and r (read) permis‐
       sion on the member to be removed.  To delete the account, you must have
       r  (read),  m (mgmt_info), a (auth_info), and u (user_info) permissions
       for the principal named in the account.

       Examples

       The following example deletes user K_Parsons from the cell: dcecp> user
       delete K_Parsons dcecp>

   user help
       Returns help information about the user task object and its operations.
       The syntax is as follows: user help [operation | -verbose]

       Options Displays information about the user task object.

       Used without an argument or option, the user help command returns brief
       information about each user operation.  The optional operation argument
       is the name of an operation about which you want detailed  information.
       Alternatively, you can use the -verbose option for more detailed infor‐
       mation about the user task object itself.

       Privileges Required

       No special privileges are needed to use the user help command.

       Examples

       dcecp> user  help  create	       Creates	a  DCE	user.	delete
       Deletes	a DCE user.  show		 Shows the attributes of a DCE
       user.  help		  Prints a summary  of	command-line  options.
       operations	    Returns  a	list  of the valid operations for this
       command.	 dcecp>

   user operations
       Returns a list of the operations supported by  the  user	 task  object.
       The syntax is as follows: user operations

       The  list  of  available operations is in alphabetical order except for
       help and operations, which are listed last.

       Privileges Required

       No special privileges are needed to use the user operations command.

       Examples

       dcecp> user operations create delete show help operations dcecp>

   user show
       Returns the attributes of a single DCE user.  The syntax is as follows:
       user show user_name_list

       The  show  operation  returns  the  attributes  of  the	users named in
       user_name_list.	  The	information   returned	 includes    principal
       attributes,  account  attributes,  and  policies.   The	information is
       returned as if the following commands were run in the following	order:
       principal show account show -all

       Privileges Required

       You  must  have	r  (read)  permission  to  the	principal named in the
       account.

       Examples

       dcecp> user show K_Parsons {name K_Parsons} {fullname  {}}  {uid	 5129}
       {uuid  00001409-a943-21cd-be00-0000c08adf56}  {alias  no} {reserved no}
       {quota unlimited} {groups users} {acctvalid yes} {client yes}  {created
       /.../my_cell.goodco.com/cell_admin 1994-07-27-13:02:51.000+00:00I-----}
       {description  {}}  {dupkey  no}	{expdate  none}	 {forwardabletkt  yes}
       {goodsince  1994-07-27-13:02:51.000+00:00I-----} {group users} {home /}
       {lastchange			    /.../my_cell.goodco.com/cell_admin
       1994-07-27-13:02:51.000+00:00I-----} {organization users} {postdatedtkt
       no} {proxiabletkt no} {pwdvalid yes} {renewabletkt  yes}	 {server  yes}
       {shell {}} {stdtgtauth yes} nopolicy dcecp>

RELATED INFORMATION
       Commands: dcecp(1m), dcecp_account(1m), dcecp_group(1m), dcecp_organi‐
       zation(1m), dcecp_principal(1m), dcecp_xattrschema(1m).

								      user(1m)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net