Users

Users are the authenticated entities that make KMIP, REST or NAE-XML calls. To authenticate to the NAE-XML interface, you send an AuthRequest with the user credentials. To authenticate to the REST API, you POST the user credentials to an authentication endpoint, and receive an API token, which you can use in subsequent API calls.

Managing Users

Users can be created and managed via the REST API and the CLI tool. The legacy NAE-XML requests for user management are also supported, through the NAE-XML interface.

On launch, a single user exists, named "admin". This user can create, modify and delete other users. The user that is created in the ksctl setup is this admin user; see CLI Installation.

The following options are available for managing users:

• Create

• Delete

• Get a single record

• List records

• Modify

Note that when you create a new user there is a 'username' that is set. It is used as the login of that user and cannot be changed. Another field is ‘user’ that is the full name of the use; this is an optional field and can be modified. Finally, there is also a 'User ID' field created by the platform that is used for all updates to the user. This field is of the form: local|<UUID>

To create a user named "bob":

$ ksctl users create --name bob --pword bob

The response looks like

    {
            "created_at": "2018-04-27T21:10:53.191577Z",
            "email": "",
            "last_login": null,
            "logins_count": 0,
            "name": "bob",
            "nickname": "bob",
            "updated_at": "2018-04-27T21:10:53.191577Z",
            "user_id": "local|c7560d06-3628-4fb0-81e3-5881d2f8d7b3",
            "username": "bob",
            "failed_logins_count": 0,
            "account_lockout_at": null,
            "failed_logins_initial_attempt_at": null,
            "last_failed_login_at": null,
            "password_changed_at": "2018-04-27T21:10:53.192083Z",
            "password_change_required": false
    }

Configuring LDAP Authentication

The CipherTrust Manager authenticates users against its internal database and also provides an option to authenticate with an external authentication provider (LDAP). It is possible to have a mix of both local and LDAP users.

Overview

When LDAP is configured the users and credentials are located in an external LDAP server and CipherTrust Manager acts as a forwarder to the LDAP server. The first time a new LDAP user is successfully authenticated, a corresponding user record is stored in the CipherTrust Manager and is marked to belong to the respective LDAP connection. All CipherTrust Manager user records associated with a LDAP connection are deleted when the LDAP connection is deleted from the CipherTrust Manager.

To authenticate users against LDAP, it is required to configure an LDAP connection in the CipherTrust Manager. Only CipherTrust Manager users with administrator privilege are authorized to configure LDAP connections. It is possible to configure LDAP connections through either the REST API, the CLI or the GUI.

Each LDAP connection is given a name that needs to be known by the end user and be provided during authentication; this is often referred to as the domain. For example, if a user joe exists in the LDAP directory ldap://192.168.0.1:389 and this LDAP server is created in CipherTrust Manager with the name myco, the end user would have to authenticate with either myco\joe, myco/joe or myco|joe in the GUI. On the CLI, you would instead specify the name of the connection as a separate parameter.

LDAP authentication also works through NAE-XML. The connection and/or username can be specified in following formats:

• username - A local user in the root domain. For example, joe.

• ldap-connection|username - An LDAP user in the root domain. For example, ldap-connection|joe.

• domain-id|ldap-connection|username - An LDAP user in a specific domain. For example, domain-id|ldap-connection|joe.

• domain-id||username - A local user in a specific domain. For example, domain-id||joe.

When browsing the GUI, LDAP users can be identified from the source property. The user is displayed in either of the formats listed above. A local user is displayed as local|<username>.

Setting Up a New Connection

Using either the CLI or the GUI it is possible to test a connection, create (bind) a new connection, get a list of connections, modify a connection and delete a connection.

Required fields for LDAP connection:

• name - Unique identifier for the connection and commonly referred to as the domain, for example myco.

• server_url - Hostname and port of the LDAP server, for example ldap://192.168.0.1:389.

• root_dn - The base DN as the starting point for the search, for example DC=myco,DC=local.

• strategy - Type of connection to create, must be "ldap" in the case of an LDAP connection.

• uid_field- The field containing the user's login name, for example uid.

Optional fields for LDAP connection:

• search_filter - Optional LDAP search filter which can further restrict the set of users who will be allowed to log in, for example memberOf="CN=example,OU=Users,DC=myco,DC=local".

• guid_field - The LDAP field name of a globally unique identifier for the user, for example objectGUID. If this field is specified, the user record in the CipherTrust Manager would have the value of this field as identifier of the user instead of the provided username. If for example the user joe, on the LDAP connection myco, has the objectGUID value 3450be9a6ee76540956e7c6b10d98831, then his user record would be myco|3450be9a6ee76540956e7c6b10d98831 instead of myco|joe. The friendly name joe would still be in the user record and be search-able.

• bind_dn - If authentication is required to perform search this is the name of the entity to bind to, for example CN=poweruser,CN=Users,DC=myco,DC=local.

• bind_pass - Password of the user provided in bind_dn.

  If bind_dn and bind_pass fields are not provided, the LDAP search will be performed using the 'end user provided' user id and password.

• group_id_field - The field that contains the group name, for example 'cn'. If group_id_field is not provided, it will default to whatever is in uid_field.

• group_filter - Search filter for listing groups. If group_filter is not provided, it will default to "(objectclass=Group)".

• group_member_field - The field which contains a user's group membership information, for example 'member'. If group_member_field is not provided, it will default to 'member'.

Once a connection is created, it is not possible to modify these fields: name, strategy or bind_pass.

CLI command example

Test the connection configuration to verify it can authenticate one of the LDAP users.

$ ksctl connections test --test-username=jdoe --test-password=ji32k7au4a83 --name=myco --strategy=ldap --bind-password=admin --bind-dn="CN=poweruser,CN=Users,DC=myco,DC=local" --server-url="ldap://192.168.0.1:389" --user-id-field=uid --root-dn="DC=myco,DC=local" --search-filter="(memberOf=CN=example,OU=Users,DC=myco,DC=local")

Bind the connection configuration.

$ ksctl connections bind --name=myco --strategy=ldap --bind-password=admin --bind-dn="CN=poweruser,CN=Users,DC=myco,DC=local" --server-url="ldap://192.168.0.1:389" --user-id-field=uid --root-dn="DC=myco,DC=local" --search-filter="(memberOf=CN=example,OU=Users,DC=myco,DC=local")