I've recently been working on some old code and, when testing, I've started seeing the "Credential Required" window: "Do you want to allow the app to access your private key? Key description: CryptoAPI Private Key."
It happens at this line of code:
object result = this.m_DirectoryEntry.Invoke(MethodName, Argument);
where MethodName
is SetPassword
.
Clicking 'Don't Allow' still allows the method to proceed.
It also happens when I run the application outside of Visual Studio. This will not be an acceptable user experience.
Why is it happening? How can I stop it?
I'm using Visual Studio Community 2015 Update 3 on a Server 2016 machine. The project uses .NET 4.5.2.
New solution. In the project Properties, set Target framework to .NET Framework 4.5.2. Add a reference to System.DirectoryServices.
namespace SetPasswordCryptoApiTester1
{
using System;
using System.DirectoryServices;
class Program
{
static void Main(string[] args)
{
var adsPath = "LDAP://CN=path_to_user";
using (var de = new DirectoryEntry(adsPath))
{
Console.WriteLine("Press a key to set the password...");
Console.ReadKey(true);
object result = de.Invoke("SetPassword", "Sausag32");
Console.WriteLine("Press a key to continue...");
Console.ReadKey(true);
}
}
}
}
Maybe you've already worked around this, but I thought I'd answer anyway. Although I can't say for certainty what's happening.
That calls the SetPassword
method on the native Windows IADsUser
object. In the Remarks section of the documenation it describes 3 methods it tries to reset the password. It's possible that one of those methods is causing the pop-up, and when you click "Don't allow", it just moves on to the next.
The first one it uses is LDAP over SSL (LDAPS). I've never seen this, but there might be something weird with the way LDAPS is setup on your domain where it's asking for a client certificate maybe?
You can test this theory... In PowerShell, try this:
Invoke-WebRequest https://example.com:636
(Replace "example.com" with your domain name) You will either get a certificate error (maybe that same pop up?), but if the SSL handshake works then you should get a "The underlying connection was closed".
If you do get that pop up when trying through PowerShell, then I don't think there's anything you can do unless you're a domain admin. Something would have to change on the Domain Controller.