The solution to this problem has been found.
As many of us suspected earlier, though the MDS-CS debug log clearly indicates that its query for certificate status checks uses the pre-defined LDAP scheme, it actually does not do so and uses anonymous credentials to check certificate status.
For example, when performing a certificate lookup, the debug log clearly references the pre-defined LDAP scheme:
----------------------------------------------------------------------
<= IPPP, HANDLER = LDAP, Starting query request: ldap:///?givenname,cn,sn,mail,usercertificate,usercertific ate;binary?sub?(&(|(givenname=Richard*)(cn=Richard *))(|(usercertificate=*)(usercertificate;binary=*) ))>
<= IPPP, HANDLER = LDAP, Using default server: hq.xyz.com>
<= IPPP, HANDLER = LDAP, Using default port: 389>
<= IPPP, HANDLER = LDAP, Using default query: DC=xyz,DC=com>
<= IPPP, HANDLER = LDAP, Using default authentication username and password>
<= IPPP, HANDLER = LDAP, scheme: 'ldap'>
<= IPPP, HANDLER = LDAP, auth: 'hq.xyz.com:389'>
<= IPPP, HANDLER = LDAP, path: 'DC=xyz,DC=com'>
<= IPPP, HANDLER = LDAP, query: '?givenname,cn,sn,mail,usercertificate,usercertifi cate;binary?sub?(&(|(givenname=Richard*)(cn=Richar d*))(|(usercertificate=*)(usercertificate;binary=* )))'>
<= IPPP, HANDLER = LDAP, attributes: 'givenname,cn,sn,mail,usercertificate,usercertific ate;binary'>
<= IPPP, HANDLER = LDAP, scope: 'sub'>
<= IPPP, HANDLER = LDAP, filter: '(&(|(givenname=Richard*)(cn=Richard*))(|(usercer t ificate=*)(usercertificate;binary=*)))'>
<= IPPP, HANDLER = LDAP, extensions: 'null'>
<= IPPP, HANDLER = LDAP, Starting query>
<= IPPP, HANDLER = LDAP, Disabling datastream compression>
<= IPPP, HANDLER = LDAP, Query complete. Sent 1 entries to device.>
----------------------------------------------------------------------
And then shows that it uses, what one would assume, to be the same scheme as used when performing the certificate lookup to perform a certificate status check:
----------------------------------------------------------------------
<2008-07-21 11:14:05.125 EDT>:[317]:<MDS-CS_BLACKBERRY_MDS-CS_1>:<DEBUG>:<LAYER = IPPP, HANDLER = CRL, LDAP Server -
Scheme: 'ldap', Auth: '', Path: 'CN=xyz%20Certification%20Authority...
----------------------------------------------------------------------
As you can see from the above query, the pre-defined LDAP scheme is thought to be used, including port number, server, and credentials, as this type of debug information in relation to scheme usage is also present when performing a certificate lookup/retrieval.
There is absolutely nothing noted in the administrative documentation which reveals that the BES performs certificate status lookups anonymously. Not sure if there is any information on the development side which might detail this fact.
The solution:
No matter which SKU or build of Windows Server 2003 is used, anonymous queries to the LDAP are disabled by default for security purposes and must be enabled manually. They are disabled to prevent unauthorized parties from performing DoS attacks, done by launching massively complex queries for extended durations. No other form of malicious activity other than this can occur by enabling anonymous lookups.
To do this, the ADSIEdit snap-in will be required to make a very careful change to the schema. This snap-in is available when the Windows Server 2003 Support Tools library is installed.
The details are available at
Novell's Cool Solutions Forum, in the second-half of the document titled:
"Additional Configuration for Windows 2003 server" and you may disregard the first half as it does not apply to this situation.
Once anonymous lookups have been enabled, you should definitely not see the previous connection binding error.
From the log snippet below, you can see that the query is now actually being performed.
----------------------------------------------------------------------
<= IPPP, HANDLER = CRL, Fetching CRL via LDAP from ldap:///CN=xyz%20Intermediate%20Certification%20Authority, CN=certification,CN=CDP,CN=Public%20Key%20Services ,CN=Services,CN=Configuration,DC=xyz,DC=com?certif icateRevocationList?base?objectClass=cRLDistributi onPoint>
<= IPPP, HANDLER = CRL, Parsing Query ldap:///CN=xyz%20Intermediate%20Certification%20Authority, CN=certification,CN=CDP,CN=Public%20Key%20Services ,CN=Services,CN=Configuration,DC=xyz,DC=com?certif icateRevocationList?base?objectClass=cRLDistributi onPoint>
<= IPPP, HANDLER = CRL, LDAP Server - Scheme: 'ldap', Auth: '', Path: 'CN=xyz%20Intermediate%20Certification%20Authority ,CN=certification,CN=CDP,CN=Public%20Key%20Service s,CN=Services,CN=Configuration,DC=xyz,DC=com', Query: '?certificateRevocationList?base?objectClass=cRLDi stributionPoint'>
<= IPPP, HANDLER = CRL, Starting LDAP query>
<= IPPP, HANDLER = CRL, Parsing LDAP response threw a NamingException:javax.naming.NameNotFoundException : [LDAP: error code 32 - 0000208D: NameErr: DSID-03151EFD, problem 2001 (NO_OBJECT), data 0, best match of:>
<= IPPP, HANDLER = CRL, 'CN=Configuration,DC=xyz,DC=com'>
<= IPPP, HANDLER = CRL, ]; remaining name ''>
----------------------------------------------------------------------
(For our own environment, we're seeing another error related to the MDS-CS not being able to find the CRL in LDAP, but this will be detailed in a separate post so not to sidetrack this particular issue.)
Try this out and I hope this gets you guys back up and running.
MDS-CS LDAP Connection Binding Error (DSID-0C090627)
