{section: Enabling Authentication for your Execute Machines}

To enable authentication on your pool's execute machines, you essentially want to add the following to the condor_config on your execute machines:
{code}
SEC_DAEMON_AUTHENTICATION = REQUIRED
{endcode}

However, it is not quite that simple.  If you haven't already, you will need to configure an authentication method that works from daemon-to-daemon, such as =PASSWORD, SSL, GSI, KERBEROS,= (or =IDTOKENS,= if using a very recent HTCondor version)

You can check your current security settings by running:
{code}
condor_config_val -dump SEC_
{endcode}

Based on those results, find the scenario below that matches your configuration for instructions.

====

{subsection: Scenario 1: Authentication is already required for all daemon-to-daemon communications}
If you are flocking to another pool, or jobs are flocking into your pool, you must also have daemon-to-daemon authentication configured for everything flocking in and/or out as well.

Assuming that is true, you are all set and can follow the workaround options in the HTCONDOR2020-0002 CVE.

If you do not have daemon-to-daemon authentication configured for flocking, keep reading and follow the instructions below.

====

{subsection: Scenario 2: No authentication is set up at all, and no jobs are flocking in or out}
In this scenario, you have not configured any authentication.  How you want to set up authentication varies a lot depending on your computing environment.  If your pool is "self contained" and is not flocking to or from other pools, the easiest way to do this is to set up =PASSWORD= authentication.  Instructions for doing that are located on the Wiki here:

_:https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToEnablePoolPassword

Then you are all set and can follow the workaround options in the HTCONDOR2020-0002 CVE.

Other options for types of authentication that could work here are =SSL, KERBEROS, GSI, and IDTOKENS.=  Please consult the security section of the manual for more information on those authentication methods and their configuration:

_:https://htcondor.readthedocs.io/en/latest/admin-manual/security.html

====

{subsection: Scenario 3: Jobs are flocking to other pools, or jobs are flocking into your pool}

This type of setup can vary drastically as it depends on how you want to configure your own pool in addition to how other administrators have configured the pools you are flocking to and/or from.  This configuration can be quite involved, and if possible we highly recommend upgrading to the latest version of HTCondor.

Please review the security section of the manual to become acquainted with the general security framework if you are not already:
_:https://htcondor.readthedocs.io/en/latest/admin-manual/security.html

Because we cannot control the configuration of remote pools, the best we can do is secure communications within your own pool.  Jobs that flock to other pools may still be vulnerable to this issue unless you have set up authentication between your SchedD and the remote pool, in which case you might belong to Scenario 2 above.

If you cannot upgrade and wish to continue, you will be setting up your pool to use PASSWORD authentication internally.  But be aware that using this configuration, jobs that flock in or out will not necessarily be authenticated.

Follow the instructions above for configuring PASSWORD authentication.  However, instead of the config shown there, use this instead:

{code}
...
{endcode}