Page 2 of 2

Posted: Thu Nov 30, 2006 6:00 pm
by mgroeninger
Ok, I have some code back up, but I'm really not sure what exactly it will find during the lookup...

http://www.theledge.net/uploads/serendi ... h_test.txt


As I said, I don't have a server to test this with. And the plugin is designed with the idea that individual users have the ability to bind to the server, so having it bind with a single user may very well introduce bad, bad results. (Like all users are authenticated, whether the password is right or not, etc...)

Posted: Thu Nov 30, 2006 6:17 pm
by mgroeninger
Nope, I'm taking it down again. And withdrawing from this thread.

This plugin is designed so that the user authenticates against the ldap server as themselves. That is the only check it seems to make concerning the password. Therefore my code means that any user found in the ldap server that has the right userlevel will be authenticated (as far as I can tell).

Without an ldap server to test against I have no way to ensure that any code I post is secure. Authentication is too important for me to be spewing code out without being able to verify my results.

Sorry for the noise, and for the wrong directions. I think what you are trying to do is possible if you do a little research into the plugin architecture and into php ldap authentication, but I think it will mean rewriting most of the lines after the if statement at line 258.

LDAP plugin working with Microsoft AD/LDAP

Posted: Fri Dec 01, 2006 8:00 pm
by colas
See my version at http://wikix.ilog.fr/wiki/bin/view/Proj ... ternalauth

My changes add the following:

* Ability to connect to Microsoft Active Directory LDAP interface. For this, one MUST issue the 2 commands: ldap_set_option($ds,LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option($ds, LDAP_OPT_REFERRALS, 0); juste after the ldap_connect
* Ability to connect to LDAPs not supporting anonymous browsing via the 2 new config vars 'bind_user' & 'bind_password'
* Ability to use LDAPs where users are not cleanly stored in one part of the tree, i.e., one have to perform a search with the login name on all the subtree given in 'rdn' with an LDAP search-expression given in the new config variable 'auth_query' with %-expansion of rdn
* Setting the s9y 'realname' field from the LDAP 'name' one in all cases

For instance in my config at ILOG, rdn = DC=ilog,DC=biz bind_user = CN=webcoreadreaddev,CN=Users,DC=ilog,DC=biz bind_password = noneofyourbusiness auth_query = (&(objectcategory=person)(objectclass=user)(sAMAccountName=%1))

I changed the files

* serendipity_event_externalauth.php for the code
* lang_en.inc.php for the english descriptive text of the new 3 options
* ChangeLog.txt I added this file.

Posted: Fri Dec 01, 2006 8:22 pm
by mgroeninger
Very nice! Can we update the plugin in CVS with this version?

Posted: Fri Dec 01, 2006 10:10 pm
by colas
mgroeninger wrote:Very nice! Can we update the plugin in CVS with this version?
Of course!

Posted: Tue Dec 12, 2006 7:55 pm
by nappy_d
This is very promising!!

I am still uable to authenticate and wanted to look at the logs. Where does Serendipity store this info? I have enabled the logging option for this.


Also,

These are the settings I have used:

authentication string = uid=%1,ou=internal,ou=people,dc=myDomain,dc=com

Query to find an User = (&(objectclass=myCompany-person)(uid=%1))

LDAP DN name used to connect(bind) = myCompany-unique=companyUserName,ou=internal,ou=people,dc=myCompany,dc=com

I will keep testing tho with my LDAP Admin.

Posted: Wed Dec 13, 2006 8:52 am
by colas
to debug:
edit the php file plugins/serendipity_event_externalauth/serendipity_event_externalauth.php
and change "static $debug = false;"
to true
If I remember well, the log file is debug.log

Note that if you choose to use "authentication string" you should not use "Query to find an User"
Basically, either you have non-braindead LDAP admins (or admins that do not obey the stupid Microsoft LDAP recommendations) and you wll have all your users stored in some
predetermined place in the tree (the "authentication string" ).
Or they will have scatterred the users everywhere in the LDAP tree and you will have to perform a full-tree query to search them (using "Query to find an User", starting in the tree
at the path given by "authentication string" )

PS: using the command line tool "ldapsearch" from a script is a great way to debug LDAP access, instead of using tools with a GUI where you must retype all the parameters.

Posted: Wed Dec 13, 2006 3:13 pm
by nappy_d
Thanks. I enabled logging(had to change the file path). The bind seems successfull, however, it does not seem like lookups are being performed. Here is the output. I have tried it with/without "Query to find an user".

I think I am missing something in my search string and I am trying to figure out what

[13.12.2006 08:07] Plugin authentication called.
[13.12.2006 08:07] LDAP auth started.
[13.12.2006 08:07] LDAP connection to 192.256.123.11: Resource id #51
[13.12.2006 08:07] LDAP connection successful.
[13.12.2006 08:07] $auth_query = (&(objectclass=myCompany-person)(uid=myUsername))
[13.12.2006 08:07] LDAP Search failed
[13.12.2006 08:07] Updating author, invalidating login.
[13.12.2006 08:07] LDAP connection close.
[13.12.2006 08:09] Plugin authentication called.
[13.12.2006 08:09] LDAP auth started.
[13.12.2006 08:09] LDAP connection to 192.256.123.11: Resource id #51
[13.12.2006 08:09] LDAP connection successful.
[13.12.2006 08:09] LDAP bind call: uid=MyFull\ Name,ou=internal,ou=people,dc=myCompany,dc=com
[13.12.2006 08:09] LDAP connection close.

Posted: Wed Dec 13, 2006 5:06 pm
by colas
[13.12.2006 08:07] $auth_query = (&(objectclass=myCompany-person)(uid=myUsername))
Try to perform this search via ldapsearch or other LDAP clients to see if it works

Posted: Wed Dec 13, 2006 5:15 pm
by nappy_d
I have another opensource app; phpScheduleit that searches and authenticates successfully.

Near the beginning of this post, I posted some info of what it uses and seems to work with successfully.

Check it out and see if there is anything I am missing.

I tried to apply it but no luck.