Product:
Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
Problem:
In a Active Directory Domain and Forrest, when we try to add AD groups to the internal Cognos groups in Cognos Connection – Administration – Security, we can not see all groups.
Solution:
AD Domain Local Groups can only be seen if they are in the same sub-domain as the Cognos Content Manager server. If the Cognos CM server is in a different domain than the DLGroup, it is not visible.
You should create a Cognos security group for your function, then to that Cognos group add AD groups from the different namespace you have created to allow users of different forest have access to the Cognos solution.
When you configure an authentication namespace for IBM® Cognos®, users from only one domain can log in. By using the Advanced properties for Active Directory Server, users from related (parent-child) domains and unrelated domain trees within the same forest can also log in. There is no cross-forest support; there must be a namespace for each forest.
If you set a parameter named chaseReferrals to true, users in the original authenticated domain and all child domains of the domain tree can log in to IBM Cognos. Users from a parent domain of the original authenticated domain or in a different domain tree cannot log in.
If you set a parameter named MultiDomainTrees to true, users in all domain trees in the forest can log in to IBM Cognos.
https://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_includedomainsusingadvancedproperties.html#IncludeDomainsUsingAdvancedProperties
If you specify Binding Credentials (i.e. if you fill in this section), then:
• (in some environments) it can lead to performance problems. This is because it causes Cognos to ‘unbind’ its original user and re-bind as the ‘specified’ user
• You must ensure that the password (of the user that you choose) does not change/expire
=> Therefore, only fill in the ‘Binding credentials’ section if your “test” (see later) fails. If authentication fails, specify a Windows user ID and password for the Binding credentials property.
• Use the credentials of a Windows user who has at least ‘search’ and ‘read’ privileges for that server.
• This should be a domain user who can ‘see’ the folders inside the AD where the users are located.
http://www-01.ibm.com/support/docview.wss?uid=swg21380097
In order to setup SSO in a multi-domain Active Directory environment, follow these steps:
1. Launch “Cognos Configuration”
2, Create a new namespace
3. Make sure that this is set to “Active Directory” (not LDAP)
4. Use the root domain as the hostname
5. Locate “Advanced properties” and click edit/modify button
6. Enable either ‘ChaseReferrals’ or ‘MultiDomainTrees’.
TIP:
- ChaseReferrals – This will allow users from ‘child’ domains (i.e. domains below the domain that your namespace is connected to) to logon
- This is often the best choice (for performance reasons).
- MultiDomainTrees – Allows users from ALL domains (inside the forest) to logon
- If you are unsure where your users will be located, ‘MultiDomainTrees’ can be the best option (to ensure that all users are able to logon, wherever they are located).
- However, this means that searches will traverse the entire forest, leading to performance slowdowns.
Once you have chosen, add one of the following entries:
- chaseReferrals: True
- multiDomainTrees: True
6. Decide on whether to use NTLM (“REMOTE_USER”) or KERBEROS authentication.
If you want to use NTLM/REMOTE_USER, then also add the following entry:
- singleSignOnOption: IdentityMapping
Do not use this entry if you want to use Kerberos (which is the preferred option for many environments).
7. Perform a test on this namespace to make sure a connection can be made
8. Restart the service
From the web:
– universal group membership is replicated to all Global Catalogs (i.e. it has forest-wide replication scope). This can be beneficial (since it provides efficient way to retrieve group members) – but has its drawbacks (it increases volume of replication traffic).
– domain local groups do not have any limitations regarding their membership – i.e. they can contain accounts the same domain/forest or any trusted domain/forest. This does not apply to domain global groups (they can contain only accounts from the same domain) or universal groups (they can contain only accounts from the same forest).
– universal group is a security or distribution group that contains users, groups, and computers from any domain in its forest as members. You can give universal security groups rights and permissions on resources in any domain in the forest.
– global group is a group that can be used in its own domain, in member servers and in workstations of the domain, and in trusting domains. In all those locations, you can give a global group rights and permissions and the global group can become a member of local groups. However, a global group can contain user accounts that are only from its own domain.
– domain local group is a security or distribution group that can contain universal groups, global groups, other domain local groups from its own domain, and accounts from any domain in the forest. You can give domain local security groups rights and permissions on resources that reside only in the same domain where the domain local group is located.
More information:
http://www-01.ibm.com/support/docview.wss?uid=swg21598533
