[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Questions about Security on Windows Install
- Date: Mon, 12 Oct 2009 13:44:14 +0200
- From: "Ochtrup, Carsten" <carsten.ochtrup@xxxxxxx>
- Subject: Re: [Condor-users] Questions about Security on Windows Install
is the pool password the only way for the communication with the credd daemon?
What about using SSL instead of the pool password method?
Even the registry might be a safe place, distributing the same pool password to all PCs would mean to distribute one and the same key to decrypt the passwords to all these machines. This is a security issue at bigger installations.
Or is the pool password meant as sitting on top of the daemon authentications, thus it requires SSL to establish the daemon communication and the pool password to ask for the credentials?
Von: condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] Im Auftrag von Ben Burnett
Gesendet: Freitag, 9. Oktober 2009 05:31
An: Condor-Users Mail List
Betreff: Re: [Condor-users] Questions about Security on Windows Install
1. The pool password allows communication between client machines and
Is this authentication used so matchmaking can occur or is it so certain
can submit jobs? The documentation (6.2.4) states that the pool password
communication between execute machines and condor_credd, but then states the
password needs to be installed on all machines in the pools--hence the
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
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
passed across the ethernet. When a user adds their credentials, my
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
occuring across the ethernet as well or is the password passed over the
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
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.
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
You can also unsubscribe by visiting
The archives can be found at: