group authorization

[Alan DeKok]

Brendan Kearney wrote:
> as defaulted in the config:
> #groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=
> %{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=
> %{control:Ldap-UserDn})))"

  The LDAP-UserDn attribute is populated by the rlm_ldap module, with
the user's DN.  The intention is that the DN can be used to identify the
user in later queries.

  i.e. the rlm_ldap module takes User-Name = 'bob' as one of the inputs,
does a search with that in the "filter", and gets a unique entry.  It
finds the DN in that entry, and uses it to create the LDAP-UserDn attribute.

  Caching the LDAP-UserDn attribute means that the ldap module can do
faster ldap searches, as it knows the user's DN.  It doesn't have to
find the user during every search.  It can just grab the users
information directly... because it has a DN.

> 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.

  I don't know what you mean by "short form".  The LDAP-UserDn contains
the full DN as returned by the LDAP server.  If your LDAP server returns
a "short form", then that's the source of the problem.

  i.e. FreeRADIUS just queries LDAP.  If the LDAP server returns crap...
don't blame FreeRADIUS.

  That message is a difficult one to get across.  A lot of people get
upset at me for being "unhelpful", because "Don't blame FreeRADIUS" is
nearly a mantra here.  Yet I'm giving them all the help that's possible
to give.

  FreeRADIUS depends on databases for it's data.  If the databases
return crap... don't blame FreeRADIUS.

  FreeRADIUS depends on the NAS to enforce post-authentication network
access.  If access fails when it should succeed, or succeed when it
should fail... don't blame FreeRADIUS.

  FreeRADIUS depends on the NAS to supply accounting data.  If the NAS
doesn't send it... don't ask "How do I configure FreeRADIUS to get X in
accounting packets?"

  Much of your hostility is due to the above issues.  FreeRADIUS is
working the way it's designed to work.  Yet something is going wrong.
You're blaming FreeRADIUS.  I'm trying to convince you that (in this
case), it's very likely something else.

  And yes, I do sometimes say that FreeRADIUS has bugs.  I'm not
completely soulless.  When people report a bug, the turn-around time for
a fix is often measure in *minutes*.  Try having any commercial product
beat that.

>  the value therefore, cannot be a called a DN.

  It's *intended* to be the DN.  If the database supplies crap for that
field... why would you blame FreeRADIUS?

  Think about it.  There is NO configuration entry for LDAP-UserDN in
FreeRADIUS.  The ONLY place it comes from is the database.  Yet it's
filled with crap.

  So... which piece of the puzzle is to blame?

>  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).

  That's all true... provided that the LDAP-UserDN is filled with crap.

> 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.

  Only if your LDAP server returns a UID instead of a DN when FreeRADIUS
asks it for the users DN.

  If you run Version 3, it has MUCH better debugging for LDAP.  It will
print out the exact DN returned by the LDAP server.  That should help
with debugging.  Try that.  If the DN is crap... go fix your database.
Or, update the FreeRADIUS queries to work with a crap DN.  That's why
the queries are editable.

> 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.

  Likely because the LDAP server returned something unexpected for the
users DN.

  Again, FreeRADIUS isn't a database.  It isn't magic.  It asks the LDAP
server for information, and then uses that information in later LDAP
queries.  All of the LDAP queries used by FreeRADIUS are documented in
the rlm_ldap module configuration file.  They're printed out in
debugging mode.  All of this is to tell you *exactly* what it's doing.

> ldapsearch -h ldap1 "(&(objectClass=posixGroup)(memberUid=brendan))"
> the above will work and return the posixGroup groups that i am a member
> of.

  You can use that in group membership filters.  That's why the
configuration is text and editable... so you can edit it.

> 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.

  You can create *any* string out of concatenated variables.  String
expansion is documented extensively in "man unlang", and there are
hundreds of examples in the config files.

  i.e. the debug log you posted previous shows the INPUT strings before
expansion, and the OUTPUT strings after expansion.  This should make it
*very* clear how to create dynamically formulated strings.

> 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.

  I would bet the second.

  The default configuration files are designed to work in as many
situations as possible.  Many people have used the default ldap config
unmodified (only setting hostname), and had it work with OpenLDAP,
Active Directory, Sun DS, and other LDAP servers.

  If a new release didn't do LDAP searches correctly, we would be
*inundated* with complaints.  Since that hasn't happened, I can only
conclude that the 10s of 1000s of people using FreeRADIUS with LDAP
don't have the problems you're seeing.  And therefore there's nothing
wrong with FreeRADIUS.

  Alan DeKok.