Re: [HTCondor-users] Authentication for university/local users - kerberos and mapping user names to ClassAds

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

Hi Luke,

Apologies, I know very little about Kerberos (may I interest you in grid certificates? ;).  However, from these lines:

08/07/14 14:30:20 HANDSHAKE: client received (method == 64)
08/07/14 14:30:20 AUTHENTICATE: method 64 (KERBEROS) failed.

It appears Kerberos was tried but failed pretty quickly.  Perhaps the misconfiguration was client side?  You can see from:


_condor_TOOL_DEBUG=D_SECURITY condor_submit -debug SUBMIT_FILE

The combination of the "_condor_TOOL_DEBUG" env var and "-debug" should cause the same amount of information to be logged to the console.

Brian

On Aug 7, 2014, at 9:09 AM, L Kreczko <L.Kreczko@xxxxxxxxxxxxx> wrote:

> Hi Brian,
> 
> Thank you, this gives me additional output:
> https://gist.github.com/kreczko/9bac4a9adbfe50157b86
> 
> However, nothing of value (to me). I am trying to figure out at which
> step the kerberos authentication fails.
> At which point does HTCondor check the validity of the kerberos
> ticket? Would this appear somewhere in the logs?
> 
> Cheers,
> Luke
> 
> On 7 August 2014 14:19, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:
>> Hi Luke,
>> 
>> Maybe try again with D_SECURITY?  That should provide much more information about the authentication process and failures.
>> 
>> Brian
>> 
>> On Aug 7, 2014, at 6:06 AM, L Kreczko <L.Kreczko@xxxxxxxxxxxxx> wrote:
>> 
>>> Dear all,
>>> 
>>> I cannot find a problem with the configuration and I have enabled
>>> D_FULLDEBUG for one of the schedulers.
>>> The additional information I get is:
>>> 08/07/14 12:01:05 DC_AUTHENTICATE: authentication of
>>> <137.222.79.12:34269> did not result in a valid mapped user name,
>>> which is required for this command (1112 QMGMT_WRITE_CMD), so
>>> aborting.
>>> 08/07/14 12:01:05 DC_AUTHENTICATE: reason for authentication failure:
>>> AUTHENTICATE:1003:Failed to authenticate with any
>>> method|AUTHENTICATE:1004:Failed to authenticate using
>>> KERBEROS|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
>>> 08/07/14 12:01:07 DC_AUTHENTICATE: authentication of
>>> <137.222.79.12:39737> did not result in a valid mapped user name,
>>> which is required for this command (1112 QMGMT_WRITE_CMD), so
>>> aborting.
>>> 08/07/14 12:01:07 DC_AUTHENTICATE: reason for authentication failure:
>>> AUTHENTICATE:1003:Failed to authenticate with any
>>> method|AUTHENTICATE:1004:Failed to authenticate using
>>> KERBEROS|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
>>> 08/07/14 12:01:09 DC_AUTHENTICATE: authentication of
>>> <137.222.79.12:33654> did not result in a valid mapped user name,
>>> which is required for this command (1112 QMGMT_WRITE_CMD), so
>>> aborting.
>>> 08/07/14 12:01:09 DC_AUTHENTICATE: reason for authentication failure:
>>> AUTHENTICATE:1003:Failed to authenticate with any
>>> method|AUTHENTICATE:1004:Failed to authenticate using
>>> KERBEROS|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
>>> 
>>> Where does HTCondor try to map the user?
>>> The kerberos map file does the translation Kerberos realm ->
>>> UID.domain and the user exists on submission machine, worker node and
>>> scheduler.
>>> HTCondor (8.2.1) is running as root (as per manual).
>>> 
>>> I would be very grateful for any suggestions or hints as to what I am
>>> doing wrong. According to
>>> https://lists.cs.wisc.edu/archive/htcondor-users/2014-July/msg00103.shtml
>>> it should work.
>>> 
>>> Cheers,
>>> Luke
>>> 
>>> On 10 April 2014 17:43, L Kreczko <L.Kreczko@xxxxxxxxxxxxx> wrote:
>>>> Dear all,
>>>> 
>>>> I am currently trying to enable our university users to use an HTCondor
>>>> cluster that is configured for the grid (via ARC CE). The goal is to
>>>> 1) give local users access to the pool
>>>> 2) provide fine-grained mapping (user -> AccountingGroup) and therefore
>>>> quota
>>>> 
>>>> For this I had a look at the HTCondor documentation for password and
>>>> kerberos authentication.
>>>> Password seems easy to set up, but since the local account authentication
>>>> uses kerberos I wanted to try it first. For this I added [1] in the
>>>> configuration and [2] on the submitting node as well as the
>>>> scheduler/negotiator. The values inside '<>' are of course substituted in
>>>> the actual configs.
>>>> 
>>>> However, after getting a kerberos ticket (kinit) I still can't authenticate
>>>> to condor:
>>>> AUTHENTICATE:1003:Failed to authenticate with any method
>>>> AUTHENTICATE:1004:Failed to authenticate using KERBEROS
>>>> AUTHENTICATE:1004:Failed to authenticate using PASSWORD
>>>> AUTHENTICATE:1004:Failed to authenticate using FS
>>>> 
>>>> Am I missing something or doing something wrong? What is the best way to
>>>> debug this?
>>>> 
>>>> 
>>>> Secondly once the above works I would like to map individual users.
>>>> Currently I use [4] to fill the AccountingGroup automatically.
>>>> For the university users I would like to end up with a structure like
>>>> physics.astro.<user a>
>>>> physics.particle.<user b>
>>>> etc.
>>>> One way to do it is to assign these users to groups like astro, particle,
>>>> etc and assume the 'physics.' part if they don't have a certificate.
>>>> However, this is problematic as the primary group for all users is, and has
>>>> to be for various reasons, "users". Therefore I am looking for an
>>>> alternative way to make this mapping.
>>>> I had a look at the Unified Map File, but it does map users to a condor user
>>>> name. Is there an easy way to create AcctGroup, AcctSubGroup?
>>>> Ideally I would have one file on the scheduler/negotiator with the content
>>>> # user_name AcctGroup AcctSubGroup
>>>> <user a> physics astro
>>>> <user b> physics particle
>>>> It is easy to make a script to parse the above, so probably the correct
>>>> question is:
>>>> How do I make condor use script (let's say python) in an ifThenElse to fill
>>>> a ClassAd in [4]?
>>>> 
>>>> Sorry for the long email and thank you in advance for any help.
>>>> 
>>>> Cheers,
>>>> Luke
>>>> 
>>>> 
>>>> [1]
>>>> # Authentication
>>>> SEC_PASSWORD_FILE = /etc/condor/pool_password
>>>> SEC_DEFAULT_AUTHENTICATION = REQUIRED
>>>> SEC_READ_AUTHENTICATION = OPTIONAL
>>>> SEC_CLIENT_AUTHENTICATION = REQUIRED
>>>> SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS,KERBEROS
>>>> SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD,KERBEROS
>>>> SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD,KERBEROS
>>>> SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE,KERBEROS
>>>> SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,KERBEROS,CLAIMTOBE
>>>> KERBEROS_MAP_FILE = /etc/condor/kerberos.map
>>>> 
>>>> [2]
>>>> cat /etc/condor/kerberos.map
>>>> <Kerberos realm> = <UID domain>
>>>> 
>>>> [3]
>>>> [libdefaults]
>>>> default_realm = <Kerberos realm>
>>>> dns_lookup_realm = true
>>>> dns_lookup_kdc = true
>>>> 
>>>> [realms]
>>>> <Kerberos realm> = {
>>>> kdc = <server>:88
>>>> }
>>>> 
>>>> [domain_realm]
>>>> <Kerberos realm> = <Kerberos realm>
>>>> .<Kerberos realm> = <Kerberos realm>
>>>> 
>>>> [4]
>>>> AcctSubGroup = \
>>>> ifThenElse(regexp("prd",Owner), "production",\
>>>> ifThenElse(regexp("pil",Owner),"pilot",\
>>>> ifThenElse(regexp("sgm",Owner),"admin",\
>>>> x509UserProxyVOName)))
>>>> # This one is not useful for grid sites but is useful if you want to
>>>> # implement user based quotas:
>>>> # group_<name>.<subgroup>.<user name>
>>>> AcctGroup = strcat("group_", x509UserProxyVOName, ".",AcctSubGroup, ".",
>>>> Owner)
>>>> # condor uses AcctGroup, but some monitoring scripts use AccountingGroup
>>>> # let's have both.
>>>> AccountingGroup = $(AcctGroup)
>>>> ConcurrencyLimits = strcat(AcctGroup, ",", AcctSubGroup, ",", Owner)
>>>> SUBMIT_EXPRS = $(SUBMIT_EXPRS) AcctGroup, AcctSubGroup, AccountingGroup,
>>>> ConcurrencyLimits
>>>> --
>>>> *********************************************************
>>>> Dr Lukasz Kreczko            +44 (0)117 928 8724
>>>> CMS Group
>>>> School of Physics
>>>> University of Bristol
>>>> *********************************************************
>>> 
>>> 
>>> 
>>> --
>>> *********************************************************
>>> Dr Lukasz Kreczko            +44 (0)117 928 8724
>>> CMS Group
>>> School of Physics
>>> University of Bristol
>>> *********************************************************
>>> _______________________________________________
>>> HTCondor-users mailing list
>>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>>> subject: Unsubscribe
>>> You can also unsubscribe by visiting
>>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>>> 
>>> The archives can be found at:
>>> https://lists.cs.wisc.edu/archive/htcondor-users/
>> 
>> 
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>> 
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
> 
> 
> 
> -- 
> *********************************************************
>  Dr Lukasz Kreczko            +44 (0)117 928 8724
>  CMS Group
>  School of Physics
>  University of Bristol
> *********************************************************
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/