Need option for Converting user's ID to uppercase/lowercase in group LDAP Sync

[mgjadoul]

In an Classical Enterprise using Active Directory + ADAM for authentication and authorization, login are case insensitive. In Unix / openshift the UID are case sensitive apparently. In AD, there is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later. We implemented an Apache config for authentication in Kerberos and including normalizing the login to uppercase. This resolved the issue for authentication.

Now we would like to implement group syncronization and the issue is basically the same issue. The UID we retrieve (from ADAM) is case insensitive and there are no guarantee the the case match the case in AD and in any case it is not always uppercase.
We need an option in oc adm group sync ... to allow converting uid to uppercase.

The output is currently:

apiVersion: v1
items:
- apiVersion: v1
  kind: Group
  metadata:
    annotations:
      openshift.io/ldap.sync-time: 2016-12-06T15:20:5900100
      openshift.io/ldap.uid: CN=G1,OU=myapp,OU=Apps,O=xxx
      openshift.io/ldap.url: ldapvip.xxx.corp:636
    creationTimestamp: null
    labels:
      openshift.io/ldap.host: ldapvip.xxx.corp
    name: G1
  users:
  - USER1
- apiVersion: v1
  kind: Group
  metadata:
    annotations:
      openshift.io/ldap.sync-time: 2016-12-06T15:20:5900100
      openshift.io/ldap.uid: CN=G2,OU=myapp,OU=Apps,O=xxx
      openshift.io/ldap.url: ldapvip.xxx.corp:636
    creationTimestamp: null
    labels:
      openshift.io/ldap.host: ldapvip.xxx.corp
    name: G2
  users:
  - USER2
  - user3
- kind: List
metadata: {}

Notice the user "user3" in lower case. We need an option to get the same output but with all users in upper case.

The lower case user does not exists in openshift:

$ oc get user USER3
NAME      UID                                    FULL NAME   IDENTITIES
USER3   5f9487ba-b716-11e6-9a1c-68b5996b6fee               requestheader:USER3
$ oc get user user3
Error from server: users "user3" not found

Where are you experiencing the behavior? What environment?

PROD in enterprise with ActiveDirectory Authentication and AD LDS authorisation.

Version

oc v3.2.1.17
kubernetes v1.2.0-36-g4a3f9c5

[enj]

cc @stevekuznetsov @liggitt

[liggitt]

We do not use user input as user names directly, but use that to look up data from LDAP. The attributes read from LDAP should be canonical.

[liggitt]

I'd rather see documentation for using attributes from LDAP as the username in Apache auth (should be possible with mod_lookup_identity), rather than trying to normalize the user-provided id in parallel ways in multiple components

[liggitt]

some documentation around mod_lookup_identity exists at https://docs.openshift.org/latest/install_config/advanced_ldap_configuration/configuring_extended_ldap_attributes.html

would like to see a reference configuration that pulls the uid from LDAP using that, which would remove the need for upper-casing in Apache, and would make group sync and auth agree

[mgjadoul]

We do not use SSSD (yet).... It could take some time as in our case it requires implementing IPA.
If you do a reference implementation based on this only.... Some won't be able to use it.

As far as I understand, your solution does not solve fully the issue .... As stated above: There is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later. Our Openshift Project is a small project and changing identity management processes is not in the scope.
If we do not make the uid uppercase, we would have to delete existing users and recreate them or at the end we would end with multiple users in openshift for the same person: UserX=userx=userX=USERX=....
And if users have role attached, you need to recreate those roles also.

NB: We have an httpd configuration able to do the same as mod_lookup_identity does: sending attribute from ldap. It is quite simple with mod_authz_ldap. The config bellow set a header for the email.

#Kerberos authentication.
    AuthType VAS4
    AuthVasUseBasic On
    AuthName Openshift
    AuthVasRemoteUserMap ldap-attr sAMAccountName
    AuthVasAuthz Off

#Ldap Authorization also providing mail attribute
    LDAPReferrals On
    AuthLDAPUrl "ldaps://<myldapurl>/O=acme?uid,mail?sub?(objectClass=*)"
    AuthLDAPBindDN CN=binduser,OU=Users,OU=Apps,O=acme
    AuthLDAPSubGroupClass group
    AuthLDAPBindPassword <...>
    AuthLDAPGroupAttributeIsDN on
    AuthLDAPCompareDNOnServer on
    AuthLDAPMaxSubGroupDepth 2
    Require ldap-group CN=developers,OU=Groups,OU=openshift,OU=Apps,O=acme

    RequestHeader set X-Remote-Email "%{AUTHORIZE_MAIL}e" env=AUTHORIZE_MAIL

[mgjadoul]

In the mean time we implemented a filter and calling it like this:

$ oadm groups sync --sync-config=rfc2307_config.yaml -o json | ./groupmember_to_upper.py | oc create -f -

The filter is basic: importing json, changing users to upper, exporting json.

[stevekuznetsov]

As far as I understand, your solution does not solve fully the issue .... As stated above: There is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later.

Could you expand on this? As I understand it, if you were to configure your authentication via the LDAPPasswordIdentityProvider to report the LDAP entry DN with fidelity, there will be no issue. If the LDAP attribute used for naming OpenShift User objects is passed without processing from LDAP to OpenShift (through Apache, etc), when further data is requested from LDAP by the sync, the same attribute, again with no changes, will be used to denote group membership for users in OpenShift. If you can ensure that your authentication flow is passing canonical information from LDAP to OpenShift, the sync operation will require no such lower-casing option, or filters otherwise.

[mgjadoul]

Hello Steve, Our AD, LDAP or more generally our corporate directories are only publication of identity access information for applications. It is driven by an Identity layers. This Identity Layer is composed from many historical tools. It is continuously evolving depending the company evolution (reorganization of the company, purchase of selling of companies, implementation of new tool / processes, consolidation, .....). In addition a user may be removed and then recreated tomorrow as another user (other DN) for other external reason (user disabled/reenabled, ...). He would keep its attributes but the DN would change. The DN or the user is typically : CN=X-140925131929508787857,OU=<locality>,OU=FR,OU=Persons,O=Acme There is no garantee from the IAM Departement that the letter case of any case insensitive attribute (including uid) will not change. Regards, Marc

…

On Sun, Dec 11, 2016 at 11:02 PM, Steve Kuznetsov ***@***.***> wrote: As far as I understand, your solution does not solve fully the issue .... As stated above: There is no guarantee if the ID will be upper case, lower case or a mix. There is also no guarantee that it won't change later. Could you expand on this? As I understand it, if you were to configure your authentication *via* the LDAPPasswordIdentityProvider to report the LDAP entry DN with fidelity, there will be no issue. If the LDAP attribute used for naming OpenShift User objects is passed without processing from LDAP to OpenShift (through Apache, etc), when further data is requested from LDAP by the sync, the same attribute, again with no changes, will be used to denote group membership for users in OpenShift. If you can ensure that your authentication flow is passing canonical information from LDAP to OpenShift, the sync operation will require no such lower-casing option, or filters otherwise. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARLbSN8yw81STwcs_xG282qvuXX74Pjwks5rHHL8gaJpZM4LGfBO> .

[stevekuznetsov]

He would keep its attributes but the DN would change.

@liggitt will have more insight on this, but I think a core assumption for any of the data stores backing an Identity Provider for use in OpenShift is that they should be stable, canonical sources of data.