Hello,

On the ldap module's setup form, the field "Username attribute", have you tried entering sAMAccountName there? You might need to enter it as all lower-case, regardless of how the case is set up in LDAP. This is a weird thing that happens in PHP, but I see that I forgot to place a reminder text about that for that field.

As for determining users via their OU (or really, their DN is what gets returned by LDAP)-- that's a great point. At ULM, we have another property that I can look at instead, to determine if they are a student or not.

Right now, this version of the module can't let you test against their dn that gets returned, but it is a very easy fix, and I'd be happy to do it right quick and then put up an update for the ldap module.

Please test my previous suggestion about using lowercase sAMAccountName for the Username field, and see if that works at all. I'd like to make sure that's going to work, too, before I put out a new version of the module, in case there's anything else I need to do code-wise.

Richard

Hmm. I see the line of code you are talking about.

Do you have any code samples yourself of an ldap_bind() that works for your situation? Without knowing more about your setup, and being able to tinker around and experiment with your ldap server, it would be pretty tough for me to come up with a patch.

This might be a situation where you will need to make the edits to the .module file yourself for your specific situation-- if you do, I would love to see them. I might be able to improve the LDAP module, if you do come up with a code solution.

In the meantime, I did go ahead and put out a new release with my latest code as "beta5":
http://getflightpath.com/project/ldap

If you want, all you need to copy over is the new .module file from that zip file. If we can figure out how to get your setup working, I will incorporate it into the next official release as well.

Richard

I would be very curious to know, too, at what point the code fails for you.

For example, does it bind OK, but then it can't search correctly (as on line 111). If you could put a debug statement on line 106 (of the new module), like:

die("I made it to line 106");

And just see if it gets that far, that would at least indicate where the breakdown is occurring. If it makes it there, try moving the die() command lower, like after line 113.

If it makes it past 106, but not past 113, that at least indicates which command it fails on (the bind or the search).

Just some thoughts ;)

Richard

Hmm.

Just so I understand, your user name attribute is held in samaccountname, right? That shouldn't cause a problem for the code, the "cn" property isn't hard-coded or anything like that. It will test against whatever you enter for the username attribute field.

The change in beta5 should make it easier to identify who is student or faculty, should you ever get it past the bind & search successfully, by allowing you to test "dn". You said you had separate cn's (which get returned as the full DN string), one for student, one for faculty. At ULM we do the same thing. In the test for students, you can test if the "dn" contains whatever bit of text that makes it different from the faculty dn string.

But the first hurdle needs to be to figure out how to get a successful bind in the first place. The module, as of beta5 anyway, assumes that the users can bind directly to the ldap server with their username and password. If that is successful, the app then performs a second bind so it can do a "non-anonymous search", where it looks for that username's details, and returns them.

If you LDAP server doesn't allow users to bind directly to it, for example, then the code would need to be changed to accommodate that. I might can do that, but without knowing exactly how your LDAP server is set up, it would be pretty tough.

At this point, I am afraid I don't think I can help much more, without seeing some kind of code sample that DOES work, if you have such from another project perhaps?

Richard

Okay-- yes, our DNs are set up very similarly at ULM, for employees and students.

I found this article, which points to a way of setting up authentication with samaccountname:
http://stackoverflow.com/questions/8324785/authenticating-user-with-ldap...

I am curious-- on your campus, I assume you just log into things using "ronsolomon" and your LDAP password right? Meaning, you would like your students & staff to be able to login with their samaccountname and their password? Also, you said you had other systems which were set up to use samaccountname-- on one of their settings pages, do you see anything which differs from FlightPath's LDAP module settings page, which might give an indication to extra settings I might be missing?

Finally, do you know if your LDAP server is set up to allow anonymous searches, or if there is like a higher-level (root?) LDAP user which is the only one that can do that? That is how we have it set up at ULM.

On that stackoverflow link, the first answer shows them connecting as the high-level user FIRST, then searching for the user in question by samaccountname, then, once they know the full DN for the user, re-attempting a bind, this time with the user's supplied password.

I think this approach would probably work in your situation. I just need to re-arrange the order in which the binds are carried out, if so. (Right now, in FlightPath, it binds as the user first, THEN it searches out details as the high-level user).

Richard

Okay, I think then that the first answer on that stackoverflow page is probably the way to go. I will do some experimenting, and get back to you (maybe tomorrow) with some new code to try out, if you don't mind being a guinea pig.

I'm afraid I'm also not super-familiar with LDAP :/, all the options can be confusing, but I am sure there's a way we can make this work.

Richard

Okay, I am attaching my latest attempt-- please rename it to ldap.module (remove the .txt) and overwrite the existing ldap.module you have. The link should be at the bottom of this post.

For this, try using your samaccountname as the "username attribute".

I've also added a new setting, which is the fieldname where the user's individual dn is stored in LDAP. This works on my system as the field "dn", and on that stackoverflow link, someone claims it's in "name", though that seems odd to me. Try "dn" first.

If this works for you, then I will make this version of the module the next beta release.

Richard

What does the page error say when you get no return on the search? I tested it on my side, and it simply doesn't log in; it says it doesn't recognize username and password. Does yours say something different?

Also, as far as the user type, you would be testing the dn of the user.

When the user logs in, the value of the user's entire dn should be returned as a field. For you it would be:
CN=Solomon\, Ronald,OU=Staff,OU=BRCC,DC=lctcs,DC=edu

So, you can simply test for the text "student" to see if this person is a student or not. Please see my attached screenshot.

Now, this is true only if the "dn" field is actually present, and if it's actually called "dn". You can add this to line 123 to test:
die("<pre>" . print_r($result, TRUE) . "</pre>");

That will kill the script but show you what actually got returned from LDAP. It will kill it on the first try, of course, so you may need to try a valid student login first, or staff-- whichever order you have them listed in the "Base DNs" settings box.

As for the "Loading" box-- that's just put up there with javascript when the form submits, so the user doesn't get upset at a long wait.

Does it take just as long when you log in as admin? Or is that immediate? If so, it means the LDAP lookup is what's taking the longer amount of time, or, there is some kind of error happening.

You may want to check to make sure you don't see any javascript errors.

FlightPath does load some course descriptions on login, and holds them in memory, to make things faster later on. If your server is just slower than normal, you can reduce the number of courses it pre-loads by editing your settings file at /custom/settings.php

Look for this setting: $system_settings["load_course_inventory_on_login_number"] = 2000;

And set it to a lower number, like 10. Just for testing, anyway, until we get this LDAP problem figured out.

Richard

Hm, most odd. If you can log in as admin normally, then it must not be an issue with loading the courses on login. I am assuming that it's trying to do *something* to your LDAP server, and eventually timing out. That is probably what the long delay is before it gives up.

At this point, without knowing more about your set up, I'm afraid all I can suggest is to start putting in die("here"); commands, then moving them down through to the code each time, to see where it is hanging.

The *_validate() function is what gets called immediately after you click submit. From there it calls ldap_auth_connect(), then keeps going.

I would suggest moving the die("here") statement a few lines at a time, until it gets to the hang, then see what function it was calling right before, where it never reaches the die() statement, I mean.

Richard

Hmmm. Interesting. If you can make it all the way through the _validate function (meaning, through all the LDAP work as well), that indicates something else possibly going wrong, further down the line.

It *could* be a MySQL memory issue, or, I was thinking a PHP memory issue actually (FlightPath is a little bit of a memory hog), but the fact that you can log in as admin makes me question that.

Check on something-- go to your Modules page, and make sure that the "User" module is enabled. After that you can go back to the Admin console page, scroll towards the bottom to the Users link, and arbitrarily create new users that don't have to exist in LDAP. I would suggest just creating one with a random name and password, then try logging in as that new user. If you can get in, it goes back to indicating there's something special about LDAP users that FlightPath is hanging on.

You might can check the logs on your server, to see if you spot any errors when you try to log in and it hangs until it gives up. That might give an indication.

Ad for server configs, ours are Linux and Unix servers, so there might be some differences there, I am not sure. I will admit that server configs aren't my area of expertise. I did check though, and for mysql our max_allowed_packet is set to "32M".

In the php.ini file, I would suggest that you up your memory_limit value to at least 500M. If it's already there, then double whatever it is, at least for now, until you get FlightPath working. You can always reduce the values later on before you actually go live with it.

As for recommendations for a production machine in general, it really depends on how much load you are going to place on your machine. If you are going to have hundreds of thousands of hits a day, you'd probably want at least 8GB of memory, maybe 16GB. If this is going to be a single-purpose machine, then 4GB might well be OK.

Another thing to consider would be your webserver program (apache, for example), and it's max number of clients, and the max amount of memory each one is allowed to consume. The default values should certainly be enough for testing while you set up FlightPath, since you'd be the only one using it. But if you started to have crashes, I'd look there too.

But going back to what I said earlier-- try and see if you are getting any error messages in your log files (wherever they are on your server) when the login hangs. Also, create a new local test user, and see if he can log in just fine with no hang. If so, it takes us back to the LDAP module. Also, make sure your memory_limit setting in PHP is at least 500M if not more, at least while testing. On my live demo on this site, it's only 128mb, but then I am only dealing with a small amount of data, and a linux machine, which may have different limitations than a Windows server.

Richard

Okay, yeah, that's definitely a PHP memory error then. So weird. I take it now, you still get the hang with LDAP users? Can you see what the new error message says?

For some reason, the call to LDAP is eating up a heck of a lot of memory, when a normal non-LDAP login is not. Almost like it's entering some kind of loop and loading data until it dies.

Can you confirm that you get to line 592 of the ldap.module? That is, the return, after it says
$form_state["passed_authentication"] = TRUE;

If you could add a statement right after that like, die("I got here");

Just to confirm that. That's what so weird to me-- it seems like it wouldn't be completing the LDAP lookup at all. It seems like that is where the hangup would occur.

Richard

Hrm.....

So odd.

So, with the new memory limit at 1GB, do you still get the out of memory error in your log? If so, crank it up to 2GB. At least as an experiment to see how far it's going to go.

Richard

I would assume that warning is being generated during the ldap_auth_connect() function call. Not after the validate function. As in, its working in the order you think it is. But a PHP Warning is not enough to stop the execution of the code. It will just skip over it.

But-- the warning message does lead to an interesting issue.

It looks like it's complaining that the connection was never established. I think it's saying that $ldapconn isn't set to anything.

Which is odd, because around like 82, where we are establishing the ldap connection, if it isn't set it should kick the form back out with an error.

Right after the connection line, try this:

die(print_r($ldapconn, true));

And see if that is actually being set to a resource. If it isn't, that means it isn't connecting to your LDAP server at all. Which might explain the hang up-- its trying to connect, then eventually timing out (hence the delay).

Richard

Interesting. Hrm-- I sent you an email at your mybrcc address from my ULM work email address-- since your issue is specific to your set up, it might be best if we continue using emails instead of the forum. If you'd rather the forum, I'm OK with that, too ;)

Richard