Troubleshooting Active Directory
Troubleshooting Active Directory
Troubleshooting Active Directory
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 .
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
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.
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.
‘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)
‘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’
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
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.
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.
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.
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:
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:
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:
Keep in mind that this will make global changes to Active Directory
and will not be limited to our schema.
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
Note: this utility must be run against the directory server schema master.
2. Import the ldif into the directory server using ldifde (i.e. "ldifde -i -f
c:\AccessMgrInit.ldif")
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.
LDAP://ads.SUPPORT.COM/OU=Applications,DC=SUPPORT,DC=COM
O=Cognos, OU=Applications,DC=SUPPORT,DC=COM