Symantec Access Management

Hi All,

I have a very simple setup, 

Policy server Version: 12.7; Update: 02.00; Build: 1609; CR: 00;

CA Access Gateway Agent, Version 12.7 QMR02, Update None, Label 1609

Both on running Windows 2012 R2 SP2

I have a virtual host which works when its not protected, as soon as I protect it with Basic Authentication it gives:

spswebagent.log

[7076/1668][Thu Feb 15 2018 15:43:23][ProxyValve.java][ERROR][sm-ProxyAgent-00060] Agent failed to process request with return code: '-1'.

SPS TraceLog

[02/15/2018][15:43:23][7076][1668][16d5daa7-0b270d70-1b15fa18-518f4bf7-40e2c979-b5e4][Tomcat5SerializedAgentData::doResponse][HTTP Status Code = 403]
[02/15/2018][15:43:23][7076][1668][16d5daa7-0b270d70-1b15fa18-518f4bf7-40e2c979-b5e4][Tomcat5SerializedAgentData.doError][Response message not present; Returning SmFailure]
[02/15/2018][15:43:23][7076][1668][16d5daa7-0b270d70-1b15fa18-518f4bf7-40e2c979-b5e4][ProxyValve::invoke][The agent Failed to process the request with a returncode of 5Returning internal server error to the client]
[02/15/2018][15:43:23][7076][1668][16d5daa7-0b270d70-1b15fa18-518f4bf7-40e2c979-b5e4][ErrorPageImpl::displayMessage][Custom Error Pages : Custom message is not an URL. If URL is specified then it might not be in proper format. Considering it as plain text message.]

Server.log shows:

[15/Feb/2018:15:43:23-382] [INFO] - FAILED TO PROCESS RESPONSE

=======

In addition to this I don't see any auth events happening in smaccess.log, at basic Pop-up if I will enter invalid credentials then also I will get above error. In smTrace.log I see Status *Protected* but after that nothing happens on policy server side.

So, I changed the authentication scheme to Form based authentication, after that I get login page, I enter the credentials and After AuthAccept it goes to back to Login page no Authorize Events.

Any suggestions what I could be missing here, which is not allowing me to login with form based and giving error with Basic Authentication. 

I have already eliminated any network issue.

Hi Vikas,

Can you in check the  ACO parameter value 'requirecookies' ?, If it is Yes then change it to No i.e.  'requirecookies=no'. Recycle the SPS and then try the same transaction again

Thanks,

Shankar

Thanks Shankar, it helped me for basic Authentication now I can login with basic Auth, but still for Form based Authentication, after AuthAttempt its not forwarding for AZ events, any suggestions here?

What is the host name mentioned in the form  authentication scheme?  

for example If you are accessing the url in the browser like http://test.abc.com

then mention the hostname  in theform authentication as test.abc.com and then give a try.

Thanks,

Shankar

Hi Vikas,

Check for ValidTargetDomain & CookeDomain  ACO Parameter. 

Regards,

Leo Joseph.

Shankar malsi07

What is the catch here with RequireCookies=NO that we are not disclosing ?

By default RequireCookies=YES. And the product should work with the default value. Why would setting RequireCookies to NO cause this to work, but RequireCookies to YES causes it to fail. Remember as per Agent Configuration the default value is YES, thus anything default should work.

Configure Web Agent Single Sign-On Settings - CA Single Sign-On - 12.7 - CA Technologies Documentation

Configure the Virtual Host Settings Manually - CA Single Sign-On - 12.7 - CA Technologies Documentation

Things just working is not enough. Understanding why things work and why things do not work is also a must to save us from falling into an unknown pit.

As per the documentation setting RequireCookies=NO has implications, @Vikas have you considered the implications.

Regards

Hubert

Vikas

What URL are you using to access on the browser ? Are you using a FQDN or an IP to access on browser. Though It seems like your problem is around cookies to beginwith. But the fundamental / core problem is elsewhere which is incorrect. Changing default values to get product work OOB, is always questionable.

All of this should work with RequireCookies=YES.

Picked this from one of Ujwol's blogs....

SMCHALLENGE=YES cookie header ( This is required if RequireCookies= YES in the ACO of the agent protecting the resource).

When using Basic Authentication, check using fiddler are you seeing SMCHALLENGE=YES being set. The problem seems to be your browser is not setting the necessary cookies OR cookies missing in the Request Header incoming to server. Could be possible due to the way you are accessing the resource.

Refer : CA SSO : How to resolve "Missing required cookies, exiting" 

Dennis,

I am using a URL, I made a host entry with www.demo.local and using this URL to test in browser.

Could you get a fresh set of logs.

• Configure one resource to be protected using Basic Auth.
• Configure another resource to be protected using Forms. 
• Stop and Start CA AG.
• Close all open browsers.
• Start Fiddler. Open IE from within Fiddler.
• Access resource protected using Basic. If it fails, it OK.
• Save the fiddler trace.
• Close IE browser, Restart Fiddler.
• Open IE from within Fiddler.
• Access resource protected using Forms. If it fails, it OK.
• Save the fiddler trace.
• Upload to CA Support Case and you can mentioned this link in CA Case.
  • both fiddler trace.
  • All logs from CA AG.
  • Upload a copy of server.conf and proxyrules.xml.
• Paste the Case Number here.

Hi Vikas,

we were having the similar issue where we were using URL http://abc.com to protect from SSO, with basic auth scheme and requirecookie set to no it was working but for form based auth it wasn’t,    Finally CA support guys caught the issue why cookie wasn’t being set in browser.

Our URL was having single dot so it was trying to create cookie for .com domain, which browser doesn’t allow to create, so we extended our URL to multiple dot (http://www.abc.com)and kept requirecookie=yes after which everything was working fine.

I am not sure if this is the same in ur case. But raising support ticket might help you to resolve this issue.

Regards

Prashant

PKSahu that's more like identifying & having a solution. Thank You for sharing key insights.

Yes initially I had http://demo.local, this makes sense that I need to have it like http://www.demo.local to get have requirecookies=yes .

thanks for you inputs Dennis, Prashant, Shankar and Leo.