Sonoma doesn't recognize updated SMB password

Good afternoon,

I have an issue that is cropping up more and more now and I have yet to determine the cause or a solid solution. We have an SMB file server on our campus network, which is protected by a VPN and requires the user to enter their University network username and password to access it.

Four separate users in the last few months have reported that, after they change their University account password, they can no longer log into the fileserver - the credentials window rejects their password, even though they are 100% positive that they entered the new password correctly (and I have confirmed / tested it myself for them.)

EDIT: They are able to log onto the VPN stage normally, it is only the Go > Connect to Server option to reach the smb:// server that is rejecting their password.

In every case, the user is running OS 14 Sonoma. In the first two cases, I was able to resolve it by having them restart and then it worked normally.

The third user was able to log onto the server on other computers, and I was able to log in with my own credentials on their computer. We went through Keychain > Passwords, but there was nothing stored that we were able to locate. The 'resolution' came when I had the user create a new local profile on their Mac - THAT fixed the problem, in that they could log onto the server with their correct password on the new profile.

Now I have a fourth user, I am just beginning to work on this issue with them as well.

It seems to me like either Sonoma is caching the old password and using that, rather than using what they're actually typing in at the credentials screen - or it's not communicating with the server to authenticate, but rather using its own cached password to authenticate (and thus failing). I will obtain whatever details I can but I would like to find out why this is happening with Sonoma users (and I fear it will happen more and more as more users upgrade/purchase new machines.)

The machines vary, one was an iMac, two were Macbook Pros and this current one is a Macbook Air M2, 2023 model.

Brian

MacBook Air (M2, 2023)

Posted on Feb 13, 2024 10:54 AM

Top-ranking reply

LRDC-Brian Author

Level 1

47 points

Posted on Sep 27, 2024 5:16 AM

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.

View in context

16 replies