[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Condor-users] Kerberos problem



Hi,
	I'm starting the rollout of Condor at our site, and am trying to
get the most secure configuration reasonably possible.  As such, I'm
trying to get Kerberos working.  Currently, I have only a single node
that is my test box - it's the central manager, submit node, and single
execute node.  I know that's not a good long term strategy, but it's a
nice simple case for initial configuration testing.  

The problem:  condor_status running as root works, but when running as
another non-privileged user, it fails with:
AUTHENTICATE:1003:Failed to authenticate with any method
AUTHENTICATE:1004:Failed to authenticate using KERBEROS

Details:  
Condor 6.6.7
Kerberos server is Active Directory on Win2003
OS is Fedora Core 1
PAM is configured to use Kerberos, so if I create a local user with the
same id as in AD (e.g. miskellc) with no password, logging in with my
Windows password lets me in, and gives me a kerberos ticket

The relevant portions of the condor_config file are:
SEC_DEFAULT_ENCRYPTION = REQUIRED
SEC_DEFAULT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_INTEGRITY = REQUIRED
SEC_CLIENT_ENCRYPTION = REQUIRED
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_CLIENT_INTEGRITY = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = KERBEROS
SEC_CLIENT_AUTHENTICATION_METHODS = KERBEROS
KERBEROS_MAP_FILE = /usr/local/condor/etc/condor.kmap

ALLOW_READ = condor@xxxxxxxxxxxxxxxx/*.agresearch.co.nz,
*@agresearch.co.nz/*.agresearch.co.nz
ALLOW_WRITE = condor@xxxxxxxxxxxxxxxx/*.agresearch.co.nz,
*@agresearch.co.nz/*.agresearch.co.nz
ALLOW_ADMINISTRATOR = condor@xxxxxxxxxxxxxxxx/*.agresearch.co.nz
ALLOW_CONFIG = condor@xxxxxxxxxxxxxxxx/*.agresearch.co.nz
ALLOW_OWNER = root@xxxxxxxxxxxxxxxx/$(HOSTNAME)
ALLOW_NEGOTIATOR = condor@xxxxxxxxxxxxxxxx/$(NEGOTIATOR_HOST)

I've created a host/hostname.agrseearch.co.nz principal in AD and put
the keytab in /etc/krb5.keytab, and this appears to be being used by the
daemons to communicate with each other (I know this because when I had
the file incorrectly named, nothing worked ;-)).  So this means that
Kerberos is fundamentally working.

I login as a normal user (miskellc), and the output of klist is:
***********************************************************
Ticket cache: FILE:/tmp/krb5cc_501_wrmERU
Default principal: miskellc@xxxxxxxxxxxxxxxx

Valid starting     Expires            Service principal
11/25/04 11:22:21  11/25/04 21:22:26
krbtgt/AGRESEARCH.CO.NZ@xxxxxxxxxxxxxxxx
        renew until 11/26/04 11:22:21


Kerberos 4 ticket cache: /tmp/tkt501
klist: You have no tickets cached
***********************************************************

Running condor_status with the handy dandy -debug option gives the
following for root
***********************************************************
11/25 15:17:01 KEYCACHE: created: 8267658
11/25 15:17:01 STARTCOMMAND: starting 5 to <AAA.BBB.CCC.DDD:9618> on TCP
port 36790.
11/25 15:17:01 SECMAN: command 5 to <AAA.BBB.CCC.DDD:9618> on TCP port
36790.
11/25 15:17:01 SECMAN: new session, doing initial authentication.
11/25 15:17:01 SECMAN: Auth methods: KERBEROS
11/25 15:17:01 HANDSHAKE: in handshake(my_methods = 'KERBEROS')
11/25 15:17:01 HANDSHAKE: handshake() - i am the client
11/25 15:17:01 HANDSHAKE: sending (methods == 64) to server
11/25 15:17:01 HANDSHAKE: server replied (method = 64)
11/25 15:17:01 Server principal is
host/XXXXXXX.agresearch.co.nz@xxxxxxxxxxxxxxxx
11/25 15:17:01 Trying to get credential
11/25 15:17:01 Success..........................
11/25 15:17:01 Remote host is AAA.BBB.CCC.DDD
11/25 15:17:01 Authentication was a Success.
11/25 15:17:01 SECMAN: successfully enabled message authenticator!
11/25 15:17:01 SECMAN: successfully enabled encryption!
11/25 15:17:01 SECMAN: added session XXXXX:23809:1101349021:6 to cache
for 60 seconds.
11/25 15:17:01 SECMAN: startCommand succeeded.

Name          OpSys       Arch   State      Activity   LoadAv Mem
ActvtyTime

XXXX.agresea LINUX       INTEL  Unclaimed  Idle       0.030  1008
0+00:00:05

                     Machines Owner Claimed Unclaimed Matched Preempting

         INTEL/LINUX        1     0       0         1       0          0

               Total        1     0       0         1       0          0
***********************************************************
Whereas running it as miskellc gives:
***********************************************************
11/25 15:17:07 KEYCACHE: created: 8267658
11/25 15:17:07 STARTCOMMAND: starting 5 to <AAA.BBB.CCC.DDD:9618> on TCP
port 36791.
11/25 15:17:07 SECMAN: command 5 to <AAA.BBB.CCC.DDD:9618> on TCP port
36791.
11/25 15:17:07 SECMAN: new session, doing initial authentication.
11/25 15:17:07 SECMAN: Auth methods: KERBEROS
11/25 15:17:07 HANDSHAKE: in handshake(my_methods = 'KERBEROS')
11/25 15:17:07 HANDSHAKE: handshake() - i am the client
11/25 15:17:07 HANDSHAKE: sending (methods == 64) to server
11/25 15:17:07 HANDSHAKE: server replied (method = 64)
11/25 15:17:07 Server principal is
host/XXXXX.agresearch.co.nz@xxxxxxxxxxxxxxxx
11/25 15:17:07 Acquiring credential for user
11/25 15:17:07 No credentials found with supported encryption types
11/25 15:17:07 AUTHENTICATE: method 64 (KERBEROS) failed.
11/25 15:17:07 HANDSHAKE: in handshake(my_methods = '')
11/25 15:17:07 HANDSHAKE: handshake() - i am the client
11/25 15:17:07 HANDSHAKE: sending (methods == 0) to server
11/25 15:17:07 HANDSHAKE: server replied (method = 0)
11/25 15:17:07 AUTHENTICATE: no available authentication methods
succeeded, failing!
AUTHENTICATE:1003:Failed to authenticate with any method
AUTHENTICATE:1004:Failed to authenticate using KERBEROS
***********************************************************

The obvious difference is just after it mentions what the Server
principal is - for root it says "Trying to get credential", but for
miskellc it sais "Acquiring credential for user".

I get the feeling I'm missing something obvious.  I would be grateful if
somebody could point that out, or suggest some additional
debugging/logging I could turn on that might indicate what's wrong?

Thanks,

Craig Miskell,
Technical Support,
AgResearch Invermay
03 489-9279
We categorically reject the argument that a vendor has a right 
under the  Constitution or otherwise to send unwanted material 
into the home of another.  [...]the answer is that no one has a 
right to press even 'good' ideas on an  unwilling recipient.  	--
 Chief Justice Berger, SCotUS 
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================