claims/default zone issue

Question

We have a 2010 environment with a Dev, stage, and production environment. We try to keep them identical (at least on stage and prod) the best we can. We are having a strange issue with getting our tester accounts to be able to hit the stage environment root site, or any site for that matter.

We use claims based authentication, CAC cards, and our trusted identity provider is Vordel. The tester user accounts do not have a CAC card associated with them, and we just log on to the workstations using a user name and password.

When you go to the check permissions option on the site permissions menu there is some differences between the two environments. On production it shows that the account shows up with having permissions given through "All authenticated users" and "All users". When you look at the account on Stage, it shows as it has no permissions for some reason. Not sure why it is not getting the "all authenticated users" permissions, but I would imagine this is a problem.

When looking at the web applications in central admin, the Stage environment has 3 authentication providers; Default, Internet, and Custom. Production has 4 membership providers. The one that stage does not have has the following settings:

Zone: Intranet Claims type auth: Enable windows authentication, Basic Authentication Default sign in page Enabled client integration

I have given the user account specific rights at the root site level, but still could not get to the site.

New info: When viewing the site with a regular user account, down at the bottom it says that the stage site is in "local intranet | Protected mode: off", but when viewing the site from the Spuser account, it is showing as the site is in the Internet zone

At first glance, i thought this was simply a user account problem. Then I thought maybe it might have been a authentication provider problem, and then maybe even something with IIS.

We never had a problem with this up until sometime within the last month (we do not use our test accounts very often and this issue came to light within the last day or so).

Answer 1

It turns out that someone had changed a setting on our authentication provider. The SSL parameter for the Stage endpoint was set to only accept certificates. The accounts that were unable to reach the Stage environment were all non CAC accounts, so the setting to also allow Kerberos was changed, and we were back in business!

Hope this helps if anybody runs across an issue such as this, but I do understand this is probably going to apply only to our setup.