FreeRADIUS fails to include attributes in response to a Juniper switch

[Alan DeKok]

On Aug 12, 2022, at 7:30 AM, White, Daniel E. (GSFC-770.0)[AEGIS] via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
>  Old and not necessary.  Delete it.
> 
> It is in the default file from  freeradius.x86_64               3.0.20-12.module+el8.6.0+13617+542eca26                @rhel-8-for-x86_64-appstream-rpms

  Are you using those entries?  No?  Then they don't do anything for you.  Either they can be left alone, (because they have no effect), or they can be deleted (because they have no effect).

  The server comes with many examples and defaults for many different situations.  We're well aware of where these come from.  The goal is to allow administrators to get "most things" working quickly, with minimal effort.

  But it never hurts to read the examples and defaults.  For many reasons.  It helps you understand how the server works.  I helps you see examples of the server doing different things.  And it lets you read something and go "I'm not using that feature, I can probably delete this bit of the configuration".

>  The documentation makes it clear that "Group" and "Group-Name" is for unix group checking.
> ...
> Please be more specific as to “the documentation”.  I found “LDAP-Group", "Group", and "Group-Name" referenced in dictionary.freeradius.internal but without any  explanation.

  Is that the only documentation which comes with the server?

  If you read the LDAP module configuration and documentation, it says to use LDAP-Group for LDAP group checking.  Nothing in any of the LDAP documentation says to use Group or Group-Name.

  There is *other* documentation which refers to Group and Group-Name, and *other* module configuration.  But that doesn't matter, because you're not using the relevant module(s).

> Where is the documentation about adding VSA’s to the RADIUS response, please ?

  VSA documentation is not needed.  There is nothing special about VSAs.  They're just attributes with names.

  So to add VSAs to the response, you use "name = value", as with any other attribute.  You got that part right in the example "users" file you posted.  If you had fixed it so that the rest of it was correct, you would have seen the Juniper-Local-User-Name in the response.

  Your "users" file entry would have worked if you had added reply attributes to the line using LDAP-Group.  Which was what I was suggesting that you do.  If you had simply done that, there would be no need to ask the question about "adding VSAs to the RADIUS response".  You would have done it, and seen that it worked.

  There are few things to improve here.  One is a methodical approach.  This is documented in "man radiusd" among other places.  Make one change, test it, and go to the next thing only when that change works.  This method allows you to focus on one problem at a time.  It also is *faster* than making a bunch of changes, and then trying to figure out which of 10 things broke the server.

  Making one change at a time also lets you understand the server better.  It lets you ignore all of the stuff you don't care about right now, and focus on the behavior difference which MUST be due to that change.  That lets you build a mental model of how the server works, one piece at a time.

  Another thing to improve is attention to detail.  Nothing in the documentation says you can use "Group" or "Group-Name" for LDAP group checking.  The documentation DOES say to use LDAP-Group.  It is therefore completely wrong (and a waste of time) to use anything other than LDAP-Group for group checking.

  The same goes for "users" file entries.  Don't just randomly type things in, and wonder why entries with no reply attributes don't send reply attributes.  The format of the "users" file is document, and the file itself points you to the relevant "man" page.  It is a complete waste of time to randomly poke at the file without understanding how it works.  A much better approach is to read the documentation, and edit the file with the goal of creating a configuration that reaches the goal you want, given the behavior of the "users" file.

  The way it's coming across right now is that you don't read the documentation, or you don't believe it, or you simple don't pay attention.  This approach is guaranteed to waste enormous amounts of time.

  Alan DeKok.