Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1998531

Summary:	String length exceeded local_id mapping to LDAP
Product:	Red Hat OpenStack	Reporter:	Jeremy <jmelvin>
Component:	openstack-keystone	Assignee:	Grzegorz Grasza <ggrasza>
Status:	CLOSED DUPLICATE	QA Contact:	Jeremy Agee <jagee>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16.1 (Train)	CC:	alee, oblaut
Target Milestone:	ga	Keywords:	Triaged
Target Release:	17.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-30 14:50:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jeremy 2021-08-27 13:31:51 UTC

Description of problem:

Copying upstream bug here to implement into RHOSP:
https://bugs.launchpad.net/keystone/+bug/1929066

LDAP Group ID may exceed the current table limit:

String length exceeded. The length of string '***' exceeds the limit of column local_id(CHAR(64)). (HTTP 400) (Request-ID: req-bf68d05f-dc7b-4f4b-bbb0-d2a11728de86)

From an upstream bug[1] we had the following solution:

The workaround for this issue is to not use objectGUID as the user or group ID. However, that workaround might not be applicable in all situations. For example, the default value for user_id_attribute is 'cn', but if that value spans more than 64 characters, keystone can't work with it.

But for security reasons, customer can't change the field mapped.

I believe the limit can be safely changed to 255 without impacting other openstack projects, keystone backends or subsystems.

[1] https://bugs.launchpad.net/keystone/+bug/1889936/comments/1

Comment 1 Grzegorz Grasza 2021-08-30 14:29:38 UTC

https://bugzilla.redhat.com/show_bug.cgi?id=1959345 <- this is the original bug, maybe we should mark this one as duplicate?