Re: [Condor-users] How can I explicitly weaken security requirements *just* for condor.cs.wisc.edu ad updates?

[Zachary Miller <zmiller@xxxxxxxxxxx>]

On Tue, Mar 15, 2005 at 02:47:06PM +0000, David McBride wrote:

> Seperately, I have configured the master pool controller to send
> periodic updates to condor.cs.wisc.edu.  However, my
> authenticate-everything-by-default security configuration is preventing
> successful updates from taking place:
> 
> 
> 3/15 14:24:53 AUTH_ERROR: Client/server realm mismatch in initial ticket request
> 3/15 14:24:53 AUTHENTICATE: no available authentication methods succeeded, failing!
> 3/15 14:24:53 ERROR: SECMAN:2004:Failed to start a session with TCP|AUTHENTICATE:1003:Failed to authenticate with any method|AUTHENTICATE:1004:Failed to authenticate using KERBEROS

right, kerberos isn't going to work cross-realm...

and our collector does not allow the "ANONYMOUS" method...


> I would like to weaken my security configuration to allow
> unauthenticated state updates to the condor.cs.wisc.edu server, in much
> the same way that I allow anonymous access _just_ for read-only
> operations.
> 
> However, after reviewing the security documentation in the manual, I
> can't see any obvious way of reducing the minimum security level of the
> off-site connection without also affecting other purely local actions.

okay.  you are on the right track.  but there's a subtle difference between
authenticating using the "ANONYMOUS" method, and not authenticating at all.

what you want to say is this:

SEC_CLIENT_AUTHENTICATION = OPTIONAL
SEC_CLIENT_ENCRYPTION = OPTIONAL
SEC_CLIENT_INTEGRITY = OPTIONAL

all outgoing connections look first at SEC_CLIENT_*, and fall back to
SEC_DEFAULT_* if the first is not found.  this tells the client it doesn't
need to authenticate unless the server asks it to, which is what you want.

so our collector wont ask you to authenticate your update, but your local
daemons will still require it.  (they will use the SEC_DEFAULT_*)


> (I assume that the state update command being sent to the Condor master
> falls under the SEC_WRITE_* class of configuration options; naturally, I
> cannot simply allow anonymous authentication for all WRITE operations
> without also compromising local security.)

acutally, all outgoing commands look at SEC_CLIENT_*.  the other levels (READ,
WRITE, ADMINISTRATOR) are looked at only by the server side to enforce policy
on incoming commands.


please let me know if that wasn't clear.


side note:

> I'm running a Condor pool with v6.7.5 with the following authentication
> rules:
[snip]
> # Anonymous access is sufficient for read access.
> SEC_CLIENT_AUTHENTICATION_METHODS = KERBEROS, ANONYMOUS
> SEC_READ_AUTHENTICATION_METHODS = KERBEROS, ANONYMOUS

you'll still be using KERBEROS for read commands.  while both the client side
(which looks at SEC_CLIENT_*) and the server side (which looks at SEC_READ_*)
both have anonymous in the list, the list is ordered.  you should say:

  SEC_READ_AUTHENTICATION_METHODS = ANONYMOUS, KERBEROS

instead.  it is the order of the methods that the server sees that is used.


cheers,
-zach