Send Freeradius-Users mailing list submissions to
freeradius-users@lists.freeradius.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freeradius.org/mailman/listinfo/freeradius-users
or, via email, send a message with subject or body 'help' to
freeradius-users-request@lists.freeradius.org
You can reach the person managing the list at
freeradius-users-owner@lists.freeradius.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Freeradius-Users digest..."
Today's Topics:
1. Re: Not trivial configuration of Freeradius as DHCP server
(Tony DeMatteis)
2. Re: Old school: FreeRADIUS and NIS (Alan DeKok)
3. Re: Old school: FreeRADIUS and NIS (Alan DeKok)
4. Re: Old school: FreeRADIUS and NIS (A.L.M.Buxey@lboro.ac.uk)
5. RE: Authorise based on Calling Station ID ?
(Darren Ward (darrward))
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Mar 2014 13:07:37 -0700
From: Tony DeMatteis <tonyd@commspeed.net>
To: freeradius-users@lists.freeradius.org
Subject: Re: Not trivial configuration of Freeradius as DHCP server
Message-ID: <531E1B89.4040007@commspeed.net>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hello,
Took this snippet from what I'm doing which I got from a colleague who
first pulled a working config together. See where you can with this...
'dhcp' folder resides in raddb/dhcp and the dhcp-config.txt file is raddb/sites-available/dhcp
# Main conf - dhcp-config.txt
server dhcp {
client any {
ipaddr = 0.0.0.0
#netmask = 0
dhcp = yes
}
listen {
ipaddr = *
port = 67
type = dhcp
}
dhcp DHCP-Discover {
update reply {
DHCP-Message-Type = DHCP-Offer
}
switch "%{DHCP-Gateway-IP-Address}" {
case 192.168.60.1 {
$INCLUDE dhcp/pool_system1
}
case 10.20.0.1 {
$INCLUDE dhcp/pool_system2
}
case {
# Do not reply to DHCP requests from subnets
# which we are not authoriative
update reply {
DHCP-Message-Type !* 0
}
do_not_respond
}
}
# Global DHCP parameters
$INCLUDE dhcp/global
dhcp_sqlippool
if(notfound || noop) {
reject
}
ok
}
dhcp DHCP-Request {
update reply {
DHCP-Message-Type = DHCP-Ack
}
switch "%{DHCP-Gateway-IP-Address}" {
case 192.168.10.1 {
$INCLUDE dhcp/pool_system1
}
case 10.20.0.1 {
$INCLUDE dhcp/pool_system2
}
case {
# Do not reply to DHCP requests from subnets
# which we are not authoriative
update reply {
DHCP-Message-Type !* 0
}
do_not_respond
}
}
# Global DHCP parameters
$INCLUDE dhcp/global
dhcp_sqlippool
if(notfound || noop) {
reject
}
ok
}
dhcp DHCP-Inform {
}
# If there's no named section for the packet type, then the packet
# is processed through this section.
dhcp {
# send a DHCP NAK.
reject
}
}
# End main conf
# Global Conf
# ./dhcp/global.conf
update reply {
DHCP-Domain-Name-Server = 8.8.8.8
DHCP-Domain-Name-Server += 8.8.4.4
DHCP-Domain-Name = "mydomain.com"
DHCP-DHCP-Server-Identifier = <dhcp-server-ip>
}
# System 1 devices - Cable Modems
# ./dhcp/pool_system1.conf
if(DHCP-Vendor-Class-Identifier =~ /^docsis[1-2].*$/){
update control {
Pool-Name := 'system_pool1'
}
}
# System 2 devices
# ./dhcp/pool_system2.conf
if(DHCP-Vendor-Class-Identifier){
update reply {
DHCP-Subnet-Mask = 255.255.255.0
DHCP-Router-Address = 10.20.0.1
DHCP-Broadcast-Address = 10.20.0.255
DHCP-IP-Address-Lease-Time = 3600
}
update control {
Pool-Name := 'system_pool2'
}
}
On 03/10/2014 12:38 PM, Alan DeKok wrote:
> Vyacheslav Maliev wrote:
>> Hello! I`ve tried to configure my freeradius installation like described
>> here http://wiki.freeradius.org/guide/dhcp-for-static-ip-allocation
>> but it`s very simple case for only one subnet. Now we have two networks
>> which needs to get IP by DHCP server. So is there any possibility to
>> configure DHCP scopes for different networks? Thanks!
> Yes. It's not as easy as with a dedicated DHCP server. You'll need
> to split the packets, so that some use subnet A, and some use subnet B.
> Look at the packets (radiusd -X) to see how they're different. Usually
> there will be a gateway IP address different, or perhaps something else.
>
> It's probably best to use groups to assign the network parameters.
> e.g. use the radgroupcheck and radgroupreply tables. For users in group
> A, assign them options for network A, and users in group B should be
> assigned options in network B.
>
> i.e. separate the *common* configuration into group parameters. Thenm
> each user should have only user-specific parameters. e.g. an IP
> address, and a group membership.
>
> For v3.1, we're looking at maybe coming up with DHCP-specific queries
> for SQL. But getting help from other people would be useful, too.
>
> Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140310/b8edb1a8/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 10 Mar 2014 16:18:57 -0400
From: Alan DeKok <aland@deployingradius.com>
To: FreeRadius users mailing list
<freeradius-users@lists.freeradius.org>
Subject: Re: Old school: FreeRADIUS and NIS
Message-ID: <531E1E31.7050809@deployingradius.com>
Content-Type: text/plain; charset=ISO-8859-1
Arran Cudbard-Bell wrote:
> An excerpt from the Fedora list:
It's nice to see he's getting the same answers from others.
i.e. the problem isn't us.
> > Thing is, based on my searching, getting FreeRADIUS to work with NIS
> > isn't possible. At least I've found no documentation on how to make
> > it work. There's tons on getting it to work with LDAP, but not NIS.
> > Which is the reason for my OP.
I fail to see what the problem is. NIS is just a way of adding more
back-ends to getpwent() and getspwent(). The applications using those
function calls don't need to do anything.
i.e. to "integrate" FreeRADIUS with NIS, you just configure NIS.
Then, use the "unix" module in FreeRADIUS, in the "authenticate"
section. The module will do PAP checks by using getspwent() to get the
crypt'd password.
*Where* that crypt'd password comes from is for NIS to determine.
FreeRADIUS (and the Unix module) doesn't need to do anything.
His question amounts to "how do I get FreeRADIUS to read files from
MySQL, where MySQL is using ext4 instead of ext3". The answer is "you
don't". FreeRADIUS interacts with X, and X does it's magic. What's
*behind* X doesn't matter.
Either NIS works, and getspwent() returns something useful, or NIS
doesn't work, and getspwent() doesn't return anything. Maybe running
FreeRADIUS as "root" will help. But if that doesn't work, then the
problem is NIS (or something else), *not* FreeRADIUS.
And yes, this is one of my common answers. It's why my answers are
seen as "unhelpful". I talk about the *cause* of the problem, not the
*symptom*. Very often, the cause of the problem is a something external
to FreeRADIUS. The symptom is that FreeRADIUS doesn't work the way you
want, but that's just a symptom.
Sadly, some people *refuse* to understand this.
Alan DeKok.
------------------------------
Message: 3
Date: Mon, 10 Mar 2014 16:22:03 -0400
From: Alan DeKok <aland@deployingradius.com>
To: FreeRadius users mailing list
<freeradius-users@lists.freeradius.org>
Subject: Re: Old school: FreeRADIUS and NIS
Message-ID: <531E1EEB.8010605@deployingradius.com>
Content-Type: text/plain; charset=ISO-8859-1
Adam Bishop wrote:
> I suspect the problem here is either SELinux or the shadow group not existing.
Quote possibly.
> RHEL doesn't have a shadow group by default - as it's a nasty hack and potential source of vulnerability, you're expected to have the sense to create it yourself if its needed.
That's unfriendly. Oh well.
> It's also tagged with a unique policy type:
>
> [root@orps1 ~]# ls -alZ /etc/shadow
> ----------. root root system_u:object_r:shadow_t:s0 /etc/shadow
>
> Which I *think* would cause an AVC denial.
Yes.
> Then there's the small matter of /etc/shadow having no permission mask by default.
Arg. That's Unix 101 debugging, TBH. Track down the root cause of
the problem, and fix it.
> But someone who's been doing this for a long time would have checked such things, or even provided us with the output of strace, right? :)
Yes. The people who claim decades of experience usually don't follow
standard practices. The people who have decades of experience just get
follow standard practice, and things done.
Alan DeKok.
------------------------------
Message: 4
Date: Mon, 10 Mar 2014 20:42:57 +0000
From: A.L.M.Buxey@lboro.ac.uk
To: FreeRadius users mailing list
<freeradius-users@lists.freeradius.org>
Subject: Re: Old school: FreeRADIUS and NIS
Message-ID: <20140310204257.GC4519@lboro.ac.uk>
Content-Type: text/plain; charset=us-ascii
Hi,
> I don't think I've ever flamed anyone in my life, but now I believe I
> have to.
oh..this is going to be interesting... just grabbing the popcorn and
cola ready for the show! :-)
<snip> oh...that wasnt a flame!
disappointed...the rest of the popcron is going away now and the colas
going to be flat for when its needed :(
> Radiusd.conf DOES NOT talk about issues with reading /etc/shadow.
> ANYWHERE. PERIOD.
..do you mean this bit of radiusd.conf:
# On systems with shadow passwords, you might have to set 'group = shadow'
# for the server to be able to read the shadow password file. If you can
# authenticate users while in debug mode, but not in daemon mode, it may be
# that the debugging mode server is running as a user that can read the
# shadow info, and the user listed below can not.
? seems clear to me.
> And due to that 'take two steps forward and half-dozen back', I've
> made it clear to my boss that FreeRADIUS, while it may work just fine,
lets hope I dont come across the contact details for your boss ;-)
alan
------------------------------
Message: 5
Date: Mon, 10 Mar 2014 20:46:19 +0000
From: "Darren Ward (darrward)" <darrward@cisco.com>
To: FreeRadius users mailing list
<freeradius-users@lists.freeradius.org>
Subject: RE: Authorise based on Calling Station ID ?
Message-ID:
<5D5ED6338DFDB54B8E876331223AEE2D1F88F871@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Hi Alan
I guess the question is because the accounting files are the only place that contains both the calling-station-id and username how can I write unlang in the authorise that would be able to look up the active session to match the mac address?
i.e. I would need to parse the accounting files for the mac address and find the matching username then look up the username in the 'users' file to authorise with the appropriate attributes
I'm not sure how to do that lookup of files or cache
Darren
-----Original Message-----
From: freeradius-users-bounces+darrward=cisco.com@lists.freeradius.org [mailto:freeradius-users-bounces+darrward=cisco.com@lists.freeradius.org] On Behalf Of Alan DeKok
Sent: Monday, 10 March 2014 11:11 PM
To: FreeRadius users mailing list
Subject: Re: Authorise based on Calling Station ID ?
Darren Ward (darrward) wrote:
> The mac address was sent by the wifi controller as the
> calling-station-id but the question is how do I match that field
> against the user to authorise them?
$ man unlang
It tells you how to do if/then/else checks.
Perhaps you have a more specific question?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
End of Freeradius-Users Digest, Vol 107, Issue 42
*************************************************