Troubleshooting Active Directory Server

Proven Practice Troubleshooting Active Directory Server Product(s): IBM Cognos Series 7 Area of Interest: Security

Troubleshooting Active Directory Server 2 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 cscogpp@ca.ibm.com.

Troubleshooting Active Directory Server 3 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 LAE FILE... 10 2.7 UPGRADING FROM AD 2000 TO 2003... 11 2.8 EXTENDING SCHEMA IN AD 2003... 12 2.9 MANUALLY CREATING IBM COGNOS NAMESPACE... 12 2.10 READ ONLY SCHEMAS... 13 2.11 OTHER TROUBLESHOOTING TOOLS... 14

Troubleshooting Active Directory Server 4 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.

Troubleshooting Active Directory Server 5 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.

Troubleshooting Active Directory Server 6 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: regsvr32 schmmgmt.dll

Troubleshooting Active Directory Server 7 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.

Troubleshooting Active Directory Server 8 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.

Troubleshooting Active Directory Server 9 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!!!

Troubleshooting Active Directory Server 10 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 - Then, type "q", you should return to the "ldap policy" command prompt

Troubleshooting Active Directory Server 11 - 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 Note: this utility must be run against the directory server schema master.

Troubleshooting Active Directory Server 12 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 the password in plain text, it will need to be set using the Access Manager Administration interface. Simply add a connection to the directory server, click on the Runtime Credentials tab and fill in the password.

Troubleshooting Active Directory Server 13 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 schema as per section 2.4.

Troubleshooting Active Directory Server 14 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 LDAP://machine_name/ and this becomes the suffix for your base DN. O=Cognos, OU=Applications,DC=SUPPORT,DC=COM