Recently heard complaints:

I’ve done a deployment , and every time I try to log in to the dashboard, I get “An error occurred authenticating. Please try again later.” Somewhat surprisingly, the only log that I’m noticing showing anything of note is the Apache error log, which reports ‘Login failed for user “admin”‘. I’ve bumped keystone — where I’d assume the error is happening — to DEBUG, but it’s showing exactly zero activity. How do I go about debugging this?’

Trying to enable LDAP with OpenStack/keystone in Juno release. All the horizon users return error “You are not authorized for any projects.” Similarly, all the OpenStack services are reported not to be authorized.’
What is supposed to happen:

1. You Login to Horizon using admin and the correct password
2. Horizon passes that to Keystone in a token request
3. Keystone uses that information to create a token. If the user has a default project set, the token is scoped to the default proejct
4. token is returned to Horizon

Let’s take a deeper look at step 3.
In order to perform an operation on a resource in a project, a user needs to be assigned a role in a project. So the failure could happen at a couple steps.

1. The user does not exist in the identity backend
2. The user has the wrong password
3. The user has no role assignments
4. The user has a default project assigned, but does not have a role assignment for that project

The Keystone configuration file

Most deployments run with Keystone reading its configuration values from /etc/keystone/keystone.conf. It is an ini file, with section headers.
In Juno and Icehouse, the storage is split into two pieces: Identity and Assignment. Identity holds users and groups. Assignment holds roles, role assignments, projects and domains. Let’s start with the simplest scenario.
Identity in SQL, Assignments in SQL:
This is what you get from devstack if you make no customizations. To confirm that you are running this way, look in your Keystone.conf file for the sections that starts with
[identity]
and
[assignment]
and look for the value driver. In a Devstack deployment that I just ran, I have

[identity]
driver = keystone.identity.backends.sql.Identity

Which confirms I am running witht he SQL driver for identity, and

[assignment]
driver = keystone.assignment.backends.sql.Assignment

Which confirms I am running with the SQL driver for Assignment
First steps
For Devstack, I get my environment variables set using

. openrc
and this will set:
$OS_AUTH_URL $OS_NO_CACHE $OS_TENANT_NAME
$OS_CACERT $OS_PASSWORD $OS_USERNAME
$OS_IDENTITY_API_VERSION $OS_REGION_NAME $OS_VOLUME_API_VERSION
echo $OS_USERNAME
demo

To change to the admin user:

$ export OS_USERNAME=admin
$ export OS_PASSWORD=FreeIPA4All

While we are trying to get people to move to the common CLI, older deployments may only have the keystone CLI to work with. I’m going to start with that.

$ keystone --debug token-get
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://192.168.1.58:5000/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): 192.168.1.58
DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens HTTP/1.1" 200 3783
+-----------+----------------------------------+
| Property | Value |
+-----------+----------------------------------+
| expires | 2015-03-25T16:03:25Z |
| id | ec7c2d1f07c5414499c3cbaf7c59d4be |
| tenant_id | 69ff732083a64a1a8e34fc4d2ea178dd |
| user_id | 042b50edf70f484dab1f14e893a73ea8 |
+-----------+----------------------------------+

OK, what happens when I do keystone token-get? The CLI uses the information I provide to try and get a token;

$ echo $OS_AUTH_URL
http://192.168.1.58:5000/v2.0

OK…It is going to go to a V2 specific URL. And, to confirm:

$ echo $OS_IDENTITY_API_VERSION

2.0

We are using Version 2.0
The username, password and tenant used are

$ echo $OS_USERNAME
admin
$ echo $OS_PASSWORD
FreeIPA4All
$ echo $OS_TENANT_NAME
demo

Let’s assume that running keystone token-get fails for you. Let’s try to isolate the issue to the role assignments by getting an unscoped token:

$ unset OS_TENANT_NAME
$ echo $OS_TENANT_NAME

That should return a blank line. Now:

$ keystone token-get
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| expires | 2015-03-25T16:14:28Z |
| id | 2a3ce489422342f2b6616016cb43ebc2 |
| user_id | 042b50edf70f484dab1f14e893a73ea8 |
+----------+----------------------------------+

If this fails, it could be one of a few things:

1. User does not exist
2. Password is wrong
3. User has a default tenant that is invalid

How can we check:

Using Admin Token

Bootstrapping the Keystone install requires putting users in the database before there are any users defined. Most installers take advantage of an alternate mechanism called the ADMIN_TOKEN or SERVICE_TOKEN. To see the value for this, look in keystone.conf section:
[DEFAULT]
for a value like this:
#admin_token = ADMIN
Note that devstack follows the best practice of disabling the admin token by commenting it out. This password is very powerful and should be disabled in common usage, but is very powerful for fixing broken systems. To enable it, uncomment the value, and restart Keystone.

Using the Common CLI

The keystone command line has been deprecated with an eye toward using the openstack client. Since you might be deploying an old version of Openstack that has different library dependencies, you might not be able to install the latest version on your server, but you can (and should) run an updated version on your workstation which will then be capable of talking to older versions of keystone.
To perform operations using the common cli you need to pass the endpoint and admin_token as command line parameters.

The os-url needs to be the publicly routed URL to the admin interface. The firewall port for that URL needs to be Open.

$ openstack --os-token ADMIN --os-url http://192.168.1.58:35357/v2.0/ user list
+----------------------------------+----------+
| ID | Name |
+----------------------------------+----------+
| 042b50edf70f484dab1f14e893a73ea8 | admin |
| eb0d4dc081f442dd85573740cfbecfae | demo |
+----------------------------------+----------+
$ openstack --os-token ADMIN --os-url http://127.0.0.1:35357/v2.0/ role list
+----------------------------------+-----------------+
| ID | Name |
+----------------------------------+-----------------+
| 1f069342be2348ed894ea686706446f2 | admin |
| 2bf27e756ff34024a5a9bae269410f44 | service |
| dc4e9608b6e64ee1a918030f23397ae1 | Member |
+----------------------------------+-----------------+
$ openstack --os-token ADMIN --os-url http://192.168.1.58:35357/v2.0/ project list
+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| 69ff732083a64a1a8e34fc4d2ea178dd | demo |
| 7030f12f6cb4443cbab8f0d040ff023b | admin |
+----------------------------------+--------------------+

Now, to check to see if the admin user has a role on the admin project:

$ openstack --os-token ADMIN --os-url http://192.168.1.58:35357/v2.0/ user role list --project admin admin

+----------------------------------+-------+---------+-------+
| ID | Name | Project | User |
+----------------------------------+-------+---------+-------+
| 1f069342be2348ed894ea686706446f2 | admin | admin | admin |
+----------------------------------+-------+---------+-------+

If this returns nothing, you probably have found the root of your problem. Add the assignment with
$ openstack --os-token ADMIN --os-url http://192.168.1.58:35357/v2.0/ role add --project admin --user admin admin
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 1f069342be2348ed894ea686706446f2 |
| name | admin |
+-------+----------------------------------+