We have a few student researchers who have been at our institution for long enough that a change many years ago which standardised usernames is causing weird issues in our Open OnDemand environment.
The OOD VM is joined to our Active Directory, with users authenticating in their browsers via MS365 which sends their UPN. Since 99.9% of users have both a matching legacy sAMAccountName and UPN, home directory mapping goes through without an issue. However with the very few users that have this mismatch, home directory mapping fails as `Etc.getpwuid` seems to use passwd which doesn’t put the two together, instead of getent passwd which does correctly link the UPN and sAMAccountName together.
We currently have an exception in place for these few users that let them login to the portal via SSH however Cyber isn’t too keen on this staying put (which unfortunately we don’t have much leeway over). This is definitely a very niche bug so I’m not sure if there’s any actual workarounds we could use here. Has anyone else tackled this at their site?
Right now they’re just shown our “Home directory not found” page. I think there was an instance where they got a blank page that just showed “Invalid user 123456” (not their actual username), but they haven’t provided a screenshot of this.
Seems like re implement our use of Etc.getpwuid wherever we use it.
Initially it’s here:
Then when the dashboard boots up here:
If you have a test or dev instance you don’t mind corrupting and possibly rolling back or re-installing ondemand, it may be worth a go, but seems quite dangerous anyhow. You can issue commands in ruby with backticks like this `getent passwd`.
Again going to kind of a big lift and probably even a bit dangerous, but I’m not really sure what else can be done.
We’ll have a poke around with it on our dev instance, I did speak to our systems head earlier today who said they might just go down the route of renaming the affected account to match, which if it doesn’t cause issues with any other systems, will probably be the preferred fix until the few remaining students with this discrepancy graduate out over the next year or so
This issue was thankfully the motivation needed internally to fix the affected users once and for all on the IdP end where our systems guys renamed their sAMAccountName to their UPN, and will be doing this for the few remaining researchers with this discrepancy so we don’t need to go digging into the OOD source and potentially make things vulnerable.
This was thankfully easy for them to do since the rest of our services already go by UPN anyway, I can’t say this’ll be as painless at other places that might come across this in the future