Bug 1459196 - While using "add" mappingMethod strategy, when the LDAP attribute name has a space, it can't recognize as the same identity and create a new user registry.
While using "add" mappingMethod strategy, when the LDAP attribute name has a ...
Status: CLOSED NOTABUG
Product: OpenShift Container Platform
Classification: Red Hat
Component: Auth (Show other bugs)
3.3.0
All All
unspecified Severity medium
: ---
: ---
Assigned To: Jordan Liggitt
Chuan Yu
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-06 10:01 EDT by Bruno Andrade
Modified: 2017-07-01 09:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-01 09:49:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Andrade 2017-06-06 10:01:55 EDT
Description of problem:

Issue while using "add" mappingMethod strategy, when the LDAP attribute name has a space, it can't recognize as the same identity and create a new user registry.

Version-Release number of selected component (if applicable):
3.3.0

Steps to Reproduce:

Steps to reproduce this problem:

1-
User DN : CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo

Ldap settings:

oauthConfig:
  assetPublicURL: https://console.bandrade.me:8443/console/
  grantConfig:
    method: auto
  identityProviders:
  - name: ldap_provider
    challenge: true
    login: true
    mappingMethod: add
    provider:
      apiVersion: v1
      kind: LDAPPasswordIdentityProvider
      attributes:
        id:
        - dn
        email:
        - mail
        name:
        - cn
        preferredUsername:
        - uid
      bindDN: cn=admin,ou=Users,ou=LDAP,dc=directory,dc=osedemo
      bindPassword: "***"
      insecure: true
      url: ldap://10.0.2.63:389/ou=Users,ou=LDAP,dc=directory,dc=osedemo?sAMAccountName

First login:
oc login -u bandrade -p ****
oc get user

NAME                                                        UID                                    FULL NAME       IDENTITIES
CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo   d999b05c-4a53-11e7-ad19-02a9f58e73b3   bruno andrade   ldap_provider:CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo


2) Change id attribute from "dn" to "sAMAccountName" and restarted master service

oauthConfig:
  assetPublicURL: https://console.bandrade.me:8443/console/
  grantConfig:
    method: auto
  identityProviders:
  - name: ldap_provider
    challenge: true
    login: true
    mappingMethod: add
    provider:
      apiVersion: v1
      kind: LDAPPasswordIdentityProvider
      attributes:
        id:
        - sAMAccountName
        email:
        - mail
        name:
        - cn
        preferredUsername:
        - uid
      bindDN: cn=admin,ou=Users,ou=LDAP,dc=directory,dc=osedemo
      bindPassword: "***"
      insecure: true
      url: ldap://10.0.2.63:389/ou=Users,ou=LDAP,dc=directory,dc=osedemo?sAMAccountName

systemctl restart atomic-openshift-master

Second login: 

oc login -u bandrade -p ****


oc get users
NAME                                                        UID                                    FULL NAME       IDENTITIES
CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo   d999b05c-4a53-11e7-ad19-02a9f58e73b3   bruno andrade   ldap_provider:CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo
bandrade                                                    2e1f69a4-4abe-11e7-b90a-02a9f58e73b3   bruno andrade   ldap_provider:bandrade



Actual results:

oc get users
NAME                                                        UID                                    FULL NAME       IDENTITIES
CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo   d999b05c-4a53-11e7-ad19-02a9f58e73b3   bruno andrade   ldap_provider:CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo
bandrade                                                    2e1f69a4-4abe-11e7-b90a-02a9f58e73b3   bruno andrade   ldap_provider:bandrade




Expected results:
Only one user registry with two identities.

oc get users
NAME                                                        UID                                    FULL NAME       IDENTITIES
CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo   d999b05c-4a53-11e7-ad19-02a9f58e73b3   bruno andrade   ldap_provider:CN=bruno andrade,OU=Users,OU=LDAP,DC=directory,DC=osedemo


Additional info:

This using Active Directory
Comment 1 Jordan Liggitt 2017-06-06 10:13:42 EDT
It appears that the LDAP entries for the users do not have a uid attribute, which means they fall back to using the id attribute (first "dn", then "sAMAccountName") as the preferred username.

When you changed the id attribute, it meant the next login retrieved what appeared to be a new identity. It then determined the openshift username for that identity using the sAMAccountName, found that user did not exist, and created it as well.

Is the goal to use sAMAccountName as the OpenShift username? If so, you can simply change the preferredUsername attribute to sAMAccountName, and leave the id attribute as dn. Existing users will not change their username, but new users will get a username matching their sAMAccountName.
Comment 2 Bruno Andrade 2017-06-07 00:52:37 EDT
The goal is to use sAMAccountName as Kibana due to a bug with the customer Distinguished Names https://bugzilla.redhat.com/1456584. The problem is that Kibana uses the  x-proxy-remote-user header that uses the ID attribute. As the customer already have some users added on Openshift, the purpose was to use mappingMethod ADD to not loose all already added roles. But as I'm seeing the only way to go is delete all users and identities.
Comment 3 Jordan Liggitt 2017-06-08 03:56:03 EDT
If you want to change openshift usernames for new users while keeping old users as-is, change the preferredUsername setting, NOT the id setting. 

Switching back to dn for the id, and using sAMAccountName as the preferredUsername should do what you want for new users

Note You need to log in before you can comment on or make changes to this bug.