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

[Condor-users] User based security in Condor 7.6.1 - domain not resolved



I'm playing around with the user based security (authentication) on a
Windows machine running Windows XP x64. The machine is a member of an
Active Directory domain and all user accounts are domain accounts.
Let's call our domain "foo". So I entered into the local config file
on the machine:

ALLOW_READ            = */*.foo.de
ALLOW_WRITE           = */*.foo.de
##
## Administrative permissions needed to configure the system.
## Only trusted admin users should have this right!
##
ALLOW_ADMINISTRATOR   = FelixWolfheimer@foo/*.foo.de
ALLOW_CONFIG          = FelixWolfheimer@foo/*.foo.de
ALLOW_OWNER           = FelixWolfheimer@foo/*.foo.de

#######################################################################
##
## Security settings (daemon communication)
##
#######################################################################
##
## Condor internal communication between daemons. Trust every daemon connecting
## from any machine in cst.de domain.
##
ALLOW_DAEMON = */*.foo.de
ALLOW_NEGOTIATOR = */*.foo.de

##
## Authentication methods are configured here
##
## All names are accepted as they are announced (CLAIMTOBE), i.e. we don't
## verify that user foo@bar is really this user or if someone tries to trick
## the system.
##
SEC_DEFAULT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
SEC_DAEMON_AUTHENTICATION_METHODS = CLAIMTOBE
SEC_NEGOTIATOR_AUTHENTICATION_METHODS = CLAIMTOBE

# Clear out any old-style HOSTALLOW settings:
HOSTALLOW_READ =
HOSTALLOW_WRITE =
HOSTALLOW_DAEMON =
HOSTALLOW_NEGOTIATOR =
HOSTALLOW_ADMINISTRATOR =
HOSTALLOW_OWNER =

The problem occurs for the admin settings (e.g. ALLOW_ADMINISTRATOR)
because the domain is not resolved correctly by Condor. I switched on
the debug level to "D_SECURITY" and found in the MasterLog file after
issuing for example "condor_off":

06/16/11 10:52:19 DaemonCore::Wake_up_select called from an unknown
thread. windows tid = 122006/16/11 10:52:19 DC_AUTHENTICATE: received
DC_AUTHENTICATE from <10.2.4.60:1952>
06/16/11 10:52:19 DC_AUTHENTICATE: generating 3DES key for session
livingstone:23992:1308214339:6...
06/16/11 10:52:19 SECMAN: new session, doing initial authentication.
06/16/11 10:52:19 HANDSHAKE: in handshake(my_methods = 'CLAIMTOBE')
06/16/11 10:52:19 HANDSHAKE: handshake() - i am the server
06/16/11 10:52:19 HANDSHAKE: client sent (methods == 2)
06/16/11 10:52:19 HANDSHAKE: i picked (method == 2)
06/16/11 10:52:19 HANDSHAKE: client received (method == 2)
06/16/11 10:52:19 Authentication was a Success.
06/16/11 10:52:19 ZKM: setting default map to FelixWolfheimer
06/16/11 10:52:19 ZKM: post-map: current user is 'FelixWolfheimer'
06/16/11 10:52:19 ZKM: post-map: current domain is '(null)'
06/16/11 10:52:19 ZKM: post-map: current FQU is 'FelixWolfheimer'
06/16/11 10:52:19 DC_AUTHENTICATE: authentication of 10.2.4.60 complete.
06/16/11 10:52:19 DC_AUTHENTICATE: added incoming session id
livingstone:23992:1308214339:6 to cache for 80 seconds (lease is
3620s, return address is unknown).
06/16/11 10:52:19 DC_AUTHENTICATE: Success.
06/16/11 10:52:19 PERMISSION DENIED to FelixWolfheimer from host
10.2.4.60 for command 454 (DAEMONS_OFF), access level ADMINISTRATOR:
reason: cached result for ADMINISTRATOR; see first case for the full
reason

It seems that the line

06/16/11 10:52:19 ZKM: post-map: current domain is '(null)'

is somehow the critical one. When I open cmd and enter "whoami" I get:

foo\felixwolfheimer

Does anyone have an idea why the domain is not resolved properly by
the Condor daemons?

Thanks for your help!