I’ve been meaning to put all the steps together to do this for a while:

Got an IPA server running on Centos7
Got a Packstack all in one install on Centos 7. I registered this host as a FreeIPA client, though that is not strictly required.

Converted the Horizon install to be domain aware by editing /etc/openstack-dashboard/local_settings

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'

And restarting HTTPD.

sudo yum install python-openstackclient

The keystonerc_admin file is set for V2.0 of the identity API. To make it work with the v3 api, cp keystonerc_admin keystonerc_admin_v3 and edit:

export OS_AUTH_URL=http://10.10.10.25:5000/v3/
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default

And confirm:

$ openstack domain list
+----------------------------------+------------+---------+----------------------------------------------------------------------+
| ID                               | Name       | Enabled | Description                                                          |
+----------------------------------+------------+---------+----------------------------------------------------------------------+
| default                          | Default    | True    | Owns users and tenants (i.e. projects) available on Identity API v2. |
+----------------------------------+------------+---------+----------------------------------------------------------------------+

Add a domain for the LDAP backed domain like this:

$ openstack domain create YOUNGLOGIC
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | a9569e236912496f9f001e73fc978baa |
| name    | YOUNGLOGIC                       |
+---------+----------------------------------+

To Enable domain specific backends, edit /etc/keystone.conf like this:

[identity]
domain_specific_drivers_enabled=true
domain_config_dir=/etc/keystone/domains

Right now this domain is backed by SQL for Both Identity and Assignments. To convert it to LDAP for Identity, create a file in /etc/keystone/domains. This directory and file needs to be owned by the Keystone user:

Here is my LDAP specific file /etc/keystone/domains/keystone.YOUNGLOGIC.conf

# The domain-specific configuration file for the YOUNGLOGIC domain

[ldap]
url=ldap://ipa.younglogic.net
user_tree_dn=cn=users,cn=accounts,dc=younglogic,dc=net
user_id_attribute=uid
user_name_attribute=uid
group_tree_dn=cn=groups,cn=accounts,dc=younglogic,dc=net


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

Restart Keystone. Juno RDO has Keystone running in Eventlet still, so use:

sudo systemctl restart openstack-keystone.service

Now, grant the admin user an admin role on the new domain:

openstack role add --domain YOUNGLOGIC --user  admin admin

Like most things, I did my initial test using curl:

{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "YOUNGLOGIC"
                    },
                    "name": "edmund",
                    "password": "nottellingyou"
                }
            }
        }
    }
}

curl -si -d @token-request-edmund.json -H "Content-type: application/json" $OS_AUTH_URL/auth/tokens

That requests an unscoped token. It has the side effect of populating the id_mappings for the user and group ids from the user that connects.

You can then assign roles to the user like this:

openstack role add --project demo --user  9417d7b6e7d53d719106b192251e7b9560577b9c1709463a19feffdd30ea7513 _member_

I have to admit I cheated: I looked at the database:

$   echo "select * from id_mapping;"  |  mysql keystone  --user keystone_admin --password=stillnottelling 
public_id	domain_id	local_id	entity_type
7c3448d7dc5f51861444a7f974bc63c77a2685a057d8545341a1fbcafd754b96	a9569e236912496f9f001e73fc978baa	ayoung	user
9417d7b6e7d53d719106b192251e7b9560577b9c1709463a19feffdd30ea7513	a9569e236912496f9f001e73fc978baa	edmund	user
862caa65329a761556ded5e6317f3f0cbfcab839f01340b334bdd2be4e54f1c4	a9569e236912496f9f001e73fc978baa	ipausers	group
b14ecd0d21ffb1485261ffce9c95b2cf8fec3d8194bfcda4257bb0ac74f80b0e	a9569e236912496f9f001e73fc978baa	peter	user
4e2abec872c7559279612abd2834ba1a3919aad9c01035cb948a91241a831830	a9569e236912496f9f001e73fc978baa	wheel	group

But with that knowledge I can do:

openstack role add --project demo --group  862caa65329a761556ded5e6317f3f0cbfcab839f01340b334bdd2be4e54f1c4 _member_

And now every user in the ipausers group gets put in the demo project. This works upon first login to Horizon.

UPDATE: See this post for a necessary configuration change.