IBM Security Directory Server Fixes

SDS 8 appliance hungs with "press any key to continue"

Enable COM port in your virtual machine configuration

SDS Install manager gives GLPINS008E An error occurred while installing GSKIT package.

Likely your GSKIT rpms are already installed. If you did response recording they are installed, but your response file indicates that they are to be installed. Edit the response file and change key='user.use.existing.gskit,com.ibm.security.directoryserver.v64' to value='true'

SDS errors on db2 startup

Symptoms

LDAP is unavailable. When trying to start it with
/opt/IBM/ldap/V6.4/sbin/ibmslapd -I isimldap -n -t
you see
SQL1072C The request failed because the database manager resources are in an inconsistent state.
or
SQL1220N The database manager failed to allocate shared memory.

Fixing

First, stop ldap

/opt/IBM/ldap/V6.4/sbin/ibmslapd -I isimldap -k
/opt/IBM/ldap/V6.4/sbin/ibmdiradm -I isimldap -k

Make sure it is stopped
ps -ef | grep isimldap
If it did not kill it forcefully
pkill -9 ibmslapd
Switch to the DB2 user and check the shared memory

su - isimldap
db2stop
ipcs | grep isimldap

If there is anything shown, clean the memory
ipcrm -a
exit
start ldap back up

Additional troubleshooting:

try to start db2 as isimldap

su - isimldap
db2start

Kill all isimldap processes
pkill -9u isimldap

References


https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.messages.sql.doc/doc/msql01072c.html
http://www-01.ibm.com/support/docview.wss?uid=swg21968633
http://www-01.ibm.com/support/docview.wss?uid=swg21131509

LDAP is overloaded and requests are hung

Do the perftuning per IBM guides if you have not already, then try enabling selectivity on the underlying DB2.

Here is what it means: "You can improve the performance of subtree searches on search bases that are high in a directory tree by using SELECTIVITY in Structured Query Language (SQL). The inclusion of SELECTIVITY in SQL enables the DB2 optimizer in the formation of access plans to resolve the search request (identifying which tables to access first during searches). Determination of the entries that are high in the tree (having a large number of children) is based on DB2 statistics. If a subtree search is done using one of these entries as the search base, the SELECTIVITY clause will be added to the SQL query. This causes DB2 to use the search filter to narrow down the search results before reading the table that identifies the entries that are descendants of a base in a search."

To use SELECTIVITY, the DB2 registry for the database instance must have DB2_SELECTIVITY set to YES. This is in addition to the environment variables described above. This is done when creating a database instance or while migrating from previous versions.

DB2LDIF fails with a failed to log on user error message

So you are getting this when running db2ldif:

GLPCOM014E Failed to log on user: ''instancenamehere''.
GLPRDB111E The server is unable to use the username and password combination for the DB2 instance owner in the configuration file to establish a connection to the database.

Make sure your instancenamehere user is active and has the active password. On windows go to the "Local Users and Groups" console, pull up the user and make sure that it is active, the password change is not required and that the password never expires.

Attributes names limitations

  • IDS does not support underscores in attribute names
  • IDS does not support attribute names that are nonunique within the first 16 characters (DB2 limitation for index field names)

IDSWebApp logs location

WebSphere\AppServer\profiles\default\IDSLogs\logs

LDAP cant connect to a db on start and continues in a config-only mode

Try to connect to the db directly. Su - ldapdb2 and run:

db2 connect to database database using user  using password

If is in a backup pending mode run the Offline backup script.

Lost password to superadmin to ITDSWebApp

replace the contents of ldap/appsrv/installedApps/DefaultNode/IDSWebApp.war.ear/IDSWebApp.war/WEB-INF/classes/security/console_passwd with this ef13c691261ad9f4f313 ef03d586310f (makes the password back to 'secret')

A suffix is in a read-only mode because it is a slave of a replication. need to make it read-write

First you should have read this.

If nothing helped this is what I did - backup everything into an ldif. kill the db2. remove slave replication entries from the ldif. recreate the db2. import everything back into the ldap. Seemed to work fine on a db2 with close to a million entries. Here is the list of commands

idsdb2ldif -o ldap.ldif -I iamldap
idsucfgdb -I iamldap
idscfgdb -I iamldap -a db2admin -t idsdb -l e:\
idsldif2db -i ldapx.ldif -I iamldap -r no


Replication error in a peer-to-peer configuration only on one side

Make sure replicator user (e.g. cn=replicator) has proper priviliges on the system. try to add an entry from the other side manually
ldapadd -h host -D cn=replicator -w... -i file.ldif
with the file.ldif like this

dn: cn=test,dc=com
cn: test
objectclass: accessGroup

if it fails then the easiest solution is to add cn=replicator to the suffix owners. login into IDS WebApp, directory management->manage entry, select the suffix, in a drop down next to the "go" button select "edit acls" click owners (last tab) and add it (cn=replicator) as a new "access-id" type. Try the ldapadd again.

See here for an official fix. (last time I tested the fix did not work so I had to come up with the above workaround)


Attributetype directory string default maximum length is 240 characters

You can increase it by specifying "(xxx)" parameter after an attribute type

@Troubleshooting @ITDS