Testing the LDAP Authentication and Access Policies

Lab Steps

lock
Logging in to the Amazon Web Services Console
lock
Opening the AWS Cloud9 IDE
lock
Installing HashiCorp Vault
lock
Starting the Vault Sever in Development Mode
lock
Understanding the LDAP Directory
lock
Creating Vault Policies for the Organization
lock
Configuring Vault LDAP Authentication
lock
Testing the LDAP Authentication and Access Policies
lock
Validate AWS Lab
Need help? Contact our support team

Here you can find the instructions for this specific Lab Step.

If you are ready for a real environment experience please start the Lab. Keep in mind that you'll need to start from the first step.

Introduction

Now that Vault is configured to use the LDAP server for authentication, you will test that it works in this Lab Step. You will also confirm that the group to policy mappings give the correct access to the two users in the organization. The LDAP structure is included below for your convenience:

alt

 

Instructions

1. Authenticate using LDAP with the common name Jeremy Cook and enter the Password sheep when prompted:

Copy code
vault login -method=ldap username='Jeremy Cook'

alt

The ldap auth method uses a username and password for authentication. The output displays Key-Value pairs for the token of the authenticated user. Observe that the token_policies pair includes engineering, which confirms the mapping from LDAP groups to Vault policies is working. The Vault CLI will automatically issue commands on behalf of the last authenticated user by using the token. You do not need to issue any additional commands

 

2. List the capabilities of the authenticated user at secret/Engineering:

Copy code
vault token capabilities secret/data/Engineering

alt

These capabilities correspond to the ones granted by the engineering policy.

 

3. List the capabilities of the authenticated user at secret/Research:

Copy code
vault token capabilities secret/data/Research

alt

None of the policies attached to the token grant any access to secret/data/Research. Vault denies access to any path by default so the result is to deny.

 

4. Read the secrets stored at secret/Engineering:

Copy code
vault kv get secret/Engineering

alt

The two secrets are displayed at the bottom of the output. Recall that version 2 of the key-value storage engine uses versioning. To gain access to the secret at secret/Engineering, you actually needed permission to read secret/data/Engineering.

 

5. Attempt to read the secrets stored at secret/Research:

Copy code
vault kv get secret/Research

alt

The request fails with a permission denied error. The output also shows that the request is sent to the secret/data/Research path.

 

6. Repeat the previous commands but authenticate with username='Logan Rakai' and password wolf.

Confirm the access controls match your expectations.

 

Summary

In this Lab Step, you tested the Vault LDAP configuration by authenticating and accessing secrets using LDAP users. By leveraging identities in LDAP, you do not need to duplicate any usernames and passwords in Vault. You can configure appropriate policies, and start using Vault with minimal overhead.

 

Challenge (Optional)

If you have time remaining in your Lab Session, try creating a policy and attaching it to a specific user instead of a group. To gain the required permissions, you will need to authenticate using the Root Token given in the yellow section of the Vault server output with the command:

Copy code
vault login <Root_Token>

Hint: LDAP user to policy mappings are written to paths in auth/ldap/users/