Handling Change to IBM Cognos 8 security Guideline

Guideline
Handling Change to IBM Cognos 8
security
Product(s): IBM Cognos 8
Area of Interest: Security
Handling Change to IBM Cognos 8 security
2
Copyright and Trademarks
Licensed Materials - Property of IBM.
© Copyright IBM Corp. 2009
IBM, the IBM logo, and Cognos are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at
http://www.ibm.com/legal/copytrade.shtml
While every attempt has been made to ensure that the information in this document
is accurate and complete, some typographical errors or technical inaccuracies may
exist. IBM does not accept responsibility for any kind of loss resulting from the use of
information contained in this document. The information contained in this document
is subject to change without notice.
This document is maintained by the Best Practices, Product and Technology team.
You can send comments, suggestions, and additions to [email protected].
Linux is a registered trademark of Linus Torvalds in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems
Inc. in the United States, other countries or both.
Handling Change to IBM Cognos 8 security
3
Contents
1
INTRODUCTION ............................................................................................ 4
1.1
1.2
1.3
PURPOSE ................................................................................................................ 4
APPLICABILITY ......................................................................................................... 4
EXCLUSIONS AND EXCEPTIONS ..................................................................................... 4
2
USER IDENTIFICATION IN IBM COGNOS 8 .................................................. 4
2.1
2.2
2.3
2.3.1
2.4
2.4.1
AUTHENTICATION PROVIDERS ...................................................................................... 4
AUTHENTICATION RUNDOWN ....................................................................................... 5
TRUSTED CREDENTIALS .............................................................................................. 7
Table 2 – Support for Trusted Credentials............................................................ 8
AUTHORIZATION AND THE CAM ID ............................................................................... 8
Table 1. CAMID details ...................................................................................... 9
3
CHANGES WHICH AFFECT CAMID................................................................. 9
3.1
3.2
3.3
3.4
3.5
3.6
COGNOS ............................................................................................................... 11
LDAP.................................................................................................................. 11
SERIES 7 .............................................................................................................. 12
ACTIVE DIRECTORY ................................................................................................. 12
NTLM ................................................................................................................. 13
SAP.................................................................................................................... 13
4
CHANGES WHICH AFFECT TRUSTED CREDENTIALS (TCS) ......................... 13
5
REACTIVE SOLUTION BEST PRACTICES ..................................................... 14
5.1
5.2
5.3
USER HAS BEEN DELETED FROM THE AUTHENTICATION SOURCE ........................................... 14
USER’S CAMID HAS CHANGED ................................................................................... 18
RENEWING TRUSTED CREDENTIALS ............................................................................. 19
6
PRO-ACTIVELY HANDLING CHANGE – BEST PRACTICES ........................... 21
6.1
6.2
6.3
REMOVE USERS ...................................................................................................... 21
HANDLING CAMID CHANGE (USER MOVE OR TRANSFER) ................................................... 21
PREVENT STUCK CREDENTIALS .................................................................................... 21
7
RESOURCES................................................................................................. 22
Handling Change to IBM Cognos 8 security
4
1 Introduction
1.1
Purpose
This document describes best practices and guidelines for handling changes
to configured authentication sources and their impact to a running IBM
Cognos 8 deployment.
1.2
Applicability
The guidelines given herein apply to IBM Cognos 8
1.3
Exclusions and Exceptions
The document will not describe any techniques implementing changes to
external authentication sources or SDK solutions. If required references are
provided.
2 User identification in IBM Cognos 8
IBM Cognos8 doesn’t authenticate users itself but rather relies on 3rd party
authentication sources like LDAP or Microsoft Active Directory to do so. This concept
implies that IBM Cognos8 presents logon data (essentially credentials) entered by
the user or obtained through single sign-on (SSO) mechanisms to the 3rd party
authentication sources on behalf of the user. Then, once authenticated IBM Cognos8
needs to read the user’s groups and roles from the authentication source as well and
make them available to the authorization functionality.
This task is implemented by authentication providers.
2.1 Authentication Providers
Authentication providers are software modules which attach to one specific type of
authentication source like LDAP, Active Directory, etc by leveraging some API
provided by the authentication source vendor and implement the handling of
authentication with the authentication source as well as (in most cases) SSO.
Authentication providers are plug-ins to the Cognos Access Manager (CAM)
component which is co-located with the Content Manager install-component. They
appear as namespaces in Cognos Connection and can be browsed through the UI to
locate objects stored in them like users, groups and roles. Configuration is done
through namespace resources in Cognos Configuration.
Authentication providers expose the objects stored in authentication sources to the
IBM Cognos8 security but they don’t have write access. This implies that IBM
Cognos8 is not involved with user management at all. The only exception is that
some authentication providers allow reacting to forced password updates triggered
by the authentication source by presenting some password update dialog.
There is one “invisible” authentication provider with a corresponding namespace
already built-in to IBM Cognos8. This namespace is called the Cognos Namespace
and it is pre-populated with some groups and roles which can be used to define
authorization. An administrator can extend this namespace by creating new groups
and roles to his liking. It’s impossible to create users though.
Handling Change to IBM Cognos 8 security
5
2.2 Authentication rundown
Whenever a request is sent to IBM Cognos8 the system first will determine if this
request requires authentication or if it is sent as part of an already authenticated
session. This is done by looking for a cookie (“cam_passport”) which is used to store
session authentication for IBM Cognos8. If this cookie is not present or expired the
request will be passed to the CAM component to run authentication.
When CAM receives a request to authenticate the session the first decision about the
type of authentication is made based on configuration. If the system is configured to
allow anonymous access, then sessions will become authenticated using a special
anonymous user as there are no real anonymous sessions in Cognos8. An internal
authentication provider is used to implement this functionality which is neither visible
nor configurable. The dummy user credential does not contain a password and hence
no login is required.
For named (=non anonymous) access CAM will use the configured authentication
providers to authenticate, the request is hence passed to the provider.
The request must contain all the information required for authentication at once,
like the namespace to authenticate to or credentials. There is no concept of passing
in additional information in a secondary request which is related to the first request.
Instead the architecture implements a concept of returning qualified responses to
the sender which might trigger further action like re-sending the request with
additional information attached. So each request sent to CAM is treated
independently but a sequence of requests may constitute the logon process for a
given session.
There are four possible ways to pass in logon data in a request to the authentication
provider.
Trusted credential(s) (TC)
Credentials of this type have been created by some authentication provider in the
past and were stored (encrypted) in Content Store. For example a schedule will have
a reference to TC (a credential path) stored alongside with it. Technically they can be
binary tokens or string(s) like username (and password). Only the credential path is
passed in requests though, TCs never leave the Content Store.
When submitting a TC to an authentication provider, indirectly by passing in the
credential path, the provider will not verify their origin or consistency but simply try
to complete authentication against the authentication source. TCs may expire
though, if for example the password has been changed in the authentication source
after they have been stored in Cognos.
Credentials
Credentials of this type are used when authenticating through SDK. An SDK
application may have placed those credentials in the request. Another use case is
when authenticating users for a data source based on “external namespace”.
Technically they will be strings likely consisting of username and possibly but not
necessarily a password. The credentials will be passed in the request in clear text.
When submitting those to an authentication provider, the provider will verify them
against the authentication source.
Handling Change to IBM Cognos 8 security
6
Form fields - Username & password
When running basic authentication, that means a user is prompted to enter
username and password, the HTML code will submit the entered credentials in two
predefined FORM variables. They will be visible in the request to the Entry Point but
as soon as the request is parsed, the Entry Point it will encrypt the password and
hence obscuring it.
(Trusted) Environment variables or generic SSO tokens
Authentication providers may allow reading SSO information from an environment
variable or some binary token.
As the values of those variables or tokens are never read from the request directly
but rather get provided by the entry point component through the authentication
dance (see below) it evolves that support for those SSO tokens or variables requires
code in some other components at the entry point layer as well. Currently only
Kerberos Tickets are supported for binary SSO tokens. The code for Environment
variables accepts generic variables though, both trusted (eg. REMOTE_USER,
USER_PRINCIPAL) and arbitrary variables (HTTP_REFERRER, HTTP_xxxx ) are
supported.
When serving a request the authentication provider will reach out to its
authentication source and read information from it to verify the passed logon data. If
authentication succeeds, the provider will issue a visa for the namespace the
user/client was authenticated against.
A Visa maintains the user’s security context, that is the logon data (whatever was
used to authenticate to Cognos8), and his identity (the groups and roles he’s a
member of). The visa will be used to derive credentials (saved logon data from
previous authentication to pass to other services) which will be used whenever
another Cognos8 service requests authentication or for example when scheduling
reports or to authenticate to a data source, so called Trusted Credentials. The visa
will be added to a CAM in-memory table which will hold all active visas. All the visas
for a single session and hence a user/client, one for each namespace to which
authentication has been successfully completed, make up a Passport. They share the
same primary key in that table, the Passport ID. Only this Passport ID is exposed
externally to CAM as a reference. It’s that Passport ID which is returned to CM and
the user/client.In case of a browser client the Passport ID is stored in a session
cookie in the browser memory, for SDK it’s the application’s duty to manage the
Passport ID for the duration of the session.
In addition to the visa table which is not persisted into Content Store a user profile
get’s created when the user logs in to IBM Cognos 8 for the very first time. The user
profile is created as a copy of the default user profile which is configurable by a
system administrator. This object holds the user‘s personal properties, his
preferences like theme, language etc, the user’s portal tabs and potentially TCs if
they get created later on. In addition the profile stores a link to the user’s MyFolder
object and the user’s watch list object in the Content Store. The primary key to the
user object is the CAMID. As of version 8.3 administrators can actually access any
user object and apply changes to almost all aspects of it; however an administrator
cannot renew TCs as this would require to be logged on as that particular user.
Handling Change to IBM Cognos 8 security
7
2.3 Trusted Credentials
Trusted Credentials are a set of credentials which got saved to be used with a report
or schedule so that another user or process can act on a users behalf.
The primary application is scheduling, where the Job and Scheduling Component
(SDS) will spawn a thread to run a report on behalf of a user at a defined point in
time. The thread executing the scheduled report will authenticate to IBM Cognos 8
on the user’s behalf using the trusted credentials. That way, the user’s security
context will be applied when executing the report thus respecting user specific filters
and settings.
The same logic applies to Agents defined in Event Studio or tasks for loading IBM
Cognos Metric Manager (CMM) Data into CMM data store.
Trusted Credentials are generated implicitly or explicitly during an authenticated
session of the user. TCs get created implicitly when a user saves a schedule. At that
point the schedule will trigger the generation of TCs for the user saving the schedule.
To create TCs explicitly some user would go to the Personal tab in MyPreferences.
The Credentials section allows generating TCs and grant users/groups/roles
permissions to use them to execute reports or other executable objects on the user’s
behalf.
The generation of TCs is based on the current session the user has within IBM
Cognos 8. It’s important to note, that generating Trusted Credentials will trigger
creation of a Trusted Credential for every namespace the user has an active visa for
in his current session.
That means, that if the user is logged on to three namespaces A,B and C a Trusted
Credential will get generated for each namespace TCX by calling the
GenerateTrustedCredential() function of the respective provider. Each credential will
be specific for the provider creating it and differ from the others. Each will
specifically be based on the user’s logon data he provided for authentication to that
particular namespace. The collection of those Trusted Credentials {TCA,TCB,TCC}is
then saved as a set and referred to as Trusted Credentials.
Not all sets of logon data are sufficient for generating a TC though. If a user came in
by SSO the logon data consists of a username or some binary token only. Depending
on the IBM Cognos 8 authentication provider to which those TCs will get presented a
simple username or token may not be sufficient.
By default all full blown out of the box providers (except Siteminder and CJAP) do
support Trusted Credentials when the user provided username and password at
logon time. Some authentication providers though don’t allow the generation of
Trusted Credentials if the logon data is insufficient (SSO). They will prompt the users
to provide username and password to create a proper trusted credential. This may
appear confusing to the user when he came in through some SSO, however it’s the
only choice and not an “issue” or a design flow of the product. For the most part the
restrictions stem from the authentication sources themselves. The table below
documents the support for TCs for the providers delivered with the product.
Handling Change to IBM Cognos 8 security
2.3.1
8
Table 2 – Support for Trusted Credentials
Provider
SSO
TCs
Prompt
Remarks
LDAP
YES
NO
SSO by HTTP Header only. Header is sufficient
by default (1).
Active Directory
NO
YES
SSO by Kerberos token or REMOTE_USER only.
Kerberos token is not sufficient for TC ->
prompt; REMOTE_USER is sufficient by default
(1)
NTLM
NO
YES
SSO by REMOTE_USER or NTLM token. Token is
insufficient -> prompt; REMOTE_USER is
sufficient (1).
SAP
NO
YES
SSO by SAP SSOv2 token only which is
insufficient -> prompt.
Series7
YES
NO
SSO by cookie or HTTP header which is matched
to saved OS-Signon. This is sufficient.
(1) Allowance of REMOTE_USER for TC is a potential security risk as its relatively
weak if transmitted over a clear text line (use SSL!). The provider does allow it by
default, it can be deactivated through some advanced property
(“allowTCsForRemoteAuth”) which must be set to false.
Trusted Credentials get saved in Content Store attached to the user’s profile.
2.4 Authorization and the CAM ID
As mentioned before authentication will result in some visa being issued for a
namespace. This visa will refer to a user’s identity which to IBM Cognos8 implies
which groups/roles the user is a member of directly or indirectly (nested group
memberships). This is true for groups and roles from the namespace the particular
visa has been issued for plus groups and roles from the Cognos Namespace.
Authorization in IBM Cognos8 applies to basically all objects which make up a IBM
Cognos8 application. All content (reports, analysis, folders, packages …) as well as a
wide range of functions and capabilities of system can have permissions attached to
them. A permission defines who, a user, group or role, has what privileges on an
object/capability/function. There are 5 privileges within IBM Cognos: READ, WRITE,
EXECUTE, TRAVERSE and SET POLICY.
Internally those permissions contain not the users’/groups’/roles’ name but some
internal ID called the CAMID. The CAMID is constructed by the authentication
provider for each object read in from an external authentication source. This applies
to the internal authentication provider as well so all the objects of the Cognos
Namespace have a CAMID assigned to them.
It’s by this CAMID that IBM Cognos stores and verifies access to objects when it
comes to authorization. The CAMID of objects in the user’s identity is compared to
the permissions assigned to an object and if they match the privileges get granted or
denied.
Handling Change to IBM Cognos 8 security
9
The CAMID is built differently among authentication providers. They all use a
common layout though. The CAMID will be a string consisting of two fields which get
concatenated.
CAMID:=“CAMID(<NamespaceID>:<AuthProviderSpecificID>)”.
NamespaceID is the id specified in Cognos Configuration for the namespace.
AuthProviderSpecificID is an ID as constructed internally by the authentication
provider.
Warning:
This ID is not officially documented as it is considered internal and subject to change
without further notice. The layout documented here is current as of Cognos 8.4,
however it may change in future versions without notice.
Currently the AuthProviderSpecificID is composed from a a type field indicating the
type of entry and some ID string. Type is one of “u” for user, “g” for group and “f”
for folder. ID totally depends on the provider.
The table below shows the details about how each provider constructs the CAMID.
2.4.1
Table 1. CAMID details
Auth provider
LDAP
Active Directory
ID format
Depends on “unique identifier”
setting. Default is DN attribute
of user.
Active Directory GUID
Series7
SAP
NTLM
authID
USER ID from SAP
SID
Cognos
CM search path
Example
CAMID(“myLDAP:u:cn=user1,dc=i
bm,dc=com”)
CAMID("ads:g:9addd3497e0a804e
b83bf159d50b9a3b")
CAMID("S7NS:u:authid=3547022297")
CAMID("SAP - sottbwt1:u=GRSUPP")
CAMID("NTLM:u=S-1-5-211219126167-4442633782758616537-1017")
CAMID(":Folder1:MyRole")
3 Changes which affect CAMID
Given the explanations of the two previous sections a very important point becomes
clear now. Since IBM Cognos8 relies on the CAMID for checking authorization it’s
crucial that the CAMID stays consistent when:
- Deploying an application from one environment to another.
This may involve the use of IBM Cognos8 mechanisms like deployments or external
mechanisms like Data Base backups.
- Applying changes to the authentication source.
This may include change of passwords, change of user attributes or name, structural
changes or deployments to different servers/hardware
- Changing configuration settings in the context of the namespace for IBM Cognos8.
Change Namespace ID, Namespace name or other namespace settings.
If CAMID changes all authorization information will be lost!
Handling Change to IBM Cognos 8 security
10
This does not only include the content objects like reports, folders etc but also things
like the “MyFolders” content. This happens because MyFolder is a special folder to
which only the user and administrators (members of System Administrator or
Directory Administrator role) have access to. It is linked to a user based on CAMID.
If the CAMID is changed, access to this folder will not work any more and thus
accesses to all objects saved to it are going to be “lost” as well.
The content which was secured against some CAMID will not get deleted from
Content Store instantly though. The data physically stays in until a Content Manager
Maintenance task of type “Consistency check” is run. There are two types of
Consistency check tasks though. While the check of “internal references” will solely
affect Content Manager database schema structures the second one checking
“References to external Namespaces” which will purge all user profile data including
MyFolder content in the Content Stored data base for all users which cannot be
located in the external authentication source any longer. This “Namespace Check”
however does not purge any objects referencing the profile like groups/roles or
capabilities referring to the user, those will contain invalid references which have to
be removed manually. This poses some opportunity though to restore access to
some content which is not accessible any more.
At this point it’s comprehendible that all precautions and measures must be taken to
avoid changing CAMID. There are some well know scenarios in which CAMID will
change though.
The Security and Administration Guide (part of the IBM Cognos8 product
documentation) states, that CAMID is going to change when a user gets deleted and
re-created afterwards with the same name in Series7 and NTLM authentication
sources.
This stems from the fact, that in both authentication sources the ID part of the
CAMID is some internal ID of those systems which is unique. Each user in a Series7
namespace will always have a unique “authid”, same applies to NTLM as every user
account in Windows always will have a unique “SID”.
Finally it has to be pointed out though, that in some setups it’s not possible to
guarantee this or sometimes not even desired. Depending on the scenario it’s
foreseeable that CAMIDs will change when moving from TEST to PROD for example.
For those setups the security Best Practice as stated in the Security and
Administration Guide of the product documentation offers some elegant solution.
To recall, the Best Practice describes that all authorization should be defined using
Objects from the Cognos Namespace only. That means that to secure some folder,
capability or package one should assign groups and roles from defined in the Cognos
Namespace only. External security objects like Users, groups and roles get assigned
to the Cognos Namespace groups and roles.
This will guarantee that those permissions can be deployed to any Cognos 8 setup as
this will make authorization independent from the configured authentication sources.
But there’s more to be aware of. Below are explanations by authentication provider.
Handling Change to IBM Cognos 8 security
11
3.1 Cognos
Though it may seem strange that the Cognos Namespace is listed here there is one
very important thing to be aware of. As for LDAP when using DN, the CAMID of an
entry in the Cognos Namespace is derived from a path in a hierarchical structure.
The CAMID for elements of the Cognos Namespace is basically the CM search path
(an XPath expression). Hence objects in the Cognos Namespace must not be
moved around once they have been created; otherwise this will impact their
CAMID. As a result permissions granted based off this object may not work as
intended any more.
Example: A role “MyRole” has been created in the root of the Cognos namespace.
Users from external namespaces have been assigned to this role following the
security best practice. Consequently this role has been added to the Directory
Administrator role. At some point MyRole (CAMID=”:MyRole”) is moved to a folder
“custom roles” which exists at the root level in the Cognos Namespace. This will lead
to all members of MyRole not having Directory Administrator access any more
because the MyRole CAMID changed to “:custom roles:MyRole”.
Best Practice for custom objects in Cognos Namespace hence is to carefully plan the
structure before implementing it. If structural changes are required, define new
objects in the new location instead, don’t move objects! (Enhancement 573422).
3.2 LDAP
For LDAP the “unique identifier” setting determines what the ID part will look like.
This setting will specify an attribute of a user entry in the LDAP to use for what
internally is called the “CAMID-attribute”.
If this is set to “DN” the ID part of CAMID will be the absolute DN of a user. This is
the default setting for the LDAP provider. Using DN for CAMID is ambivalent though.
On one hand using DN allows re-creating a user deleted by accident and restoring
access to the user’s data and MyFolder automatically. On the other hand, the fact
that the same DN is sufficient to have the user linked to Cognos application content
bears the risk of identity fraud. If an employee of the same name and hence the
same DN gets created in the LDAP while Cognos Content Store still contains objects
from the former executive of the same name, then the clerk may get access to
sensitive data if no adequate process is in place to prevent this from happening.
However, DN will work with every LDAP and hence is the default. Finally, the use of
DN will allow for simple deployment from one environment to another if same LDAP
or an LDAP with the same schema will be used, independent of the LDAP server
type/brand.
Using some CAMID-attribute other than DN provides some advantages and drawbacks as well. Some (SunONE, Active Directory, Novell) but not all LDAP servers use
some operational attribute which contains a globally unique value to uniquely identify
each entry. This attribute allows for most efficient indexing and is an ideal candidate
for CAMID-attribute. The authentication performance will benefit from this approach
as well, as instead of decomposing and analyzing the DN a single attribute can be
used to lookup entries. The draw-back of not using DN though is, that no entry will
ever have the same CAMID and hence simply re-creating a user which was deleted
by accident won’t help fixing this. This however is a plus in security but it will make
migrations from one environment to another more challenging as well because it
requires using the same LDAP in source and destination. If one followed the best
practice of implementing security though, this is trivial to solve.
Handling Change to IBM Cognos 8 security
12
Just to recall, the Best practice is to define authorization based on roles/groups
contained in the Cognos namespace only. User will only get assigned to Cognos
namespace roles/groups, never directly to an object. With this approach deployment
content is independent from the defined authentication source, as the Cognos
namespace is part of the deployment and hence in the target environment all that
needs to be re-adjusted is the assignment of users to Cognos namespace roles and
groups if the authentication sources are different.
As a best practice when using LDAP authentication sources, follow the security best
practice and configure some unique attribute other than DN for optimal performance
in production environments.
3.3 Series 7
The Series7 authentication provider uses some special private attribute of a Series7
user the “authID” for CAMID. This is not configurable. Even with schema version
17.0 which introduced external user support the CAMID is still derived from the
“authID” as documented in Table 1. CAMID details. The “authID” is uniquely
generated for every user in S7 and is never the same for any two users. This implies,
that as documented in the Security and Administration guide, re-creating a user will
lead to a different authID for that user and consequently to a different CAMID. This
again implies to deploy the S7 namespace together with the IBM Cognos 8
application content when migrating from one environment to another. Fortunately
the Series7 Access Manager offers the functionality of the LAE export to facilitate
this. Make sure you overwrite the target namespace (“empty target namespace”)
contents instead of merging; otherwise the authIDs of users won’t get changed.
Besides from the deleting a user no other change applied to Series7 users will affect
the authID and such the CAMID. Moving users in the structure, adding or removing
userclass memberships and or signons won’t have any negative impact.
There was a software issue in the Series7 migration tools for IBM Cognos 8 prior to
versions 8.3 which led to authID being calculated wrong in some cases. This might
cause issues if content has been migrated to IBM Cognos 8 from Series7 with older
versions of IBM Cognos 8. Simply make sure you use a recent version of IBM Cognos
8 (8.3+) when dealing with migrated Series7 content.
As a best practice, always deploy LAE files along with application content when
moving from one environment to another.
3.4 Active Directory
The Active Directory authentication provider as of IBM Cognos 8.2 uses the Active
Directory GUID (Globally unique identifiers). The GUID is a 128-bit number which is
unique within a single forest. According to Microsoft the GUID never changes even
though the DN or RDN of an entry may. It is assigned to an object at creation time
only. Earlier versions of IBM Cognos 8 (pre 8.2) used the Windows NTLM SID which
was Windows’s predecessor to the GUID up to Windows NT.
The change to GUID in 8.2 (539568) led to issues when migrating content from 8.1
to 8.2+ versions. In addition the SID may not be stable depending on the actions
applied to a user in Active Directory. Fortunately the GUID will be stable for almost
all changes happening in Active Directory, however exceptions apply. Moving a user
Handling Change to IBM Cognos 8 security
13
across Forests will lead to a different GUID. Same applies to deleting and re-creating
a user in Active Directory.
The use of GUID is not configurable nor can any changes be applied to the
authentication provider to influence the handling.
The bigger challenge with Active Directory Namespaces is in regards to Trusted
Credentials, refer to next section.
As a best practice avoid cross forest configurations and deleting users in AD before
their IBM Cognos application content is properly backed up.
3.5 NTLM
The NTLM authentication provider should be phased out by now or will shortly as
Microsoft has announced end of life for Windows NT and Windows 2000. The
provider uses the NTLM SID to construct the CAMID. This implies that all changes
within an NTLM domain don’t affect the SID.
Again there aren’t any configuration items or settings to influence the provider’s
handling of the CAMID.
Best Practice is to refrain from leaving this provider except for single server test
systems where access is by local users only. The reasons given above should be
sufficient to not use it in production any more. So far no operation is known which
would change the SID except of course deletion and re-creation of the user, similar
as for Active Directory.
3.6 SAP
The SAP provider will use the SAP user ID to construct CAMID. This poses the same
challenges as for LDAP using DN. There are no two users with the same UserID at
the same time, however, if user “X” gets deleted and re-created later, for Cognos
those two users will be “identical”.
There is no configuration item or setting to influence the creation of CAMID so the
best practice for SAP is to establish a proper process in case users get deleted from
SAP and hence their Cognos content should be wiped as well or moved to a safe
spot.
4 Changes which affect Trusted Credentials (TCs)
The most common reason for TCs to become invalid is the expiry or change of
passwords such that the password stored in the credential is not valid any longer
when presented to the authentication source by the provider. The need to change
passwords is imposed by the underlying authentication source only, TCs don’t expire
for Cognos.
Another possible destructive change to TCs is when REMOTE_USER based TCs are
saved and a user now achieves SSO by some different value of REMOTE_USER, for
example because a new OS-Signon has been added to a Series7 user.
As mentioned in the first part of this document, Trusted Credentials get stored in a
user’s profile. Since that profile’s primary key is the CAMID it evolves that any
Handling Change to IBM Cognos 8 security
14
invalidation of the CAMID will automatically lead to loosing access to the user’s
profile as well.
All of the mentioned changes must be addressed by renewing credentials as outlined
in the next section.
One particular special change which is mistakenly mentioned to invalidate Trusted
Credentials though is environmental. The Trusted Credentials are stored encrypted.
The key used to encrypt them is generated when starting up Content Manager and is
used throughout the IBM Cognos 8 System. This key is called CSK and is stored in
Content Store. It has been mentioned to some that if a new instance of the CSK is
created because of a change of JRE used to run Cognos this would render TCs
invalid. This is not correct.
If the CSK used to crypt the Trusted Credential is lost the credential cannot be
decrypted any longer. However, Content Store will keep historic instances of CSKs
and such be able to decrypt TCs. The key can only get lost through malfunction or
re-creation of Content Store DB which implies all content is lost anyway. A full
Content Store export will contain CSKs so the deployment will work as well.
5 Reactive Solution Best Practices
5.1 User has been deleted from the authentication source
If for some reason a user has been deleted from an authentication source before his
Cognos application contents have been saved or backed up those contents will be
inaccessible. Since the user has been deleted from the namespace there’s no way to
get to his profile through the UI, not even for an administrator. The deletion will
affect MyFolder, Schedules and Reports this user has saved and Trusted Credentials
this user has granted. Finally permissions assigned to this user will refer to nowhere.
Trusted Credentials
Trusted Credentials are saved as part of the account object (“profile”) and hence will
get removed along with the account object when a Content Maintenance task of type
Namespace check is run in “Find and Fix” mode. The trusted credentials are invalid
anyway because the user has been deleted from the authentication source.
Schedules
It’s very easy to find the orphaned schedules of a user. Simply go to Cognos
Administration -> Status Tab -> Schedules option in the left hand side menu. All
Schedules with a value of “Unavailable” or some system date in the “Scheduled by”
column are orphaned and can be removed or disabled at least.
There is a technote providing an SDK to automate this task
Technote 1346334 – retrieve list of scheduled jobs
MyFolder
The most comfortable way to rescue the MyFolder contents of that deleted user is by
leveraging the Cognos SDK. The following Technotes describe ways to re-gain the
objects. Please note, that those Technotes contain sample code only which is not
supported but can be used to create own programs which suite the needs of the
environment.
Handling Change to IBM Cognos 8 security
15
Technote 1340789 - Recover MyFolder from a deleted user
Technote 1344373 - SDK to copy reports between MyFolders
If you don’t have the SDK available to you and the authentication source backup is
misplaced, there is a manual way of restoring the MyFolder Contents.
Run a Content Manager Maintenance Task which checks the namespace in question,
from which the user was deleted..
When prompted for run options choose “Find only”, don’t FIX anything as this will
remove the user object and the MyFolders
Once the task has been run display the outcome by going to the task’s “more…” ->
View Run History option. From the most recent run click “View run history details”
and find the CAMID of the deleted users.
Handling Change to IBM Cognos 8 security
16
Log in to Cognos Connection and create a backup folder at the root of Public Folders
which shall take on the contents of the MyFolders. Once created view the properties
of that folder and obtain it’s search path
Access <GW_host>:<GW_port>/<alias>/cm_tester.htm
This will bring up some Java Script controlled page which can be used to send
commands to Content Manager.
Press “Options”
In the upcoming dialog specify your Content Manager URI and press “Test…” to
verify it’s working. You will see the Content Manager status page if the connection
can be established fine.
Handling Change to IBM Cognos 8 security
17
Press “Close” to exit this dialogue.
If you followed the steps in the correct order you will already have been logged on to
Cognos and hence will have a CAM_PASSPORT cookie in your browser session. This
will be reflected in cm_tester as well.
If not follow these steps to authenticate.
Press “Log On…” in the upper left
In the upcoming dialog specify namespaceID and credentials of a member of the
System Administrator Role. Press “Log On” to authenticate to Cognos and see a
passportID appearing in screen like shown above.
Continue with issuing a copy operation like this
From the “choose a request template” drop-down select “copy”
Press “Send” now
Prompts will appear which prompt for PATH and TARGET_PATH.
For PATH enter the Search path deducted from the Maintenance Task output and
append /folder[@name='MyFolders'] to it.
Example: CAMID(“openldap:u:cn=user2,ou=people”)/folder[@name=’MyFolders’]
For TARGET_PATH enter the search path of the newly created backup folder.
Wait for the command to complete, once completed some content will be displayed
in the lower frame.
All objects from the user’s MyFolder will now have been copied to the backup folder.
Reports
Reports which have been saved by a user now deleted will continue to work,
however if they have been set to “run as owner” the results may be off. To fix this
those reports some other account has to take ownership of them. This can be done
either manually by going through all those reports as an administrator or by
leveraging the SDK. The required information is a list of such “orphaned” reports.
Handling Change to IBM Cognos 8 security
18
Technote 1338358 - Find orphaned reports and re-assign to owner
The same can be done with the CM_Tester.htm page again. Assuming a content
Maintenance task of type Namespace check has been run previously the following
steps will provide a list of all reports which have no owner.
Choose the “query” template from the template dropdown and provide the following
values when prompted:
PATH (Searchpath) = //report[not(@owner)]
PROPERTY1 (attribute to find) = defaultName
PROPERTY2 (attribute to find) = searchPath
SORT_BY (sorting results by) = defaultName
In the lower pane find the list of reports with no owner set.
5.2 User’s CAMID has changed
When a user’s CAMID changes this really is similar to a user being deleted with the
exception of the user logon maybe still intact.
For example, while the name of an LDAP user changed which is reflected by his DN
his uid attribute may still remain unchanged. Thus his logon which refers to the uid
attribute will continue to work and he can still logon with the same credentials.
The impact to Cognos will be that MyFolder will get unreachable and Schedules and
Reports will loose their owner because his CAMID changed. However the Trusted
Credentials may stay intact and the user object will remain in the Content Store until
it’s wiped through a Content Maintenance task of type Namespace check. Effectively
Schedules using the TCs will continue to run and hence this inconsistency may go
unnoticed until a content Namespace check type Content Maintenance task is run.
Since in this scenario the user who’s CAMID changed still does exist in the external
namespace there is a simple GUI based way to copy his profile and/or MyFolder
contents to another existing account.
Simply have a member of the Directory Administrators or System Administrators Role
log in to the namespace the moved user is from. In addition the Admin will have to
log in to the namespace which contains the user to which the contents shall be
copied to.
Then have the Admin navigate to the unreachable account in the source namespace
and click on “More..” next to the account.
Now select Copy the user’s profile…
Handling Change to IBM Cognos 8 security
19
In the upcoming dialog the Admin can chose which contents of the user’s profile he
would like to copy, specify the target account and whether the source user profile
should be wiped after the copy is complete.
As this is a manual process it’s not feasible for bulk processing, if required refer to
the steps given for rectifying a deleted user to get an idea about how this can be
automated through the use of the SDK or cm_tester.
5.3 Renewing Trusted Credentials
Whenever Trusted Credentials (TCs) become invalid they must be renewed.
Opposed to generating Trusted Credentials initially, renewing credentials only works
explicitly. Explicitly renewing credentials is when the user who saved a schedule
issues the Renew credentials operation on it or if the user goes to the Personal tab in
MyPreferences and renews the credentials there.
From the above it evolves that Trusted Credentials can only be renewed by the user
himself from inside an authenticated session for which he has provided applicable
credentials (refer “Trusted Credentials”). This is in particular true as IBM Cognos8
doesn’t know a “role” model such that an administrator can impersonate a user
session.
The fact that only a user himself can renew credentials poses a challenge to
administrators in regards to operating the system.
Expired TCs can be monitored through auditing/server log and schedule execution
Handling Change to IBM Cognos 8 security
20
history only, but only after the fact, e.g. the credential is already expired. However
administrators are prevented from acting on those errors applying a
controlled/enforced process. They rather have to rely on users to remedy in an
uncontrolled informal process. Best case users react to failed schedules themselves
but often they don’t have access to the execution history to learn about the root
cause of schedule failure. Worst case is though, that schedules fail due to invalid
credentials and the user is not available to renew his TCs which will lead to a “stuck
credential”.
For ideas on preventing stuck credentials, refer to “Pro-Activly handling changes”.
Reacting to stuck credentials is cumbersome. The obvious solution is to ask a user to
log in and renew his credentials. This may or may not be an applicable solution
based on circumstances outside of the Cognos product realm.
Another approach is to ask the user to disclose his username/password to
administrators so that they may act on his behalf. This however may incur severe
legal concerns in several countries.
A third option, which is actually the best practice so far, is to use dedicated service
accounts to run non-bursted schedules. Those accounts would be managed by
administrators and everyone is granted access to their adjected trusted credentials.
If those expire administrators can simply renew the credentials or pro-actively
manage the expiry anyway.
The process of renewing Trusted Credentials can only be automated through the use
of SDK and only if the credentials required to authenticate as that user are know to
the program. The challenge is extended by fact that when renewing credentials the
user should be logged on to all namespaces he was logged on when he created the
TCs initially. If he’s not, the set of credentials will not be identical to the original one
and may accidentally overwrite credentials still valid from another namespace.
Effectively not only credentials for a single namespace may be required but possibly
to all namespaces configured for a system. (Refer to “Trusted Credentials” for
details).
Assuming all the required credentials are available renewing Trusted Credentials for
a single user can be implemented as described by
Technote 1344318 – How to generate/renew trusted Credentials
The potential for improvement in this context is acknowledged by Product
Management and they are looking at improving this in a future release.
For now the best practice to react to expired Trusted Credentials is to raise
awareness with users and ask them to renew them according to their password
expiry in the underlying authentication source. Administrators should pay close
attention to the cogserver.log at BASIC audit level and scan for invalid credential
errors (CAM-ERR-0036) when running schedules. The approaches to pro-actively
address this challenge should be looked into and applied where possible.
The author is aware of “solutions” where SDK programs verify the saved credentials
still being valid regularly and reporting expired credentials in one or another way.
This is possible because the SDK can validate a credential without knowing its
contents. While these approaches address the lack of monitoring they do not change
a thing about the requirement to act and renew the credentials by providing
sufficient authentication information.
Handling Change to IBM Cognos 8 security
21
6 Pro-Actively handling change – Best Practices
6.1 Remove users
When looking to remove users from the underlying authentication source IBM
Cognos is configured for follow these steps:
- Backup the Content Store by Data Base backup or full deployment
OR
- Move user’s contents to a safe spot in the Public Folders hierarchy. It’s a good
practice to create some folders, to which only Administrators have access and which
are otherwise hidden (using authorization) from other users.
- Disable/delete/reassign all Schedules saved by the user. Go to Cognos
Administration -> Status -> Schedules and find the schedules for the user in
question.
- Delete the user in the authentication source
- Run a Content Maintenance task of type Namespace check in “find & fix” mode
6.2 Handling CAMID change (user move or transfer)
Moving a user deliberately is equivalent to deleting a user and transferring the user’s
application content to a new/different user account. The assumption here is that the
“move” changes the CAMID! The steps therefore are
- Backup the Content Store by Data Base backup or full deployment, simply to have
a fall back.
- Move user’s contents to a safe spot in the Public Folders hierarchy. It’s a good
practice to create some folders, to which only Administrators have access and which
are otherwise hidden (using authorization) from other users.
- Reassign all Schedules saved by the user to some special user. Go to Cognos
Administration -> Status -> Schedules and find the schedules for the user in
question.
- Delete the user in the authentication source
- Run a Content Maintenance task of type Namespace check in “find & fix” mode
- Create the new user
- Create the user’s account object
- Either have the user log in or have a member of the Directory Manager or System
Administrator role browse the namespace for the user and issue the “create profile”
action for that user.
- Copy back the saved application contents to the new users’ MyFolder as required
and re-assign the schedules to the new user.
6.3 Prevent stuck credentials
To prevent stuck credentials (expired trusted credentials which cannot be renewed
due to the user not being able to renew them) there are limited options depending
on the authentication source, the environment and the use case.
The authentication source may impose restrictions like no additional user accounts
permitted, password expiry or company policies. The environment may dictate SSO
only so that no applicable credentials are available to IBM Cognos to form a Trusted
Handling Change to IBM Cognos 8 security
22
Credential. Some use cases even may require the users to run the reports in their
context.
A good approach is to create some dedicated schedule account(s) in the
authentication source. Those accounts would be managed by Administrators only
and every user is granted access to the Trusted Credentials of those accounts. That
way all schedules get run by only a defined set of accounts and the credentials can
be renewed any time.
A second approach is less controllable but rather asks for user’s cooperation by
reminding them to renew their credentials periodically. Through training and
announcements by email or websites users have to be educated about the
backgrounds and asked to follow a certain practice.
Finally Administrators should pay close attention to the cognos.log at BASIC audit
level and scan for invalid credential errors (CAM-AAA-0036) when running schedules.
In addition running content Maintenance tasks of type Namespace check in find
mode regularly will help maintain CS integrity.
7 Resources
Background on formats of Active Directory GUID “Bind version of GUID/GUID info”.
IBM Cognos 8 , “Security and Administration Guide”, chapter 12
Credential FAQ – Technote #1335738