LDAP auth - sAMAccountName vs Common Name (cn)

29 posts / 0 new
Last post
LDAP auth - sAMAccountName vs Common Name (cn)

Is there any way that I can login via sAMAccountName instead of CN? Our cn is represented by lastname, first name. We use sAMAccountName with other applications authenitcated via LDAP. I have test and don't see how this can be accomplished on the LDAP setting page. Can you assist me with the setup?

Also, our faculty and students are located in their own OU. Is there a way to determine is_faculty or is_student via OU? Thanks.

Ron

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

Hello Richard,
I tried making the username attribute lowercase, I get the same results. What I notice in the ldap.module file, at line 97. The ldap.bind function has a concatenation of "user attribute" to the username plus base DN. This only works if the common name(cn) and sAMAccountName are the same.

I really appreciate you making changes to the code.

Ron

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

Sorry for the delay, we had graduation.

It's failing on the bind. It's because our CN is lastname comma firstname, and not our user_id in smaccountname.

I was trying to compare beta 4 to beta 5 ldap.module file and couldn't see too much difference. Were changes made to faculty/student identification?

Ron

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

Ok, according to line 97, a bind is happening on userattr with username and base_dn. When I look myself in AD I see this:

CN=Solomon\, Ronald,OU=Staff,OU=BRCC,DC=lctcs,DC=edu

I didn't think you can use samaccountname for a bind, right?
This the reason why I was using cn in the username attribute field. Also, samaccountname didn't work.

my samaccountname is ronsolomon.

Here are the base DNs for staff/faculty and students:

ou=staff,ou=brcc,dc=lctcs,dc=edu
ou=students,ou=brcc,dc=lctcs,dc=edu

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

Yes, I want my students and staff to login with their samaccountname and LDAP password.

Our other systems, uses similar settings. I think, what makes it function differently is that it doesn't bind with username and password, but only admin username and password. In which in our case, the cn and smaccountname for the admin account are the same.

I too saw that document, I was thinking that maybe I only need to search and not bind with username and password. I'm just not familiar with LDAP (to bind or not to bind) to do the programming.

I don't think we are setup to do anonymous searches.

Ron

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

OK thanks

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

Attached file(s): 

Okay, I have tested the changes. This is my findings:

line 113: ldap_search: Page error if no return on search

I put die commands in the ldap_login_form_validate function, to follow the logic. It was unable to determine whether I was student or faculty. I'm not sure what the usertype should be on the ldap setup page, to identify what OU to differentiate between Faculty or students . Also, once my ID and password was correct, the "Loading.." box appeared and never went away.

Ron

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.

Attached file(s): 

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

I have changed the setting $system_settings["load_course_inventory_on_login_number"] from 10 to 1, to see if it would speed thing up. The "Loading" box is still being displayed for a long time. The "This page can't be displayed" will eventually display.

I have debugged the function "ldap_auth_connect" until it returns "TRUE". I have even reduced the number of Base DNs to only the DN that contains my username (ronsolomon). I am not sure what else the "Login" process is doing.

Ron

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

OK, I have debugged it throughout the *_validate() function. Data is being inserted and updated in the appropriate tables. I think the reason of why the "Loading" box is being displayed for a long time, is because of the memory setting of the database. The machine I'm running this on win 64 bit with 4GB of memory. I checked performance monitor and it's only consuming about 3GB.

I checked the my.ini for mysql and noticed some small numbers for the database allocation. Can you give me some production size settings to use for the database? And also make other recommendations for a production machine.

I'm almost there!!!

Ron

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

I have verified that the user module is enabled, located on the module page. I also created a new user that don't exist in LDAP. I was able login successfully with that username.

I checked my mysql memory settings and notice that my settings were a little bit higher than yours.

I did notice this error in the php error log:

Allowed memory size of 536870912 bytes exhausted (tried to allocate 548 bytes) in C:\xampp\htdocs\flightpath\classes\_DatabaseHandler.php on line 305

This error occurs when I enter a valid LDAP username. It doesn't occur immediately. I did a little research on the error on xampp. I have changed memory_limit from 512M to 1024M.

I noticed that when a valid no-ldap user is entered successfully, the"Welcome...." page is displayed. This never happens for valid LDAP usernames. It just says "Loading..."

Ron

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

Yes, when I was debugging the ldap_login_form_validate function, I put a die("Finished") command after the $form_state["passed_authentication"] = TRUE;. It had no problem reaching the die command.

I was thinking that the problem was coming after the call to ldap_login_form_validate. I noticed that page moves from login to main page, when the user is not located in LDAP. I was thinking that was where the delay is happening, trying to perform a load before displaying the page "Main".

Ron

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

OK........

Now I'm totally confused. I thought the ldap_search function was only called in the ldap_login_form_validate (via ldap_auth_connect). I debugged ldap_login_form_validate until completion. This is what was reported in the php_error_log:
PHP Warning: ldap_search(): Search: No such object in C:\xampp\htdocs\flightpath\custom\modules\ldap\ldap.module on line 113

Line 113 is the ldap_search function. Why a search is needed after the *_validate?

Ron

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

Nevermind last post. Testing again.

Ron

Yes, it's set to a resource,"Resource id #75"

Ron

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

Log in to post comments