With LDAP auth against AD, namespace names sometimes become broken

[AndreasUfert]

Hi,

I've recently set up a Portus system based on the opensuse/portus image from Docker Hub (contains portus-2.1.0~dev+git050d095b08875306923663c8a1f9dfd9798bd0fb-5.1.x86_64). Portus authenticates against AD using this configuration:

ldap:
  enabled: true
  hostname: "<some_domain>"
  port: 636
  method: "simple_tls"
  base: "<some_base>"
# all non-disabled users
  filter: "(&(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
  uid: "sAMAccountName"
  guess_email:
    enabled: true
    attr: "mail"
  authentication:
    enabled: true
    bind_dn: "<some_dn>"
    password: "<some_password>"

This works pretty well. Users are created on first login, together with their personal namespaces.

But some users get ForenameSurname as their username, others get forenamesurname. It might depend on what form the user uses on first login.

In case of the username this is not such a big deal. But it is when it comes to the name of the personal namespace, users with an username ForenameSurname get their namespace created as orename_urname while the all-lowercase users get their namespace created identical to their username (forenamesurname).

I guess, some lowercase transformation of the username in the first place (on first login) might be necessary to avoid both problems.

[AndreasUfert]

Just one small remark: The LDAP objects of all-lowercase and camelcase users in AD don't seem to differ substantially. That's why my guess was that it depends on how the user states his username on first login.

[mssola]

I will look into this. I've already heard some cases on case insensitivity problems...

[mssola]

Wrong button 😁

[mssola]

@andreaskrause I believe that #993 should already cover your case. Now, the first thing Portus will do if the given username does not match Docker's requirements, is to downcase everything. So, if I have a user named Miquel, it will now have a namespace named miquel instead of _iquel.

If this makes sense to you, I believe that we can re-tag this from bug to enhancement. This is because I believe that the most offending case is solved with this, but it could be further improved somehow (don't really know since this depends on the configuration of the LDAP server being used).