views:

868

answers:

4

Having an issue with random individuals trying to access an intranet site with a security certificate. Most users are able to simply select their Smartcard/CAC certificate, enter the pin number and then are granted access to the site's pages.

However, random individuals enter their pin and then are immediately re-prompted by the IE alert dialogue to enter their domain username and password. If they don't enter their network domain username and MS password, then they receive a 401.1 Unauthorized.

I am confused as to why these certain users (who are selecting the same certificates as the successful ones) are being prompted for their domain name/pwd. Furthermore, they're able to access other sites which require a CAC to get past the security certificate.

Possible that a user token is unable to be established via a CAC card for the particular site, but not sure why. Since these users are getting a 401.1, then somehow their identity associated with their CAC credentials is not validating.

In IIS: Anonymous users are not allowed (unchecked). 128-bit encryption is required with SSL. Integrated Windows Authentication is checked. Accepting client certificates In the site's web.config file all users are allowed and only anonymous are denied.

The exact same setup is present on the development box without any issues at all, indicating to me that the problem resides on the production server's ability to properly receive/handle CAC information from those individuals or that something funky is going on with the way the security certificate is relating to the client's CAC x.509 certificate.

A little more information that may be of use: the browser prompt that initially asks for the CAC has nothing to do with the code of the site, but rather is enabled by applying the security certificate to a site in IIS; thus indicating to me that there is something written into the certificate that looks for client certificates tied to the ActivClient agent via the browser???

Then again, I probably have no idea what i'm talking about, just throwing a bone here to see if anyone has had the same issue or has any ideas.

Thanks in advance for any input, questions, or ideas.

A: 

Check the functioning of the card with other applications.

Also check that the certificates are valid (not expired) and otherwise similar - same issuer, PIN not locked etc.

martin
That's the frustrating part, the card works on all other applications and even on SSL sites on other servers that bring up a CAC prompt. I believe we have confirmed that the certificates associated with the card and the browser are valid through 2015 (or longer in some cases), and are the same, given it's the same x509 certificate from the card... and issuer is being consistently selected as DOD Email CA-15 (though the regular DOD CA-15 works as well).Again, maybe something with the fact that it's isolated to one production server, something with the SSL cert. on that url or user access??
aimlessWonderer
A: 

I understand your development environment works as you want and that your production environment is not.

Have you tried to reproduce the error in another environment to confirm which behavior is consistent?

Chad
We have tried to reproduce the problem in testing and development environments, but have fortunately/unfortunately been unable to duplicate this issue. This furthermore eludes to an issue that might be isolated to the production server, users access to it, and/or the certificate that is applied to that SSL website on that server.
aimlessWonderer
A: 

Had a very similar problem that was solved by bypassing the proxy server. Try adding it to the exemption list.

In IE, go to:

Tools | Internet Options | Connections | Lan Settings | Advanced

Add site to exemptions list.

May not work for you, but could be worth a try. Like I said, it worked for me with a very similar issue.

A: 

The problem was a stinking DLL that serves to help parse long URL's with many aliases (dots). The faulty DLL had been written into many people's re-image of their computers. The violating computer re-freshes contained an old version of a DLL used by Internet Explorer called URLMON.dll. The version of the DLL you need should end in '21073', but the one included on the faulty images listed above ends in '19.....'.

You can confirm this by going into IE7 and clicking on Help > About Internet Explorer > System Information (btn on bottom) > Internet Settings > Internet Explorer > File Versions > urlmon.dll

Updating this DLL has shown to fix the issue with secure SSL sites having problems validating CAC/pin entry that have long DNS entries (such as https://something.something.something.something.something.something).

There is an IE7 hotfix for this, but it will only install if you don't have ServicePack 3. If you do have SP3, , you cannot run the needed Hotfix, b/c it assumes that SP3 has already put into place the correct DLL. 1. Uninstall SP3 2. Reboot 3. Install the IE7 Hotfix 4. Reboot 5. Run Microsoft Updates via the Window MS updates website

Sucks, but that's what you get with crappy software like IE run on a deficient operating system, then coupled with software that's limited in it's abilities to truly talk to the operating system.

aimlessWonderer