How and where the OSSO server keeps its configuration is a wierd and wonderful thing. The first few times I faced OSSO server issues I remember digging through a collection of metalink notes to piece together the story. It was after forgetting the details a second time that I committed the understanding to a script (validateSso.sh).

1. Firstly, the SSO server uses a privileged connection to an OID server to retrieve the OSSO (database) schema password.
2. With that password, it can retrieve the SSO OID (ldap) server connection details from the OSSO (database) schema.
3. Thus the SSO Server finally has the information needed to connect to the OID server that contains the user credentials.
The validateSso.sh script I've provided here gives you a simple and non-destructive test of all these steps. The most common problem I've seen in practice is that the OSSO schema password stored in OID gets out of sync from the actual OSSO schema password. I think various causes of these problems, but the script will identity the exact point of failure in a jiffy.