Re: [Condor-users] authenticating administrative access

[Dan Bradley <dan@xxxxxxxxxxxx>]

Ian,

To get more diagnostic information about how the security policy is 
being applied, add D_SECURITY to the debug flags (e.g. to ALL_DEBUG or 
to a particular problematic daemon's configuration).

When you make changes to Condor's authorization policy (ALLOW/DENY), you 
should do 'condor_reconfig -full' or restart condor.  (And verify that 
these operations actually happen, because condor_reconfig and 
condor_restart do not provide confirmation to the user about whether the 
command was accepted by the daemon or not.  This is broken and must be 
fixed.)  I only recently discovered the need for -full to clear out 
information cached in the authorization table.  In my opinion, this is 
also broken and must be fixed.

--Dan

Ian Stokes-Rees wrote:

> Hi,
>
> My condor installation is again reporting:
>
> 4/2 17:21:03 DaemonCore: PERMISSION DENIED to unknown user from host 
> <10.0.10.39:58837> for command 442 (REQUEST_CLAIM), access level DAEMON
> 4/2 17:21:04 DaemonCore: PERMISSION DENIED to unknown user from host 
> <10.0.10.39:37224> for command 443 (RELEASE_CLAIM), access level DAEMON
>
> in the StartLog, so clearly I do not have my security settings 
> correct, however I really am at a loss to figure out what I should be 
> putting in them.  The condor_config file is over 2000 lines long, and 
> section 3.6 (Security) is 30 pages.  I've read through it 3 times, and 
> really am no closer to understanding what a normal setup is.  I have 3 
> machines in my condor pool.  One is the head node with a public IP 
> address, the other two are on a private sub-net.  They have shared 
> home directories and a few other bits for OSG data and apps.  There is 
> nothing out of the ordinary for this.  Surely there should be some 
> example security policy which makes sense for this most standard of 
> configurations.
>
> Regards,
>
> Ian
>
> Dan Bradley wrote:
>
> > Dan Bradley wrote:
> >
> >  
> >
> > > However, if you just want to authenticate trusted administrative users 
> > > on each local machine, you can do that with FS authentication.  Example:
> > >
> > > # Authenticate administrative access so we can see if it
> > > # is an administrative account local to this machine.  If you
> > > # don't allow remote administrative commands (such as condor_reconfig 
> > > -all)
> > > # or all remote administrative commands are required to be
> > > # authenticated via some remote authentication method such as GSI,
> > > # then you could instead set this to REQUIRED.
> > > SEC_ADMINISTRATOR_AUTHENTICATION = PREFERRED
> > >
> > > ALLOW_ADMINISTRATOR = \
> > > root@$(UID_DOMAIN)/$(FULL_HOSTNAME) \
> > > condor@$(UID_DOMAIN)/$(FULL_HOSTNAME)
> > >    
> >
> >
> > I am surprised to find that this configuration causes rejection of 
> > unauthenticated administrative access, even if ALLOW_ADMINISTRATOR is 
> > configured to allow it (e.g. unauthenticated access from the central 
> > manager).  I had forgotten this detail of how authentication works in 
> > Condor.
> >
> > So if you want unauthenticated remote administrative access in addition 
> > to authenticated local administrative access (i.e. because you don't 
> > have a method of remote user authenticated configured), then you need to 
> > add ANONYMOUS to the allowed authentication methods.  Example:
> >
> > SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS, KERBEROS, GSI, ANONYMOUS
> > SEC_CLIENT_AUTHENTICATION_METHODS = FS, KERBEROS, GSI, ANONYMOUS
> >
> > Then you can authorize remote unauthenticated access by IP address in 
> > addition to local authenticated access by trusted accounts:
> >
> > ALLOW_ADMINISTRATOR = \
> > */$(CONDOR_HOST) \
> > root@$(UID_DOMAIN)/$(FULL_HOSTNAME) \
> > condor@$(UID_DOMAIN)/$(FULL_HOSTNAME)
> >
> > # clear out the older-style hostallow setting to avoid confusion
> > HOSTALLOW_ADMINISTRATOR =
> >
> > SEC_ADMINISTRATOR_AUTHENTICATION = PREFERRED
> >
> >
> > --Dan
> >
> > _______________________________________________
> > Condor-users mailing list
> > To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> > subject: Unsubscribe
> > You can also unsubscribe by visiting
> > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
> >
> > The archives can be found at: 
> > https://lists.cs.wisc.edu/archive/condor-users/
> >  
>
> --
> Ian Stokes-Rees                            W: http://sbgrid.org
> ijstokes@xxxxxxxxxxxxxxxxxxx               T: +1 617 418-4168
> SBGrid, Harvard Medical School             F: +1 617 432-5600
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at: 
> https://lists.cs.wisc.edu/archive/condor-users/
>