SSO stopped working all of a sudden

Using Eric Means document titled "Technical Description Use of WebMemberServices To Provide Unified Login for Third Party Sites" (attached), we successfully implemented SSO and it was working great for three months. Today it stopped working all of a sudden.

This morning we started receving the  Error Message The value '08/28/2007' is not valid for the system setting System_Control.DateInstalled. ASI told us that this is a known issue regarding the install date and public view. Could this have affected the SSO in any way?

Login is at the CMS end, web service is used to authenticate the user and a wild card cookie is created for the domain. The <machinekey> tag is matching for both the iMIS web and app server. Nothing changed since yesterday. Any help would be most appreciated.

AttachmentSize
TechnicalDoc.doc121.5 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Did you manage to resolve

Did you manage to resolve this? Did the SSO stop working after you applied any patches to iMIS15?

Machine key issue

Did you see my posting to NiUG last week? I have posted the message here and hope it helps.

Hello everyone,
 
We just solved a very tough problem that some of you may run into right now. ASI just submitted a note about this just today. The issue is that there is a patch that Microsoft suggest you apply to your web servers to address a vulnerability in ASP.NET.
 
 
As you apply the patch you might get caught in the following situation.
 
For single sign on between servers, each webserver has a machinekey that needs to be the same in the web.config files of each server. When the patch gets applied to one server and not the other, the single sign on will not work even though the machine keys are the same. That is because the Microsoft Patch changes the way that the encryption/decryption is handled.
 
In some cases you could just upgrade all servers with the patch so that they encrypt/decrypt the same. However, that isn’t always feasible or possible in hosted situations. In some cases your hosting company might upgrade before you are ready or vice versa.
 
So in the interim, a solution is to force the servers to revert to the old process of encryption/decryption. In order to do that add this key to the web.config in the appsettting section.
 
<configuration>
...
<appSettings>
...
<add key="aspnet:UseLegacyEncryption" value="true" />
</appSettings>
</configuration>
 
That will force the webservers to use the old encryption. You should then take this out when all servers are back in synch with the patch.
 
Hopefully this will save some of you a lot of headaches and save the associations a lot of consulting dollars. If it does, buy me a beer at the next NiUG!
 
Thanks,
Randy
-----------------------------------------------
Randy Richter
Director, Technology Solutions, Partner
Association Technology Solutions
Office: 720-945-7256
Cell: 720-272-3994
 
We can solve it!
-----------------------------------------------
 
 

 

Machine Key Issue

Randy:

Thank you very much for your solution. All of a sudden this has started happening again. Have you heard of other instances? Any suggested solutions?

Another change to formsAuthentication

Per one of my developers

 

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

MicrosoftInternetExplorer4

It seems the same Windows Update that changed the FormsAuthentication ticket encryption/decryption routines also introduced a limit on the number of form fields that can be posted back at once. If you suddenly start hearing about or getting the following error, you can work around it – read on.

 

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

MicrosoftInternetExplorer4

<configuration>

  <appSettings>

    <add key="aspnet:MaxHttpCollectionKeys" value="1000" />

  </appSettings>

</configuration>

 

More info at http://support.microsoft.com/kb/2661403

 

Thanks,

Randy

Machine Key Issue

Thank you very much. This is what we have have for the web.config file in the imis_public folder. We added in the key but it does not seem to have resolved the issue. Am I doing anything wrong? Any tips?

  <appSettings>
    <add key="aspnet:MaxHttpCollectionKeys" value="1000" />
    <add key="System.WebLogin" value="GUEST" />
    <add key="EnableContentManager" value="false" />
    <add key="PublicSiteMasterPageFile" value="~/Templates/MasterPages/Public.master" />
    <add key="PublicSiteTheme" value="iMIS" />
    <add key="Request.Url.Authority.ToString" value="localhost" />
    <add key="EmailAddressGlobalErrors" value="webmaster@aag.org" />
    <add key="UsingIMISSecurityTable" value="true" />
      <add key="ImisWebServerUrl" value="IP VALUE" />
    <add key="iBOCacheRefreshIntervalSeconds" value="300" />
    <!-- To sign up for a free Recaptcha account, and acquire API keys for the settings below, visit http://recaptcha.net/whyrecaptcha.html -->
    <add key="RecaptchaPublicKey" value="" />
    <add key="RecaptchaPrivateKey" value="" />
    <!-- allowed values: red, blackglass, white, clean -->
    <add key="RecaptchaTheme" value="white" />
  </appSettings>

SSO issue solved

Hi Randy,
Thanks for the prompt response. The information you gave was very helpful and helped us resolve the issue.
Thanks again for your help and next NiUG we owe you one.
Cheers,
Chamika

One server using classic asp

Looks like we got hit by this security update.  The problem is the other server is running classic asp so there is no web.config.  How do we address this on that side?

Steve Russell GI Solutions/Graphic Images Denver, Colorado 303-883-3861