CA Single Sign On : IIS7.x Modules : ReOrdering SM Module

[Legacy User]

Here another one of the Product Interoperability dilemma when it comes to Microsoft.

 

WebAgent on IIS does not intercepts requests made on webservices resource ("*.svc"). It does other kind of resources (sa…

GLIMPSE and CA Single Sign On WebAgent interoperability issues

 

One of the key similarities rather expectation in IIS is to have the SiteMinder MODULE right at the TOP.

 

Now with IIS7.x and upwards we need to make this reordering change in 2 places

• Modules Section.
• ISAPI Filters Section.

 

Here's the usecase and the challenge.

1. When we configure the WA, we select only the "Default WebSite" i.e. Site-Level (not "Select All" i.e. Server Level).
2. After configuration
   1. we go to "Default WebSite" and choose ISAPI Filter, select View Ordered List from Right Pane (We are able to Move the SM ISAPI up and down).
   2. we go to "Default WebSite" and choose Modules, select View Ordered List from Right Pane (We see an Info message "The entries cannot be reordered because one or more of them have been locked in the parent file").
   3. I try to jiggle a few IIS Setting (See Image-1 Below) by going through each line item under "system.webServer" and flipping the ones which were locked to unlock.
   4. Yet no luck.

 

Now I do understand that is purely IIS related, nothing to do with SiteMinder Modules; because I took a swanky new W2K8R2 64bit did not install WA. Just tried to check 2.2 and the info message was there. We then tried to do 2.3 and yet no luck. Hence in this case it is pure IIS (how do we move the MODULE? it is easier said than done - darn!!!). Tried googling with tons of responses and steps - going through each of them and tinkering to see what could click.

 

Question : Do we have any well documented steps OR approach on how do we move the SM Modules up the stack?

 

 

Image-1

 

 

Regards

 

Hubert

[Chris_Stallone]

Is anyone able to assist with the above question?

 

Thank you!

[Anon Anon]

Do you even know if reordering some of the Modules will fix your issue?

 

FWIW, we have some installs of IIS 7.5 and the webagent.dll's are not first in the ordered list and everything works fine.

[Legacy User]

Thank You Mike rtnmike

 

You've tabled a very valid point which I purposely avoided and did not want to counter argue as I wanted to focus my attention on procuring one answer at a time. Hence my focus primarily was on how to get the MODULE ordered list working. As that is what we (CA) proclaim in a glorified way; the questions (a) it works even if unordered OR (b) would it resolve the problem of race conditions in a managed module architecture, is secondary and subsequent to ponder.

 

My gut feeling is (b) won't work within current remit of the product. Hence I have an ER Raised to review the Design of the IIS WebAgent.

Enhancement Request : CA Single Sign On : IIS WebAgent Interoperability

 

Hence the purpose of this thread is not ascertain the solution for the IIS Interoperability issues that we are encountering. The sole focus is only to validate what we proclaim to do and how do we do it i.e. Move / Re Order the Module.

 

Hope this helps and still looking out for the reordering (got a bit sidelined due to some new customer engagements, may need to pool in some time to figure this out via R&D a.k.a Trial&Err).

 

 

Regards

 

Hubert

[Legacy User]

Another point Mike

 

If the MODULE needs to be on TOP, then I believe it is also an INSTALLER Defect. We would like to reduce the amount of Manual Intervention needed to configure the product and also like to reduce the amount of confusing / ambiguous words that are added in documentation (in an effort to improve customer experience using documentation). Hence the INSTALLER / CONFIGURATION WIZARD should push the module onto the TOP (I am also looking at power-shell commands which may possess the capability to do so).

 

Therefore I am unsure if anyone has even raised a product defect to include the capability within the configuration wizard to reorder the module as part of configuration process.

 

Regards

 

Hubert

[Anon Anon]

I would say that it FIRST needs to be proved first that having the webagent at the top of the MODULE list solves the issue, BEFORE calling it a defect.

[Anon Anon]

I just ran a quick test.  I placed a test.svc file in a protected directory on IIS7.5.  The web agent did intercept and I did authenticate (using IWA).  When redirected back to the test.svc target, IIS gave me a 404 file not found even though the file is there.

 

In test.svc I tried staright html, then some xml text.  Both received 404's.

 

My webagent.dll is not first on the ordered list for ISAPI and MODULES.

 

Even though IIS could not display the file contents, the agent did intercept the request.

[Legacy User]

Thank You Mike,

 

I know it works for some standard OOB stuff. The challenge is when it does not work when interworking with other MODULES (e.g. GLIMPSE MODULE or SITE CORE MODULES).

 

 

Regards

 

Hubert

[wayne.sharpton]

From the beginning of SiteMinder in the Netegrity days it has always been a step for the SiteMinder administrator to move the ISAPI filter to the top of the list. We continue to that to this day with IIS 8. so I suspect it will always be a step. While CA has made great strides in making it easier on us, I'm sure we will have to live with this one until Windows 10 comes out and at that time CA will have an even bigger issue. So I wouldn't say this is a defect. It's more of a nuisance. We've never seen this not work nor have we ever seen it where we cannot move it as some have said above. Maybe we are just lucky I guess. We've been using SiteMinder since version 3 I believe so that is a long time.

[Legacy User]

Wayne

 

Thank You - I do concur on the fact that it was always proclaimed that the SM Filter should be on top. Folks who know about it do it judiciously. Folks who are unaware and by sheer luck the Filter works even if it sitting down the order are under the assumption that "it works so its fine".

 

However I would like to highlight one key point.

 

ISAPI Filter is the older way, kindly do not get confused between ISAPI FILTER and MODULES. OOB we can move the ISAPI Filters easily. However MODULES cannot be moved.

 

I think everyone is getting confused between ISAPI and MODULES. This thread is specifically about MODULES and moving MODULES UP. We do the same step for ISAPI too from hay days.

 

For ease I've circled'em both.

 

 

[Ujwol]

To add on to this, If there are two Modules subscribed to the same event in the request life-cycle (e.g AUTHENTICATE)..it is still possible to configure the order of the execution of the module by altering the RequestPriority.

 

This has been covered in our bookshelf itself.

IIS Web Server Settings

 

Control IIS 7.x Module Execution Order when using the CA SiteMinder® Agent for IIS

When you install and configure the CA SiteMinder® Agent for IIS on an IIS web server, the Agent for IIS executes before any other modules. If your IIS environment requires another module to execute first, you can change the number set the following location in the Windows Registry:

HKLM\SOFTWARE\Wow6432Node\Netegrity\SiteMinder Web Agent\Microsoft IIS\RequestPriority 

For example, suppose another module in your IIS 7.x web server (like UrlScan) is assigned the same execution priority as the CA SiteMinder® Agent for IIS. Use this setting to control when the CA SiteMinder® module executes.

Follow these steps:

1. Open the Windows Registry Editor on your IIS web server.
2. Expand the following keys:HKLM\SOFTWARE\Wow6432Node\Netegrity\SiteMinder Web Agent\Microsoft IIS
3. Locate the following value:RequestPriority
4. Change the value of RequestPriority to the number which corresponds to the following value you want:

   PRIORITY_ALIAS_FIRST

   Executes the CA SiteMinder® Agent for IIS before any other modules on your IIS web server. This setting is the default.Example: 0 (First)Default: 0

   PRIORITY_ALIAS_HIGH

   Executes the CA SiteMinder® Agent for IIS module after any modules set to execute first, but before any modules set to execute with medium, low or last priority.Example: 1 (High)

   PRIORITY_ALIAS_MEDIUM

   Executes the CA SiteMinder® Agent for IIS module after modules set to execute first and high, but before modules set to execute with low or last priority.Example: 2 (Medium)

   PRIORITY_ALIAS_LOW

   Executes the CA SiteMinder® Agent for IIS module after modules set to execute first, high, and medium, but before modules set to execute with last priority.Example: 3 (Low)

   PRIORITY_ALIAS_LAST

   Executes the module for the CA SiteMinder® Agent for IIS after all other modules.Example: 4 (Last)

5. Save your changes and close the registry editor.
6. Test your settings and verify that the module you want executes before the Agent for IIS module executes.

[Legacy User]

Thank You Ujwol

 

I have not tried this. However I still feel this would not solve the interoperability issues.

 

Taking usecase-1 : PRIORITY_ALIAS_FIRST

This is the default correct. But with even this set, SiteMinder Module can be involved in a Race Condition if another external-Third Party module also has this property set (I believe PRIORITY_ALIAS_FIRST is a Microsoft IIS property).

 

It now becomes the onus on testing to figure out which setting may contribute to 'firstly' functional working of both modules. Even if both modules work functionally, there is no assurity that in the longer run they'd be performant. We just hope and pray they gel because now we have so many permutation combination with IIS - it is just overwhelming.

 

Permutation = Managed-Native / 32-64 / Priority_Alias_xxxxx  (Phew just too much).

 

 

Regards

 

Hubert

[SKhurana]

well I did the Native Module ordering work in SiteMinder IIS7.5 and we set the priority_Alias_first in the webagent code pro grammatically.  just like this....

 

In the register module API,

 

HRESULT hr = S_OK;

    IHttpModuleFactory* pModuleFactory = NULL;
    // create module factory

    hr = pModuleInfo->SetRequestNotifications(pModuleFactory, RQ_BEGIN_REQUEST, 0 );

// Read the Registry Key settings for Module Priority and set this

    hr = pModuleInfo->SetPriorityForRequestNotification(
                RQ_BEGIN_REQUEST,
                PRIORITY_ALIAS_FIRST);

And to answer the second question about ISAPI filters and Modules, well ISAPI filters are still loaded to support backward compatibility but the new architecture of IIS7.5 only supports modules. Microsoft has gone to the Apache path and they introduced Module  based architecture and dynamic loading of modules.

 

Let me know if you need more information on this, i will be happy to help.

 

Regards

Sandeep Khurana

[Legacy User]

MODULES Could be unlocked at Server Level or at a Site Level. I am interested in unlocking them at Site Level.

 

 

 

Finally found some space to research this at 0130AM after returning back from Customer Engagements.

 

asp.net - iis 7.0, module order change - Stack Overflow

 

Because you don't really know which modules are affected, I tried to unlock them all. The easiest way to do this is with a PowerShell script.

 

 

Open a PowerShell prompt as elevated administrator and run the script.

 

 

The script loops through all the modules at server level. Usually only the native modules (with and empty 'type' property) are locked. Unlock them all.

 

 

Now you can make changes to the order of the module at site level.

 

 

Be careful when the re-ordering, if you change the order of some of the system modules, IIS may no longer work in the expected way.

 

 

 

 

#################################################################################################

Import-Module WebAdministration

 

 

Get-WebConfiguration `

-pspath 'MACHINE/WEBROOT/APPHOST' `

-filter "system.webServer/modules/add" -recurse | `

where {$_.PSPath -eq 'MACHINE/WEBROOT/APPHOST' -and $_.Type -eq ''} `

| foreach {       

     $filter = "system.webServer/modules/add[@name='" + $_.Name + "']"   

     Remove-WebConfigurationLock -pspath 'MACHINE/WEBROOT/APPHOST'  -filter $filter -verbose

}

#################################################################################################