Fixing Folder Permissions and Row-Level Data Leakage After a Migration

Authentication is probably working: the North user is recognized and signed in through Active Directory. The failure is authorization at two layers. First, object-level permissions are too broad because the team folders allow All Authenticated Users, so a URL or search result can expose a South report. Second, data-level security is missing because the package query subject returns all member claims regardless of the user's business unit. Fixing only folders would still leave data exposed if a user opens a shared report; fixing only data would still expose South's report metadata and possibly other objects.

Use a layered fix. Replace All Authenticated Users on team folders with mapped Cognos groups for the appropriate business unit, and remove inherited permissions that grant broader access. Map nested Active Directory groups to Cognos groups deliberately, then test effective permissions for representative users. In the package, add data security filters at the query subject or model layer so that claims rows are restricted by a session parameter tied to the user's business unit. Existing reports that use the secured query subject inherit the filter without being redesigned. Test both direct report access and folder browsing, because a user who cannot see a folder may still reach a report by URL if object permissions are wrong.

Put the row-level rule in the shared semantic layer, not in each report. In Framework Manager or an equivalent modeled package, define a data security filter on the claims query subject that compares the business-unit column to a session parameter derived from the authenticated user's Cognos group or a custom variable. Because every report uses that query subject, the filter applies at query execution time. Validate with users from each unit and with a user who belongs to multiple units; define whether multiple units should union access or require explicit selection.

The burst risk is separate. A scheduled burst report runs under the schedule owner's credentials unless a run-as identity is configured. Bursting does not automatically restrict each recipient to their own rows; it delivers report output to recipients, and the query is executed in the context of the schedule owner. If the owner has broad access, a burst can send South data to North recipients. Safer options are one schedule per business unit under a restricted run-as account, or a burst key combined with a filter that is explicitly parameterized per burst value. Do not rely on recipient identity alone. Test the burst with a restricted owner and inspect the actual rendered output, not just the delivery list.

Enable and use the audit database to capture report executions, report views, security changes, and administrative actions. Build audit reports that show which users accessed which packages and reports, and review them after a pilot. Use Cognos administration to inspect effective permissions for sample users, including nested-group members and users with multiple business units. Do not test only with administrators or report authors, because their permissions mask problems.

For data-level verification, use a run-as or test-account approach to render the same report as a North user, a South user, and a user with no claims access. Compare row counts and totals, not just whether the report opens. Check scheduled entries for their owners and run-as settings, because a schedule with an overly broad owner can bypass the intended restriction. Document the group-to-business-unit mapping and the data security rule so that future migrations do not repeat the All Authenticated Users mistake. Finally, review object permissions on team folders and on any shared public folders, and remove permissions that are broader than the business requirement.