Re: [Bodington-developers] More LDAP Fun and Games

[Jon M. <jo...@te...>]

Alistair Young wrote:
>> the main problem that
>> prompted the posting has been resolved and the Novell API is not to
>> blame
>>     
> Can you tell us what the original problem was Jon? First of all it was all
> chaos and doom in the openldap api. Now it's not. It was only yesterday
> that you said a switch to jndi was essential. Now it's not?
>   
The original problem prompted doubts but the test program prompted 
alarm.  The original problem has gone away but the results of the test 
program have not! So, I still feel a switch to JNDI is needed.
> Sounds like you may have sorted a problem with ad interfacing - would be
> nice to know what it was.
>   
The original problem initially seemed random - we put log results into a 
database and ran a lot of queries but couldn't find a pattern. Because 
it seemed random at first I created the test program which attempts an 
LDAP search in a loop with a pause between each iteration - it didn't 
recreate the same exceptions but it produced the other random exceptions 
which caused so much alarm.  However, after we collected more data from 
the Bodington installation and examined the code more carefully we found 
a pattern to the *original* exceptions - it was always a student whose 
DN was not cached in a Bodington alias and who typed in a password other 
than the one in the active directory. The Leeds code needs to search 
twice for user names from two different base DN corresponding to staff 
and students because the common DN that contains both also contains vast 
numbers of other records which are best ignored. So, the code connects, 
loops on a list of configured base DN doing a search on each and 
disconnects. However, the bug was caused by not rebinding with the admin 
account to do the second search. The part that confused us was that the 
exception didn't occur on the search call or the hasMore call but with 
the next() call to the API and that the error code from active directory 
indicated an internal error.  It looked like the connection was bound 
when the search was performed but that this had been forgotten or lost 
by the time the first record was loaded.  We know now that the error was 
generated in AD with the search operation but the error condition is 
actually returned to the client end inside the first search result 
record. So, hasMore returns true, not because the search found a user 
record but because an error record is available. It is the next call 
that throws the exception because it loads the error record from the 
LDAP payload, interprets it as an error and throws the appropriate 
exception. That problem is now fixed - if the user can't authenticate 
using the first configured base DN  the admin credentials are used to 
rebind before the next base DN is searched.
>> I can supply the test program to anyone who would
>> like to give a go.
>>     
> go on then, mail it to the list.
>
>   
Attached to this message.
I've now run this test against OpenLDAP and it also throws exceptions 
for example;

13188 [main] DEBUG ADDebug  - 1000000c    Found by user name.
13211 [main] DEBUG ADDebug  - 1000000c    Authentication OK
14392 [main] DEBUG ADDebug  - 1000000d    Found by user name.
14395 [main] DEBUG ADDebug  - 1000000d    Authentication OK
15580 [main] DEBUG ADDebug  - 1000000e    Found by user name.
15583 [main] DEBUG ADDebug  - 1000000e    Authentication OK
16760 [main] DEBUG ADDebug  - 1000000f    Found by user name.
16763 [main] DEBUG ADDebug  - 1000000f    Authentication OK
17952 [main] DEBUG ADDebug  - 10000010    Found by user name.
17954 [main] DEBUG ADDebug  - 10000010    Authentication OK
19137 [main] DEBUG ADDebug  - 10000011    Found by user name.
19140 [main] DEBUG ADDebug  - 10000011    Authentication OK
20320 [main] DEBUG ADDebug  - 10000012    Found by user name.
20322 [main] DEBUG ADDebug  - 10000012    Authentication OK
21508 [main] DEBUG ADDebug  - 10000013    Found by user name.
Exception in thread "Thread-72" java.lang.NullPointerException
        at com.novell.ldap.Message.putReply(Message.java:340)
        at com.novell.ldap.Connection$ReaderThread.run(Connection.java:1295)
        at java.lang.Thread.run(Thread.java:595)

or like this;

0 [main] DEBUG ADDebug  - 10000001    Found by user name.
18 [main] DEBUG ADDebug  - 10000001    Authentication OK
1121 [main] DEBUG ADDebug  - 10000002    Found by user name.
Exception in thread "Thread-4" java.lang.RuntimeException: 
Connection.freeWriteSemaphore(7): thread does not own the semaphore, 
owned by -3
        at 
com.novell.ldap.Connection.freeWriteSemaphore(Connection.java:324)
1141 [main] DEBUG ADDebug  - 10000002    Authentication OK
        at com.novell.ldap.Message.putReply(Message.java:348)
        at com.novell.ldap.Connection$ReaderThread.run(Connection.java:1295)
        at java.lang.Thread.run(Thread.java:595)
2251 [main] DEBUG ADDebug  - 10000003    Found by user name.
Exception in thread "Thread-8" java.lang.RuntimeException: 
Connection.freeWriteSemaphore(12): thread does not own the semaphore, 
owned by -3
        at 
com.novell.ldap.Connection.freeWriteSemaphore(Connection.java:324)
        at com.novell.ldap.Message.putReply(Message.java:348)
        at com.novell.ldap.Connection$ReaderThread.run(Connection.java:1295)
        at java.lang.Thread.run(Thread.java:595)
2269 [main] DEBUG ADDebug  - 10000003    Authentication OK


The Null pointer exception brings the code execution to a complete halt 
but the runtime exception allows execution to continue.