Cognos 10.2 with Active Directory

[ghostraider]

Hi All,

Our client is using Cognos 10.2 with Active Directory as the authentication provider. Currently we have Cognos groups created in Active Directory itself and these groups are in turn added to the default Cognos roles for users to have Report Studio, Query Studio and Analysis Studio capabilities. Is it a good practice to create user groups in the AD server itself or should the groups be handled inside Cognos? Also, currently we have two departments Finance and Sales. Our groups are created as Finance Query Studio, Finance Analysis Studio and so on. Similarly for the Sales group we have Sales Query Studio, Sales Analysis Studio and so on. Until now, data for finance group is exclusively available to finance team and sales data exclusively to the sales team. We now have requests where some users will need to see data for both the departments. Please let me know if there are any best practices to implement this.

Thank you for your time.

[Yunus]

The best practice is to create groups in AD and create the same groups in the Cognos Namespace as well and make the AD group a member of the group in the Cognos Namespace.  Only add users to your AD groups, not to your Cognos namespace group.  This makes it easier to migrate to a new LDAP or new Cognos environment since you only need to update the groups in the Cognos namespace not the user members of the groups.

As for your other issue of data security, how are you actually securing the data?  Is it done through report filters and object security so Sales and Finance look at different reports or is it done in Framework manager based on group membership or is it at the database level or something else all together?  A simple solution is to add users to both groups but personally I would avoid that, where I work we do not allow groups of groups because it can be difficult to figure out permissions and accidental data leakage could result.  My recommendation and I don't know if its a best practice is to create different types of security for Cognos and keep them independant.  Create a set of capabilities based groups depending on what you need (1 for Analysis Studio, 1 for Query Studio, etc), then create a data based set of groups (Finance data, sales data, no restrictions, etc), then create a set of object based groups(I use it to allow/deny access to specific folders in Cognos Connection).  This offers more flexibility when setting up a user account but does make it a bit more complex.  Also making 1 group per capability makes keeping up with licensing a little easier because you can quickly identify all users that have access to a given studio by looking at a single group.

[bdbits]

I do not know if there is a hard-and-fast 'best practice'. Having people needing to be in more than one group will not matter as the end result - people in groups - works pretty much the same way. It is sort of a six-of-one, half-a-dozen of the other kind of thing to me.

We do have our groups defined in Active Directory. This decision was consultant-driven and before my time here, though I probably would have ended up doing the same thing just because AD is our preferred default security provider organization-wide. But if I could start over, I would probably use Cognos groups with AD-authenticated users/members. For me this would greatly simplify certain things, e.g. having the same user with different permissions on different Cognos environments (dev, test, prod, others). You can work around this with multiple AD trees/forests, but that complicates it for the users and/or has infrastructure maintenance headaches. On the downside, you cannot delegate membership management in Cognos like you can with AD OUs.

We do have separate AD groups for granting Cognos capabilities versus permissions to data, kind of like Yunus alludes to in his post. This was handy when we were audited last year.  :-X

In general, I think you can make arguments for doing it either way. It really comes down to how your client is set up with both technology and user management, as well as organizational preferences.