This is caused after Upgrade to use Spring Security.
May be an Breaking Change for coming LTS Upgrade is needed.

see: https://community.developer.atlassian.com/t/crowd-login-error-java-lang-unsupportedoperationexception-not-giving-you-the-password/35183

The exception is thrown from CrowdUser.getPassword, which was indirectly called by TokenBasedRememberMeServices2.onLoginSuccess, which would then forward the password to makeTokenSignature. However, TokenBasedRememberMeServices2.makeTokenSignature ignores its password parameter. TokenBasedRememberMeServices2.makeTokenSignature is not overridden in any other class: no class in jenkinsci/jenkins extends TokenBasedRememberMeServices2, and plugins do not extend it either because it has a @Restricted(NoExternalUse.class) annotation. So, it seems to me that TokenBasedRememberMeServices2 could be changed not to call getPassword at all.

Until then, I'll just check the "Disable remember me" check box at the top of the "Configure Global Security" page.

See also JENKINS-65358.

The culprit seems to be Jenkins core PR#4848 (for JEP-227 aka JENKINS-5303), which made TokenBasedRememberMeServices2.onLoginSuccess call UserDetails.getPassword(). Before that was merged, TokenBasedRememberMeServices2.loginSuccess used to pass the whole UserDetails object to TokenBasedRememberMeServices2.makeTokenSignature, which did not call UserDetails.getPassword().

Perhaps this could be fixed by adding private String makeTokenSignature(long tokenExpiryTime, String username) to TokenBasedRememberMeServices2 and then make TokenBasedRememberMeServices2.loginSuccess call that rather than protected String makeTokenSignature(long tokenExpiryTime, String username, String password). I think that would be cleaner than passing a dummy or null password.

ImpersonatingUserDetailsService2.attemptToImpersonate, ReverseProxyUserDetails.getPassword, GitLabOAuthUserDetails, and PWauthSecurityRealm.createSecurityComponents use an empty string as the password.

SamlUserDetails.getPassword uses null as the password.

So if CrowdUser.getPassword were changed to return an empty string or null, instead of throwing, I think it would fix the problem and be consistent with existing practice. Perhaps the license issue INFRA-2271 and the JAXB dependency JENKINS-59301 are more urgent, though.

So if CrowdUser.getPassword were changed to return an empty string or null, instead of throwing, I think it would fix the problem and be consistent with existing practice.

This is indeed what I did. We're using a custom build with this change sucessfully for a couple of months now.

 mcmics thank you for the information !

New version got released and this should fix this error. 

Thank you, much appreciated!