I've found parts of the problem, but here is my policy.json excerpt:

"cloud_admin": "role:admin and (token.is_admin_project:True or domain_id:d8aaf957fa5d4ced85cf308d464e0020)",
    "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s",
    "identity:get_domain": "rule:cloud_admin or rule:admin_and_matching_domain_id or token.project.domain.id:%(target.domain.id)s",
    "identity:list_projects": "rule:cloud_admin or rule:admin_and_matching_domain_id",
    "identity:list_user_projects": "rule:owner or rule:admin_and_matching_domain_id",
    "identity:list_users": "rule:cloud_admin or rule:admin_and_matching_domain_id",
    "identity:list_groups": "rule:cloud_admin or rule:admin_and_matching_domain_id",
    "identity:list_users_in_group": "rule:cloud_admin or rule:admin_and_matching_target_group_domain_id",

The cause of problem was the keystonerc-file I was sourcing, but I cant help wondering wether this error should be possible to avoid, and it seems I am still not all the way home...This was my inital keystonerc_admin:

export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=admin00
export OS_AUTH_URL=http://172.16.12.100:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

I realized from ngrepping on the keystone api at :35357, that openstack was asking for a project scoped token, (which I thought I needed since my belief was that a domain-local admin should only have admin-role on a project in the domain but that doesnt seem to be the case?), but reading the policy rule made me realise that the "admin_required and domain_id:" wanted a domain-scoped token.

So I ran "openstack user list --os-domain-name default", trying to get a domain scoped token, with the admin role, since my default admin user in the default domain, has the admin role on both default domain, and the admin project in the default domain. (Which seems to be a requirement, even for a local-domain admin)

However, because of (I assume) the OS_PROJECT_NAME env, the token is created with a:

{"auth": {"scope": {"project": {"domain": {"name": "Default"}, "name": "admin"}}, "identity": {"password": {"user": {"domain": {"name": "Default"}, "password": "admin00", "name": "admin"}}, "methods": ["password"]}}}

Now, yes, defining both OS_PROJECT_NAME and using --os-domain-name default is of course kinda stupid, but since I can only have EITHER project scoped OR domain scoped tokens, isnt it kind of a bug that the openstack CLI is trying to give me a project scoped token, using the DOMAIN NAME???

However, it still doesnt work 100% correctly I think. Undefining OS_PROJECT NAME, and running

"openstack user list --os-domain-name Default"

Will still not work. I have to do:

"openstack user list --os-domain-name Default --domain default "

And the reason I dont like that, is that I have to know the domain UUID(default), which a normal project/domain-*local* admin cant find out, because of the rule for identity:get_domain which said:

"identity:get_domain": "rule:cloud_admin or rule:admin_and_matching_domain_id or token.project.domain.id:%(target.domain.id)s",

The only way I can do openstack domain show <domain>, is if I already now the uuid to begin with...

Running

openstack user list --os-domain-name Default --domain Default
openstack domain show --os-domain-name Default Default

result in: "Could not find resource Default"

So. Maybe I can fix this by allowing domain-names in the rule for get_domain, but since I cant fathom that I would be the first to try to list users with a domain local admin-user, I cant believe that I need to change the recently downloaded policy file.

Surely the major users of Openstack have started using domains by now?

Best Regards

Taisto Qvist

2016-11-01 22:17 GMT+01:00 Taisto Qvist <taisto.qvist@gmail.com>:

Hi folks,

I've run into a wall with making openstack domain auth working, and I dont know where to get help, so I am trying here. I've created a question on:

https://ask.openstack.org/en/question/98429/project-specific-admin-unable-to-list-users-or-use-horizon/

..but no-one seems to be able to help.

Since I wrote that, I've gotten as far as creating a working cloud-wide admin(the policy trigger for cloud_admin matching against domain_id, didnt seem to work for the default domain...?), and that user is now working fine as super-mega-admin.

But my old admin user, that has admin rights only in the default domain, admin project, cant list users, or projects, in the default domain.

And sureley he should be able to, with the rules:

    "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s",
    "identity:list_users": "rule:cloud_admin or rule:admin_and_matching_domain_id",

I've tried to find comprehensive and up2date references on how to read the policy.json syntax, but no success so I am unsure on how to interpret the rule exactly though.
I tried changing to:

    "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(target.domain_id)s",

after looking at the rule for:

    "identity:get_project": "rule:cloud_admin or rule:admin_and_matching_target_project_domain_id or project_id:%(target.project.id)s",

But it didnt help. During the failure, I can see keystone logging:

2016-11-01 22:16:24.521 4824 INFO keystone.common.wsgi [req-46e3301f-f234-434b-a013-5aa2297b6119 admin_User                       admin_Prj                        - default default] GET http://172.16.12.100:35357/v3/projects/admin_Prj

(where admin_Prj/User is the UUID's regexped)

What is wrong? Where can I learn how to do this???