> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # SAP HANA > Connect SAP HANA Cloud or an SAP HANA 2.0 tenant database to Oleria to bring database users, technical users, user groups, roles, and privileges into your identity and access graph. Connect SAP HANA to Oleria to see who can sign in to your SAP HANA databases and what they can reach. That covers people, technical users, SAP-managed users, roles, user groups, and every system, schema, object, and remote-source privilege. Oleria reads this data from the SAP HANA system views over an encrypted SQL connection, using a read-only connector user. It works with SAP HANA Cloud and with tenant databases of SAP HANA 2.0. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from each SAP HANA database: * **Accounts** - every database user, with sign-in methods (password, LDAP, SAML, JWT, X.509 certificate, Kerberos), status, validity period, last successful sign-in, and e-mail address when the user has one. Users holding an administrative system privilege, such as `USER ADMIN` or `ROLE ADMIN`, are marked as administrators. * **Non-human identities** - technical users, users created by HDI containers and SAP BTP service bindings, and SAP's own users such as `SYSTEM` and the `_SYS_*` and `_SAP_*` users. Each one appears as a service account. Credentials stored in the SAP HANA secure store appear as secrets, linked to the user that holds them. * **User groups** - every user group and its members. Users with the `OPERATOR` privilege on a group are shown as able to administer its users. * **Roles** - global and schema-local roles, which roles contain other roles, and which users hold each role, including whether they can grant it to others. * **Resources** - the database, its schemas, remote sources, and every table, view, procedure, or other object granted directly to someone. Oleria shows each object's owner. * **Access** - every system, schema, object, and remote-source privilege granted to a user or a role. * **Administrative access from SAP BTP** - on SAP HANA Cloud, anyone with the SAP HANA Cloud Administrator role collection in SAP BTP can reset the `DBADMIN` password. Oleria shows this as a group named **SAP HANA Cloud administrators (SAP BTP, synthesized)** that can act as `DBADMIN`. The group has no members in Oleria, because SAP BTP manages them. Review who holds the role collection in your SAP BTP subaccount. * **Activity** - sign-ins, failed sign-ins, user and role changes, grants and revokes, credential changes, and other events recorded by your SAP HANA audit policies. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > Oleria doesn't read table contents. ## Prerequisites * An SAP HANA Cloud instance, or an SAP HANA 2.0 tenant database. * A user that can create users and grant privileges in the database, such as `DBADMIN` on SAP HANA Cloud. * Admin access to the Oleria workspace. * For SAP HANA Cloud: permission to edit the instance's allowed connections in SAP HANA Cloud Central. ## Create the connector user in SAP HANA **1. Create a dedicated user** Sign in to the database as `DBADMIN`, or as another user that can create users, and run: ```sql theme={null} CREATE USER OLERIA_CONNECTOR PASSWORD "" NO FORCE_FIRST_PASSWORD_CHANGE; ALTER USER OLERIA_CONNECTOR DISABLE PASSWORD LIFETIME; ``` **2. Grant read access** ```sql theme={null} GRANT CATALOG READ, AUDIT READ TO OLERIA_CONNECTOR; ``` `CATALOG READ` is required. Without it, the database shows the connector only its own user, and Oleria rejects the connection. `AUDIT READ` is needed for activity. **3. Grant action privileges (optional)** To use [remediation actions](#remediation-actions), also grant the privileges for your platform. **SAP HANA Cloud:** ```sql theme={null} GRANT ROLE ADMIN TO OLERIA_CONNECTOR; GRANT OPERATOR ON USERGROUP DEFAULT TO OLERIA_CONNECTOR; GRANT CREATE USERGROUP TO OLERIA_CONNECTOR; GRANT SESSION ADMIN TO OLERIA_CONNECTOR; ``` Repeat the `OPERATOR` grant for each user group whose users Oleria may create, change, or delete. On SAP HANA Cloud, even `DBADMIN` manages users through `OPERATOR` on their user group, and `DBADMIN` can grant these privileges. **SAP HANA 2.0:** ```sql theme={null} GRANT ROLE ADMIN TO OLERIA_CONNECTOR; GRANT USER ADMIN TO OLERIA_CONNECTOR; GRANT SESSION ADMIN TO OLERIA_CONNECTOR; ``` SAP HANA 2.0 has no `DEFAULT` user group, and users often belong to no user group. Oleria can change a user who is in no user group only with `USER ADMIN`. Instead of `USER ADMIN`, you can grant `OPERATOR` on each user group whose users Oleria may change, but then Oleria can't act on users who are in no user group. On both platforms, `CREATE USERGROUP` or `USERGROUP ADMIN` is needed only to create user groups, and `SESSION ADMIN` only to end sessions. > [!WARNING] > > Use a dedicated user for Oleria, not `DBADMIN` or a person's user. If the user's password expires or the user is locked, the sync stops. To sign in with an X.509 client certificate instead of a password, create an X.509 provider, map the certificate's subject to the connector user, and run `ALTER USER OLERIA_CONNECTOR ENABLE X509`. The mapping alone doesn't enable certificate sign-in. ## Turn on audit policies for activity SAP HANA records only the events that an enabled audit policy covers. To collect activity, create and enable policies like these: ```sql theme={null} CREATE AUDIT POLICY OLERIA_CONNECT_AUDIT AUDITING ALL CONNECT LEVEL INFO; CREATE AUDIT POLICY OLERIA_USER_ROLE_MGMT_AUDIT AUDITING ALL CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE USERGROUP, ALTER USERGROUP, DROP USERGROUP LEVEL INFO; CREATE AUDIT POLICY OLERIA_GRANT_AUDIT AUDITING ALL GRANT ANY, REVOKE ANY LEVEL INFO; CREATE AUDIT POLICY OLERIA_CREDENTIAL_AUDIT AUDITING ALL CREATE CREDENTIAL, ALTER CREDENTIAL, DROP CREDENTIAL LEVEL INFO; ALTER AUDIT POLICY OLERIA_CONNECT_AUDIT ENABLE; ALTER AUDIT POLICY OLERIA_USER_ROLE_MGMT_AUDIT ENABLE; ALTER AUDIT POLICY OLERIA_GRANT_AUDIT ENABLE; ALTER AUDIT POLICY OLERIA_CREDENTIAL_AUDIT ENABLE; ``` Oleria also picks up events from audit policies you already have, including data-access policies on specific tables. ## Allow Oleria to connect For SAP HANA Cloud: in SAP HANA Cloud Central, open your instance, select **Manage Configuration**, and add Oleria's egress IP addresses under **Allowed connections**. Contact [support@oleria.com](mailto:support@oleria.com) for the addresses for your region. Then open the instance's actions menu, select **Copy SQL Endpoint**, and keep the endpoint for the next step. > [!NOTE] > > For SAP HANA 2.0, the tenant database's SQL port must be reachable from Oleria's egress IP addresses. Contact [support@oleria.com](mailto:support@oleria.com) for the addresses, and to discuss connecting to a database on a private network. ## Connect SAP HANA to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **SAP HANA**. **2. Complete the connection form** Select **Continue** and provide the following: | Field | Notes | | :- | :- | | Host | Required. The SQL endpoint host, such as `.hana.prod-us10.hanacloud.ondemand.com`. If you leave **Port** empty, you can paste the endpoint with its port, such as `.hana.prod-us10.hanacloud.ondemand.com:443`. | | Port (optional) | Defaults to `443`, the SAP HANA Cloud port. For SAP HANA 2.0, use the tenant database's SQL port, usually `315`. | | Tenant database (optional) | The tenant database name, for SAP HANA 2.0 systems with several tenants. | | Authentication method | **Password** (default) or **X.509 client certificate**. | | Username and Password | Required for password sign-in. The connector user you created. | | Client certificate and Client private key | Required for certificate sign-in. PEM format. | | CA certificate (optional) | PEM format. For SAP HANA 2.0 systems whose server certificate is signed by a private certificate authority. | | SAP HANA Cloud Central URL (optional) | The address of your instance in SAP HANA Cloud Central. Oleria links to it from the database. | **3. Confirm the connection** Select **Authenticate**. Oleria signs in, then checks that the user has `CATALOG READ`. The connection always uses TLS with server certificate verification. > [!NOTE] > > Each connection covers one database. To connect several SAP HANA Cloud instances or tenant databases, add one integration for each. ## Verify the integration Confirm the database appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered accounts, groups, roles, resources, and activity in your Oleria workspace. > [!NOTE] > > If the connector user's password or certificate changes, edit the integration and enter the new value. Leave a credential field empty to keep the stored value. To change the host, port, tenant database, or username, add a new integration. After a rejected sign-in, Oleria waits 10 minutes before trying again, so the connector user isn't locked by repeated failed attempts. ## Remediation actions Oleria can take these actions in SAP HANA, and you can revert each one: * **Deactivate a user** and **reactivate a user**. This includes disabling technical and other service-account users from the non-human identity inventory. * **Grant a role to a user** and **revoke a role from a user**. Revoking removes the role however many users granted it. * **Move a user into a user group**, and **remove a user from a user group**. On SAP HANA Cloud, every user belongs to one user group, so removing a user moves them to the `DEFAULT` group. On SAP HANA 2.0, removing a user leaves them in no user group. * **Revoke a user's privileges on a resource**. This removes the privileges granted directly to the user on a schema, object, or remote source. * **Create a user** in a user group, with an e-mail address. The new user must change the password at first sign-in, and stays deactivated unless you activate it. Reverting deletes the user only if Oleria created it. * **Create a user group**. Reverting deletes the group only while it has no users. Oleria can also take these actions, which can't be reverted: * **Delete a user**. SAP HANA refuses to delete a user who owns objects other than their own empty schema, so no data is deleted with the user. * **End a user's sessions**. This disconnects every open session. SAP HANA has no session tokens, so a user can sign in again; deactivate the user to keep them out. Keep these limits in mind: * Oleria won't act on the connector user itself or on SAP-managed users, and it won't deactivate or delete `DBADMIN`. * SAP HANA lets only the user who granted a privilege revoke it. Oleria can revoke only privileges that the connector user granted, and it tells you who granted any others. * Access a user gets through a role isn't changed by a privilege revocation. Revoke the role instead. * SAP HANA can create, deactivate, move, or delete only users whose names contain just letters `A`–`Z`, digits, `_`, `#`, and `$`. Users created with SQL always qualify. * Oleria doesn't disable stored credentials, because SAP HANA can't restore a dropped secret. ## Known limitations * Oleria doesn't import structured (analytic) privileges or column masks yet. * Each connection reads one database. Oleria doesn't enumerate the tenants of an SAP HANA 2.0 system from its system database. * Activity depends on your audit policies. Events that no enabled policy covers aren't recorded by SAP HANA. * SAP HANA has no second sign-in factor of its own. Multi-factor authentication for single sign-on users is enforced by your identity provider. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.