I think many are still in our own Slack team here: https://drupalutah.slack.com If you join and post people will see it.
I'm not sure how many people made it over to the Drupal Slack or other platforms.
I've created a MR with the suggested original fix. In doing so I realized the fix should actually be that unknown entity type IDs, such as `taxonomy_term`, should not be passed into this method in the first place.
Until then, this fix will get me by.
Did you find a work around other than enabling taxonomy @jive01?
I ran into this again and Google brought me here, I'd forgotten that I ran into this before and posted about it. The fix I originally suggested above did work for me.
If anyone else has run into this I'm curious to hear what things you've done to work around it.
I agree that it would be more desirable to prompt a re-authentication with which ever auth plugin they used to sign in with rather than to provide a "bypass password confirm" permission.
In the scenario described in the original post, the person logging in as User 1 will still not be able to perform this action since they probably don't even know what random string was generated for User 1's password in the first place. Perhaps the solution for that level user is a drush command?
FWIW: The systems where I'm running into this issue I am using OpenID Connect connecting to an oAuth Server, not LDAP.
jeremyr → created an issue.