Symantec Access Management

Hi all,

we are having group attribute as memberOf in user AD.

I have tried configuring it as follows:

userclass- Filter by User Property

filter- memberOf=cn=abc,ou=cd,dc=re,dc=com

but it's giving unauthorized even for the user whois authorized to access this app.

is there anything wrong with filter? am i missing something to check?

Regards,

Shrawan

Shrawan shrawan.bhagwat

Could we check the smtracedefault.log as to exact reason for Authorization Reject. It may be possible that it could be something other than the group that caused the reject. Hence lines from the smtracedefault.log would be crucial in understanding.

Added Info

https://docops.ca.com/ca-single-sign-on/12-7/en/configuring/partnership-federation/user-identification-for-a-partnership

Clarification

The difference between “FILTER USER PROPERTY” and “FILTER ANY” is the root of where that search starts. The whole directory or just searching the existing user object. “FILTER USER PROPERTY” only issues a search to current user (authenticated user) i.e. uses current user as the Search Base. “FILTER ANY” by default uses the ROOT DN as the Search Base.     The “FILTER GROUP PROPERTY” refers to a Group Object having those attributes. So if the user is a member of a Group that has an attribute of businesscategory of CA Support. It's not saying the group name is CA Support (nor is it referring to businesscategory being an attribute of a User), but businesscategory being an attribute of the group itself & any group could have that attribute. While it is somewhat obscure we have run across scenarios that do just that. They have 10 groups for an application, and each group has an attribute of appName. Thus if we wanted to see whether the user was in Any of the groups for that app, we would use a group search where appname="MyApp" vs if they were a member of a particular group. Think of it almost as groups of groups.     The “FILTER OU PROPERTY” is similar to “FILTER GROUP PROPERTY”.

Hi Dennis,

Thanks. I was looking for this kind of clarification in docops but i dint able to find. That helps me alot to clear concepts regarding SAML configurations.

Regarding the issue, i kept the configurations same as it was earlier, and dont know how it started working. I dint found apart from "Not Authorized" logs for that user prior to resolution.

Regards,

Shrawan

Hi,

Can you give a bit more background on your federation configuration? what does your federation URL look like (i.e. who's the Identity Provider, who's the service provider, etc), the one you are calling? Who responds to you that the user is not authorized - is it Identity provider or service provider? I believe a user may not be authorized to access a specific resource for many various reasons (and certainly depends on the service provider with which you configured federation): for example an assertion cannot be generated for whatever reason, the user is not authorized to access specific protected URIs, a SAML assertion is NOT valid (ex. the validity has passed), user identity could not be determined from a SAML assertion, a SAML assertion is not accepted by the service provider because the issuer is NOT trusted, etc, etc.

For federation to work, you also protect /affwebservices/redirectjsp/  is there a policy that also allows the members of this group to access federation services?

As Hubert said, it's best to check your SSO traces.

Regards,

Russi

Hi Russi,

This issue somehow resolved. but i think configurations were proper and in place from starting and it's resolved by it's own then definitely it will return

I will reply back on your comment if i face this again.

Regards,

Shrawan