System.DirectoryServices.AccountManagement 9.0.1 PrincipalContext.ValidateCredentials fails with a COM exception

[tlencse]

Description

With System.DirectoryServices.AccountManagement 9.0.1, PrincipalContext.ValidateCredentials with ContextType.Machine works only once for a user. Every subsequent call (even after restarting the application) fails with the following 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. (Exception from HRESULT: 0x800704C3)
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)

It does not happen in version 9.0.0

Reproduction Steps

Write a console app with the code below, using package references

<PackageReference Include="System.DirectoryServices" Version="9.0.1" />
<PackageReference Include="System.DirectoryServices.AccountManagement" Version="9.0.1" />

using PrincipalContext pc = new PrincipalContext(ContextType.Machine, null);
pc.ValidateCredentials(someUserName, somePassword);

The app will run only once, all subsequent runs will give the above error

Expected behavior

The call should not fail on subsequent runs of the application

Actual behavior

It runs correctly once, and then never again until restarting the Workstation service.

Regression?

Yes, it works correctly with

    <PackageReference Include="System.DirectoryServices" Version="9.0.0" />
    <PackageReference Include="System.DirectoryServices.AccountManagement" Version="9.0.0" />

Known Workarounds

restarting the Workstation service, or using COM interop directly (haven't tried)

Configuration

.net 8
Windows 11 Pro, build 26100.2894 x64
I guess it is not specific to this config

Other information

I think it is exactly the same issue as #83269 but that one is already closed.

[dotnet-policy-service]

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

[ericstj]

@jkoritzinsky it seems similar to #83269 which was regressed by introduction of the interop source generators. We tried to fix it, but there still seem to be problems. Could also be the same root case as #106905. Could you have a look at the repro?

[ericstj]

@tlencse -- are you sure you notice this regression between 9.0.0 and 9.0.1? The only change to these packages in that release was 43515e5 which doesn't appear to be hit in this codepath. cc @steveharter

I tried your repro and it works fine for me with both 9.0.0 and 9.0.1 - but there could be something environmental here - as we could not reproduce #106905 either.

[tlencse]

@ericstj Yes, it was those two versions. It started working when I downgraded to 9.0.0. However I cannot reproduce it today with the same test app, either. It works with both versions, so maybe it was independent of the version. I must have been tricked by finding #83269, and the solution worked for me. (I had a service using 9.0.0 working for a long time and I created a test program using 9.0.1 and the copy-pasted code of the service, and that test produced the com error. I downgraded it to 9.0.0 and it started working. I was near deadline and did not have too much time for testing.) Sorry about the fuss, next time I encounter this, I will do a thorough testing.

[ericstj]

Sounds good, I'm going to go ahead and close this since we don't have a repro. Given the error code also hinted at a sharing violation - I also tried testing calling this API concurrently from multiple threads to see if that would reproduce. I did not have luck with that either.

If you are able to reproduce in the future - please reopen and share more detail about how to reproduce.