Download as pdf or txt
Download as pdf or txt
You are on page 1of 14

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 .

IBM Cognos Proprietary Information


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

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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!!!

IBM Cognos Proprietary Information


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

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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.

IBM Cognos Proprietary Information


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

IBM Cognos Proprietary Information

You might also like