I'm working on restricting access to portions of my metadata on the Reporting Server. I use LDAP authentication and can import the groups into my Access Area and define capabilities. This works well, if I am connecting directly to the Reporting Server. The RS will query LDAP and bring back the groups associated with the User. When I connect to the client and try to access the Reporting Server through a trusted connection, the Client is passing the Internal Security Groups that the user has access to, and not the LDAP groups. This is creating a disconnect between the groups used on the Client and the Groups used on the RS. Does anyone know how to pass the LDAP groups associated with a User instead of the Internal Security groups?

Thanks!

This message has been edited. Last edited by: eric.woerle,

Eric,

I assume that you have LDAP/AD or OPSYS security on your Reporting Server and WFRS Authentication on the WebFOCUS 8 client.

If that is the case then you can use the LDAP groups on the Reporting Server to create GROUP profiles and set/append the APP PATH based on the LDAP Group.

One point to note - the Reporting Server on Windows defaults to group_profile of "primary", which means that only the users primary group profile will be executed. In three out of four sites I've worked at the primary group has been "Domain Users". Change this to "all" and you can create and use profiles for any LDAP group. Of if they have a bucket load of gropus then choose "select" and then get the ones you want/need to use.

You should see the users' groups in the edaprint.log when they run reports in OPSYS or LDAP security provides are used.

Cheers

Stu

Stu,

you are correct I have LDAP/AD Security on my Reporting Server, and I am using WFRS Authentication.

I have my group_profile set to "all"

For my Remote Services Security setting, I have it set to trused - Pass WebFOCUS User ID and Groups. This is where I'm having the issue. The client is not passing the LDAP Groups, it is passing the Internal Client Groups. As you rightfully point out, I can use the LDAP Groups to specify my Application Security, and I have my RS configured to do just that. Unfortunately, the Group values being passed from the client are the wrong ones. The LDAP group never gets passed to the Reporting Server. Do you know if there is a different Variable I can pass for the Groups? One that might contain the External LDAP Grouops for a User?

I don't think the client ever gets the LDAP groups, it's always the RS.

We had an issue that IBI fixed where every client request to the RS was always going out to LDAP to get the list of user groups, that was causing a lot of overhead and performance was poor.

I had a discussion with IBI about always allowing more LDAP attributes to be passed to be able to allow more RS security, but I am not sure if that ever made it into a release.

I have to agree with MattC, I checked few SET commands with different parameters and also didnt find anyway to send LDAP groups to RS.

Regards,

MattC,

The client has to get the LDAP groups at some time. Otherwise it wouldn't be able to do external authentication. Unfortunately, those external groups are not stored in the security tables. But, in working with IBI on another issue, they pointed me to an undocumented variable, &IBIMR_memberof. I'm guessing that there is probably another undocumented variable for external groups. At least I'm hoping so. Because otherwise, there is no way to secure the RS when accessing it through the client. With all of the security improvements that were made on the client side, I'm hoping that this wasn't an oversight. I opened up a case yesterday. I'll see what they come up with.

How do you handle it? Or do you not secure your metadata from the reporting server?

I know it seems backwards, but all security is now handled in the RS. Prior versions of 8 had it on the client side, but they moved it all to the RS.


We don't use the groups to secure metadata, we don't really have a lot of metadata. We use SiteMinder Headers to control SQL-pass thru results. IBI talked to me about using LDAP attributes to secure metadata.

I think if the clients got the groups, you may end up with some performance issues, especially in cases where a user may have many groups.

One day our WF environment came to a creeping crawl during peak hours, when we found out our LDAP team had created this master group causing WF to parse through it and try and pull a list of groups.

Have you tried this page? There are some useful calls in there, that may help in someway.

ibi_apps/WFServlet?IBFS1_action=TEST

MattC,

Thats an interesting page. I'll have to put that into my bag of tricks for later.

When you say the RS handles all of your security what do you mean? How do you secure your MRE Content?

To secure my Content I mapped my LDAP group to a WF group in the Security Center. I used basic roles created by the domain template, but I have also edited the role to limit what the user can/cant do.

I presented this at Summit last summer, in my presentation there are a few slides that cover this at a "High" level. Look for the Wendy's presentation or PM your email and I can send you my PP.

Now what we don't do is allow users to create new content and control the metadata as to what you are trying to do. Is there a way you can use the WF internal groups to map to your metadata?

Eric and Matt,

You are both correct here. This has changed and I was confused in that the client I'm working with has mapped their active directory groups to webfocus groups with the same name.

One of the tests from the page that Matt gave is the listExtGroupsForUser call that rerurns all the external groups - regardless of whether they are mapped or not.

Also on the reporting server it appears that 8008 has a bug with GRPLIST that makes it return blank with Security trusted.

If GRPLIST works for you then you can add that to a general profile. Alternatively you can create a mapped WebFOCUS groups solely to pass through to RS for profiles (or do it in site.wfs)

Cheers

Stu

Stu,

Thanks for the update. Matt and I were actually talking about this off the forum a bit the other day, and we realized that you can manually add your Internal Groups to the Reporting Server in the Admin.cfg file. Or you can register them as PTH groups, and go to the admin.cfg file and remove the PTH/ prefix. This way you will use your Client Groups for security on the RS. I wasn't sure whether this was the recommended approach to this or not, So I spoke with IBI yesterday and had a really good conversation. It seems that what Matt and I figured out is currently the reccommended approach for 8008 (it may not work this way in earlier versions). In 8009 (I think) there are improvements where if you use the resource templates when creating your Domains/Tenants, then it will automatically register corresponding groups on the Reporting Server. The good news, is that IBI is actively working on improving this and has improvements in 8009 and other future releases.

In my discussions with IBI, we talked about GRPLIST. I was able to get this to work just fine in my 8008 (gen 159)... sort of. In my Dev environment it is actually causing the agent to crash, but I have no issues with my QA server. I'm not sure what the issue is in my Dev environment, but I must have something set up wrong there. I was warned though about using GRPLIST. Apparently this is being removed from 8009 forward and being replaced by &FOCSECGROUPS. In 8008 there is &FOCSECGROUP which will return your Primary group (basically the first one in your list of groups). &FOCSECGROUPS will provide all of your groups, semi-colon delimited. When I compared &FOCSECGROUP against GRPLIST, I found that GRPLIST returns my External groups every time, where &FOCSECGROUP returns the primary group that is active on the reporting server (The passed internal group when a trusted connection, my LDAP group when an explicit connection)

IBI also brought up a very important note that I had never thought about/realized before. Our discussions had moved to reportcaster, and my use of &IBIMR_memberof for DBA Security. What I learned was that ReportCaster does not connect through the Client. So all of the client custom settings aren't available when running a scheduled report. Apparently this is one of the areas that IBI is working on improving in 8009 and future releases, I think we will be able to expect better integration from RC. The biggest takeaway that I've had from this discussions is that as I improve my data security, I need to not only account for my Client Groups, but also my LDAP groups as I create my application security rules on the RS. I will need to experiment a bit more with my DBA security. I don't know yet if I will focus on using GRPLIST and creating my rules based on the LDAP groups, or do a Hybrid approach and account for both like I will have to do on the RS. I will be experimenting with this over the next few days.