Symantec Access Management

[Denying request due to authorizeEx call failure.]

Greetings Everyone,

I know that there have been a few threads on the issue I am facing, but I am not able to resolve my issue regarding authorizeEX call failures.

In my case I am certain that the user is valid, I am certain that the user can login and I am certain the user is Authorized as I have several realms in the same Domain using the same Allow Policy.

I was using Basic as an Authentication Scheme, but it was suggested to me that I 'must' use a form. No difference.

The return in the browser is quite fast:

The following error occurred: 403 - Request Forbidden. Transaction ID: 8963d84d-b8b28818-5c07364a-88516478-d4513980-803 failed.

Any insight would be most appreciated.

Cheers to all!

Albert

abriones

The authorization failure is not necessarily due to User Policy. In federation it could be due to variety of reasons beyond User Policy. The only way to confirm what happened is to look at the Policy Server Trace logs.

Please enable Policy Server Trace Logging. This would tell you why the Policy Server returned to WAOP an authorize failure. Make sure we have selected 'Fed Server' in component. I've also provided a snippet of the smtracedefault.txt file which you could copy directly into your smtracedefault.txt before enabling trace logging.

Snippet of C:\CA\siteminder\config\smtracedefault.txt

components: AgentFunc/Init, AgentFunc/UnInit, AgentFunc/IsProtected, AgentFunc/Login, AgentFunc/ChangePassword, AgentFunc/Validate, AgentFunc/Logout, AgentFunc/Authorize, Server/Policy_Server_General, IsProtected, Login_Logout, IsAuthorized, Tunnel_Service, JavaAPI, Directory_Access, ODBC/Sql_Statement_Begin_End, ODBC/Sql_Errors, ODBC/Connection_Monitor, LDAP/Ldap_Call_Begin_End, LDAP/Internal_Operation, LDAP/Ldap_Error_Messages, Fed_Server

data: Date, PreciseTime, SrcFile, Function, TransactionName, Message, Data, AgentName, Resource, User, Group, Realm, Domain, Directory, Policy, Rule, ActiveExpr, Expression, ErrorValue, ReturnValue, ErrorString, IPAddr, IPPort, Result, Returns, CallDetail, AuthScheme, AuthReason, AuthStatus, Query

version: 1.1

Regards

Hubert

Hubert,

You are in fact correct.

Our team had long set the Policy Domain side and have had scripted demonstration links set for several weeks now.

Several new User Repositories where set in place, all with Names set apart by only a single ending letter.

The partner definition was modified to reflect the new User Repository changes but it turns out the wrong User Repository was selected. ( vs. that of the Domain side )

Trace Profiler was set and IsOK showed a result of No.

What made things harder was that the User Repository which was incorrect did in fact have the same user/password. So the logs looked real good showing the user every step of the way except for Authorization.

The key IMO was the profiler saying  'No Associated Policy Found'...... resulting in IsOK returned as No.

Notes for those interested:

User was authenticated and authorized at Policy Domain, user was not authorized from a Federation Partnership perspective.

FWS Trace Log

Result of authorizeEx call is: 2

AffWebServices Log:

Reason: FAILED_AUTHEX

Cheers to all,

Alberto

Hello Alberto,

Did you get the resolution for this issue, even though PS is Authenticated and Authorized, did you get the cause why azex is still fails?

Thanks

Sreekanth

Yes!

SM was correct .... User was not authorized.

Our flow touched a separate SM Domain first .... User was authn and az..... But then when invoking SAML Fed Services we were then getting the az failure .... Turns out the user directory defined in Fed Domain was not the same one .... Spelled almost identical but in fact not the same dir.

A dumb mistake that cost us a few days ?

Albert

Sent from Outlook<http://aka.ms/Ox5hz3>

wow, now that makes sense and yes its a lot time to identify this petty mistake .

Thank you so much for putting this info here.

Hi All,

We faced similar issue in our Siteminder environment where Federation Partnership is configured.

Siteminder version r12.52 cr1

Error message:

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Calling authorizeEx to invoke SAML2 assertion generator.]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Request to policy server for generating saml2 assertion/artifact based on selected profile. [CHECKPOINT = SSOSAML2_GENERATEASSERTIONORARTIFACT_REQ]]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Result of authorizeEx call is: 2.]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Received the assertion/artifact response based on profile selected. [CHECKPOINT = SSOSAML2_RECEIVEDASSERTION_RSP]]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Transaction with ID: 11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72 failed. Reason: FAILED_AUTHEX]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Denying request due to authorizeEx call failure.]

[02/23/2016][07:58:31][6732][4884][11c399fd-07644a6a-c07e1e29-39424c26-f79f8065-9b72][SSO.java][processAssertionGeneration][Sending 500 error]

Solution:

The issue is related to the selected User Directory in the Federation Partnership and to rectify we followed the steps below:

1. We deactivate the Federation Partnership having issue and attempted to modify the Federation definition.

2. Removed the selected User Directory and assigned the dummy User Directory so that the section is not empty.

3. Click on Next button till the last stage where its shows the confirmed screen before submitting the changes.

4. On submitting, re-opened the same Federation to modify the definition.

5. Reassigned the User Directory which is originally meant for authentication/authorization purpose.

6. Submit the change and Activate the Federation Partnership.

7. Attempt to access the Federated based application.

Result: On performing the changes above the issue was resolved.