Re: [HTCondor-users] Using Kerberos for HTCondor with Centrify?

[Oliver Freyermuth <freyermuth@xxxxxxxxxxxxxxxxxx>]

Dear Michael,

no Centrify here, but plain Kerberos (with sssd adding in ldap). We use Kerberos both for user and for Condor daemon authentication. 
Our UID_DOMAIN actually is not in all caps, but we have:

CERTIFICATE_MAPFILE = /etc/condor/certificate_mapfile
which contains:
KERBEROS host/[^@]*@(.*) condor_pool@\1
KERBEROS ([^/]*)/?[^@]*@(.*) \1@\2

And we also have:
KERBEROS_MAP_FILE = /etc/condor/kerberos_mapfile
which contains:
OUR_REALM_IN_ALL_CAPS = our_uid_domain_not_in_caps

Then, we equip each host with a keytab with host/FQDN@REALM . 

For the ALLOW rules, we basically do what puppet-htcondor[0] does out of the box. That's basically, for the daemons:
 ALLOW_DAEMON = condor@$(UID_DOMAIN), \
                condor@$(UID_DOMAIN)/*.$(UID_DOMAIN), \
                condor_pool@$(UID_DOMAIN), \
                condor_pool@$(UID_DOMAIN)/*.$(UID_DOMAIN), \
                $(FULL_HOSTNAME)
and then of course you need to set up things similar for the users and different services, for example:
USERS = *@$(UID_DOMAIN)
CMS = \
      condor_pool@$(UID_DOMAIN)/condor-cm1.example.com, \
      condor_pool@$(UID_DOMAIN)/condor-cm2.example.com, \
      root@$(UID_DOMAIN)/condor-cm1.example.com, \
      root@$(UID_DOMAIN)/condor-cm2.example.com
ALLOW_WRITE = $(CMS), $(CES), $(WNS)
etc. and then:
SEC_DEFAULT_AUTHENTICATION = REQUIRED
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = KERBEROS,SSL
SEC_CLIENT_AUTHENTICATION_METHODS = KERBEROS,SSL
SEC_READ_AUTHENTICATION_METHODS = KERBEROS,SSL
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = KERBEROS,SSL
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = KERBEROS,SSL

There are a few gotchas with Kerberos still. See for example:
 https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=6970
or also the recent fix here:
 https://github.com/htcondor/htcondor/pull/103
I think most people are not using Kerberos for inter-daemon authentication, but for users "only", but things are improving in each release :-). 

On our end, we use the PERSISTENT kernel keyring as credential cache (default with CentOS 7 and higher) which works well for us. 
Users need to prolong their tickets manually, though, unless you automate that for them (we don't, since we found it questionable to handle their credentials for them). 
I think there are developments ongoing to have the HTCondor credd take care of that in the future. 
Be aware though, when fetching tickets from different realms, you may run into issues (HTCondor does not handle multi-realm caches well yet,
but it's not the only software not doing that ;-) ). 

Hope this helps,
	Oliver

[0] https://github.com/HEP-Puppet/htcondor

Am 02.05.20 um 22:24 schrieb Michael Pelletier via HTCondor-users:
> Hi folks,
> 
> If anyone's using the Centrify DirectConnect software for Linux Active Directory integration, and has any insights on using the Kerberos tickets generated via that interface for HTCondor authentication, I'd appreciate any tips and pointers you might have to offer.
> 
> Or even if you're using HTCondor without Centrify but with Kerberos auth, that'd be terrific too.
> 
> My "klist" command shows a TGT renewable for five days, and my UID_DOMAIN is set (in all-caps) to match my Kerberos realm, but I'm not quite sure where to go from there. Thanks for any insights!
> 
> Michael V Pelletier
> Principal Engineer
> Raytheon Technologies
> 
> _______________________________________________
> 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/
> 


-- 
Oliver Freyermuth
UniversitÃt Bonn
Physikalisches Institut, Raum 1.047
NuÃallee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature