Conference iosg::all-in-1_v30

    
    Stefan,
    
    I've no docs at hand (but I should only being 5 feet away from EDU here
    in Dublin ;-)), but last time I saw OAFC$DEFAULT used it was for a
    'Remote' user accessing a Drawer on out system which had *WORLD defined
    as access level. So, as the 'remote' user didn't have a PROXY set up,
    the OAFC$DEFAULT served as the account to access the drawer.
    
    Ciao,
    
    	Simon

    
    re .0
    
    Here's what they are for...
    
    OAFC$SERVER: This is the account that the FCS is started from. It is 
                 created with the privs needed during the installation of
                 the FCS.  It will never be logged into, this is the
                 INSPECT problem we have run into with it.
    
    OAFC$DEFAULT: Again, this will never be logged into. THe FCS uses this
                 account on a remote connection (brokering), remote
                 connections are authenticated via proxy checks, when you 
                 don't have a proxy check we (the FCS) authenticates you 
                 into OAFC$DEFAULT, this is how the FCS allows world
                 access. We gotta let you in as someone with no privs so
                 that you have access to world accessible docs, so we 
                 create this one during installation for that reason. It
                 should not be priv'd.
    
    --Bob
    

    Thanks for your quick answers, Simon and Bob!
    
    I still have some questions:
    
    1.	Where are this accounts documented?
    
    2.	>This is the account that the FCS is started from. It is
    	>created with the privs needed during the installation of
    	>the FCS.  It will never be logged into, this is the
    	>INSPECT problem we have run into with it.
    
    	What means "...during the installation of the FCS."? Installation
    	of the image during system startup or installation of FCS during
    	VMSINSTAL?
    
    	
    3.	What do you suggest to overcome the INSPECT problem? 
    	(The only dirty way I found was to stop FCS, backup SYSUAF.DAT and 
    	RIGHTSLIST.DAT, delete the OAFC$* accounts, run INSPECT, restore 
        SYSUAF.DAT and RIGHTSLIST.DAT)
    
    
    	Stefan

    2. The ALL-IN-1 installation creates the accounts. We tell you about it
    in the log. We ask you for UICs, but we make up the passwords, since
    you'll never log into these accounts.
    
    
    3. Get INSPECT fixed to cope with this sort of requirement, which must
    be common to other products too.
    
    What exactly does INSPECT complain about?
    
    Run a batch job that uses the account every couple of weeks to make it
    look active? Login to it interactively occassionally?
    
    It's possible that you can disable a lot of the access to these
    accounts and have everything still work. Bob would need to confirm
    that!
    
    Graham

    There are a number of these `server' accounts that fail INSPECT (e.g.
    EPC$SERVER, DFS$SERVER.)  See note #466 in the IAMOK::INSPECT_SRF notes
    conference for a (oldish) discussion on this.

    Cheers,
        Paul

    (Strictly speaking, it is not INSPECT that is broken but the security
    policy [11.1].  INSPECT just checks your compliance with the policy.)

    
    >3. Get INSPECT fixed to cope with this sort of requirement, which must
    >be common to other products too.
    
    As .5 mentions, it is the security policy, not inspect that is broken.
    DNS$SERVER is another that we have had problems with.
    
    >What exactly does INSPECT complain about?
    
    It complains about a priv'd account not being logged into in x days, 
    same for OAFC$DEFAULT, but x is bigger for non-priv'd accounts.
    
    >Run a batch job that uses the account every couple of weeks to make it
    >look active? Login to it interactively occassionally?
    
    Won't work, I believe you actually have to log into the account. 
    
    >It's possible that you can disable a lot of the access to these
    >accounts and have everything still work. Bob would need to confirm
    >that!
    
    We REQUIRE OAFC$DEFAULT to be there so you can't do much about this
    one. You could always change the FCS startup file to start hte FCS
    under another account, I don't recommend it, but it would work as long
    as the account you use has the proper privs and quotas.
    
    --bob
    

	Hi,

	I asked our security manager what to do to avoid the described INSPECT
	conflict.

	He gave me a program that fixes the problem of template/broker accounts.
	It must be run regularly (eg. once a month from sched) to update the
	batch access date of the account. This stops inspect complaining about
	them.

	The program image may be copied from bern02::sys$kits:uaf_hack.exe

	Stefan