Keystone not removing mapping between deleted LDAP user and Openstack

[Nusrath Mohammed]

Keystone not removing mapping between deleted LDAP user and Openstack

The client is using LDAP for authentication and has used uid as a key for user_id_attribute. The client created a LDAP user say ABC with UID=100, this user is associated with an OpenStack user ABC. The relationship is recorded in id_mapping table within keystone database.

Now when the client delete the ldap user ABC, the entry is not deleted from the id_mapping table. Thus when the client create a new ldap user XYZ which get the same UID=100, the incorrect record in id_mapping restrict the new user XYZ from authenticating and successfully log on to OpenStack.

Note: there is not record for XYZ within the id_mapping table.

Details of domain config:

# User supplied configuration flags
user_filter = (memberof=cn=xxx,ou=Group,dc=xxx,dc=xxx)
user_id_attribute = uidNumber
user_name_attribute = uid
user_objectclass = posixAccount
user_tree_dn = ou=xxxxx,dc=xxx,dc=xx
[identity]
driver = ldap

Table Description

mysql> desc id_mapping;
+-------------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+----------------------+------+-----+---------+-------+
| public_id | varchar(64) | NO | PRI | NULL | |
| domain_id | varchar(64) | NO | MUL | NULL | |
| local_id | varchar(64) | NO | | NULL | |
| entity_type | enum('user','group') | NO | | NULL | |
+-------------+----------------------+------+-----+---------+-------+

[Xav Paice (xavpaice)]

Adding the charm because maybe there's a more unique field we can use than uid, given this behaviour with re-use of uid's

[Nusrath Mohammed (nusrath.mohammed)]

More details of the bug:

http://pastebin.ubuntu.com/25712801/

[David Ames (thedac)]

Xav,

In other deploys we have seen either of the following used:

user_id_attribute=cn
or
user_id_attribute=sAMAccountName

Docs use cn:
https://docs.openstack.org/keystone/latest/admin/identity-integrate-with-ldap.html

I don't think this is a charm bug. It is either configuration or upstream keystone. Please feel free to re-open the charm portion of the bug if I am mistaken.

[Nobuto Murata (nobuto)]

Cleanup of id_mapping table can be done with `keystone-manage mapping_purge`. More details:
https://docs.openstack.org/keystone/latest/configuration.html
Which is something the charm does not expose through charm actions as far as I understand.

[Drew Freiberger (afreiberger)]

For the upstream component, I'm finding from the database that I have a user id:

jujumanage@cmg01z00infr001:~$ openstack user delete --domain 8ce102de5ac644288f61838f5e0f46e7 21ea52cd8d92b555a8f0abdfcdc29dd5c9749a360c82628bc6779baddd19e601
No user with a name or ID of '21ea52cd8d92b555a8f0abdfcdc29dd5c9749a360c82628bc6779baddd19e601' exists.
jujumanage@cmg01z00infr001:~$ openstack user delete 21ea52cd8d92b555a8f0abdfcdc29dd5c9749a360c82628bc6779baddd19e601
You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-302698a3-ae69-4d0f-95aa-f00c352ffdb0)
jujumanage@cmg01z00infr001:~$
jujumanage@cmg01z00infr001:~$ openstack user list --domain 8ce102de5ac644288f61838f5e0f46e7 | grep 21ea52cd8d92b555a8f0abdfcdc29dd5c9749a360c82628bc6779baddd19e601
| 21ea52cd8d92b555a8f0abdfcdc29dd5c9749a360c82628bc6779baddd19e601 | <redacted> |
jujumanage@cmg01z00infr001:~$ openstack user delete --domain 8ce102de5ac644288f61838f5e0f46e7 <redacted>
You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-6e015c49-20c5-4c8a-b260-b1a16b8794e8)

You can clearly see that the user is defined in LDAP and in the database, but it is providing a 403 error, not authorized to the admin user of admin_domain. The LDAP backend is a separate domain context, so I could imagine that might be causing issues, or the fact that the LDAP backend is read-only.

I figure the cloud_admin role should be able to delete users in other domains:
keystone.conf:admin_project_domain_name = admin_domain
keystone.conf:admin_project_name = admin
policy.json: "cloud_admin": "rule:admin_required and (is_admin_project:True or domain_id:8402a2e7ba814885820198252398ee93 or project_id:1dd7ea6892c14ce480c9ecdaa5456f15)",
policy.json: "identity:delete_user": "rule:cloud_admin or rule:admin_and_matching_target_user_domain_id",

Is there a better method to purge the id_mapping and nonlocal_user table to be able to re-import users from an LDAP backend that may have changed it's primary user_id_attribute?

[Lance Bragstad (lbragstad)]

LDAP is a read-only backend for keystone. We do provide a way to purge users from the id_mapping backend [0][1][2]. Keystone does not receive push notifications from LDAP when users or group changes are made there.

Not that this must be done using the `keystone-manage` command. If you need more information on how this works, please swing by #openstack-keystone.

[0] https://github.com/openstack/keystone/blob/47dbd256258d747d95cb5320bd02ae207ecf60d6/keystone/cmd/cli.py#L824
[1] https://github.com/openstack/keystone/blob/47dbd256258d747d95cb5320bd02ae207ecf60d6/keystone/identity/core.py#L1470
[2] https://docs.openstack.org/keystone/latest/cli/index.html#keystone-manage