by Jarrad Giskard.
Ok, so I used Wireshark and understand better what's happening now as well as the point of this setting.
When 'Member attribute uses dn' is set to no, the
LDAP search uses the user's 'undistinguished' username in the filter, as seen in this example:
Lightweight Directory Access Protocol
LDAPMessage searchRequest(2) "cn=Moodle Managers,ou=SGs,ou=Administration,dc=xxx,dc=org,dc=uk" baseObject
messageID: 2
protocolOp: searchRequest (3)
searchRequest
baseObject: cn=Moodle Managers,ou=SGs,ou=Administration,dc=xxx,dc=org,dc=uk
scope: baseObject (0)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: False
Filter: (member= yyyz)
filter: equalityMatch (3)
equalityMatch
attributeDesc: member
assertionValue: yyyz
attributes: 1 item
AttributeDescription: member
This returns no matches, even though this user is in the Moodle Managers group.
But when 'Member attribute uses dn' is set to 'yes', it first runs a search to get the user's distinguished name and then uses that in the filter, as seen in this example:
Lightweight Directory Access Protocol
LDAPMessage searchRequest(1225) "cn=Moodle Managers,ou=SGs,ou=Administration,dc=xxx=org,dc=uk" baseObject
messageID: 1225
protocolOp: searchRequest (3)
searchRequest
baseObject: cn=Moodle Managers,ou=SGs,ou=Administration,dc=xxx,dc=org,dc=uk
scope: baseObject (0)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: False
Filter: (member=CN=yyy zzz,OU=ITE,OU=Resources,OU=THT,DC= xxx,DC=org,DC=uk)
filter: equalityMatch (3)
equalityMatch
attributeDesc: member
assertionValue: CN=yyy zzz,OU=ITE,OU=Resources,OU=THT,DC= xxx,DC=org,DC=uk
attributes: 1 item
AttributeDescription: member
Which does find the user is in the group, as expected.
So it seems that MS Active Directory does need the member attribute to be passed with the distinguished name.
--BUT--
Checking the mdl_config_log table, the only entry for this setting was when we first installed, and it was set to an empty string:
SELECT TOP (1000) [id]
,[userid]
,DATEADD(second,[timemodified], CAST('1970-01-01 00:00:00' AS datetime)) timemodified
,[plugin]
,[name]
,[value]
,[oldvalue]
FROM [Moodle].[dbo].[mdl_config_log]
WHERE plugin = 'auth_ldap'
AND name = 'memberattribute_isdn'
id userid timemodified plugin name value oldvalue
----- -------- ----------------------- --------- -------------------- ------- --------
1087 2 2018-05-18 13:25:54.000 auth_ldap memberattribute_isdn NULL
(1 row affected)
And the update changed it to 0 (without a log entry of the change):
SELECT TOP (1000) [id]
,[plugin]
,[name]
,[value]
FROM [Moodle].[dbo].[mdl_config_plugins]
WHERE plugin = 'auth_ldap'
AND name = 'memberattribute_isdn'
id plugin name value
----- --------- -------------------- -------
1403 auth_ldap memberattribute_isdn 0
The instruction for the 'Member attribute uses dn' setting says: Whether the member attribute contains distinguished names (1) or not (0).This option takes a default value based on the User type value you choosed above. So unless you need something special, you don't need to fill this in.
That is, the default value is NOT 0 or 1, but based on the 'User type' you set.
So, the implication is this setting should be OPTIONAL; if you leave it blank, Moodle will itself decide whether the member attribute contains DNs or not based on the 'User type' setting.
We have 'User type' set to 'MS ActiveDirectory', so my guess is prior to the upgrade, when 'Member attribute uses dn' could be left blank, Moodle knew the member attribute would contain DNs based on our 'User type' being set to 'MS Active Directory', so ran as if we set the value to '1'. But with the update, this setting is no longer optional - it's a pick list that must be set to yes or no, so it would seem Moodle isn't being given the opportunity to do this automatically based on the 'User type'
This would seem to be a bug - 'Member attribute uses dn' should be allowed to be left blank so Moodle can decide for itself whether the member attribute contains DNs based on the 'User type' set. Only in special circumstances should it be explicitly set to 0 or 1.
For now, I can set to 'yes' and at least I now know why it needs to be 'yes', when it previously worked with this left blank. But I'll log this as a bug, as I think we should be able to leave this setting blank.
