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

[L Kreczko <L.Kreczko@xxxxxxxxxxxxx>]

Hi Brian,

Thanks again for your answer.

On 7 August 2014 15:19, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:
> Hi Luke,
>
> Apologies, I know very little about Kerberos (may I interest you in grid certificates? ;).  However, from these lines:
I wish it would be that simple. Grid certificates are our current
solution for the particle physics group, but we are also in need to
authenticate other university users.
>
> 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.
Thanks, that provided some more clues:
08/07/14 15:24:32 KERBEROS: krb5_unparse_name: host/lcgce02.phy.bris.ac.uk@
08/07/14 15:24:32 KERBEROS: no user yet determined, will grab up to slash
08/07/14 15:24:32 KERBEROS: picked user: host
08/07/14 15:24:32 KERBEROS: remapping 'host' to 'condor'
08/07/14 15:24:32 Failed to map principal to user
It seems it tries to read the scheduler principal (lcgce02), which
does not exist and for some reason is picking user host and then
remapping to condor.
There is no sign of the actual user name (owner of kerberos ticket).
>From the lines above I assume I have to set-up host principals for the
schedulers and the workernodes. Is that correct? I thought (based on a
previous answer on this mailing list) that they are not needed.

Cheers,
Luke
>
> 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/
>
>
> _______________________________________________
> 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
*********************************************************