In case anyone else runs into this problem when using LDAP with Group Attribute...
Basic and User Attribute worked fine, but Group Attribute resulted in logins failing with the message "User does not have sufficient access rights".
DO NOT make any security group being used for Group Attribute control the "Primary Group" for an object in AD. Turns out one of the LDAP queries from the MPU asks for matches in the Member attribute for LDAP objects and the list will not include a primary group.
That was not very clear. For example, if the MPU is named "MPUone", the computer object in AD has to be named MPUone. If the MPU admin group in AD was named "MPU_admin_group", then MPUone and all the admin accounts have to be members of that group. Great, pretend Active Directory Users and Computers (ADUC) was used to add MPUone and the admin accounts to the security group called MPU_admin_group. Looks great so far. By default, the MPUone computer account was created with "Domain Computers" has its primary group. ADUC will show MPUone is a member of "Domain Computers" and MPU_admin_group. If you used the attribute editor to look at the attributes for MPU_admin_group, you will see the "member" attribute has the distinguished names for all of its members. Great! Now to break it: make the MPU_admin_group the primary group for MPUone. Go back and look at the "member" attribute for MPU_admin_group and you will see the entry for MPUone is gone. The GUI still shows MPUone is a member because MPUone has MPU_admin_group as its primary group, but that membership is no longer directly recorded in the "member" list. Since the LDAP query is looking at the list in the "member" attribute, the indirect membership is not seen.
This was with an MPU8032 running 1.20.12.23112 and Windows 2008 R2 domain controller.