I think I have the answer, but I'm not sure whether this is a bug in
the code or a configuration error on your part (if I've read the code
correctly).
The problem is, the code uses 'ldap_user_attribute' to search for
users, when running the sync code. And then creates a temporary table
where it stores all the values it get from LDAP. In your config, this
is the sAMAccountName. So you only have sAMAccountName's in your temporary table.
But then, when comparing existing Moodle users when the users in the temporary table, it uses the idnumber field for the existing Moodle users. And then, unless you have mapped sAMAccountName onto the ID Number field for users, kaboom!, all your Moodle users are no longer found in the temporary table and are marked for deletion (and subsequently deleted).
As I say, I'm not sure if this in an error in the code, or in your configuration (that doesn't match what the sync code is doing/expecting).
Saludos. Iñaki.
Iñaki is right, the code expects to have idnumber pointing to the unique field in LDAP. It was a bit like that before, and I made it more so when I worked on the sync code.
It allows (or should allow) username to be mapped from another LDAP field, something that in practice isn't very useful. At least the use of idnumber as the main key should be optional.
Long term the use of idnumber vs username needs to be reviewed. I suspect we went astray at some point, and things aren't 100% consistent. With the current code, as long as idnumber is populated everything works correctly.
It allows (or should allow) username to be mapped from another LDAP field, something that in practice isn't very useful. At least the use of idnumber as the main key should be optional.
Long term the use of idnumber vs username needs to be reviewed. I suspect we went astray at some point, and things aren't 100% consistent. With the current code, as long as idnumber is populated everything works correctly.
That all makes sense now. The problem I have is that I am trying to use ID number to hold staff and student ID numbers but our implementation of AD is a real mess and not under my control. Staff detail is fairly accurately stored in AD and nowhere else so I was trying to use auth_ldap_synch.php to pre-load the moodle database but since ID number is not in AD I missed it out.
From a student perspective it is even worse since we do not have their names properly in AD just a mixture of their initials and their ID number. As a result I have had to pre-load student data from a data warehouse which is fed by all college systems and which in turn feeds AD. Unfortunately there is no staff data in the warehouse.
Thanks anyway as now I can at least see a way around the problem even if it means loading ID number with the login name (sAMAccountName).
Well, this can a bit of a problem for us, as we store student's ID in that field, to later use it with en database enrollment system. Given that our students' ID has nothing to do with their LDAP usernames (the former is a pure number), we would be in trouble if we used the auth_ldap_sync.php script (we currently don't).
I may have a look at it when I have time (not much spare time recently, and I would like to push the multi-auth code first).
Saludos. Iñaki.
I may have a look at it when I have time (not much spare time recently, and I would like to push the multi-auth code first).
Saludos. Iñaki.