In addition to it, in order to be able to used a distiguished name with '\'
(and other LDAP special characters) in a LDAP filter to find the user
enrolments, we need to quote it using the LDAP filter quoting rules
Both CAS and LDAP auth plugins open new connections to the LDAP server
to get the user account details. While this is the desired behaviour
for regular logins (we probably don't have an already open connection
to the LDAP server), this is a ressource hog when we are doing user
synchronization, as the closed connections remain in the TCP_WAIT
state for a while before the server can reuse them. If we are syncing
a lot of users, we can make the server run out of available TCP
ressources.
So we cache the connection the first time we establish it and return
the same connection handle everytime, unless we've closed all the
'open' connections, or the auth object is destroyed.
In addition to that, there were a few missing calls to ldap_close().
These include:
MDL-14078: redirect() doubles the specified timeout when we haven't printed
the page header and uses javascript to execute the redirect. This
is interacting badly with some versions of IE and FF (at least
3.0.x Windows version) that fireup javascript timers even if
we already left the page where we set those up. Just print
the page header (we are printing other content anyway) to
make redirect respect our timeouts.
MDL-14071: All the relevant details are in the description of the bug :)
MDL-14297: This is probably the same as MDL-14078
Merged from MOODLE_18_STABLE
If we are using auth_ldap_sync_users.php to synchronize our users, and we
have a database which is case-sensitive when doing comparisons (Postgres and
Oracle at least), and any of our users has the vale of the username attribute
in mixed-case (like 'John Smith'), we get duplicated users.
This is because we don't make sure the username attribute value is 'lowercased'
after we retrive it from the LDAP server and before we insert it into the
database.
Merged from MOODLE_18_STABLE.
The fix is wrong, as it breaks auth_db_sync_users.php and
auth_ldap_sync_users.php at least. No new users are added to Moodle, as the
username is missing from the new user info record.
The fix needs to go into update_user_record() in lib/moodlelib.php to make it
skip the 'username' key, as we really need get_userinfo() to return the
username as part of the user info array.
It doesn't make sense at all (username is not part of the externally mapped
fields) and produces a notice that breaks HTTP headers with debugging enabled.
print_error()'s third parameter is the URL we jump to (defaults to
$CFG->wwwroot if not set) when we click the 'Continue' button, not the message
string parameter object.
Forward ported from MOODLE_18_STABLE
It was still using the 'old' get_config() interface, so the 'cookie'
set by ntlmsso_finish() wasn't retrieved at all, and the automatic
login always failed.
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Author: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Committer: Martin Langhoff <martin@catalyst.net.nz>
Now the DNs that indicate a course-creator role can also be contexts.
This way we support one more widely used practice in the weird and
wonderful LDAP world... MDL-12178
cache_flags is now the apropriate way to manage this kind of temp
data. It gives us time expiry and GC for free, so it's a perfect fit
for the job, as it simplifies the code a bit.
From Iñaki Arenaza - fix for
... I forgot to put the textlib conversion
call before the block of code that uses $extusername, so it
completely breaks the user validation process.
Fix a bug in ntlmsso_finish(), and tighten up user_login() to avoid a
pointless DB lookup if the password doesn't match the sesskey.
Hopefully this makes things work again...
(thanks I~naki for the testing!)
Several tidyups:
- use moodle_strtolower() for utf-8 correctness
- use sesskey as the key instead of IP addr to support
proxied users
- clean the sesskey after success!
- pull timeout out to a constant: AUTH_NTLMTIMEOUT
From Iñaki Arenaza...
Right now, if someone logs in via NTLM magic, we don't check if that
user is inside the contexts specified in the LDAP settings. I mean,
if I want to restrict my Moodle site to those users inside a given OU
or subtree of my LDAP directory, with the current code any valid user
in my whole AD domain (and if we are using a GC as the LDAP server,
the whole forest) can log in. We should check that the user is inside
one of the configured contexts before allowing his/her to log in.
Something along the lines of the attached patch could do it.
As Iñaki points out, ntlmsso_finish() needs to do all the setup that
login/index.php would do for a user once auth succeeds. With this
patch, the session setup is complete so the logon is usable.
Use $nomoodlecookie global to avoid session troubles. Also
* Ensure we load the appropriate config.php, even if we are executing
under a strange environment (ie: with a user's credentials!)
* Test we have a spacer gif to open before we open it
Flesh out the functions that get the job done. These will be triggered
by PHP files sitting under auth/ldap/ ...
ntlmsso_magic() - here is where the magic happens. Call it serving
something harmless, like a space GIF, from a URL that is blessed with
Integrated Windows Authentication. If the IWA is successful, it will
set a special session cookie in config_plugins table.
It won't complete the job because when we are under IWA magic we
cannot change (even read!) the session data, as the execution happens
under the OS privileges of the actual user acct being logged in (!!!)
ntlmsso_finish() - if it finds the session set by ntlmsso_magic() and
it hasn't expired, it will finish the job of logging in the user, by
calling authenticate_user_login() and exercising the whole auth
machinery.
user_login() - when called by authenticate_user_login() it will check
to see if there's a session setup by ntlmsso_magic() and OK the login
without really asking the AD backend to proof a password we don't have
anyway.
A work in progress -- initial loginpage_hook() and headers for the
remaining functions. One thing to consider here is that this won't
work if there's a proxy in the middle.
Does NTLM auth thingy support proxies?
iarenaza