Symantec Access Management

Would anyone have any idea why I appear to missing SM specific HTTP server variables while trying to intercept HTTP requests using a handler in ASP.net web forms running in IIS 8.5 ?

When trying to capture the HTTP server variable HTTP_SM_USER it is never found in the handlers request. 

Thanks in advance 

Sean 

Hi Sean,

Did you try reading HTTP_SMUSER header as well ? 

Is this specific to SMUSER/SM_USER header or are you not able to get any SM Headers ?

Also have a look at this :

Tech Tip : CA Single Sign-On :: Web Agent ::Custom HTTP Module unable to read the HTTP Headers set by SiteMinder in the integrated pipeline mode 

This could also be related to the behaviour that you are seeing.

Regards,

Ujwol 

Hi Ujwol,

Thank you for the reply. This looks exactly like the information I needed. I will be reviewing this code tomorrow and will post additional details or mark as answered. 

Background:

• Legacy ASP.NET web-forms application
• Previously running for many years in classic app pool mode with SiteMinder
• Migrated to new servers (Windows Server 2012 R2, IIS 8.5) and changed to integrated app pool mode.
• The HTTP Handler is only getting 3 SM header variables:
  • HTTP_SMSESSION
  • HTTP_SM_FILTERCTXPTR
  • Can't recall the third one from memory.

Regards

Sean

Hi Ujwol,

After a server reboot I appear to be hitting the HTTP handler and I am getting the HTTP_SM_USER header.

Unfortunately I am getting a SQL login failure when the handler is making a call to the DB:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

The SQL credentals are all correct and have been working perfectly pre-Siteminder setup.

All of my application pools run with a specific Active Directory account and have full permissions on the IIS folders.

Is this something you would have come across before in Siteminder?

Hi Sean,

No haven't come across such scenario.

What DB is this and what is used for ? 

If you disable SM, what login is used for this DB Login ?

May be enable IIS failed request tracing for both working/non working scenario ?

It turned out that this definitely fixed the issue, We also had a custom SM header variable from years ago that we relied on.

Once the SM policy was updated and the IIS request priority changed for SM, it all worked. 

Thanks Ujwol.