<div dir="ltr">Hey all, hoping that someone else might be running into this too... Right now I'm in the process of trying to get Keystone deployed, set up for v3 API usage, with multiple identity backends (specifically, a SQL backed default domain for service accounts, and another backed by LDAP for users). I've had luck so far using the Keystone module to get as far as I can and then doing the not yet supported multi-domain bits with lower level resources... But I'm running into one snag that I've not yet been able to find a workaround for yet. <div><br>During runs, after the multi-domain config has been laid down, I'm seeing output like this where an attempt is made to see if the admin user exists, then create the user if not. Polling of existing users fails due to an authentication failure for the user list command, which causes an attempt to create the already extant admin user, which results in the resource failing and following actions being abandoned. </div><div><br></div><div>--</div><div><br></div><div><div>Debug: Executing '/usr/bin/openstack user list --quiet --format csv --long'</div><div>Error: Could not prefetch keystone_user provider 'openstack': Could not authenticate.</div><div>Debug: Executing '/usr/bin/openstack user create --format shell username --enable --password password --email username@domain --domain domain'</div><div>Error: Execution of '/usr/bin/openstack user create --format shell username --enable --password password --email username@domain --domain domain' returned 1: ERROR: openstack Conflict occurred attempting to store user - Duplicate Entry (HTTP 409) (Request-ID: req-1ae18aaf-8a2c-42bd-a456-83303ec668b1)</div><div>Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[openstack-keystone]/ensure: change from absent to present failed: Execution of '/usr/bin/openstack user create --format shell username --enable --password password --email username@domain --domain domain' returned 1: ERROR: openstack Conflict occurred attempting to store user - Duplicate Entry (HTTP 409) (Request-ID: req-1ae18aaf-8a2c-42bd-a456-83303ec668b1)</div><div>Notice: /Stage[main]/Keystone::Roles::Admin/Keystone_user_role[openstack-keystone@openstack]: Dependency Keystone_user[openstack-keystone] has failures: true</div><div>Warning: /Stage[main]/Keystone::Roles::Admin/Keystone_user_role[openstack-keystone@openstack]: Skipping because of failed dependencies</div></div><div><br></div><div>--</div><div><br></div><div>If I look in the Keystone logs I can see the authorization failure.</div><div><br></div><div>--</div><div><br></div><div><div>2015-07-17 10:40:52.922 5155 INFO keystone.common.wsgi [-] GET /users?</div><div>2015-07-17 10:40:52.922 5155 WARNING keystone.common.controller [-] RBAC: Bypassing authorization</div><div>2015-07-17 10:40:52.924 5155 WARNING keystone.common.controller [-] Invalid token found while getting domain ID for list request</div><div>2015-07-17 10:40:52.925 5155 WARNING keystone.common.wsgi [-] Authorization failed. The request you have made requires authentication. from 127.0.0.1</div></div><div><br></div><div>--</div><div><br></div><div>This only happens with multi-domain configuration in place. Checking out the internals of Keystone, it looks like this happens because when a list request is made in a multi-domain context the token used must have a domain associated with it. Because the provider is using the built in admin token, this domain association doesn't exist. At least, I think that's what's going on, based on what I've read and explored so far. </div><div><br></div><div>Was wondering if anyone else had encountered this and come up with a way around it. So far I'm not seeing any satisfying way of dealing with this, but still poking around...</div></div>