Sonoma doesn't recognize updated SMB password

I haven't heard anything new, just the solution I worked out with Apple support that I posted above (Reposting here). I've had about a dozen users with the problem since then and this fix has worked for everyone.

~~~~~~~~~~~~~~~~~~~~~~

After working with the senior education support team at Apple for a while, I think we have a viable solution to get past this without having to rely on the capitalization workaround.

We did testing with my iMac (Sonoma, Ethernet wired) and a laptop (Sonoma, Wi-Fi only). Despite this not being the case with some earlier incidents, we were able to confirm that there is now an entry in Keychain

Access  This entry is named after the SMB server that our users are trying to reach.  Interestingly enough, this entry appears there whether or not you select the checkbox for remembering your credentials at the Connect to Server login screen (in that case, it just has no username or password info). It is the culprit.

I tested this several times with a test user of my own, and confirmed that when I see the problem (the

new password not being accepted after a change), deleting this entry entirely and rebooting has been a solution consistently.  I know in the early stages of this problem, there was not a keychain entry - I do not understand what changed in that regard, possibly something that was changed in the various updates to OS 14.

After all the testing, I wanted to wait until a user in the field had the problem to try the solution out on them. I had a user this week report the problem, and confirmed that it DID fix the problem for them.

The official fix is:

1) Having them go into Utilties > Keychain Access > Choose Keychain Access from the popup window that appears > login (top left under Default Keychains) > Passwords (at top).

2) Locate the specific entry under Passwords that matches the FQDN of the server you were accessing, delete that entry completely, and shut down/restart the laptop.

After reboot, the entry is recreated when they try to log in again (again with no username or password date) even if they do not check the box to remember the credentials. But this time, they were able to log in.

A couple of notes:

1) This problem does NOT seem to happen at all, if the user is logged on to a Mac that's wired directly to our network and bound to Active Directory. It would seem that in those cases, Connect to Server is passing the AD credentials directly on to the SMB server when the user chooses 'Go > Connect to Server', and bypassing the Keychain entirely. (My assumption, based on what I'm seeing.)

2) It only happens with Macs not bound to AD / using local accounts.

3) I did try adding the user name and password to the entry in Keychain referenced above, this did not help. At some point I may try testing deliberately checking the box to save the credentials to see if this makes a difference, but that's a low priority given that the problem does have a resolution.

I have an update to add to this: Based on something I saw, I had the user change only the capitalization of their username at the credentials screen for the SMB server. So if they were jsmith1 before, I had them change to Jsmith1. Lo and behold, now their password is accepted and they can log in. (But not with jsmith1, I had them go back and try).

So somewhere, the jsmith1 is cached.. but I cannot find it. It's definitely not in Keychain > Passwords, but somewhere. I am concerned that every time they change their network password, they'll have to change to a different capitalization (and the University requires us to change passwords every 6 months.) That's going to be problematic very quickly. Anyone have an idea where this is being cached?

As directed by Apple Senior Support Staff for Education, I captured this happening with Screen Recording, and I also recorded the capitalization workaround with Screen Recording as well. Then I uploaded the logs to them and they confirmed receipt. They said they were going to talk to their engineers about this - he noted that the engineers will try to claim it was resolved due to the capitalization workaround, but I clarified to him that what happens next time they change their password? Eventually you run out of letters to alter capitalization with (and I confirmed that all caps fails just like all lower case.) I was told they'd contact me back on Monday.. that was on 4/25/2024. I've waited this long to give them time, but will be contacting them again to follow up.

Unfortunately, changing the password for the user on the server end is not an option here (the network's password policy forces a change every 6 months, and the policy also prevents any of the last 6 passwords from being re-used). So I'm force to find temporary workarounds (like creating a new user profile on the Mac, or trying a different capitalization on the username) until I can figure out why Sonoma's not transmitting the correct password to the server. I can definitely verify that none of these users opted to remember the password in Keychain, and we dug through Keychain very carefully to ensure there was nothing saved that had anything to do with that SMB server address.