group authorization

[Brendan Kearney]

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.