On Thu, 2014-03-27 at 16:26 +0100, Jan-Frode Myklebust wrote:
I don't quite see why you conclude that it's the shortname "brendan" that's being used when searching for group memberships, but if that's correct, maybe you can work around it by changing the groupmembership_filter to:
groupmembership_filter = "(&(objectClass=GroupOfNames)(member=uid=%{User-Name},ou=Users,dc=bpk2,dc=com))"
-jf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
as defaulted in the config: #groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member= %{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember= %{control:Ldap-UserDn})))" the "groupOfNames" objectClass specifically MUST have the "member" attribute. the "member" attribute has a syntax of "Distinguished Name" (1.3.6.1.4.1.1466.115.121.1.12). Per RFC 2252, that is: 6.9. DN ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known. Examples (from [5]): CN=Steve Kille,O=Isode Limited,C=GB OU=Sales+CN=J. Smith,O=Widget Inc.,C=US CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB CN=Before\0DAfter,O=Test,C=GB 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB SN=Lu\C4\8Di\C4\87 note that the short form (as i have referred to it) is not present in the examples. so, the inappropriately named variable (control:Ldap-UserDn) does not contain a LDAP DN value when that value is not distinguishable or fully qualified. the value therefore, cannot be a called a DN. moreover, that value cannot used to query for group memberships in groupOfNames or groupOfUniqueNames groups. the short form value can be used to query for group memberships in posixGroup groups, though. the short form is a UID string, and implies a posixAccount (unless using RFC2307bis). the "posixGroup" objectClass specifically MAY have a "memberUid" attribute. the "memberUid" attribute has a syntax of "IA5 String" (1.3.6.1.4.1.1466.115.121.1.26). Per RFC 2252, that is: 6.15. IA5 String ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) The encoding of a value in this syntax is the string value itself. its a simple string. take the "uid=" off the string and it leaves the actual uid of "brendan", in my case. this is sometimes the value of the commonName (CN). the inappropriately named variable (control:Ldap-UserDn) should be called something more along the lines of UID and not DN if it contains the UID string. to sum it up: uid=brendan when used in a query will not match anything in a groupOfNames/groupOfUniqueNames group. the variable populated with that value should not be call anything to do with a DN (Distinguished Name) because it is not a DN. the group type being queried and the member type have to match. example: ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(member=uid=brendan,ou=users,dc=bpk2,dc=com))" the above will work and return the grouOfNames groups i am a member of. ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(member=uid=brendan))" and ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(memberUid=brendan))" both fail to return any matches. uid=brendan when used in a query will match appropriately in a posixAccount group. the variable populated with that value should be called something along the lines of a UID, because thats what it is. the group type being queried and the member type have to match. example: ldapsearch -h ldap1 "(&(objectClass=posixGroup)(memberUid=brendan))" the above will work and return the posixGroup groups that i am a member of. i hope this clears up the ambiguity i have found in the configs. what remains, is what i need to do to correctly lookup groupOfNames memberships of users by their DN. while your proposed filter does seem to accomplish that, i would like to know if a more dynamically formulated string can be put together, to create the DN out of concatenated variables. just a more scalable solution. man unlang is where i plan to look, now that i know that is the relevant place to be reading up on it. i will point out at this time that "tens of thousands of others" who are using FreeRADIUS with LDAP successfully either got lucky and have posixGroup groups being matched, figured this out and have not sought/provided clarification on the subject, or are not doing what i am doing with LDAP.