Proven Practice
Troubleshooting Active Directory
Server
IBM Cognos Proprietary Information
Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. 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. Cognos does not accept
responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are
trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to
IBM Cognos Proprietary Information Contents 1 INTRODUCTION ... 4 1.1 PURPOSE...4 1.2 APPLICABILITY...4 2 TROUBLESHOOTING ... 4 2.1 ACCOUNT CHANGES...4
2.2 USERS NOT IN THE USERS FOLDER...5
2.3 INVALID CREDENTIALS...6
2.4 SCHEMA OWNERSHIP...6
2.5 PARENT –CHILD DOMAINS...9
2.6 UNABLE TO EXPORT LAEFILE... 10
2.7 UPGRADING FROM AD2000 TO 2003... 11
2.8 EXTENDING SCHEMA IN AD2003... 12
2.9 MANUALLY CREATING IBMCOGNOS NAMESPACE... 12
2.10 READ ONLY SCHEMAS... 13
1
Introduction
1.1 Purpose
Some additional troubleshooting techniques may need to be used to successfully configure the Active Directory Schema. This document is an ongoing list of solutions to hurdles that have surfaced while trying to extend the IBM Cognos schema or general maintenance after the successful creation of the IBM Cognos namespace.
1.2 Applicability
Because Active Directory can be used to house the IBM Cognos schema and namespace with both UNIX and Windows, this document is not operating system specific.
2
Troubleshooting
2.1 Account Changes
In an ideal environment, the password of the user account used to extend the Active Directory schema would never change. In reality, this is not feasible s passwords change on a fairly regular basis. When the password changes for the user account that was used to create the schema, Access Manager is unable to communicate with ADS. One symptom is the following error in Access Manager being returned when opening up the GUI.
There are two possible solutions to this error message; one being the
password gets changed back to the original value. Or you can reconfigure the ADS schema and namespace through Configuration Manager, using the new credentials. This second step would probably be the best option, as this would permit the password change.
Recommendation: It would be ideal if an IBM Cognos user account was created with Schema Admin rights, with a password that is set to never expire. This would eliminate the need to have to reconfigure the IBM Cognos schema and namespace.
2.2 Users Not in the Users Folder
In some situations, like the recommendation made in section 2.1, the user that is used to configure the IBM Cognos schema will not be located in the Users folder inside of the Active Directory Users and Computers interface. In these cases, the standard cn=Adminstrator,cn=Users,dc=Support,dc=Com for the Unrestricted User distinguished name (DN) entry, will not work. The reason being is that the second cn entry indicates where to find the user reference. In this case it is the Users folder.
If you have users in a different folder, say the Builtin folder, the proper syntax would have to be modified to be
cn=Adminstrator,cn=Builtin,dc=Support,dc=Com. In cases where
Organizational Unit folders have been created, the DN entry will have to be modified accordingly. The following screen cap shows an ADS instance where a user was created in a multi tiered Organization Unit structure.
A CognosAdmin user account was created under the Sales Organization Unit, which is located under the Company Organization Unit. When entering the DN information, the above scenario will translate to:
cn=CognosAdmin,ou=Sales,ou=Company,dc=support,dc=com
Notice that there is a new addition to the entry due to the fact that the CognosAdmin user exists in a sub folder. Also to note, the cn entries have been modified to ou because the folders that the user exists are actually Organizational Units. These ou entries are also entered in a ‘bottom-up’ type fashion. If there were more than just the one level of sub folders, then there would have to be a corresponding amount of ou entries. Remember to start at the immediate sub folder that houses the administrative user and work your way up through the hierarchy until you reach the Organization Unit folder located under the root.
IBM Cognos Proprietary Information
2.3 Invalid Credentials
When trying to extend the schema using Configuration Manager, the following error is returned:
‘We were not able to connect to your Directory Server. Are your host name and port correct? Details: Invalid credentials”
If this error occurs and you are using a user that is NOT the Administrator user but does have administrative privileges, check the user account by viewing the user properties in the AD Users and Computers console. Make sure that the Unrestricted User distinguished name (DN) entry refers to the account name and NOT the user sign-on. For example, a user CognosAdmin (see screen capture in section 2.2) has a user sign-on of cognos. Using this string as the Unrestricted User distinguished name (DN)
cn=cognos, cn=users, dc=domain, dc=com will fail. But using this value should work.
cn=cognosadmin, cn=users, dc=domain, dc=com
2.4 Schema Ownership
The issue occurs when trying to configure the IBM Cognos schema from inside of the Configuration Manager tool. An error is returned and reads: ‘We were not able to write to the directory server. It could be down. Please refer to the install guide for more information. Details: ldap_modify_s: Insufficient access while adding attribute authacceptedsignons’
Similar messages indicate that sufficient rights to connect to Active Directory and read the schema have been provided, but not enough permission to extend the schema and create objects and attributes. If the Configuring Microsoft Active Directory 2003 or Configuring Microsoft Active Directory
documents were followed, the user credentials being provided were probably examined to determine whether the account was part of the Schema Admin group, which probably proved to be true.
The root of this issue can actually be found nested under a couple of dialog boxes. Before troubleshooting this issue, the correct snap-in must be enabled by executing the following command from the Start/Run command line:
Following the initialization of the snap-in, the Active Directory Schema snap-in must be added to the Server Extensions Administrator, which is located under Start/Programs/Administrative Tools or can be launched by going to
Start/Run and enter mmc /a to open the console.
From the Console menu option, select Add/Remove Snap-in …
Select the Add button.
Select Active Directory Schema from the list and press the Add button. Then Close and OK.
Once the snap-in has been added to the console, the ‘Active Directory Schema’ entry will be visible that allows the classes, permissions and attributes of the schema to be viewed.
Right clicking on ‘Active Directory Schema’ and selecting ‘Permissions…’, will allow to verify the schema owner. To get to the correct sub menu, select ‘Advanced…’ from the ‘Permissions for Schema’ dialog box, and then the ‘Owner’ tab.
The resulting dialog box should look like this,
where the current owner of the schema will be visible. In the screen capture above, the Schema Admins group is the owner of the schema. If this is anything different that Schema Admins, verify that the user credentials that are being used to configure the Cognos instance within the ADS schema, is a member of that group. This should bypass this version of the ldap_modify_s error message.
2.5 Parent – Child Domains
To successfully extend the IBM Cognos schema, the Active Directory Server that will house the schema MUST be the ‘Operations Master’. To verify which server is the current Operations Master, follow the steps in the previous section to add the ‘Active Directory Schema’ snap-in to the mmc console. Once added, right click on ‘Active Directory Schema’ and select ‘Operations Master’. This will produce the following dialog box.
There are three things to check when viewing this dialog box.
1- Is the Current Operations Master the server where you want the Cognos schema?
2- Is the server online?
3- Is the check box ‘The Schema may be modified on this Domain Controller’ selected?
The answer to all three of these questions should be yes!!!
IBM Cognos Proprietary Information If the Current Operations Master is NOT the desired server that will contain the IBM Cognos schema, one of two options will have to be taken:
Extend the schema on the Operations Master.
Temporarily promote the desired server to Operations Master. After the schema has been extended, you can promote the original server back to Operations Master. For more information on how to do this, you can consult the Microsoft document Q255690 - Title: "How to View and Transfer
FSMO Roles in the Graphical User Interface".
2.6 Unable to Export LAE File
PLEASE NOTE: The following steps should only be performed if the error
messages listed below is being encountered when exporting the LAE file AND you are working with a fairly large user base.
When trying to export to lae file using IBM Cognos Series 7 Access Manager, the following error message is returned:
'An internal error has occurred in Access Manager'.
When using the Access Manager version from 6.61, the error returned is: 'Service Failure'.
The reason for this error is that the number of items returned in a search is set to 850 by default in Active Directory. This differs from Netscape Directory Server where the default is 2000. To resolve this issue:
- Click on Start and click on Run. - In the Open text box, type "ntdsutil" - On the command line, type "ldap policies" - Then, type "connections"
- Then, type "connect to server <dns of your server, i.e. machinename.yourcompany.com>"
Example: connect to server servername.domain.com
IBM Cognos Proprietary Information - Then, type "set maxpagesize to <x>", where x is the greatest number between the maximum number of children user classes that a particular user class can have, the maximum number of users belonging to a particular user class, or the maximum number of users in a folder - The NDS default is 2000 and would be a good place to start.
- Then, type "commit changes"
- To see that the value has been changed, type "show values" - notice that the maxpagesize property is set to <x>
- Then, type "q" to quit.
Keep in mind that this will make global changes to Active Directory and will not be limited to our schema.
2.7 Upgrading From AD 2000 to 2003
Customers who currently have Microsoft Active Directory on Windows 2000 configured for use with IBM Cognos Applications will encounter errors when attempting to upgrade Active Directory for Windows 2003.
The following errors will be reported when trying to perform the "adprep /forestprep" command as part of the upgrade process from Windows 2000 to Windows 2003:
Entry DN:
CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=accmandev,DC=cognos,DC=c og
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in may-contain does not exist."
An error has occurred in the program
Before upgrading Active Directory for Windows 2003, run the following utility to modify the IBM Cognos schema and data in preparation for the Windows 2003 upgrade:
Ads_update.exe
This utility is located in the ...\cerx\bin directory as well as on the cd in :\Support Files\Microsoft
To get a full list of parameters for this utility run: ads_update –h
IBM Cognos Proprietary Information
2.8 Extending Schema in AD 2003
Before configuring your Microsoft Active Directory server for use with IBM Cognos products on Windows 2003, a modification must be made to Active Directory in order to allow anonymous access to the directory server. This was the default behaviour for Windows 2000.
For more information, refer to the Microsoft support website and search for the knowledge base article 326690 entitled "Anonymous LDAP Operations to Active Directory Are Disabled on Windows Server 2003 Domain Controllers". Also, please refer to the Configuring Microsoft Active Directory 2003
document.
2.9 Manually Creating IBM Cognos Namespace
In some rare cases, it may be necessary to extend the schema manually. The following steps will only work if the objects and attributes have previously been created and are part of the Active Directory schema.
1. Modify the AccessMgrInit7_*.ldif file found in the cer*/accman directory to reflect these changes:
a. Change the base DN from "o=Cognos, c=CA" to the appropriate base DN (do a search and replace because there is more than one place to change).
b. Ensure that you change the base DN in the line that starts with "authConfigurationItem: ds_userRootDN="
c. In the first entry, modify the line that starts with “o: Cognos“. You need to change Cognos to whatever name that you will be using as your BaseDN. For example, if your base DN is "o=MyCompany, dc=<domain>", the line should read "o: MyCompany". If your base DN is "ou=MyCompany, dc=<domain>", you should change this line to "ou: MyCompany" and the objectclass line that says organization to organizationalunit
d. Remove the lines that start with aci, modifiersname, and modifytimestamp.
e. Change the following lines to the appropriate values. For the password, enter it in plain text and it will be encrypted in the directory server the first time it's read:
i. authConfigurationItem: ds_administratorDN=<administrator DN>
ii. authConfigurationItem:
ds_administratorPassword=<administrator password> Note: If the password is left blank instead of putting
IBM Cognos Proprietary Information 2. Import the ldif into the directory server using ldifde (i.e. "ldifde -i -f
c:\AccessMgrInit.ldif")
3. Change the security permissions to allow anonymous read on the base DN (i.e. MyCompany), Authentication Data, and GlobalDirectory Data folders. You can do this by using the Active Directory Users and Computers utility. On the three folders, you will need to go to the security tab in the properties sheet (if you don't have a security tab, you need to set the view to "Advanced Features" from the folder's right-click menu). Give read permission to the group Everyone (if the group is not there, you will have to add it).
4. Using Access Manager Administration perform the following steps: a. add a connection to the directory server
b. click on test
c. if it says that the directory server is not responding, click on the runtime credentials tab
d. enter the bind credentials and click ok e. re-enter the bind credentials in the fields f. click on test to make sure that they are valid g. click on apply then ok
h. create a namespace (the default value assumed by the installation is "default")
2.10 Read Only Schemas
In some cases, errors may be encountered when trying to extend the schema that state that the schema has been set to read only. This option prevents the creation of any new attributes and/or objects. To verify that the schema has been set to read only, verify the settings of the following registry key. Hive: HKEY_LOCAL_MACHINE
Key: System\CurrentControlSet\Services\NTDS\Parameters Name: Schema Update Allowed
Type: REG_DWORD
If the value is 0 for ‘Schema Update Allowed’ then the schema is set to read only. Set the value to 1 to allow write access to the schema. To modify the schema, you must be logged on to the operating system as a member of the Schema Administrators group, or a member of whichever group owns the
IBM Cognos Proprietary Information
2.11 Other Troubleshooting Tools
ADSI Edit – This tool is available after installing the Windows 2000 Server
Support Tools, and is valuable for extracting the correct entry when trying to determine what the base DN is going to be. For example, assume that the folder called ‘Applications’ was to be the location for the IBM Cognos
namespace. In ADSI Edit, right click on the OU=Applications entry in the list, and select Properties, the path for this entry would be visible as:
LDAP://ads.SUPPORT.COM/OU=Applications,DC=SUPPORT,DC=COM
To determine the correct base DN take everything after the
