Symantec Access Management

Hi All,

I'm verifying my environment for various functions. I have a resource (lets say test.html), I have protected the resource and successfully accessed it through Basic Auth Scheme.

But, when I change the Auth scheme to HTML Form based (I'm using login.fcc), it is throwing the below error.

============================================

Your credentials are not valid for http://HOSTNAME/test.html.

  Please contact your Security Administrator or Help Desk.

============================================

I guess, this is due to empty target which is going to 'smpwservices.unauth'. And nothing is being logged,so I'm not able to find anything.

Does any one have an idea here?

Regards,

Sandeep.

Sandeep

It is quite difficult to infer based on the information where the request is being redirected. How did you conclude that TARGET is empty?

Would it be possible to attach your WebAgent Trace log and Browser Trace logs.

Also once you changed your authentication scheme to forms, are you re-accessing the protected page on the same browser OR making sure all browsers are closed then accessing on a new browser.

Could you confirm that when you re-access the protected page, your request is reaching the Server and not being served from Browser Cache, because I do see you suggest that nothing is being logged and hence no information is present to debug. I would say install a Browser trace utility like IEHttpHeader on IE and check the request going out from the Browser and response being received by the Browser.

Regards

Hubert

Hi Sandeep,

In general, in form authentication scheme, once user being redirect to login.fcc page, it should contains target in the URI. It will be odd if we didn't see one.

for example, following resource was protected by Siteminder form authentication scheme

http://drssoiam2.test.lab/transpolar/frontpage.htm

I would expect 302 redirect happen and get to login.fcc page as below:

http://drssoiam2.test.lab/siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=XXXX&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=XXXXX

&TARGET=-SM-http%3a%2f%2fdrssoiam2%2etest%2elab%2ftranspolar%2ffrontpage%2ehtm

As such, it will be good if you can first review the header trace log (tool to capture fiddler2) to check on how the request being redirect.

If the target is not being passed in, we need to know why it not.

The header trace logs and web agent logs can provide us a starting point to troubleshoot the issue.

Hi Hubert,

The logs are as below, and I can Only see the below logs ( with today's time stamp), when I access the resource today.

access log

IP - - [15/Sep/2014:02:50:07 -0400] "GET /test.html HTTP/1.1" 302 488

IP - - [15/Sep/2014:02:50:07 -0400] "GET /siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=******&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$*******&TARGET=$SM$http%3a%2f%2fHOSTNAME%2ftest%2ehtml HTTP/1.1" 200 3454

IP - - [15/Sep/2014:02:50:08 -0400] "GET /favicon.ico HTTP/1.1" 404 209

IP - - [15/Sep/2014:02:50:38 -0400] "POST /siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=******&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$*******&TARGET=$SM$http%3a%2f%2fHOSTNAME%2ftest%2ehtml HTTP/1.1" 200 2287

error log

[Mon Sep 15 02:50:08.638636 2014] [authz_core:debug] [pid 19452:tid 139719797090048] mod_authz_core.c(802): [client IP:52657] AH01626: authorization result of Require all granted: granted

[Mon Sep 15 02:50:08.638706 2014] [authz_core:debug] [pid 19452:tid 139719797090048] mod_authz_core.c(802): [client IP:52657] AH01626: authorization result of <RequireAny>: granted

[Mon Sep 15 02:50:08.638760 2014] [core:info] [pid 19452:tid 139719797090048] [client IP:52657] AH00128: File does not exist: /etc/httpd/htdocs/favicon.ico

Regards,
Sandeep.

Hi All,

Its fixed.

I was just verifying all the ACO parameters and found that "ValidTargetDomain" was enabled. I commented this parameter and there were two other parameters which I have changed their values.

EnableCookieprovider was set to no, I made it Yes.

LimitCookieProvider was set to Yes, I made it no.

After this, I flushed the policy data and then its started working fine.

Thanks for your time.

Thank You Sandeep, Glad you were able to find your way.

On a closing note, here's some tips. I would suggest you review the ACO Configurations. Because a lot of them are set by default.

EnableCookieProvider :

Default: Yes.

Default: (after using smpolicy-secure.xml to create your Policy Store) No.

LimitCookieProvider :

Default: No.

Default: (after using smpolicy-secure.xml to create your Policy Store) Yes.

In your case it looks like you have a Multi_Domain SSO Setup, however the Default ACO Parameters seems to be set for restrictive security which is done via import of smpolicy-secure.xml.

EnableCookieProvider :

https://wiki.ca.com/display/sm1252sp1/How+to+Configure+Single+Sign-On#HowtoConfigureSingleSign-On-DisableCookieProviders

LimitCookieProvider :

https://wiki.ca.com/display/sm1252sp1/How+to+Configure+Single+Sign-On#HowtoConfigureSingleSign-On-RestrictCookieProviderFunctions

ValidTargetDomain :

https://wiki.ca.com/display/sm1252sp1/Help+Prevent+Attacks#HelpPreventAttacks-DefineValidTargetDomains

Since you are possibly using secure smpolicy.xml; from a solution standpoint you'd need to evaluate the default ACO parameters in conjunction to the solution you wish to implement / achieve. If you'd been using the standard / nonsecure smpolicy.xml all of this should work OOB without having to make any changes to the ACO parameters you had to tweak (3 parameters in all). Therefore it is a balancing act between business needs and solution engineering.

Regards

Hubert

Hi Hubert,

Thanks for the additional info.

The request was failing when I have reverted all the changes and tested.

After that, I have commented only one parameter "ValidTargetDomain", then its started working. So, I have kept the Cookieprovider parameters as they were, to maintain additional security settings as default.

Sandeep,

The ValidTargetDomain has been introduced for Security purpose.

From the 12SP3 Webagent Configuration Guide:

How to Configure a CA SiteMinder Agent to Support HTML Forms Authentication

Define Valid Target Domains

To configure SiteMinder Agents to help protect your resources from phishing attempts that could redirect users to a hostile website, set the following configuration parameter:

ValidTargetDomain 

Specifies the domains to which a credential collector is allowed to redirect users. If the domain in the URL does not match the domains set in this parameter, the redirect is denied.

Default: No.

All advanced authentication schemes, including forms credential collectors (FCCs) support this parameter.

The ValidTargetDomain parameter identifies the valid domains for the target during processing. Before the user is redirected, the agent compares the values in the redirect URL against the domains in this parameter. Without this parameter, the agent redirects the user to targets in any domain.

The ValidTargetDomain parameter can include multiple values, one for each valid domain.

For local Web Agent configurations, specify an entry, one entry per line, for each domain, for example:

validtargetdomain=".xyzcompany.com"  

validtargetdomain=".abccompany.com"  

Hope it helps,

Julien.

Thanks for additional info Julien.

It only worked when we removed the validTargetDomain from ACO Parameters (Adding # infront of the property name). The property value was No still didn't work only after removing the property it worked for us.

Thanks!