Thanks.

I noticed that if I put the wrong username and password in it does come up with "Authentication failed" but the correct username and password still just brings up http://localhost:3000/Security/?executeForm=LoginForm

LDAP authentication goes through a few phases:
1) Find the user DN based on the given ID
2) Bind as this user
3) Lookup user details.

Your previous post leads me to believ that 1) is working well. To find out if 2) is working, you could try to enter a correct user id, with the wrong password. If this results in a blank screen, then this is where the problem is. If you get authentication failed, then the problem is in 3) or in the auth_external code beyond.

Could you give this a try?

As you suggested, I entered a correct user id, with the wrong password and this results in a blank screen...

In auth_external/code/drivers/LDAP.php

Find "public function Authenticate"
1) Add a double forward slash before the first instance of "restore_error_handler" and put // before it

Try good account with right and wrong pass. And report what happens then undo this change

2) Before "$bind = @ldap_bind(self::$ds, $dn, $external_passwd)" add
"$bind =ldap_unbind(self::$ds);" (remember the ; at the end of the line)
2a) Remove the @ before ldap_bind

Try good account with right and wrong pass. And report what happens then undo this change. If it works now, stop here.

3) Add "print_r($dn); exit;" before @ldap_bind and try to log on.
The logon will certainly fail now, but you can see if the DN is ok, since is should be shown in the browser window.

Undo the change.

1) With or without // a good account with right and wrong password returns a blank page.
Should I leave the // there?

2) I changed it to:
$success = false; //Initialize the result of the authentication
$bind = ldap_unbind(self::$ds);
$bind = ldap_bind(self::$ds, $dn, $external_passwd);

But a good account with right and wrong password returns a blank page.

Then I changed it back but still nothing.

Should I be doing more than saving it, doing a http://localhost:3000/db/build?flush=1 and restarting lighttpd after each change?

3) Again the same result :(

My primary browser is Firefox 3 Beta 5, but I've tried it in IE7 too. Maybe it isn't even getting this far through the code??

1) Undo the //

We could still be at the right place. This behavior could be explained if no DN was returned. So lets focus on the DN searching.

Between code changes you certainly need not restart the http server. Flushing the cache should not be needed as we are not changing templates, but it may be wise to do it anyway.

We are now going to put some checkpoints in
"private function findDN($source, $ldapattribute)"

There are 2 instances of the text
"$result = @ldap_get_entries(self::$ds, $search);"

Put "echo 'hello'; echo $filter; print_r($result); exit;"

After both. Now try to log on with all variations. You should at least get back hello. Hopefully with some more information.

You could also try to verify the workings of the module by adding another authentication source of type SILVERSTRIPE. (You'll have to add a user ID to the user record)

Don't know is the PHP install on windows uses modules, but you could check for the file php_ldap.dll on your system and/or php_ldap in your php config files (php.ini and such)

Hi Lancer,

It would be handy to get some unit tests developed for the external_authenticator module. We would then be able to run these tests against new versions of SilverStripe, to ensure that upgrades don't break your module!

Of course, to really work properly you need to be able to run the tests without having an LDAP server to connect to.

One way of doing this is to make a class LDAP, that basically contains methods that call PHP's ldap_XXX methods.

When constructing the LDAP_Authenticator, have a constructor argument that can specify which of these LDAP objects to use. Setting the default to being new LDAP(), would be fine, or you can use this to specify the LDAP server that you would like to connect to.

You can then create a test version of the LDAP object, either by coding it up explicitly, or by using mock objects: http://www.phpunit.de/pocket_guide/3.0/en/mock-objects.html

This TestLDAP object would be set up to return fixed values for the various LDAP calls. You could potentially create variant versions of this to test situations such as failing to connect to the LDAP server.

The SecurityTest class on the govtsecurity branch provides a useful example of how to test a log-in form:

http://open.silverstripe.com/browser/modules/sapphire/branches/govtsecurity/tests/security/SecurityTest.php

Hi Sam,

Unit tests was planned for 0.3. I'm trying to allocate some time to do it ;-)

As for running the test without LDAP server; We can simulate openldap behavior, but I don't know how e.g. AD behaves, since it is not fully LDAP compliant (or else we wouldn't have this problem).

But thanks for the information pointers