6

I have a credential provider that does not act the way I want it to. It provides secondary authentication, but it's scope is for all interactive Windows logins host-wide, not for a specific user.

In addition to the credential provider, a credential provider filter is installed. The credential provider filter restricts the use of credential providers on the login screen to just this credential provider. However, if the credential provider filter is removed (via deletion of the key below HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters), then a user can change the credential provider to any other available credential provider (including our good old friend PasswordProvider).

My intention is to enforce the use of credential provider for certain users. For instance, it's fine if this user attempts to login with another credential provider, but I'd like AD to reject this request... only allowing requests if they are called from the correct credential provider.

Is this possible? I'm hoping there is a way to configure a user object in AD to restrict the acceptable credential providers.

Thanks

mbrownnyc
  • 1,825
  • 8
  • 30
  • 50

1 Answers1

2

Good question. As noted here and without better sources the answer appears to be no.

Quote:

It is important to note that credential providers are not enforcement mechanisms.

Because:

Credential providers are registered on a Windows machine and are responsible for the following.

  • Describing the credential information required for authentication.
  • Handling the communication and logic with any external authentication authorities.
  • Packaging the credentials for interactive and network logon.

That is, they are client side mechanisms.

Also a best practice is described not to completely disallow access to at least one host wide provider, so as not to cause complete lockout:

While third-party credential providers may fulfill additional authentication requirements for particular groups of users, it is very important to ensure that the user can always regain access to their machine when a breaking change occurs. System credential providers provide this guarantee.

So... the recommendation appears to be not to exclude access to host wide providers. Simple solution if you want to restrict anyway: do not grant the users permission to delete the registry key.

The Protected Users Security Group does not do what you ask, but is one way of hardening the authentication process server side.

ErikE
  • 4,676
  • 1
  • 19
  • 25
  • This is a similar answer that I received on the MSFT's technet forum. The confusing point I have is that this credential provider "skims" the username, creates a web request and performs an HTTP POST. This slew of actions can be described as `Handling the communication and logic with any external authentication authorities`. I assume with a credential provider able to act so dynamically, that it would be possible for the credential provider to submit it's GUID within the authentication request to a DC, and the DC would "enforce"... (1/2) – mbrownnyc Feb 21 '17 at 12:53
  • ...the "a-okay credential providers for this user" possibly by way of an LDAP attribute for the user object. I guess this is wishful thinking and is more of a feature request, although it really seems like something someone would have thought of a long time ago. This feature is not enforcement or authorization in itself, but much like this "serialization of credentials" I keep hearing about, it would simply be like "yo, here's the GUID sucka," to the DC and the DC would be all like "yo, you're all authorized to get up in this." – mbrownnyc Feb 21 '17 at 12:56
  • I understand what you are looking for, and agree that it is a little surprising the feature isn't available out of the box. It does not sound complicated to implement as long as one can intercept the calls through client- and serverside APIs. Without having dived into the relevant API's, would hope that it could be possible to write something up oneself to that effect. – ErikE Feb 21 '17 at 13:42
  • Well... we will see. Thanks for the doomy confirmation! – mbrownnyc Feb 21 '17 at 13:44
  • 1
    Perhaps someone at StackOverflow has been down this path and can give a pointer or two? – ErikE Feb 21 '17 at 13:52
  • 1
    It's sort of backwards. The credential provider is the "client" for a cloud based two-factor authentication system. This system can sync with on-prem AD, then enforce access by group member, essentially filling part of the gap from a functionality perspective, and what we're doing now. However, this has nothing to do with the Windows authentication client structure and integration into AD authorization mechs. So, I'll just kill a lamb at the temple mount and hope @nedpyle hears my chants. – mbrownnyc Feb 21 '17 at 15:55