PrincipalContext.ValidateCredentials against the local SAM store fails with a PrincipalOperationException after any successful call to ValidateCredentials against the local SAM store

[bagrm]

Description

Only a single successful call to PrincipalContext.ValidateCredentials against the local SAM store will succeed even when the PrincipalContext is disposed correctly starting with System.DirectoryServices.AccountManagement version 7.0.0. The subsequent calls will all fail with a PrinciaplOperationException. This issue will persist through application restarts and will only cease when the Workstation service is restarted. The issue is not present in System.DirectoryServices.AccountManagement version 6.0.0.

Reproduction Steps

Please see the attached project to reproduce the issue. The project is a simple console application which simply takes 4 arguments: the username and password of a local user followed by the username and password of a second local user. The application simply calls ValidateCredentails on the first user and then on the second user using two PrincipalContext objects with ContextType.Machine that are properly disposed through using statements. The second call to PrincipalContext.ValidateCredentials will fail with the exception mentioned in the description when correct user credentials are passed to the application.

PrincipalContextTestApp.zip

Expected behavior

Both calls to PrincipalManager.ValidateCredentials should succeed without an exception when correct credentials are supplied to the ValidateCredentials calls.

Actual behavior

The second call to PrincipalManager.ValidateCredentials fails with the following exception:

System.DirectoryServices.AccountManagement.PrincipalOperationException
HResult=0x80131501
Message=Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Source=System.DirectoryServices.AccountManagement
StackTrace:
at System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(String target, String userName, String password)
at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)
at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)
at Program.

$(String[] args) in C:\Users\bgarfinkel\Desktop\PrincipalContextTestApp\PrincipalContextTestApp\Program.cs:line 12

This exception was originally thrown at this call stack:
System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(string, string, string)

Inner Exception 1:
COMException: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Regression?

Yes, this is a regression. This issue does not occur in System.DirectoryServices.AccountManagement 6.0.0. This can be verified by downgrading the System.DirectoryServices.AccountManagement nuget package to version 6.0.0. in the attached sample application.

Known Workarounds

Restarting the Windows workstation service fixes the issue until another successful call to PrincipalContext.ValidateCredentials occurs against the local SAM store.

Configuration

The code is running on .NET 7.0 and Windows version 10.0.19044 Build 19044 x64. I am not sure if the issue is specific to this configuration.

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Only a single successful call to PrincipalContext.ValidateCredentials against the local SAM store will succeed even when the PrincipalContext is disposed correctly starting with System.DirectoryServices.AccountManagement version 7.0.0. The subsequent calls will all fail with a PrinciaplOperationException. This issue will persist through application restarts and will only cease when the Workstation service is restarted. The issue is not present in System.DirectoryServices.AccountManagement version 6.0.0.

Reproduction Steps

Please see the attached project to reproduce the issue. The project is a simple console application which simply takes 4 arguments: the username and password of a local user followed by the username and password of a second local user. The application simply calls ValidateCredentails on the first user and then on the second user using two PrincipalContext objects with ContextType.Machine that are properly disposed through using statements. The second call to PrincipalContext.ValidateCredentials will fail with the exception mentioned in the description when correct user credentials are passed to the application.

PrincipalContextTestApp.zip

Expected behavior

Both calls to PrincipalManager.ValidateCredentials should succeed without an exception when correct credentials are supplied to the ValidateCredentials calls.

Actual behavior

The second call to PrincipalManager.ValidateCredentials fails with the following exception:

System.DirectoryServices.AccountManagement.PrincipalOperationException
HResult=0x80131501
Message=Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Source=System.DirectoryServices.AccountManagement
StackTrace:
at System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(String target, String userName, String password)
at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)
at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)
at Program.

$(String[] args) in C:\Users\bgarfinkel\Desktop\PrincipalContextTestApp\PrincipalContextTestApp\Program.cs:line 12

This exception was originally thrown at this call stack:
System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(string, string, string)

Inner Exception 1:
COMException: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Regression?

Yes, this is a regression. This issue does not occur in System.DirectoryServices.AccountManagement 6.0.0. This can be verified by downgrading the System.DirectoryServices.AccountManagement nuget package to version 6.0.0. in the attached sample application.

Known Workarounds

Restarting the Windows workstation service fixes the issue until another successful call to PrincipalContext.ValidateCredentials occurs against the local SAM store.

Configuration

The code is running on .NET 7.0 and Windows version 10.0.19044 Build 19044 x64. I am not sure if the issue is specific to this configuration.

Other information

No response

Author:	bagrm
Assignees:	-
Labels:	area-System.DirectoryServices
Milestone:	-

[buyaa-n]

Tagging the owners of System.DirectoryServices.AccountManagement for further triage: @BRDPM @grubioe @jay98014

[bspautz1969]

Description

Only a single successful call to PrincipalContext.ValidateCredentials against the local SAM store will succeed even when the PrincipalContext is disposed correctly starting with System.DirectoryServices.AccountManagement version 7.0.0. The subsequent calls will all fail with a PrinciaplOperationException. This issue will persist through application restarts and will only cease when the Workstation service is restarted. The issue is not present in System.DirectoryServices.AccountManagement version 6.0.0.

Reproduction Steps

Please see the attached project to reproduce the issue. The project is a simple console application which simply takes 4 arguments: the username and password of a local user followed by the username and password of a second local user. The application simply calls ValidateCredentails on the first user and then on the second user using two PrincipalContext objects with ContextType.Machine that are properly disposed through using statements. The second call to PrincipalContext.ValidateCredentials will fail with the exception mentioned in the description when correct user credentials are passed to the application.

PrincipalContextTestApp.zip

Expected behavior

Both calls to PrincipalManager.ValidateCredentials should succeed without an exception when correct credentials are supplied to the ValidateCredentials calls.

Actual behavior

The second call to PrincipalManager.ValidateCredentials fails with the following exception:

System.DirectoryServices.AccountManagement.PrincipalOperationException

HResult=0x80131501

Message=Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Source=System.DirectoryServices.AccountManagement

StackTrace:

at System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(String target, String userName, String password)

at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)

at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)

at Program.

$(String[] args) in C:\Users\bgarfinkel\Desktop\PrincipalContextTestApp\PrincipalContextTestApp\Program.cs:line 12

This exception was originally thrown at this call stack:

System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(string, string, string)

Inner Exception 1:

COMException: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Regression?

Yes, this is a regression. This issue does not occur in System.DirectoryServices.AccountManagement 6.0.0. This can be verified by downgrading the System.DirectoryServices.AccountManagement nuget package to version 6.0.0. in the attached sample application.

Known Workarounds

Restarting the Windows workstation service fixes the issue until another successful call to PrincipalContext.ValidateCredentials occurs against the local SAM store.

Configuration

The code is running on .NET 7.0 and Windows version 10.0.19044 Build 19044 x64. I am not sure if the issue is specific to this configuration.

Other information

No response

I can confirm this behavior. It can be reproducibly limited to version 7. Version 6 behaves as desired. It would be nice if this bug was fixed. We are using local SAM.

[ericstj]

I can reproduce this. I pulled out the directory services code into a standalone repro and can confirm that 6.0 works consistently, but 7.0 does not. It's also broken in 8.0.

I can reduce the repro down this the difference in using the interop source generator vs not.

If I keep a normal DLLImport for ADsOpenObject it works:

runtime/src/libraries/System.DirectoryServices.AccountManagement/src/System/DirectoryServices/AccountManagement/interopt.cs

Lines 35 to 47 in 3b204ac

	[DllImport(Interop.Libraries.Activeds, ExactSpelling = true, EntryPoint = "ADsOpenObject", CharSet = System.Runtime.InteropServices.CharSet.Unicode)]
	private static extern int IntADsOpenObject(string path, string userName, string password, int flags, [In, Out] ref Guid iid, [Out, MarshalAs(UnmanagedType.Interface)] out object ppObject);
	public static int ADsOpenObject(string path, string userName, string password, int flags, [In, Out] ref Guid iid, [Out, MarshalAs(UnmanagedType.Interface)] out object ppObject)
	{
	try
	{
	return IntADsOpenObject(path, userName, password, flags, ref iid, out ppObject);
	}
	catch (EntryPointNotFoundException)
	{
	throw new InvalidOperationException(SR.AdsiNotInstalled);
	}
	}

If that's changed to use the interop source gen, by applying

[assembly:DisableRuntimeMarshalling]

runtime/src/libraries/System.DirectoryServices.AccountManagement/src/System/DirectoryServices/AccountManagement/interopt.cs

Lines 20 to 32 in 4bc0fe9

	public static int ADsOpenObject(string path, string userName, string password, int flags, [In, Out] ref Guid iid, [Out, MarshalAs(UnmanagedType.Interface)] out object ppObject)
	{
	try
	{
	int hr = Interop.Activeds.ADsOpenObject(path, userName, password, flags, ref iid, out IntPtr ppObjPtr);
	ppObject = Marshal.GetObjectForIUnknown(ppObjPtr);
	return hr;
	}
	catch (EntryPointNotFoundException)
	{
	throw new InvalidOperationException(SR.AdsiNotInstalled);
	}
	}

runtime/src/libraries/Common/src/Interop/Windows/Activeds/Interop.ADsOpenObject.cs

Lines 11 to 12 in 4bc0fe9

	[LibraryImport(Interop.Libraries.Activeds, StringMarshalling = StringMarshalling.Utf16)]
	internal static partial int ADsOpenObject(string path, string? userName, string? password, int flags, ref Guid iid, out IntPtr ppObject);

@jkoritzinsky @elinor-fung can you help us understand what might have gone wrong here?

Not sure if it's related, but I noticed one other place where Marshal.Release is called after calling this API. ccd67b0#diff-da1c2467301bcee94db7a0e65d5b653fa3d210ea29c82647ed88a798a09a69c3R45-R48

Was that missed here?

PS: This repro is tricky, because as @bspautz1969 mentioned - once a system is reproducing it you need to reboot to get back to clean state.

[ericstj]

Not sure if it's related, but I noticed one other place where Marshal.Release is called after calling this API

That does seem to fix it! I think we just need to make

runtime/src/libraries/System.DirectoryServices.AccountManagement/src/System/DirectoryServices/AccountManagement/interopt.cs

Line 20 in e42429e

public static int ADsOpenObject(string path, string userName, string password, int flags, [In, Out] ref Guid iid, [Out, MarshalAs(UnmanagedType.Interface)] out object ppObject)

Call Release, similar to
https://github.com/dotnet/runtime/blob/e42429ef1d08b21878b9127e60bb6cfe89089845/src/libraries/System.DirectoryServices/src/Interop/UnsafeNativeMethods.cs#L32-L55C4

@jkoritzinsky - do you think you can help with this? Are there any other places that might have regressed in the same way when moving to the source generator?

[jkoritzinsky]

It sounds like this is one place where we leaked a reference to a COM object. There's only a few libraries that use built-in COM in the repo, so I'll do a quick check over the rest of them and see where we might have an issue. We only added DisableRuntimeMarshalling to a few of them, so that narrows down the possible surface area. I'll do a pass through and fix this and any other cases I find.