Menu
▾
▴
bodington-developers
|
From: Jon M. <jo...@te...> - 2006-07-27 19:39:21
|
Following on from previous posts.... Michael and I have been having nasty problems with LDAP. The authenticator discussed earlier on the list was deployed last Friday and the log is showing randomly occurring exceptions ever since. A connection, bind and search are carried out O.K. but almost randomly the next() method called on the search results throws an exception which indicates an internal error on the LDAP server but provides a message suggesting that a bind is required. Although nearly random there are some searches for particular users that always fail. I wrote a little application based on the authenticator which carries out the same operations in a loop. Although unable to reproduce the same exception, other exceptions were thrown randomly. The nature of the exceptions strongly suggests programming errors in the Novell/OpenLDAP API (which perhaps only occur when connecting to Active Directory). I say this because the exceptions are not thrown in the main program thread but within LDAP API worker threads and refer to illegal access to semaphores. It looks like a fundamental problem handshaking within the LDAP protocol. Anyway, the point of all this explanation is that it leads me to the conclusion that a switch to JNDI and to the Sun LDAP provider is essential. I think JNDI is far more likely to be well debugged against many different LDAP servers and more importantly if anyone has problems with the Sun provider in connection with their own little used LDAP server they may be able to plug in a specific provider for it. Any thoughts on this? Jon P.S. we can't be 100% certain that there isn't a problem at the Active Directory end of the LDAP but another web service at Leeds, based on uPortal is successfully authenticating to it via JNDI. |
|
From: Alistair Y. <ali...@sm...> - 2006-07-29 14:07:43
|
> almost randomly the > next() method called on the search results throws an exception sometimes the assembled information on a subject is not absolutely ready at the point of access. Are you specifically asking for certain attributes? > It looks like a fundamental problem handshaking within the > LDAP protocol how many source and destination machines have you tried it on? Have you seen the AD logs? What version of AD is it? > I think JNDI is far more likely to be well debugged against > many different LDAP servers no. In fact that's why I chose the openLDAP API as JNDI didn't work with AD at the time. There was a published "bug" from Microsoft stating that JNDI lookups would fail. As the openLDAP api worked, I used that instead. I believe the bug is now fixed though when I last tried it, it JNDI still didn't work. > switch to JNDI and to the Sun LDAP provider is > essential > ... > we can't be 100% certain that there isn't a problem at the Active > Directory end of the LDAP so what happens if you've still got the problem?, as you haven't identiifed the problem. Before you go chucking stuff out let's make sure it's not your AD that's at fault. Can you try it from other machines? Can you let us have the code and we can try it here against an AD? What's your custom socket doing? --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Following on from previous posts.... > > Michael and I have been having nasty problems with LDAP. The > authenticator discussed earlier on the list was deployed last Friday an= d > the log is showing randomly occurring exceptions ever since. A > connection, bind and search are carried out O.K. but almost randomly th= e > next() method called on the search results throws an exception which > indicates an internal error on the LDAP server but provides a message > suggesting that a bind is required. Although nearly random there are > some searches for particular users that always fail. > > I wrote a little application based on the authenticator which carries > out the same operations in a loop. Although unable to reproduce the > same exception, other exceptions were thrown randomly. The nature of th= e > exceptions strongly suggests programming errors in the Novell/OpenLDAP > API (which perhaps only occur when connecting to Active Directory). I > say this because the exceptions are not thrown in the main program > thread but within LDAP API worker threads and refer to illegal access t= o > semaphores. It looks like a fundamental problem handshaking within the > LDAP protocol. > > Anyway, the point of all this explanation is that it leads me to the > conclusion that a switch to JNDI and to the Sun LDAP provider is > essential. I think JNDI is far more likely to be well debugged against > many different LDAP servers and more importantly if anyone has problems > with the Sun provider in connection with their own little used LDAP > server they may be able to plug in a specific provider for it. Any > thoughts on this? > > Jon > > P.S. we can't be 100% certain that there isn't a problem at the Active > Directory end of the LDAP but another web service at Leeds, based on > uPortal is successfully authenticating to it via JNDI. > > > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Andrew B. <a.g...@le...> - 2006-07-29 16:42:54
|
I used the Leeds AD without problem. Let's see if it works outside the Leeds Brotherton Library. You know who we are and you know where we live. Let's put your code on one of our servers and test. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Alistair Young Sent: 29 July 2006 14:32 To: Bodington developers Subject: Re: [Bodington-developers] More LDAP Fun and Games > almost randomly the > next() method called on the search results throws an exception sometimes the assembled information on a subject is not absolutely ready at the point of access. Are you specifically asking for certain attributes? > It looks like a fundamental problem handshaking within the > LDAP protocol how many source and destination machines have you tried it on? Have you seen the AD logs? What version of AD is it? > I think JNDI is far more likely to be well debugged against > many different LDAP servers no. In fact that's why I chose the openLDAP API as JNDI didn't work with AD at the time. There was a published "bug" from Microsoft stating that JNDI lookups would fail. As the openLDAP api worked, I used that = instead. I believe the bug is now fixed though when I last tried it, it JNDI = still didn't work. > switch to JNDI and to the Sun LDAP provider is > essential > ... > we can't be 100% certain that there isn't a problem at the Active > Directory end of the LDAP so what happens if you've still got the problem?, as you haven't identiifed the problem. Before you go chucking stuff out let's make sure it's not your AD that's at fault. Can you try it from other machines? Can you let us have the code and we can try it here against an AD? What's your custom socket doing? --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Following on from previous posts.... > > Michael and I have been having nasty problems with LDAP. The > authenticator discussed earlier on the list was deployed last Friday = and > the log is showing randomly occurring exceptions ever since. A > connection, bind and search are carried out O.K. but almost randomly = the > next() method called on the search results throws an exception which > indicates an internal error on the LDAP server but provides a message > suggesting that a bind is required. Although nearly random there are > some searches for particular users that always fail. > > I wrote a little application based on the authenticator which carries > out the same operations in a loop. Although unable to reproduce the > same exception, other exceptions were thrown randomly. The nature of = the > exceptions strongly suggests programming errors in the Novell/OpenLDAP > API (which perhaps only occur when connecting to Active Directory). I > say this because the exceptions are not thrown in the main program > thread but within LDAP API worker threads and refer to illegal access = to > semaphores. It looks like a fundamental problem handshaking within the > LDAP protocol. > > Anyway, the point of all this explanation is that it leads me to the > conclusion that a switch to JNDI and to the Sun LDAP provider is > essential. I think JNDI is far more likely to be well debugged = against > many different LDAP servers and more importantly if anyone has = problems > with the Sun provider in connection with their own little used LDAP > server they may be able to plug in a specific provider for it. Any > thoughts on this? > > Jon > > P.S. we can't be 100% certain that there isn't a problem at the Active > Directory end of the LDAP but another web service at Leeds, based on > uPortal is successfully authenticating to it via JNDI. > > > = -------------------------------------------------------------------------= > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to = share > your > opinions on IT & business topics through brief surveys -- and earn = cash > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -------------------------------------------------------------------------= Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Jon M. <jo...@te...> - 2006-07-30 00:41:29
|
O.K. the original problem we had was pinned down and resolved. (Would have told you earlier if I hadn't been distracted by just trying to get message through at all.) By that time I had rewritten the code to use the JNDI API but I'm pretty sure that we could have got the Novell code to stop throwing the exceptions we observed. However, I'm still alarmed by the results of the test we ran outside of Bodington.... The loop was connecting, making a search for the DN of a record matching a given user name and disconnecting. I put Thread.currentThread.sleep() between every API call and at the end of the main loop. Although a delay of a whole second between API calls reduced the rate of exceptions to less than one in several hundred cycles they didn't go away completely. The thing that really bothers me is that none of the exceptions thrown resulted in a meaningful error condition or result message in the application itself - just nasty looking stack traces uncontrollably pumped out to standard error by the Novell API worker threads. That sort of thing should NEVER happen in a well written API - if there is an error condition it ought to be signaled properly to the application level. The test was carried out using my laptop as the client (plugged into the campus ethernet) and about three of the Active Directory servers on campus. I can supply the test program to anyone who would like to give a go. To repeat the key finding since my last posting - the main problem that prompted the posting has been resolved and the Novell API is not to blame but we have an inexplicable problem occurring in a test scenario which reduces my confidence in the Novell solution. So far the JNDI distributed with JDK 1.5 works fine with Active Directory although I haven't yet subjected it to the testing under load that we tried on the Novell API. |
|
From: Alistair Y. <ali...@sm...> - 2006-07-30 12:45:09
|
> hadn't been distracted by just trying to get > message through at all yes, I can sympathise with you there. The sf sites/lists are going to pot= . > 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 al= l 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? Sounds like you may have sorted a problem with ad interfacing - would be nice to know what it was. What do you get if you turn on java.net.debug=3Dall? Are you using sasl/tls etc? > I can supply the test program to anyone who would > like to give a go. go on then, mail it to the list. --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > > O.K. the original problem we had was pinned down and resolved. (Would > have told you earlier if I hadn't been distracted by just trying to get > message through at all.) By that time I had rewritten the code to use > the JNDI API but I'm pretty sure that we could have got the Novell code > to stop throwing the exceptions we observed. However, I'm still alarme= d > by the results of the test we ran outside of Bodington.... > > The loop was connecting, making a search for the DN of a record matchin= g > a given user name and disconnecting. I put Thread.currentThread.sleep() > between every API call and at the end of the main loop. Although a dela= y > of a whole second between API calls reduced the rate of exceptions to > less than one in several hundred cycles they didn't go away completely. > The thing that really bothers me is that none of the exceptions thrown > resulted in a meaningful error condition or result message in the > application itself - just nasty looking stack traces uncontrollably > pumped out to standard error by the Novell API worker threads. That sor= t > of thing should NEVER happen in a well written API - if there is an > error condition it ought to be signaled properly to the application > level. The test was carried out using my laptop as the client (plugged > into the campus ethernet) and about three of the Active Directory > servers on campus. I can supply the test program to anyone who would > like to give a go. > > To repeat the key finding since my last posting - the main problem that > prompted the posting has been resolved and the Novell API is not to > blame but we have an inexplicable problem occurring in a test scenario > which reduces my confidence in the Novell solution. So far the JNDI > distributed with JDK 1.5 works fine with Active Directory although I > haven't yet subjected it to the testing under load that we tried on the > Novell API. > > > > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Jon M. <jo...@te...> - 2006-07-31 11:46:08
Attachments:
ADDebug.java
|
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.
|
|
From: Alistair Y. <ali...@sm...> - 2006-08-01 07:14:19
|
> I still feel a switch to JNDI is needed I don't see why. We've run the openLDAP api against AD, openLDAP and eDirectory for 2 years now without any problems. It doesn't work on your laptop. Is that a reason to change everything? I don't think so. What happens if you remove the custom socket? Why not go back to basics and add the extra stuff like sockets as you go along? Alistair On 31 Jul 2006, at 12:45, Jon Maber wrote: > 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. > > > > /* > * ADDebug.java > * > * Created on 25 July 2006, 14:08 > * > * To change this template, choose Tools | Template Manager > * and open the template in the editor. > */ > > import java.util.Properties; > import java.net.*; > import com.novell.ldap.*; > > import org.apache.log4j.Logger; > import org.apache.log4j.Level; > import org.apache.log4j.BasicConfigurator; > > /** > * > * @author jon > */ > public class ADDebug > { > private static Logger log = Logger.getLogger > ( ADDebug.class.getName() ); > > private static final String admin_dn = > "cn=Manager,dc=ds,dc=leeds,dc=ac,dc=uk"; > private static final String admin_password = "secret"; > private static final String search_base = > "OU=Staff,DC=ds,DC=leeds,DC=ac,DC=uk"; > private static final String search_user = "bio1ama"; > private static final String search_password = "secret"; > private static final String search_server = "localhost"; > > private static final int extradelaymillis = 5; > > static > { > BasicConfigurator.configure(); > //log.addAppender( new org.apache.log4j.ConsoleAppender() ); > } > > int serial = 0x10000000; > > /** Creates a new instance of ADDebug */ > public ADDebug() > { > } > > public void test() > throws Exception > { > boolean ok; > for ( int i=0; i<20; i++ ) > { > serial++; > ok = authenticateUserName( search_user, search_password ); > log.log( Level.DEBUG, logMessage( "Authentication " + > (ok?"OK":"Failed") ) ); > Thread.currentThread().sleep(1000); > } > } > > > > private boolean searchByUserName( > LDAPConnection lc, > String basedn, String user_name, String p ) > throws LDAPException, InterruptedException > { > LDAPSearchResults searchResults=null; > > String filter; > filter = "(&(objectClass=user)(cn=" + user_name + "))"; > > //log.log( Level.DEBUG, logMessage( "LDAP search basedn " + > basedn ) ); > //log.log( Level.DEBUG, logMessage( "LDAP search filter " + > filter ) ); > searchResults = > lc.search( > basedn, > LDAPConnection.SCOPE_SUB, > filter, > null, // null seems to fetch all attributes - not > documented in API docs! > false ); > > Thread.currentThread().sleep( extradelaymillis ); > if ( !searchResults.hasMore() ) > { > log.log( Level.DEBUG, logMessage( "LDAP Search\tUser > name not found." ) ); > return false; > } > Thread.currentThread().sleep( extradelaymillis ); > LDAPEntry entry = searchResults.next(); > //dumpResult( entry ); > Thread.currentThread().sleep( extradelaymillis ); > if ( searchResults.hasMore() ) > { > log.log( Level.WARN, logMessage( > "LDAP Search\tUser name appears in more than > one record." ) ); > //dumpResults( searchResults ); > return false; > } > String userDN = entry.getDN(); > > try {lc.bind( 3, userDN, p );} > catch ( LDAPException e ) {return false;} > return lc.isBound(); > } > > > > private boolean authenticateUserName( String user_name, String p ) > { > LDAPConnection lc=null; > try > { > lc = connect(); > if ( lc == null) > return false; > Thread.currentThread().sleep( extradelaymillis ); > try {lc.bind(3, admin_dn, admin_password );} > catch ( LDAPException e ) > { > log.log( Level.DEBUG, logMessage( "Bind > Failed." ) ); > return false; > } > Thread.currentThread().sleep( extradelaymillis ); > if ( !lc.isBound() ) > { > log.log( Level.DEBUG, logMessage( "Bind Failed. > (B)" ) ); > return false; > } > Thread.currentThread().sleep( extradelaymillis ); > //log.log( Level.DEBUG, logMessage( "Bound to LDAP > for searching." ) ); > > if ( !searchByUserName( lc, search_base, > user_name, p ) ) > return false; > log.log( Level.DEBUG, logMessage( "Found by > user name." ) ); > return true; > } > catch ( Exception e ) > { > log.log( Level.ERROR, logMessage( > "Exception\tSerious problem while searching > LDAP. " + > "See stdout for stack trace." ) ); > e.printStackTrace(); > return false; > } > finally > { > try > { > if ( lc!=null && lc.isConnected() ) > lc.disconnect(); > } > catch ( LDAPException ldape ) > { > } > } > } > > public LDAPConnection connect() > throws Exception > { > LDAPConstraints constraints = new LDAPSearchConstraints(); > constraints.setTimeLimit( 5*1000 ); > LDAPConnection lc = new LDAPConnection( new > CustomSocketFactory() ); > lc.setConstraints( constraints ); > lc.connect( search_server, 389 ); > > return lc; > } > > String logMessage( String message ) > { > StringBuffer buffer = new StringBuffer(); > buffer.append( Long.toHexString( serial ) ); > buffer.append( "\t" ); > buffer.append( message ); > return buffer.toString(); > } > > public static void main( String[] params ) > { > System.out.println( "Starting" ); > try > { > ADDebug debug = new ADDebug(); > debug.test(); > } > catch ( Exception e ) > { > e.printStackTrace(); > } > } > } > > > > class CustomSocketFactory implements LDAPSocketFactory > { > public Socket createSocket( String host, int port ) > throws java.io.IOException, java.net.UnknownHostException > { > Socket socket = new Socket(); > InetSocketAddress endpoint = new InetSocketAddress(host, > port); > socket.connect( endpoint, 2000 ); > return socket; > } > } > |
|
From: Sean M. <se...@sm...> - 2006-08-01 08:07:53
|
<quote who=3D"Jon Maber"> copious stuff snipped.... Guys, if this is verified, it needs to be bugged and sent back to openldap.... interesting. s --=20 Sean Mehan Head of e-Frameworks Learning and Information Services UHI |
|
From: Jon M. <jo...@te...> - 2006-08-01 12:10:22
|
Alistair Young wrote: >> I still feel a switch to JNDI is needed >> > I don't see why. We've run the openLDAP api against AD, openLDAP and > eDirectory for 2 years now without any problems. It doesn't work on > your laptop. Is that a reason to change everything? I don't think so. > Run the test, see the errors, tell me I'm wrong then. |
|
From: Sean M. <se...@sm...> - 2006-08-01 12:17:09
|
aggie, can you verify these test results? s On 1 Aug 2006, at 13:10, Jon Maber wrote: > Alistair Young wrote: >>> I still feel a switch to JNDI is needed >>> >> I don't see why. We've run the openLDAP api against AD, openLDAP and >> eDirectory for 2 years now without any problems. It doesn't work on >> your laptop. Is that a reason to change everything? I don't think so. >> > Run the test, see the errors, tell me I'm wrong then. > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Andrew B. <a.g...@le...> - 2006-08-01 14:26:32
|
It works for me:
private static final String admin_dn =
"cn=myADusername,ou=fbs,ou=users,ou=bio,ou=temp,DC=ds,DC=leeds,DC=ac,DC=uk";
private static final String admin_password = "myADpass";
private static final String search_base =
"ou=Staff,DC=ds,DC=leeds,DC=ac,DC=uk";
private static final String search_user = "myusername";
private static final String search_password = "mypassword";
private static final String search_server = "ds.leeds.ac.uk";
D:\eclipse\workspace\ADDebug>java -classpath
build;lib/ldap.jar;lib/log4j.jar ADDebug
Starting
0 [main] DEBUG ADDebug - 10000001 Found by user name.
10 [main] DEBUG ADDebug - 10000001 Authentication OK
1113 [main] DEBUG ADDebug - 10000002 Found by user name.
1113 [main] DEBUG ADDebug - 10000002 Authentication OK
2166 [main] DEBUG ADDebug - 10000003 Found by user name.
2166 [main] DEBUG ADDebug - 10000003 Authentication OK
3209 [main] DEBUG ADDebug - 10000004 Found by user name.
3209 [main] DEBUG ADDebug - 10000004 Authentication OK
4262 [main] DEBUG ADDebug - 10000005 Found by user name.
4262 [main] DEBUG ADDebug - 10000005 Authentication OK
5316 [main] DEBUG ADDebug - 10000006 Found by user name.
5316 [main] DEBUG ADDebug - 10000006 Authentication OK
6369 [main] DEBUG ADDebug - 10000007 Found by user name.
6369 [main] DEBUG ADDebug - 10000007 Authentication OK
7422 [main] DEBUG ADDebug - 10000008 Found by user name.
7422 [main] DEBUG ADDebug - 10000008 Authentication OK
8475 [main] DEBUG ADDebug - 10000009 Found by user name.
8475 [main] DEBUG ADDebug - 10000009 Authentication OK
9518 [main] DEBUG ADDebug - 1000000a Found by user name.
9518 [main] DEBUG ADDebug - 1000000a Authentication OK
10571 [main] DEBUG ADDebug - 1000000b Found by user name.
10571 [main] DEBUG ADDebug - 1000000b Authentication OK
11625 [main] DEBUG ADDebug - 1000000c Found by user name.
11625 [main] DEBUG ADDebug - 1000000c Authentication OK
12668 [main] DEBUG ADDebug - 1000000d Found by user name.
12668 [main] DEBUG ADDebug - 1000000d Authentication OK
13721 [main] DEBUG ADDebug - 1000000e Found by user name.
13731 [main] DEBUG ADDebug - 1000000e Authentication OK
-----Original Message-----
From: bod...@li...
[mailto:bod...@li...] On Behalf Of
Sean Mehan
Sent: 01 August 2006 13:17
To: Bodington developers
Subject: Re: [Bodington-developers] More LDAP Fun and Games
aggie, can you verify these test results?
s
On 1 Aug 2006, at 13:10, Jon Maber wrote:
> Alistair Young wrote:
>>> I still feel a switch to JNDI is needed
>>>
>> I don't see why. We've run the openLDAP api against AD, openLDAP and
>> eDirectory for 2 years now without any problems. It doesn't work on
>> your laptop. Is that a reason to change everything? I don't think so.
>>
> Run the test, see the errors, tell me I'm wrong then.
>
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bodington-developers mailing list
Bod...@li...
https://lists.sourceforge.net/lists/listinfo/bodington-developers
|
|
From: Sean M. <se...@sm...> - 2006-08-01 14:32:34
|
Right, jon. Ping - pong, the ball is *firmly* back on your side of the table!-) switch to jndi --2 xxooxx!=) -s On 1 Aug 2006, at 15:26, Andrew Booth wrote: > It works for me: > > private static final String admin_dn = > "cn=myADusername,ou=fbs,ou=users,ou=bio,ou=temp,DC=ds,DC=leeds,DC=ac,D > C=uk"; > private static final String admin_password = "myADpass"; > private static final String search_base = > "ou=Staff,DC=ds,DC=leeds,DC=ac,DC=uk"; > private static final String search_user = "myusername"; > private static final String search_password = "mypassword"; > private static final String search_server = "ds.leeds.ac.uk"; > > > D:\eclipse\workspace\ADDebug>java -classpath > build;lib/ldap.jar;lib/log4j.jar ADDebug > > Starting > 0 [main] DEBUG ADDebug - 10000001 Found by user name. > 10 [main] DEBUG ADDebug - 10000001 Authentication OK > 1113 [main] DEBUG ADDebug - 10000002 Found by user name. > 1113 [main] DEBUG ADDebug - 10000002 Authentication OK > 2166 [main] DEBUG ADDebug - 10000003 Found by user name. > 2166 [main] DEBUG ADDebug - 10000003 Authentication OK > 3209 [main] DEBUG ADDebug - 10000004 Found by user name. > 3209 [main] DEBUG ADDebug - 10000004 Authentication OK > 4262 [main] DEBUG ADDebug - 10000005 Found by user name. > 4262 [main] DEBUG ADDebug - 10000005 Authentication OK > 5316 [main] DEBUG ADDebug - 10000006 Found by user name. > 5316 [main] DEBUG ADDebug - 10000006 Authentication OK > 6369 [main] DEBUG ADDebug - 10000007 Found by user name. > 6369 [main] DEBUG ADDebug - 10000007 Authentication OK > 7422 [main] DEBUG ADDebug - 10000008 Found by user name. > 7422 [main] DEBUG ADDebug - 10000008 Authentication OK > 8475 [main] DEBUG ADDebug - 10000009 Found by user name. > 8475 [main] DEBUG ADDebug - 10000009 Authentication OK > 9518 [main] DEBUG ADDebug - 1000000a Found by user name. > 9518 [main] DEBUG ADDebug - 1000000a Authentication OK > 10571 [main] DEBUG ADDebug - 1000000b Found by user name. > 10571 [main] DEBUG ADDebug - 1000000b Authentication OK > 11625 [main] DEBUG ADDebug - 1000000c Found by user name. > 11625 [main] DEBUG ADDebug - 1000000c Authentication OK > 12668 [main] DEBUG ADDebug - 1000000d Found by user name. > 12668 [main] DEBUG ADDebug - 1000000d Authentication OK > 13721 [main] DEBUG ADDebug - 1000000e Found by user name. > 13731 [main] DEBUG ADDebug - 1000000e Authentication OK > > > -----Original Message----- > From: bod...@li... > [mailto:bod...@li...] On > Behalf Of > Sean Mehan > Sent: 01 August 2006 13:17 > To: Bodington developers > Subject: Re: [Bodington-developers] More LDAP Fun and Games > > aggie, can you verify these test results? > > s > > > On 1 Aug 2006, at 13:10, Jon Maber wrote: > >> Alistair Young wrote: >>>> I still feel a switch to JNDI is needed >>>> >>> I don't see why. We've run the openLDAP api against AD, openLDAP and >>> eDirectory for 2 years now without any problems. It doesn't work on >>> your laptop. Is that a reason to change everything? I don't think >>> so. >>> >> Run the test, see the errors, tell me I'm wrong then. >> >> >> --------------------------------------------------------------------- >> - >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Atif S. <BM...@bm...> - 2006-08-01 14:35:48
|
Sean Mehan wrote: >Right, jon. Ping - pong, the ball is *firmly* back on your side of >the table!-) > > >switch to jndi --2 > >xxooxx!=) >-s > > > Jon u need a new laptop 2++. Switch 2 jndi --2. Ta Atif. |
|
From: Alistair Y. <ali...@sm...> - 2006-08-01 13:22:01
|
I tested it against our institutional eDirectory and our institutional ActiveDirectory which runs our Citrix thin client project. These are institutional-grade identity systems, managed by admins, not an AD running on a laptop. The only change I made was to enable referrals. I ran the test code on a Mac and 3 linux boxes. All passed: Starting 0 [main] DEBUG ADDebug - 10000001 Found by user name. 5 [main] DEBUG ADDebug - 10000001 Authentication OK 1124 [main] DEBUG ADDebug - 10000002 Found by user name. 1125 [main] DEBUG ADDebug - 10000002 Authentication OK 2241 [main] DEBUG ADDebug - 10000003 Found by user name. 2242 [main] DEBUG ADDebug - 10000003 Authentication OK 3352 [main] DEBUG ADDebug - 10000004 Found by user name. 3354 [main] DEBUG ADDebug - 10000004 Authentication OK 4476 [main] DEBUG ADDebug - 10000005 Found by user name. 4477 [main] DEBUG ADDebug - 10000005 Authentication OK 5594 [main] DEBUG ADDebug - 10000006 Found by user name. 5595 [main] DEBUG ADDebug - 10000006 Authentication OK 6708 [main] DEBUG ADDebug - 10000007 Found by user name. 6709 [main] DEBUG ADDebug - 10000007 Authentication OK 7816 [main] DEBUG ADDebug - 10000008 Found by user name. 7817 [main] DEBUG ADDebug - 10000008 Authentication OK 8925 [main] DEBUG ADDebug - 10000009 Found by user name. 8926 [main] DEBUG ADDebug - 10000009 Authentication OK 10060 [main] DEBUG ADDebug - 1000000a Found by user name. 10080 [main] DEBUG ADDebug - 1000000a Authentication OK 11201 [main] DEBUG ADDebug - 1000000b Found by user name. 11202 [main] DEBUG ADDebug - 1000000b Authentication OK 12308 [main] DEBUG ADDebug - 1000000c Found by user name. 12309 [main] DEBUG ADDebug - 1000000c Authentication OK 13417 [main] DEBUG ADDebug - 1000000d Found by user name. 13419 [main] DEBUG ADDebug - 1000000d Authentication OK 14555 [main] DEBUG ADDebug - 1000000e Found by user name. 14556 [main] DEBUG ADDebug - 1000000e Authentication OK 15666 [main] DEBUG ADDebug - 1000000f Found by user name. 15667 [main] DEBUG ADDebug - 1000000f Authentication OK 16773 [main] DEBUG ADDebug - 10000010 Found by user name. 16774 [main] DEBUG ADDebug - 10000010 Authentication OK 17884 [main] DEBUG ADDebug - 10000011 Found by user name. 17885 [main] DEBUG ADDebug - 10000011 Authentication OK 18992 [main] DEBUG ADDebug - 10000012 Found by user name. 18993 [main] DEBUG ADDebug - 10000012 Authentication OK 20122 [main] DEBUG ADDebug - 10000013 Found by user name. 20123 [main] DEBUG ADDebug - 10000013 Authentication OK 21234 [main] DEBUG ADDebug - 10000014 Found by user name. 21235 [main] DEBUG ADDebug - 10000014 Authentication OK Process finished with exit code 0 now you have to find out why your laptop doesn't work. The case for JNDI hasn't been made. > tell me I'm wrong then ok, you're wrong ;) Alistair On 1 Aug 2006, at 13:10, Jon Maber wrote: > Alistair Young wrote: >>> I still feel a switch to JNDI is needed >>> >> I don't see why. We've run the openLDAP api against AD, openLDAP and >> eDirectory for 2 years now without any problems. It doesn't work on >> your laptop. Is that a reason to change everything? I don't think so. >> > Run the test, see the errors, tell me I'm wrong then. > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Andrew B. <a.g...@le...> - 2006-08-01 14:35:29
|
Jon Come over and try it from one of the machines in my office. 10.115 Garstang. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Jon Maber Sent: 01 August 2006 13:10 To: Bodington developers Subject: Re: [Bodington-developers] More LDAP Fun and Games Alistair Young wrote: >> I still feel a switch to JNDI is needed >> > I don't see why. We've run the openLDAP api against AD, openLDAP and > eDirectory for 2 years now without any problems. It doesn't work on > your laptop. Is that a reason to change everything? I don't think so. > Run the test, see the errors, tell me I'm wrong then. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X