Conference tuxedo::dce-products

>[202] 4:12pm dukes ~ :  dce_login cell_admin <password> -e rgy_edit
>Current site is: registry server at /.../osse_cell/subsys/dce/sec/master
>rgy_edit=> ktl
>?(rgy_edit) Unable to retrieve key(s) - The caller is unauthorized to perform op
>eration (dce / sec)
>rgy_edit=>
>
>	2 "application" key-table files are only readable by root so I assume
>	that is the problem - correct ? 
>
>	If true, It is an unfortunate sideffect of "too much security". I 
>	believe the cell_admin user should be able to do anything DCE related !
    
    It's correct that the reason you have to be root is so that you can
    read the keytable.  However, I don't think this permission should
    necessarily be granted to cell_admin.
    
    cell_admin is the default DCE administration account.  It is intended
    to be used to manage cell-wide databases.
    
    root is the local machine's administration account.  You use root to
    manage a single machine.  Each machine within the cell has its own root
    account, and these accounts aren't (necessarily) related.
    
    The machine's keytable fall under the machine's administrative domain,
    not the cell's.  It is part of the machine-specific configuration, much
    like a machine's /etc/passwd file.  Another way of looking at this is
    that all keytables should belong to the same local account under which
    the server that uses them runs (and be inaccessible ot any other
    account).  The default keytable is used by dced, which runs under the
    local root account, therefore the default keytable has to belong to
    local root, and be innaccessible to other accounts.
    
    Note that administrative privileges in DCE aren't granted directly to
    the cell_admin account; instead they're controlled via various groups.
    For example, the group subsys/dce/sec-admin controls access to security
    management functions, while subsys/dce/cds-admin is necessary for
    access to cds administrative functions.
    
    The default keytable is in /krb5/v5srvtab.
    
    John

    
>    It's correct that the reason you have to be root is so that you can
>    read the keytable.  However, I don't think this permission should
>    necessarily be granted to cell_admin.

	The servers that read the kt run as root. 




>    cell_admin is the default DCE administration account.  It is intended
>    to be used to manage cell-wide databases.
>    
>    root is the local machine's administration account.  You use root to
>    manage a single machine.  Each machine within the cell has its own root
>    account, and these accounts aren't (necessarily) related.


	I am aware of these roles, I was just pointing out that
	in the ideal word cell_admin would be just that. ie: cell_admin	
	should be able to do ANYTHING with ANY keytable, or any other
	DCE "CDS database" for that matter. 



	Craig.

>	I am aware of these roles, I was just pointing out that
>	in the ideal word cell_admin would be just that. ie: cell_admin	
>	should be able to do ANYTHING with ANY keytable, or any other
>	DCE "CDS database" for that matter. 
    
    That's a matter for your local administrative policy.  There are some
    environments where you want a single management account for both DCE
    and each machine within the cell; for other environments that wouldn't
    be appropriate.
    
    DCE does support both styles (as well as lots of other models) - you
    just have to configure it to do what you want.  It shouldn't be hard to
    create a DCE account that's a member of all the DCE admin groups, and
    which has a mapping to root on each machine.  However, you shouldn't
    use dce_login to change your identity to that account, as that only
    changes your DCE credentials; the correct way would be to use "su"
    (with SIA enabled).
    
    John