Re: [Condor-users] authenticating administrative access

[Ian Stokes-Rees <ijstokes@xxxxxxxxxxxxxxxxxxx>]

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