Bruno's questions

EDIT: Turns out I was probably overthinking this. See answer below.

This may or may not be better on SuperUser, it's regarding issues with a few workstations failing to cleave to the Enterprise standard. All references here are to Win7 Professional installations.

Essentially, a certain machine is now showing this when the computer is locked:

(Image 1)

Rather than this:

(Image 2)

It's a big change. A different credential provider tile is being displayed, all our branding is ripped out. The normal behaviour is to go straight to the prompt to unlock the PC, but this machine requires you to actually click on the 'User Unlock' tile instead.

When you do, a rather generic prompt, again without branding and without the username pre-populated, is presented. I suspect it may be one of the default providers on a default configuration that comes with the OS.

Unfortunately I no longer have access to the broken system (I suggested the local tech just do a re-image as that is an option in our case, and faster for a rare issue).

Does anyone know good ways to troubleshoot these sorts of problems? Since giving the re-image advice, I've compared the credential provider registry on both systems, and the main difference seems to be the absence of the Novell Credential Provider on the borked system. Apparently when this credential provider is installed, it defines its own filter list. Without the filter in the main credential providers list at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters\,

the filter list contains only a generic entry (I think it is {DDC0EED2-ADBE-40b6-A217-EDE16A79A0DE}), so it isn't redirected to the novell list at:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Authentication\NCCredProvider\FilterList

This filter list contains some of the more familiar providers like {6f45dc1e-5384-457a-bc13-2cd81b0d28ed}.

My current suspicion for root cause is either something borked in group policy (likely local to the machine as otherwise the entire site should have problems), or a misconfiguration or attempted uninstallation of the novell client interacting negatively with our Enterprise MOE that assumes the novell authentication provider will be present.

UPDATE

Having checked my home system, I haven't found any glaring differences in the registry with the borked system. The filter GUID DDC0EED2-ADBE-40b6-A217-EDE16A79A0DE is linked to authui.dll in both cases And the Cred Provider list seems to be mostly the same.

However, my home system goes straight into the default unlock prompt (with my username pre-populated) when the workstation is locked, similar to Image 2 above without the branding, which is unusual because this 'User Unlock' provider appears to be a default fallback, yet it isn't showing up on the home system & I haven't mucked around with the credential provider behaviour on my home system at all. They appear to be presenting different behaviour despite both using the generic filter.

However, the difficulty to find any information regarding the administration of credential providers (as opposed to coding them) online makes me wonder if anyone used to dealing with these sorts of issues has a good check-list to go through to track down these sorts of problems quicker.

Things like:

• Does the credential provider service look anywhere other than HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication to get its providers (not counting using the GUID's from here to lookup classes_root)? For instance, does it check the Wow6432node version at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Authentication?
• Is there any form of logging that can be turned on (or turned up, if it logs to the event viewer)? If it shows up in the event viewer either by default or after tweaking a setting, what event ID's should I be looking for in which logs?
• Combining and extending on the above, does anyone have a link to either good existing troubleshooting documents, or even better a full description of how the credential providers are turned from registry entries and CLSID DLL references into the specific tiles the user ends up seeing? (Not the specification or how to roll your own, but the end-to-end process of constructing the various credential provider screens that are shown to the user in various circumstances.)

I've received a CSR from a client with a CN, but not with all the subject fields we require.

According to this answer from Scott*, it should be possible to specify the final subject values when the CA issues the certificate, taking or leaving CSR values at will.

I could just generate their cert from scratch, but then I need to start exporting and mailing around private keys. I'd prefer to use the public key they've submitted with the CSR.

Is anyone aware of a method using the certificate services web interface, the CA MMC snap-in, or the MS command-line tools (certreq, certutil, certmgr etc.) to accomplish this?

It seems installing openssl would be my best bet, but I'd prefer to not modify the environment on the CA servers unless absolutely necessary. Another possibility would be a powershell module, if there is one that operates from the perspective of an issuer rather than a requester (we don't enable remote requests of server auth certs, rather we ask for a CSR and use the web interface to generate it by pasting the base64 data into the form.)

I haven't found any workable powershell modules so far, however - they are either client-side or don't allow modifying properties as part of the issuance.

I'd appreciate any insight. If for some reason openSSL won't work even if I try (eg. perhaps it can't interface with a windows CA to issue certificates), that would be good to know too.

*"A CA creates your cert and uses whatever parts of the CSR subject it sees fit"