|
[
Permalink
| « Hide
]
Andrea Bicciolo added a comment - 12/Oct/07 06:38 PM
This is a really huge problem, especially in Corporate users where Microsoft Active Directory is widespread. Hope it can be fixed very soon.
In addition to making the database field larger, you alsa need to modify lib/moodlelib.php, in function truncate_userinfo(). Specifically, you need to change the 'idnumber' limit from 64 to whatever value you set for the corresponding database field.
Althouugh this is a 'trivial' change, I'm not sure the 'fix' can be applied to 1.9, as there is a database freeze right now. Adding Eloy here to get his opinion on this. Saludos. Iñaki. By the way, the proposed fix (enlarging the field) is really a quick hack. The real fix is modifying LDAP enrolment plugin to be able to deal with distinguished names vs non-distinguished names membership values, the same way the LDAP authentication plugin does.
I'd prefer doing the later, but that will take more time. So it's up to you Petr and Eloy. Saludos. Iñaki. Thank you to Andrea and Iñaki.
Waiting for the right/correct solution I am going to patch Moodle with the first suggested/provided solution. It is matter of adopting or not Moodle in my new office (I just changed position) so I really need to tell my mew colleagues that Moodle actually fits our needs. As soon as I'll produce a patch I'll post it here to ask your opinion about the its quality. Cross the fingers. Great.
I just changed the db with ALTER TABLE mdl_user CHANGE COLUMN idnumber idnumber VARCHAR(255); and lib/moodlelib.php from: $limit = array( 'username' => 100, 'idnumber' => 64, 'firstname' => 100, 'lastname' => 100, 'email' => 100, 'icq' => 15, 'phone1' => 20, 'phone2' => 20, 'institution' => 40, 'department' => 30, 'address' => 70, 'city' => 20, 'country' => 2, 'url' => 255, ); to $limit = array( 'username' => 100, 'idnumber' => 255, 'firstname' => 100, 'lastname' => 100, 'email' => 100, 'icq' => 15, 'phone1' => 20, 'phone2' => 20, 'institution' => 40, 'department' => 30, 'address' => 70, 'city' => 20, 'country' => 2, 'url' => 255, ); and it works properly. Thank you Iñaki. I 100% agree with Iñaki about the correct solution being to use dn/cn or whatever (I never know the meaning of them) to perform user matching, exactly like the authentication does.
Perhaps the solution should be something like presenting what to match in Moodle (username, idnumber, email) with what in LDAP to be backwards compatible and to allow new combinations not using the idnumber. In fact, I really think that 64cc is big enough to assign unique identification numbers to ANY institution (to the whole world population in fact But definitively... I'd change the way LDAP enrol works as commented by Iñaki. It's not impossible to change the field to 255... but my initial feeling is not doing that. What if one institution uses internally 345cc identificators (it sounds exactly equivalent "craziness" :-D than the 255cc change, IMO. Comments will be welcome...ciao Well, I can only report my experience on two Moodle Installation with AD as backend:
1. AD Authentication: no problem at all. It works flawlessly 2. AD Enrollments: no way to have it working using 64chars as idnumber. Just changing the idnumber size and the moodellib, AD enrollments works perfectly. AD auth works using distinguishedName as user's idnumber: this value will be matched by AD enrollment comparing the "member" attribute of the course group. Since the member attribute is also a distinguishedName, the length of 64 chars appears really too short anyway. I'm sure that we can encode any population with 64cc, but can we be able to force users to change their thousands AD entries according to our needs? After a long chat with Eloy, we ended up with the following:
1) auth only uses "username" to authenticate users (usually mapped to "cn"). Please, review! I need to double-check this, but I seem to remember that LDAP enrolment was changed to use the username instead of the user ID for enrolment matching. If this is so, then you don't need using distinguishedName as the user ID (this is really a hack arount AD that I proposed back then) and the problem goes away.
I'll have a look a it and post back. Saludos. Iñaki. It seems I was wrong. LDAP enrolment still uses user ID, so we'll need to modify it as outlined by Andrea in the short term.
In the long term, I really think we should refactor LDAP auth + enrol. They share quite a bit of code (and knowlegde about server specific characteristics) that is duplicated and could easily go in a separte lib. Just one place to add features and fix things. For example, we'll need something like ldap_find_userdn() from ldap/auth.php to convert the "cn" => "dn" in step 4 of Andrea's plan, etc. Saludos. Iñaki. Ooo.
Just discovered that this is assigned to me, I really think it must be assigned to somebody else (and it's blocker!). Ciao pong!
oki, adding this to my plan for the next two weeks Hey there should be nothing wrong with the varchar(64) data type length sofar , it is able to get enough "idnumber " length. it might have some problem with LDAP authentication and enrollment that.
Hi all,
As I see it, when mapping directories to database table like moodle, it should be done via ldap-attribute that does not change. That attribute should be stored to database and you only that for synchronize information between ldap and database. Users DN is not static. theres many organization where users are moved between ldap containers. Useful mapping attribute with ad would be SID (security id) or GUID . Both are practically static, so users could be moved and renamed in ldap without losing association in moodle. Attributes like those should be usedwith ldap-authentication and enrollment. With possibility to configure synchronization with other not so reliable attribute like dn. Problem using attributed like sid is that ldap gives group members as list of dn (or uid). The problem here is that any change in ldap enrolment plugin may cause major problems because users might be unenrolled which causes data loss (group membership, forum subscripts, tracking, etc.)
This was much easier in auth plugins - if it does not work admins just fix the settings and no data is lost (sure, the sync scripts could cause some trouble). Solutions could be: I do not think we need special handling sid/guid in auth/enrol plugins in 1.9.x, the username renames from external sources are not supported - you can workaround this by disabling sync scripts and renaming user in moodle database manually and reenabling sync scripts. I agree it would be nice to have renaming support in 2.0, maybe having extra external field with oldusername could do the trick for all exteral enrolment sources. Petr Hi,
I agree with Petr about seeking a more proper solution. However, currently Petr's point #1 - Increase the field size - looks anyway straightforward and easy. Moreover it has no impact on existing setup since you only need to increase the filed size and update moodelib.php accordingly. As a matter of fact, manually increasing the field size is the current used workaround. Andrea ok, if Martin agrees we can break the freeze and increase the idnumber size +1 for that
If increasing the field size is enough for most in 1.9 then it's a yes +1 from me to do it in 1.9 and HEAD.
I don't think any special upgrade detection code will be needed in HEAD, it's the sort of change that can be done twice without any problem... the user idnumber is no 255 chars long, fixed the truncating and user edit form too,
expect more changes and improvements in 2.0 thanks for the report and cooperation! Verified. Closing. Thanks!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Blocker
useless authentication for huge institutions
). Perhaps some sort of "identification reduction" or remapping could be necessary in your institution LDAP, that shouldn't be really complex to maintain automatically AFAIK). Or simply make idnumber = username... just thinking as I type... 
 |
|
