Skip to Content
Author's profile photo Denys van Kempen
Denys van Kempen
August 24, 2017 8 minute read

Initial Setup and Secure Configuration (GCP) – by the SAP HANA Academy

Introduction

In the upcoming weeks, we will be posting new videos to the SAP HANA Academy to help you get started on the Google Cloud Platform.

The full playlist can be accessed here: Getting Started with SAP HANA on the Google Cloud Platform.

This blog is part of a series:

In this blog, I will discuss the initial setup steps for the SAP HANA, express edition VM on GCP and provide some background information and suggestions for a secure configuration of your HXE system.

 

1. Initial Setup

Once the SAP HANA, express edition VM has been created by the GCP Cloud Launcher, you are presented with a number of suggested next steps.

Sudo su

Before you can get started using SAP HANA, express edition, you need to login first with the SAP HANA administration account: hxeadm. This is the software owner, the account that was used to install the software.

For the SAP HANA, express edition VM (the one you can run on your computer), a temporary password is provided but for the cloud version on GCP the approach is different, and to be fair, a bit more secure.

For the local VM, see

Spoiler alert! The HXEHana1 password is not valid on GCP. Message: password already used.

On GCP, you will be asked to set the password of the hxeadm user yourself. Now you may wonder, how do we connect as hxeadm if we do not have a (temporary) password in the first place? For this, a standard practice is used in Linux system administration: run the command as the superuser root.

So with the ‘sudo su – hxeadm‘ command, we want the su (substitute user) command to open a login shell with all the environment variables of the hxeadm user (note the dash in ‘su – hxeadm‘) and do this with the privileges of the superuser (sudo = superuser do). Without the sudo, su would still prompt us for the password of the hxeadm user.

So, after opening an SSH connection to the VM, enter the command:

sudo su - hxeadm

For more information about sudo and su, see

 

HANA database master password

Right after login, an initialization script prompts you to set the ‘New HANA database master password’:

The password policies of SUSE Linux and SAP HANA, of course, come both from a different source and do not exactly match. Characters that are allowed on the OS, are not allowed in the database, so, how can we set the passwords for both the operating system administration account hxeadm and the database super user SYSTEM at one fell swoop? By using a script to map the default SAP HANA database password policy to SUSE Linux.

Note that when you perform your own installation of an SAP HANA system (including express edition), the installer will prompt you to specify the passwords for both the operating system administration account and the database SYSTEM user separately. There is no single ‘database master’ password. For this reason, you will not find any reference to a ‘database master’ password in the SAP HANA platform documentation as the concept does not really exist. It is specific to the HANA express setup.

After you have set your master password, you are prompted to proceed:

If you decide to enter N at this point, nothing will have changed and the script will be launched again to prompt you to set the master password next time you connect.

If you do decide to proceed, as recommended, the initialization script will check if the SAP HANA system is up and then continues to change the SYSTEM password for both the SystemDB and the HXE tenant database.

SSFS Master Keys and Database Root Keys

Next, the initialization script will update both the SSFS master keys and all three root keys in both the SystemDB and in the HXE database, and make a backup.  This is a critically important step. Unique SSFS master keys are generated when you install SAP HANA and unique encryption root keys are generated when you create a tenant database (for the system and default tenant this also happens during the installation).

For a cloned system, like express as VM (cloud or local), all keys are the same. It’s a hacker’s paradise and a security administrator’s nightmare. So, this needs to fixed A-SAP.

In fact, this is the process that SAP recommends in the SAP HANA Administration Guide:

 

Immediately after system handover from your hardware or hosting partner, perform the following steps.

The way this is done by the initialization script on our express VM is by calling another script: change_key.sh (in $HOME/bin). You can run this script again for the green phase in the illustration above: ‘Regularly during operation’

Below the section from the script where the new master key is generated. Note that the rsecssfx utility is used for this.

You can run the rsecssfx command as well (once the script is done) to query the key store with the ‘info‘ parameter. As there can be more than one store, you need to specify where it is located and one way to do this, as in the script, is by setting the RSEC_SSFS_DATAPATH environment variable.

The tool and the concept of secure storage in the file system (SSFS) are not specific to SAP HANA and can also be found on SAP NetWeaver Application Server (AS) ABAP systems, see:

 

For those less familiar with SSFS and root keys, here is how the topic is illustrated in the SAP HANA Security Guide;

We have two secure stores, each protected by a master key, and then we also have, per database, four encryption root keys for data volume, redo log, application services (and backups, although this key is not configured by default for express edition).

Although the root keys are on the file system, SQL statements are used to create and activate them. Below the section from the script where this done.

New root keys are implemented in three stages, generate-backup-activate, and this is exactly what we see in the output:

The procedure (steps) is documented here:

For the first version of SAP HANA, express edition (1.0 SPS 12), changing keys was a manual process covered in this tutorial video:

URL: https://www.youtube.com/watch?v=8oizTbJBtsE

 

OS Passwords

Of course, for many reasons, you might not want to have a single password for both the operating system administration account hxeadm and the database super user SYSTEM. Now what?

No problem, you can easily change the password of the hxeadm user, once the script has finished. This does not impact the proper functioning of SAP HANA in any way.

For this, you can use the passwd command. This time, the default SUSE Linux password policy rules will apply and SUSE uses PAM (Pluggable Authentication Modules for Linux) for this. Configuring PAM is all command line, so not the most user-friendly part administration.

For more information about SUSE Linux password policy, see

 

Should you insist on using unsafe passwords and do not want to fiddle with the PAM configuration, you can simply use the command:

sudo passwd hxeadm

The passwd command will complain if the password does not comply with the rules but will execute the task as requested anyway. As Linux superuser, you can do anything. Even destroy the whole machine. (bold, red – that’s a warning).

Setting the password to Password1

 

Database Passwords

To change the SAP HANA database passwords, we first need to discuss the SAP HANA interactive terminal tool, hdbsql, and SAP HANA password policy. This, we will do in the next blog.

 

Tutorial Video(s)

Pre-configuration Steps

In this tutorial video below shows you exactly how the initial setup process takes places and, as a bonus, also how you can configure a static (fixed) external IP for you VM instance.

URL: https://www.youtube.com/watch?v=9ZBDCPDf9MU

 

Secure Configuration

In the next video, you can review the background information about how the secure configuration of the SAP. HANA, express edition VM is implemented:

URL: https://www.youtube.com/watch?v=rzRvYTg7SLo

 

References

For more information, see:

SAP HANA Academy Videos

SAP HANA Academy Blogs

SAP Documentation

SUSE Linux Documentation

 

Thank you for watching

The SAP HANA Academy provides technical enablement, implementation and adoption support for customers and partners with 1000’s of free tutorial videos.

For the full library, see SAP HANA Academy Library – by the SAP HANA Academy

For the full list of blogs, see Blog Posts – by the SAP HANA Academy

 

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jane Huang
      Jane Huang

      Hi Denys,

      Thanks for the great blog.

      I have launched SAP HANA, express edition (server + applications) to my project according to your instruction.

      However I cannot access services using external IP provided, ping is not working either.

      I have checked firewall and it seems to be configured correctly.

      Are there any other configurations I need to make?

      Thanks and best regards,

      Jane Huang

      Author's profile photo Denys van Kempen
      Denys van Kempen
      Blog Post Author

      Hi Jane,

      Thanks.

      I understand that the firewall on the (HANA) server side has been configured to allow connections but that you cannot access the server from your client (in the office), for example, a URL in a browser (HTTP port 80) or a telnet connection (SSH port 22).

      It is possible that there is another firewall at your office. For example, here at SAP we have network for internal systems and one for external access (like Google cloud).

      With GCP you can access the VM using SSH in a browser window to circumvent any corporate firewall. Does this work for you?

      Regards,

      Denys van Kempen / SAP HANA Academy

       

       

       

       

      Author's profile photo Jane Huang
      Jane Huang

      Hi Denys,

      Thanks for your reply!

      You were right about the firewall at my office. The problem is solved by switching network.

      Best regards,

      Jane Huang

      Author's profile photo Denys van Kempen
      Denys van Kempen
      Blog Post Author

      Hi Jane,

      Good to hear the issue is solved. Thanks for letting us know.

      Best regards,

      Denys