Understanding LDAP Security Groups - Need assistance...

[Former Member]

Hi,

Can someone walk me through a simple step-by-step outline of how to adjust LDAP security groups so that they work properly with report objects and folders. I've added a number of LDAP groups to our server and see the user accounts in them but am having difficulty understanding how to apply these groups to the right folders and have access behave correctly. As an example I have a couple groups where a few users are in LDAP under MKTDEPT and others are under SYSUSR. A few users are in both. I want to give MKTDEPT view rights to a folder whereas SYSUSR gets schedule rights. I'm having an issue with teh Everyone group in that I have to set it to at least 'view' for anyone to see anything. This is even though the MKTDEPT and SYSUSER user security is set lower. So what's the best approach to get this to work right? Any steps or documents that could help me out would be terrific.

Thanks,

Dom

[Former Member · Accepted solution]

Dominic,

Most of the information you need is in the Administration Guide.

That said, here's how I would do it:

Lets say MKTDEPT has users A,B,C,D,E and SYSUSER has users B,C,D,H,J. Lets call the folder you want to assign rights to as (rather unimaginatively) FolderA.

For FolderA, set the following rights.

Everyone Group --> No Access

MKTDEPT --> View

SYSUSER --> Schedule

The problem now is dealing with users that belong to both group. For this, I would create a new (Enterprise) group called MKTSYS and add the common users to that group. This group would get Schedule rights to FolderA.

Also, as a practice, it is best to create Enterprise copies of your LDAP groups (especially since you have users that can belong to multiple LDAP groups). So, you would have

*MKTDEPTENT which contains users in the MKTDEPT LDAP group.

SYSUSERENT which contains users in the SYSUSER LDAP group.*

I would then add these groups to the list of groups with access to FolderA.

So, the list of groups with access to FolderA would be:

Everyone

MKTDEPTENT

SYSUSERENT

MKTSYS

and the rights would be:

Everyone Group --> No Access

MKTDEPTENT --> View

SYSUSERENT --> Schedule

MKTSYS --> Schedule

Please note that the Everyone Group does not need to have View access. That said, the Everyone Group does need to be in the access list for FolderA.

Also, while this method of replicating LDAP group structure in BO creates additional administrative work, I am of the opinion that it is a small price to pay to prevent unauthorized access.

Hope this helps,

Srinivas

[Former Member · Accepted solution]

Excellent reply....very professional and I APPRECIATE the time it took.

One additionall questions. If these groups have hundreds of users, and there could be say a significant number of users that could be in both groups; how can I easily find this subset of users and add them to a third group? Do I really have to configure each user one at a time? That would stink.

Also all of your principle assignments are under folder 'user rights' correct? What exactly is 'all folder security' doing? I assume that is a blanketed security assignment for all folders. Does this setting take precedance over user rights?

Thanks a million..

Dom

[Former Member · Accepted solution]

Hello,

 One additionall questions. If these groups have hundreds of users, and there could be say a significant number of users that could be in both groups; how can I easily find this subset of users and add them to a third group? Do I really have to configure each user one at a time? That would stink. 

There unfortunately is no easy way of doing this short of using the Enterprise SDK.

Also all of your principle assignments are under folder 'user rights' correct? 

Yes, though I presume you mean the Rights for each folder

What exactly is 'all folder security' doing? I assume that is a blanketed security assignment for all folders. Does this setting take precedance over user rights?

I don't quite know what you mean here. I'll assume you mean the Rights tab under Settings (These are considered to be the rights on the Root folder). If this is the case, these are the rights that propagate through for all folders for the groups you have set rights for(if inheritance is used). By default, the only groups here are Administrator and the Everyone group. For most scenarios, it is best to leave the rights of these two groups unmodified (in this tab). You could add additional groups to this list though.

For example, if you add MKTDEPT to this list, set the right to View, then MKTDEPT will have View rights on all folders (if inheritance is used). This value does not take precedence. Precedence is always granted to the most granular level. So, for example, if MKTDEPT has View rights on the Root folder and No Access on FolderB, then MKTDEPT will not have access to FolderB. To give a specific user(s) access to FolderB, add them to another group that has access to FolderB. Also, as a best practice, do not assign rights at the user/report level. This make security management much more difficult.

Best,

Srinivas

[Former Member · Accepted solution]

One more finding....

USERA is in LDAPGROUPA and LDAPGROUPB.

LDAPGROUPA and LDAPGROUPB are both added to the Crystal Server.

UserA only gets an LDAP alias for LDAPGROUPA and not LDAPGROUPB although I see his user account is part of LDAPGROUPB in the Group member list.

I assign LDAPGROUPB to a folder and give it schedule rights. I deny access to the same folder for LDAPGROUPA.

This results in USERA not having access to the folder.

How can I either 1) add a new LDAP alias reference to USERA's account for LDAPGROUPB or 2) prevent LDAPGROUPA rights from having precedence.

Thanks,

Dom

[BasicTek · Accepted solution]

If the group information in your user member tab is not matching the group tab there could be a caching problem with your LDAP graph. It would be best to open a message with support to troubleshoot. See if restarting the CMS resolves. If so then it may be a bug that was fixed in SP4

Regards,

Tim