Authentication problem connecting to shared folder on Azure AD-joined computer

Question

Hi, I have several Windows 11 22H2 computers that are joined to an Azure AD domain (cloud-only, not hybrid). One of the computers, which I'll call Server, has a shared folder. Another computer, Client1, can access that shared folder (\\Server\Shared) with no problems. But a third computer, Client2, can't. It prompts "Enter your credentials to connect to: Server". I enter Email address user@mydomain.com and my password, and it comes back with "The username or password is incorrect".

I noticed in Server's Security event log:

An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0
Logon Type:			3
Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		user@mydomain.com
	Account Domain:		
Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC0000064
Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-
Network Information:
	Workstation Name:	CLIENT2
	Source Network Address:	10.1.1.180
	Source Port:		52416
Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

But if I access the share from Client1, where I can get to the shared folder, I see this in Server's Security log:

An account was successfully logged on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0
Logon Information:
	Logon Type:		3
	Restricted Admin Mode:	-
	Remote Credential Guard:	-
	Virtual Account:		No
	Elevated Token:		No
Impersonation Level:		Impersonation
New Logon:
	Security ID:		AzureAD\user
	Account Name:		AzureAD\user@mydomain.com
	Account Domain:		-
	Logon ID:		0xB45252D
	Linked Logon ID:		0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{00000000-0000-0000-0000-000000000000}
Process Information:
	Process ID:		0x0
	Process Name:		-
Network Information:
	Workstation Name:	CLIENT1
	Source Network Address:	10.2.1.182
	Source Port:		59187
Detailed Authentication Information:
	Logon Process:		Pku2uSsp
	Authentication Package:	NegoExtender
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The impersonation level field indicates the extent to which a process in the logon session can impersonate.
The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Looks like Client2 attempts to connect using NTLM authentication, which doesn't work, while Client1 connects with PKU2U, which does work. Why isn't Client2 using PKU2U?

Answer 1

Your post helped me resolve this issue.

Looking at Event Log ID 5379 I realized the computer that can access the server using AzureAD says Read Credentials:

Whereas the computer that was not able to access the computer said Read Domain Credentials:

I looked into credentials manager the the computer that was not able to access the server had credentials saved. I deleted those and it started working.

For PKU2U, look at this article from Microsoft to adjust Group Policy settings to allow Online Identities. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj852232(v=ws.11)

Thank you,

Farooq