Keystone not removing mapping between deleted LDAP user and Openstack

Bug #1722293 reported by Nusrath Mohammed
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Invalid
Undecided
Unassigned
OpenStack Keystone LDAP integration
Invalid
Undecided
Unassigned

Bug Description

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 | |
+-------------+----------------------+------+-----+---------+-------+

Revision history for this message
Xav Paice (xavpaice) wrote :

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

affects: keystone → charm-keystone-ldap
Revision history for this message
Nusrath Mohammed (nusrath.mohammed) wrote :

More details of the bug:

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

Revision history for this message
David Ames (thedac) wrote :

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.

Changed in charm-keystone-ldap:
status: New → Invalid
Revision history for this message
Nobuto Murata (nobuto) wrote :

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.

Revision history for this message
Drew Freiberger (afreiberger) wrote :

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?

Revision history for this message
Lance Bragstad (lbragstad) wrote :

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

Changed in keystone:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.