Skip to content

Data Access configuration

Access to NXCALS system is based on Kerberos authentication. Any NXCALS client application must obtain a valid Kerberos ticket (or renew an existing one) using kinit tool. The acquired authentication is limited in time. Its issue and expiration timestamps can be verified using klist command.

Long-term encryption keys necessary to encrypt/decrypt Kerberos tickets for one or more access requesting accounts (principals) can be store in keytab file.

Configurations tasks that have to be performed for: * Kerberos installation * Generation of Kerberos keytab file (useful for user/service account impersonation and continuous execution) * Creation of a trustStore file for the JDK (optional - please see below)

Kerberos installation

1. Install Kerberos client

This will allow access to any Kerberos protected services once a user has successfully logged into the system.

Important

Most likely the Kerberos software installation is not required on standard CERN machines (running Linux, Windows or Mac OSX), and the steps below can be simply omitted.

On the contrary if the installation is necessary please follow instructions below (given for Ubuntu Linux):

Install krb5-user package which provides the basic kinit, klist, kdestroy, and kpasswd clients:

sudo apt-get krb5-user

2. Configure local Kerberos client Configure Kerberos realm and write CERN.CH when requested to complete the realm after executing the following command:

sudo dpkg-reconfigure krb5-config
Full explanation of how to configure Kerberos Linux Client you can find on the following address: https://help.ubuntu.com/lts/serverguide/kerberos.html

Kerberos keytab file generation

NXCALS client, by default will try to acquire the user Kerberos credentials from the locally available krb ticket cache. Thus, there is no need to specify any Kerberos related properties to run the client software. Even though, this approach is quite useful for one-go analysis execution, it comes with a cost. This authentication strategy relies on the cached ticket. The mechanism will stop working once the krb cache gets invalidated (around 24 hours since initialization).

If your intention is to run the client software constantly, like analysis that has to run for days, or periodically, without user interaction/supervision, then you will need to create a keytab file and declare its path on the corresponding NXCALS Kerberos properties.

Hint

Another way that you can solve this issue, is to add a cron job entry that will re-initialize your krb ticket, like the following:

* 8,12,19 * * * kinit -f -r 5d -kt /path/to/your.keytab [username] && aklog
Where you should provide your CERN login as username.

Be aware that the krb ticket has a validity of max 24 hours, thus the provided cron schedule expression should not be less frequent than that.

Note

This action is considered optional since NXCALS client tries to obtain the user credentials from the local Kerberos cache. If your goal is to impersonate another user/service account then the following steps can guide you through, on how to achieve that.

The preferred and the easiest method for obtaining keytab file is to generate it on lxplus machine by executing:

cern-get-keytab --user --keytab <keytab.file>

Once the .keytab file is created correctly we can check if obtaining Kerberos ticket works:

kdestroy && kinit -f -r 5d -kt /<path_to_keytab_file>/<user>.keytab <user>
klist

# Correct output

Ticket cache: FILE:/tmp/krb5cc_14420
Default principal: <user>@CERN.CH

Valid starting     Expires            Service principal
07/01/17 14:00:01  07/02/17 15:00:01  krbtgt/CERN.CH@CERN.CH
        renew until 07/06/17 14:00:01

Important

Please note that this file should be well protected as it contains user's password

Troubleshooting Kerberos issues

Kerberos is relatively hard to debug. Messages coming from JVM can be difficult for diagnosing. Extra debugging information can be enabled for the client.

Please add the following settings to your Spark config under /conf/spark-defaults.conf

spark.driver.extraJavaOptions  -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext

spark.yarn.appMasterEnv.HADOOP_JAAS_DEBUG true
spark.yarn.am.extraJavaOptions -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext
Please also export the debug variable before running spark shell:

export HADOOP_JAAS_DEBUG=true

CERN grid CA certificate installation

Important

This action is considered optional since NXCALS client tries to obtain the CA certificates from the embedded trustStore file that is available on the resources.

If you still need to use your own or existing trustStore that contains the needed CERN certificates, then click on the following panel to see how you can achieve that.

Click to see how to manually install a CERN grid CA certificate...

Warning

Machines with JDK provided by BE-CO do not require creation of the truststore. It is already preinstalled. The steps below concerning certificate installation can be simply skipped.

1. Download certificate

You can download the 'CERN grid CA certificate' directly to your system from CERN's certificates page (or from direct link).

Hint

Prefer to save the certificate with a name like: CERN_Grid_Certification_Authority.crt, as this name will be used as reference for the rest of this guide.

2. Generate SSL trustStore with JDK's keytool

For this step you need to have Java present on your system. In order to import the CERN grid CA certificate, you need to run the following command via java keytool:

/path/to/jdk/bin/keytool -import -alias cerngridcertificationauthority -file /path/to/CERN_Grid_Certification_Authority.crt -keystore nxcals_cacerts -storepass nxcals -noprompt

3. Reference certificate on NXCALS client applications

Once we have the CERN grid CA certificate imported to the JDK's keystore, we need to reference it on an NXCALS client application startup. In order to do that, we have to export the SSL trustStore and trustStore password as JVM related system properties.

For example, add the following:

System.setProperty("javax.net.ssl.trustStore", "nxcals_cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "nxcals");