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

Bug 1439439

Summary: OpenShift with LDAP (active directory) auth is showing identities with non printable chars
Product: OpenShift Container Platform Reporter: Kenjiro Nakayama <knakayam>
Component: apiserver-authAssignee: Mo <mkhan>
Status: CLOSED WONTFIX QA Contact: Chuan Yu <chuyu>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.4.1CC: ahardin, aos-bugs, dranders, eparis, erich, jliggitt, jpazdziora, knakayam, mfojtik, mkhan, pweil, ssorce, tatanaka
Target Milestone: ---Keywords: OpsBlocker, Reopened
Target Release: 3.7.0Flags: mkhan: needinfo-
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-26 16:05:59 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 Kenjiro Nakayama 2017-04-06 02:01:13 UTC
Description of problem:
---
  "oc get users" shows non printable chars as below.

  # oc get users
  NAME            UID                                    FULL NAME       IDENTITIES
  foo             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   foo.bar         xxxxxxx:|K�ߵ
  A���b��5


Version-Release number of selected component (if applicable):
---
  OCP 3.4 (customer experienced this issue on Dedicated)

How reproducible:
---
  Steps to Reproduce:
  1. Configure auth with LDAPPasswordIdentityProvider (backend: Active directory)
  2. Run "oc get users"

Actual results:
---
  # oc get users
  NAME            UID                                    FULL NAME       IDENTITIES
  foo             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   foo.bar         xxxxxxx:|K�ߵ
  A���b��5

Expected results:
---
  show readable chars.

Comment 13 Michal Fojtik 2017-05-25 11:15:23 UTC
Ping?

Comment 17 Takayoshi Tanaka 2017-08-18 00:15:27 UTC
I updated the Priority and Severity to high as I have another customer's case that the new user can't log in to OpenShift due to this BZ. 
Do you have any workarounds?

Comment 19 Takayoshi Tanaka 2017-08-18 08:49:28 UTC
The behind customer wants to change objectGUID to sAMAccountName in order to workaround this issue. As far as my understanding, it has no side effect. Could you double-check this workaround is safe?

Comment 26 Jan Pazdziora (Red Hat) 2017-09-11 09:39:20 UTC
Does it make sense to work on converting objectGUID, or perhaps all binary attributes, to string representation (hex values or something)?

FWIW, I've asked how SSSD does it and the answer is: SSSD stores objectGUID as well as the SID in the string representation in the cache. Not sure if this is 'best practice' but that how we currently do it. The main reason is that from the SSSD point of view those values are either searched for with the string representation as input or the values should be displayed. In both cases storing them as strings helps to avoid some conversions.

Comment 27 Simo Sorce 2017-10-18 19:40:23 UTC
Given identities are meant to be printable strings in general and that usually there are unique printable attributes in LDAP directories (samAccoutName for example in AD), and given the fact a change in this area would be both non-trivial and potentially backwards incompatible, we think the change in documentation[1] about not using binary attributes should be sufficient.

So I am going to close this bug as WONTFIX, please reopen if necessary.

[1] https://github.com/openshift/openshift-docs/pull/5343

Comment 49 Simo Sorce 2018-04-05 11:49:56 UTC
Let me reinforce this.

The default configuration we support uses the sAMAccountName field.

This is the field that fundamentally *all* software interacting with AD uses to represent a user in AD in normal circumstances.

Other fields can *optionaly* be used as long as they are TEXT attributes (both ASCII and Unicode are fine).

Using binary attributes is not supported and also not necessary in normal AD installations and will, most likely, not be supported in future by our LDAP backend.

NOTE: If the customer has special needs around attribute trasformation, they may consider using a SAML/OIDC Idp (like ADFS, Keycloak, etc..) instead of the LDAP Idp. Assuming that those tool give them the ability to use arbitrary attributes and transforms binary ones into a text ID.