Administration and Configuration of XtremeCloud Data Grid-ldap

Introduction

Although it is a cloud-based application, XtremeCloud Data Grid-ldap is not a cloud-native application in our systems architecture. As you can see, it is a hosted application on a cloud provider’s virtual machine (VM) or on a raw iron host. As such, it falls under our Infrastructure-as-a-Service (IaaS) configuration management umbrella and is installed and managed with Ansible Playbooks. These playbooks are provided to subscription-based customers of Eupraxia Labs. The connectivity from XtremeCloud Single Sign-On (SSO) and XtremeCloud Data Grid-ldap is provided via the Aspen Mesh serviceEntry configuration, in our provided Helm Chart, which encrypts the transport layer via Mutual TLS (mTLS).

As will be seen there are some configurations and monitoring performed on the XtremeCloud Data Grid-ldap hosts. Let’s look at the currently supported version of istioctl:

[centos@vm-controller ansible-xtremecloud-datagrid-ldap]$ istioctl version
version.BuildInfo{Version:"1.1.4", GitRevision:"bc7465793cbff4c4189639b3f404e21c517cbdc6", User:"root", Host:"471e568b-66d7-11e9-a0d5-0a580a2c0304", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.3-20-gbc74657"}

Configuration

The installation and configuration of the multi-master replication (MMR) feature of XtremeCloud Data Grid-ldap is relatively simple when the provided Ansible Playbook is used. This playbook only installs the MMR replication between the CSPs. A separate optional Ansible Playbook is available, and included with our distribution, to install the server software on each VM or raw iron host on each CSP.

Note: For scalability and high availability (HA) within each Cloud Service Provider (CSP), additional replication hosts can be added.

The first file to update in the provided Ansible Playbook is the inventory file:

[ldap-masters]
ds-site1.your-company.com
ds-site2.your-company.com

In accordance with our Cloud Service Provider (CSP) convention these FQDNs represent Active-Active hosts on Google Cloud Platform (Site 01) and Microsoft Azure (Site 02). This can be modified to comply with your own conventions with respect to CSPs that you already use.

The next file to configure is xcdg-ldap-role.yaml:

- hosts: ldap-masters    # or localhost, depending on your group_vars setup
  become: yes
  vars:
    - ldap389_suffix: "dc=your-company,dc=com"               # Which area is being replicated
    - ldap389_master_authdn: "cn=Directory Manager"          # User, which is able to create entries in this area
    - ldap389_master_authdn_password: "<provide-password>"   # It's a password, plaintext
    - ldap389_replica_type: "rw"                             # master-master fullmesh
    - ldap389_masters: ""        # list of servers belonging to fullmesh group
    - ldap389_replication_user: "Replication Manager"        # replication user - used by xcDG-ldap to authenticate against peers. This user is created by this role unless you set `ldap389_create_replication_user` to `false`
    - ldap389_replication_password: "<provide-password>"     # replication user password
    - ldap389_disable_ansible_log: false                     # if you set this to true (default), sensitive information will NOT be present in Ansible outputs
  roles:
    - ansible-389dir-replication

Note: Typically, LDAP port 389 is used for non-SSL traffic between an LDAP client and an LDAP service. In effect, as far as the XtremeCloud Data Grid-ldap servers are concerned, it is non-SSL cross-cloud traffic. However, since the CSPs are connected via a Virtual Private Network (VPN), as depicted below, the transport layer is encrypted. Additionally, the VMs or raw iron hosts are set up with encrypted file sytems to protect the data-at-rest in the XtremeCloud Data Grid-ldap databases. For example, from Google Cloud documentation: “By default, Compute Engine encrypts all data at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part.”

Google Cloud to Microsoft Azure VPN - click image to enlarge

You will provide the domain name for the ldap389_suffix and two (2) passwords as indicated. Let’s run the Ansible-Playbook:

    [centos@vm-controller ansible-xtremecloud-datagrid-ldap] ansible-playbook -i inventory ansible-xtremecloud-datagrid-ldap.yaml

Post-Installation Testing and Confirmation

From your workstation/controller with istioctl installed, we will perform as an LDAP client and do some LDAP adds and deletes to each CSP and confirm that the LDAP replications are performing properly.

The bash shell scripts to perform these post-installation tests are provided in a customer repostitory along with the Ansible Playbook.

XtremeCloud Data Grid-ldap and Microsoft Active Directory (AD)

XtremeCloud Single Sign-On (SSO) comes with a built-in LDAPv3/AD provider. XtremeCloud Data Grid-ldap is compliant with LDAPv3 standards and, therefore, is fully integrated with XtremeCloud SSO. It is possible to federate multiple different LDAP servers, such as XtremeCloud Data Grid-ldap and Microsoft Active Directory (AD) in the same XtremeCloud SSO realm. XtremeCloud Data Grid-ldap provides cross-cloud active-active multi-master replication (MMR). Microsoft Active Directory (AD) can also be configured for MMR, but the specific configuration is beyond the scope of this document.

You can map LDAP user attributes into the XtremeCloud SSO common user model. By default, it maps username, email, first name, and last name, but you are free to configure additional mappings. The LDAP provider also supports password validation via LDAP/AD protocols and different storage, edit, and synchronization modes.

To configure a federated LDAP store go to the Admin Console. Click on the User Federation left menu option. When you get to this page there is an Add Provider select box. You should see ldap within this list. Selecting ldap will bring you to the LDAP configuration page.

User Federation in XtremeCloud SSO - click image to enlarge

Storage Mode

By default, XtremeCloud SSO will import users from the LDAP providers into the local XtremeCloud SSO user database. This copy of the user is either synchronized on demand, or through a periodic background task. The one exception to this is passwords. Passwords are not imported and password validation is delegated to the LDAP server. The benefits to this approach is that all XtremeCloud SSO features will work as any extra per-user data that is needed can be stored locally. This approach also reduces load on the XtremeCloud Data Grid-ldap server as uncached users are loaded from the XtremeCloud SSO database the second time they are accessed. The only load XtremeCloud Data Grid-ldap will have is password validation. The downside of this approach is that when a user is first queried, this will require an insert into the XtremeCloud SSO database. The import will also have to be synchronized with XtremeCloud Data Grid-ldap as needed.

Alternatively, you can choose not to import users into the XtremeCloud SSO user database. In this case, the common user model that the XtremeCloud SSO runtime uses is backed only by the LDAP server. This means that if XtremeCloud Data Grid-ldap doesn’t support a piece of data that a XtremeCloud SSO feature needs that feature will not work. The benefit to this approach is that you do not have the overhead of importing and synchronizing a copy of the XtremeCloud Data Grid-ldap user into the XtremeCloud SSO user database.

This storage mode is controlled by the Import Users switch. Set this to ‘On’ to import users as shown below.

Import Users Option in XtremeCloud Single Sign-On (SSO) - click image to enlarge

Edit Mode

Users, through the User Account Service, and Administrators through the Admin Console have the ability to modify user metadata. Depending on your setup you may or may not have XtremeCloud Data Grid-ldap update privileges. The Edit Mode configuration option defines the edit policy you have available.

READONLY

Username, email, first name, last name, and other mapped attributes will be unchangeable. XtremeCloud SSO will show an error anytime anybody tries to update these fields. Also, password updates will not be supported.

WRITABLE

Username, email, first name, last name, and other mapped attributes and passwords can all be updated and will be synchronized automatically with your LDAP store.

UNSYNCED

Any changes to username, email, first name, last name, and passwords will be stored in XtremeCloud SSO local storage. It is up to you to figure out how to synchronize back to LDAP. This allows XtremeCloud SSO deployments to support updates of user metadata on a read-only LDAP server. This option only applies when you are importing users from LDAP into the local XtremeCloud SSO user database.

Other Configuration Options

Console Display Name

Name used when this provider is referenced in the Admin Console

Priority

The priority of this provider when looking up users or adding a user.

Sync Registrations

By default XtrememCloud Data Grid-ldap allows the addition of new users. Click this switch if you want new users created by XtremeCloud SSO in the Admin Console or the registration page to be added to the LDAP configuration.

Allow Kerberos authentication

Enable Kerberos/SPNEGO authentication in a realm with users data provisioned from LDAP.

Other options

The rest of the configuration options should be self explanatory. You can mouseover the tooltips in Admin Console to see some more details about them.

Sync of LDAP users to XtremeCloud SSO

If you have import enabled, the LDAP Provider will automatically take care of synchronization (import) of needed LDAP users into the XtremeCloud SSO local database. As users log in, the LDAP provider will import the XtremeCloud Data Grid-ldap user into the XtremeCloud SSO database and then authenticate against the XtremeCloud Data Grid-ldap password. This is the only time users will be imported. If you go to the Users left menu item in the Admin Console and click the View all users button, you will only see those XtremeCloud Data Grid-ldap users that have been authenticated at least once by XtremeCloud SSO. It is implemented this way so that admins don’t accidentally try to import a huge XtremeCloud Data Grid-ldap database of users.

If you want to sync all XtremeCloud Data Grid-ldap users into the XtremeCloud SSO database, you may configure and enable the Sync Settings of the XtremeCloud Data Grid-ldap provider you configured. There are 2 types of synchronization:

Periodic Full sync

This will synchronize all XtremeCloud Data Grid-ldap users into XtremeCloud SSO database. Those XtremeCloud Data Grid-ldap users, which already exist in XtremeCloud SSO and were changed in XtremeCloud Data Grid-ldap directly will be updated in XtremeCloud SSO database (For example, if user Samantha Smith was changed in XtremeCloud Data Grid-ldap to Sam Smith).

Periodic Changed users sync

When syncing occurs, only those users that were created or updated after the last sync will be updated and/or imported.

The best way to handle syncing is to click the Synchronize all users button when you first create the XtremeCloud Data Grid-ldap provider, then set up a periodic sync of changed users. The configuration page for your XtremeCloud Data Grid-ldap Provider has several options to support you.

LDAP Mappers

LDAP mappers are listeners, which are triggered by the LDAP Provider at various points, provide another extension point to LDAP integration. They are triggered when a user logs in via LDAP and needs to be imported, during XtremeCloud SSO initiated registration, or when a user is queried from the Admin Console. When you create an LDAP Federation provider, XtremeCloud SSO will automatically provide a set of built-in mappers for this provider. You are free to change this set and create a new mapper or update/delete existing ones.

User Attribute Mapper

This allows you to specify which XtremeCloud Data Grid-ldap attribute is mapped to which attribute of XtremeCloud SSO user. So, for example, you can configure that XtremeCloud Data Grid-ldap attribute mail to the attribute email in the XtremeCloud SSO database. For this mapper implementation, there is always a one-to-one mapping (one LDAP attribute is mapped to one XtremeCloud SSO attribute)

FullName Mapper

This allows you to specify that the full name of the user, which is saved in some LDAP attribute (usually the common name attribute cn) will be mapped to firstName and lastname attributes in the XtremeCloud SSO database. Having cn contain the full name of a user, such as ‘samantha.smith’ is fairly common for LDAP-based deployments.

Additionally, for specific implementations of XtremeCloud Single Sign-On (SSO) for HSPD-12, or DoD Common Access Cards (CAC), other descriptive information might be added to the cn:

CN = SMITH.SAMANTHA.L.1231728446
OU = USN
OU = PKI
OU = DoD
O = U.S. Government
C = US

In the example above the Department of Defense (DoD) identification number, formerly referred to as the Electronic Data Interchange Personal Identifier (EDIPI), is included in the cn. The EDIPI is a unique 10-digit number that is associated with DoD personnel and their Common Access Card (CAC).

Role Mapper

This allows you to configure role mappings from XtremeCloud Data Grid-ldap into XtremeCloud SSO role mappings. One Role mapper can be used to map LDAP roles (usually groups from a particular branch of LDAP tree) into roles corresponding to either realm roles or client roles of a specified client. It’s not a problem to configure more Role mappers for the same LDAP provider. So for example you can specify that role mappings from groups under ou=main,dc=example,dc=org will be mapped to realm role mappings and role mappings from groups under ou=finance,dc=example,dc=org will be mapped to client role mappings of client finance .

Hardcoded Role Mapper

This mapper will grant a specified XtremeCloud SSO role to each XtremeCloud SSO user linked with XtremeCloud Data Grid-ldap.

Group Mapper

This allows you to configure group mappings from XtremeCloud Data Grid-ldap into XtremeCloud SSO group mappings. Group mapper can be used to map XtremeCloud Data Grid-ldap groups from a particular branch of an LDAP tree into groups in XtremeCloud SSO. It will also propagate user-group mappings from LDAP into user-group mappings in XtremeCloud SSO.

Microsoft Active Directory (AD) User Account Mapper

This mapper is specific to Microsoft Active Directory (AD). It’s able to tightly integrate the Active Directory user account state into the XtremeCloud SSO account state (account enabled, password is expired, etc.). It’s using the userAccountControl and pwdLastSet LDAP attributes. (both are specific to AD and are not an LDAP standard). For example if pwdLastSet is 0, the XtremeCloud SSO user is required to update their password and there will be an UPDATE_PASSWORD required action added to the user. If userAccountControl is 514 (disabled account) the XtremeCloud SSO user is disabled as well.

Certificate Mapper

This mapper is specific for mapping X.509 certificates. It will generally be used in conjunction with X.509 authentication and Full certificate in PEM format as an identity source. It behaves the same way as the User Attribute Mapper, but allows XtremeCloud SSO to filter for an LDAP attribute which stores a certificate in either PEM or DER format. It is generally advised to enable ‘Always Read Value’ from LDAP with this mapper.

By default, there are User Attribute mappers that map basic XtremeCloud SSO user attributes like username, firstname, lastname, and email to corresponding LDAP attributes. You are free to extend these and provide additional attribute mappings. Admin console provides tooltips, which should help with configuring the corresponding mappers.

Password Hashing

When the password of user is updated from XtremeCloud SSO and sent to XtremeCloud Data Grid-ldap, it is always sent in plain-text. This is different from updating the password to built-in XtremeCloud SSO database, when the hashing and salting is applied to the password before it is sent to the database. XtremeCloud SSO relies on XtremeCloud Data Grid-ldap to provide hashing and salting of passwords.

Microsoft Active Directory provides this by default.

Monitoring and Alerts of the Replication Traffic

We use Grafana to monitor XtremeCloud Data Grid-ldap within each Cloud Service Provider (CSP). Within our distribution, we provide the input plugin.

Configure your Grafana Telegraf configuration file, which is an agent for collecting, processing, aggregating, and writing metrics.

We will test the plugin to ensure you are collecting the data as explained in the plugin README.

Collector Configuration Details

# XtremeCloud Data Grid-ldap server (389 Directory Server) cn=Monitor plugin
[[inputs.ds389]]
  host = "localhost"
  port = 389

  # ldaps, starttls, or no encryption. default is an empty string, disabling all encryption.
  # note that port will likely need to be changed to 636 for ldaps
  # valid options: "" | "starttls" | "ldaps"
  tls = ""

  # skip peer certificate verification. Default is false.
  insecure_skip_verify = false

  # Path to PEM-encoded Root certificate to use to verify server certificate
  tls_ca = "/etc/ssl/certs.pem"

  # dn/password to bind with. If bind_dn is empty, an anonymous bind is performed.
  bind_dn = "cn=Directory Manager"
  bind_password = "password"

  #Gather dbname monitor
  # Comma separated list of db filename
  # dbtomonitor = ["xtremecloudDB"]
  # If true, alldbmonitor monitors all db and it overrides "dbtomonitor".
  alldbmonitor = true

  status = true

  [inputs.ds389.tags]
    instance = "instance-name"