Not totally sure, but one possibility is that the administrator of your organization has enabled or updated the master password policy to require stronger passwords for end users. In this case, the next time you log in you would be informed of this and prompted to set a new password. I would expect there to be a callout explaining the requirements.
That wasn’t relevant, but I did figure it out. By default, the Windows client attempts to connect to bitwarden .com, and not to my own org’s self-hosted bitwwarden URL (obviously). I falsely assumed that it would somehow know the correct URL via the SSO process, but that is not the case, so I was being asked for my Master Password for the bitwarden .com cloud “instance”.
There is an easily-overlooked dropdown menu underneath the email address field when you first launch the client which says “Logging in on: [source]”. By default, “bitwarden .com” is selected here. I had to select “self-hosted” and fill out our org’s bitwarden URL in the dialog that pops up. It was also a bit finicky to get it to save this URL, but I eventually fumbled my way through it.
After doing that and continuing through the normal SSO process I was asked for my existing Master Password, as expected.
Part of the confusion here I suppose comes from the fact that I didn’t expect to be able to successfully authenticate to a bitwarden .com instance through our org’s SSO. I would have expected some error message saying that I don’t have an account with bitwarden .com or something. In reality I’m guessing we could probably log into the bitwarden .com cloud instance and use it if we really wanted to, though I have no interest in setting up a new Master Password to test that.