Re: [Condor-users] Questions about Security on Windows Install

["Ben Burnett" <burnett@xxxxxxxxxxx>]

Hi Michael:

>>>
1. The pool password allows communication between client machines and
condor_cred.
Is this authentication used so matchmaking can occur or is it so certain
machines
can submit jobs? The documentation (6.2.4) states that the pool password
is for
communication between execute machines and condor_credd, but then states the
password needs to be installed on all machines in the pools--hence the
confusion.
<<<


The pool password is used by the daemons to talk each other, and therefore
any two machines which are members of a secure pool will need the pool
password.


<<<
2. If run_as_owner is used, is the pool password not required?
>>>


The RunAsOwner attribute is a Windows kludge, of sorts.  On UNIX, when a
user runs a job, the job runs using the user's credentials (this is all
under normal circumstances; you can configure this to not be the case if
you like--as with the rest of Condor, you can configure user usage as
complexly or as simply as you need it to be).  Anyway, on Windows, things
were never this easy, a submitter's user account may or may not exist on a
remote system.  So, this means that first Condor creates a "nobody" user
account for each slot to run user jobs under. What RunAsOwner does is try
and use an account on the remote machine that just happens to have the
same username and password.


<<<
3. If a pool password is used, does it not have access to the registry?
>>>


Condor stores the pool password, like user passwords, in the registry.


<<<
4. We are concerned about how passwords are stored in the registry and how
they are
passed across the ethernet. When a user adds their credentials, my
understanding is
that it is stored on the registry (encrypted via eSSPI). When a user
submits a job,
how is this users' credentials being authenticated? In other words is
encryption
occuring across the ethernet as well or is the password passed over the
network more
than once? Can someone help me understand this encryption process?
>>>


The passwords are well protected in the registry, and failing a programer
error, your password should be completely safe in the LSA.  To my foggy
memory the user's credentials, on Windows, are all stored in the central
condor_credd, which all other daemons can communicate with securely--via
the pool password.  The condor_credd server sends the user's credentials
to the requesting system (the one doing the submitting)--securely, again,
via the pool password--which can then be used to authenticate on the
execution machine. The submitter machine can optionally cache the user's
credentials (securely as well), eliminating one round trip the to the
central condor_credd during the next job submission.  So, the user's
credentials can effectively be made to be passed once per submission,
assuming they are cached on the submit node.


<<<
5. Does condor support AD, AD/LDAP, or a Radius server? We are wondering
if it is
possible to avoid typing in passwords and having these passed over the
ethernet and
it was suggested that using AD/LDAP would eliminate this security concern.
>>>


There have been some users that have user AD with some success with
Condor.  The use of AD with Condor, however, will still not eliminate the
credential problem above, it will just make it easier to ensure that all
user's exist on each machine.  Some work to integrate AD with Condor more
tightly was proposed in the past, but has been tabled (or rather put off
by more pressing matters, more likely) for the mean time.  Hopefully we
will see this work reinitiated, as it seems it would be of great use in
Condor, having password-less user job submissions.

Hope the helped clear some things up.  And any security gurus out there
please correct me if I misspoken at all.

Regards,
-B