Login username translation

Get Help
1

In my attempts to make OOD easier to use for customers, I wrote a quick one-liner to translate user logins to 1) lowercase and 2) remove the @organization.org from the user login

This was to help case tYpOs, and also allow either short or full name logins to ondemand.

The method I used for this was the user_map_cmd, which I claim worked for logins in OOD V2, but this seems to only work after login in v3 (I added a logger statement and the usernames seem happy there, but the LDAP lookup is searching for usErNaMe@organization.org instead of ‘username’)

It would be fairly easy to convince me that this never worked as intended… but I do remember at least testing this in v2 and seeing what I would have expected… Is there a way to map usernames in v3 for the ldap search?

2

Hi, sorry for the delay.

Should be the same mechanism in 3 as it was in 2. user_map_cmd works the same in both versions and should behave the same. I wonder if there’s something obvious that your missing like a misconfiguration or similar? Can you share your ood_portal.yml (obfuscating anything you need).

3

No worries at all- I appreciate your time!
snipped out hostnames and other identifying info…

servername: ondemand-prd
server_aliases:
- ondemand2
- ondemand
ssl:

  • ‘SSLCertificateFile “/etc/dehydrated/certs/cert.pem”’
  • ‘SSLCertificateKeyFile “/etc/dehydrated/certs/privkey.pem”’
  • ‘SSLCertificateChainFile “/etc/dehydrated/certs/chain.pem”’
    use_rewrites: true
    user_map_cmd: /local1/scripts/user_chomp.sh
    oidc_session_inactivity_timeout: 345600
    oidc_session_max_duration: 604800
    oidc_state_max_number_of_cookies: “7 true”
    dex:
    ssl: true
    https_port: “8080”
    connectors:
    • type: ldap
      id: ldap
      name: LDAP
      config:
      host: :636
      insecureSkipVerify: true
      bindDN:
      bindPW:
      userSearch:
      baseDN: dc=,dc=,dc=
      filter: “(objectClass=*)”
      username: sAMAccountName
      idAttr: sAMAccountName
      emailAttr: mail
      nameAttr: cn
      preferredUsernameAttr: sAMAccountName
      groupSearch:
      baseDN: DC=,DC=,DC=
      filter: “(objectClass=posixGroup)”
      userMatchers:
      - userAttr: DN
      groupAttr: member
      nameAttr: cn
      host_regex: ‘n\d+’
      node_uri: ‘/node’
      rnode_uri: ‘/rnode’

The user_chomp.sh is simple:
#/bin/sh
echo $1 | tr ‘[:upper:]’ ‘[:lower:]’ | sed ‘s/@.*//’

4

OK - I wonder if it’s as simple as the file not being executable, and therefore doesn’t execute. Can you check the file permissions of /local1/scripts/user_chomp.sh?

5

That is a good thought- I did confirm it is executing by adding a logger statement, and I checked again to ensure that +x was set… to fully validate that my eyes were not deceiving me there

6

So it is in fact running. If you turn your lua_log_level to debug, I wonder what messages you’d see? We’d start to print out stuff like Mapped user 'annie.oakley@osc.edu => 'annie.oakley'.

Or you can try something like this and check journalctl. Note I’m using echo -n here because I’m not 100% sure how those newlines are being handled.

#/bin/sh

INPUT_USER=$(echo -n $1 | tr '[:upper:]' '[:lower:]' | sed 's/@.*//')

logger -t 'ood-mapping' "Mapped '$1' to '$INPUT_USER'"

echo -n "$INPUT_USER"
7

That is turning into big data quick :slight_smile: the Mapped lines show the short name when a short name is used, but when a username@corp.edu is tested… the Mapped line does not show anything in the logfile… both with your example, and the original one-liner.

I do still see the ldap error for the lookup of the @corp.edu being included… just to confirm the auth is still doing lookups there: ‘ldap: no results returned for filter’

8

OK - not sure what this means. The names being passed are URL encoded - so maybe that’s an issue? That is - you’re not getting annie.oakley@osc.edu you’re getting annie.oakley%40osc.edu.

I’m sort of grasping at straws here - not really sure why/how you’re not seeing any output when you use that username.

9

The oddity here is that the ldap lookup is still showing the full annie.oakley@osc.edu, but it appears that ondemand-dex is not kicking off the user map cmd.
Any way that I could poke more at the process that calls ondemand-dex and passes the username to try there?

I did test out ‘UsErNaMe’ to see if I could at least see the user map cmd kick in for that username and I similarly do not see an associated ood-mapping line. This makes me think that the user map cmd is not being run until people log in successfully. The ldap query passes the ‘UsErNaMe’ as it is typed, but it seems that the search is case-insensitive and returns true on the search. Once logged in- I can see the user_map_cmd working against my user account in syslog.

I am starting to regret getting rid of my ood v2 server- would love to test this out on that machine… but like I said… I could be mistaken that this was working there

10

:man_facepalming: That’s true. Usually something like dex or an OIDC provider gives the preferred_name which is the username. But sometimes it doesn’t. So the user_map_cmd or user_map_match turns that username into the correct Linux username on the system.

Sorry I didn’t realize this before - I’m just reading this and responding to the question and didn’t think about it deeply enough.

I just tried on our system (using jOhrstroM - my username being johrstrom) and it appears Keycloak is smart enough to downcase it before issuing the ldap query (or ldap is smart enough to downcase it?).

Again - sorry to give you the run around. When I google search Ldapsearch case insensitive it returns a lot of results and apparently indicates that things should be case insensitive.

Maybe the difference here between v2 and v3 is actually Dex and how they changed something or the LDAP configuration you’re using.

11

I would also suggest replicating in a command line with ldapsearch. Yes user mapping happens after the ldap search has successfully completed, but issuing ldapsearch by hand in a CLI may indicate what the search results return and if there are LDAP settings/queries you need to modify.

12

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.