On 08/21/2012 07:08 AM, Theparanoidone Theparanoidone wrote:
Hi Alan~
We have tried to copy all configuration settings from the old server
to the new (so that nothing would change). We have no desire to
change any of our configurations because they previously were
working.
What happened? What changed? You've been careful to avoid
saying that.
I suspect the biggest change is the default executable of freeradius
that is currently shipping with Mountain Lion server (as opposed to
Snow Leopard). (I'm guessing this version may have some Apple
quirks to it???) radiusd -v radiusd: FreeRADIUS Version 2.1.12, for
host i386-apple-darwin12.0, built on Jun 20 2012 at 16:50:26
So again... we've tried to keep all configuration files the same...
if we /etc/raddb/users has the following ending entry... it does not
appear to tag the VLAN anymore:
You are aware how "Group-Name" works, and which groups it is referring
to, right? Specifically, it is not a real attribute, and doesn't exist
in a concrete form. Rather, when you perform a comparison, a real-time
search is done against the relevant database using the value on the
right-hand side.
Group-Name queries the POSIX "getgrnam" APIs, which are normally backed
by /etc/group, but can be supplemented/replaced by nsswitch.
Assuming you have it installed, what does:
python -c '\
import grp;\
print "testuser" in grp.getgrnam("testgroup").gr_mem'
...say? This fragment uses the same APIs as "Group-Name".
If this says "True" then you've mis-configured FreeRADIUS somehow. If it
says "False", then the user isn't in the group as reported by those
APIs, and you'll need to query your group database another way. It might
be the latter - maybe your new OS X machine isn't pulling Unix group
from OpenDirectory, but the old one was?
Usually, using "Group-Name" is a bad choice; if there is a backend
database (LDAP, SQL, text files) you are better off querying it
directly, rather than interposing the get*nam APIs.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
