We use the term single sign on (SSO) to describe a variety of behaviors in Windows and other applications where the result is simply to prevent the user from being prompted to provide their credentials again and again; to ideally enter their credentials only once at initial logon. Active Directory and the integrated authentication which it provides does this very well, and can be extended to other Microsoft applications like SQL, SharePoint, Exchange and others from other companies as well.
There are times, though, when someone needs to create a specific single sign on behavior. This can derive from the need to use a different credential type-smartcards for example, a need to interact with another directory service or application, a need to use one time passwords, or any of a wide variety of things. In those cases you have the option to create and install a credential provider for your client computers and servers for Windows Vista, Server 2008 and later versions. This option is a great thing for developers since programming customized experiences for prior versions of Windows could be more challenging.
We have detailed information on how to develop credential providers available starting with a great MSDN entry . Another great article on that is “Create Custom Login Experiences With Credential Providers For Windows Vista” .
Let’s go over a support scenario which underscores that credential providers alter the default behavior and also gives a technique on how to identify whether an additional credential provider may be involved or not.
In the scenario there was an administrator seeing users unexpectedly receiving the credential prompt when opening a terminal services session to a remote 2008 server from Windows clients. There are multiple reasons this prompt can appear, including broken secure channel on client or server, network problems between client and server, or even problems at the domain controller which is being used to provide the authentication.
So what do you do when you are seeing credential prompts appear unexpectedly and the more common reasons for that are not there?
- See if the issue is consistent. If it is intermittent it is less likely to be solely caused by a credential provider.
- Try removing any added credential providers to see if that makes a difference.
- Remember that in a client-server relationship the server side may be the culprit as well so check whether a credential provider is installed there.
How can you tell what credential providers are present? There are a couple of things you can easily do. First, you can look in the registry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAuthenticationCredential Providers and see what entries are present.
This alone may not tell the entire story though since what really matters is whether the credential provider is loaded or not.
Here’s another way to determine what DLLs are loaded and running code in the LogonUI.exe process. My steps were done on a Windows 7 laptop but would remain the same for Windows Vista or Server 2008.
- First, disable UAC temporarily from the Control Panel User Accounts applet.
- Create a folder named SC (for example).
- Create a text file and put the following text into it: tasklist /m /fi "imagename eq logonui.exe" >c:scresult.txt
- Rename the file extension of your text file to .CMD
- Next, go to Start-->Run and type “gpedit.msc” (without the quotes) and press enter.
- Go to User Configuration-->Windows Settings-->Scripts and add your CMD script as a Logon script.
- Log off and then log back on.
- Open your result.txt. Keep in mind that the results will find all instances of LogonUI.exe-not only one instance but all instances of it if more than one is present. Below are the results from my test, so these results show default DLLs and no additional credential providers.
Image Name PID Modules
========================= ======== ============================================
LogonUI.exe 5528 ntdll.dll, kernel32.dll, KERNELBASE.dll,
msvcrt.dll, ole32.dll, GDI32.dll,
USER32.dll, LPK.dll, USP10.dll, RPCRT4.dll,
IMM32.DLL, MSCTF.dll, CRYPTBASE.dll,
CLBCatQ.DLL, ADVAPI32.dll, OLEAUT32.dll,
authui.dll, COMCTL32.dll, SHLWAPI.dll,
DUI70.dll, sechost.dll, UxTheme.dll,
gdiplus.dll, DUser.dll, SndVolSSO.DLL,
HID.DLL, MMDevApi.dll, SETUPAPI.dll,
CFGMGR32.dll, DEVOBJ.dll, dwmapi.dll,
xmllite.dll, WindowsCodecs.dll,
WINBRAND.dll, VaultCredProvider.dll,
RpcRtRemote.dll,
SmartcardCredentialProvider.dll,
OLEACC.dll, UIAutomationCore.dll,
PSAPI.DLL, BioCredProv.dll, Secur32.dll,
SSPICLI.DLL, winbio.dll, CRYPT32.dll,
MSASN1.dll, credui.dll, VAULTCLI.dll,
NETAPI32.dll, netutils.dll, srvcli.dll,
wkscli.dll, SAMCLI.DLL,
certCredProvider.dll, CRYPTSP.dll,
rasplap.dll, RASAPI32.dll, rasman.dll,
WS2_32.dll, NSI.dll, rtutils.dll,
rsaenh.dll, SXS.DLL, WTSAPI32.dll,
WINSTA.dll, WinSCard.dll
Where do you go from here if you have noticed that an additional provider is present in the Tasklist.exe result? Try preventing it from being loaded in order to see if that alters the behavior in any positive way. You can prevent the provider from loading typically by backing up (saving) the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAuthenticationCredential Providers key and then removing the entries related to that provider from it. Alternatively the provider may have a registered installation and removal in the Programs Control Panel applet.
If the provider removal makes a difference where the problem no longer occurs then contacting the manufacturer of that provider is the next logical step since they may already be aware of the behavior that is being seen.
If removing the provider does not help then you can resume troubleshooting this using other methods like network captures, debug logging or other applicable actions.
Additional credential providers add great capabilities to your environment, and along with these may come a bit more needed info for your troubleshooting arsenal. Hopefully this post has added some for you so that you have it when you need it.