Radius + LDAP + SecurID
So I've been beating my head against a wall on this
for a few days, so I figured I'd share what "worked"
now that the swelling has gone down.
Configuration is fairly straight forward. I have
authorization via LDAP (AD), and Authentication via
SecurID (via PAM..yeah, I know you aren't s'posed to
use PAM 'cause of mem leaks, and the SecurID one certainly
had 'em, but the latest module has been stable in Radius 1.1.7
for me for over 2 years on multiple platforms).
I previously had a simple radius to securid bridge I'm just
now adding in LDAP.
Using FreeRadius 2.1.10 (I patched it for an exec callout
which can be found in the devel group).
Used the "default" site and enabled ldap:
authorize {
preprocess
auth_log
# This is important and (it's ommision) was
# the cause of the lump on my skull
files
ldap
}
authenticate {
pam
}
modules/ldap
ldap {
server = "mydc"
port = 636
identity = "exec:my_callout"
password = "exec:my_callout"
basedn = "dc=some,dc=corp,dc=com"
filter = "(CN=%{%{Stripped-User-Name}:-%{User-Name}})"
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
tls_mode= yes
tls {
start_tls = no
cacertfile = /path/to/cafile
require_cert= "demand"
}
dictionary_mapping = ${confdir}/ldap.attrmap
edir_account_policy_check = no
groupmembership_filter = "(&(objectClass=group)(member=%{Ldap-UserDn}))"
groupmembership_attribute = "memberOf"
chase_referrals = no
rebind = no
set_auth_type = no
}
users file:
DEFAULT Ldap-Group == "admins", Auth-Type = pam
Reply-Message = "Hello (admin), %{User-Name}",
(other attributes)
Fall-Through = No
DEFAULT Ldap-Group == "Operators", Auth-Type = pam
Reply-Message = "Hello (operator), %{User-Name}",
(other attributes)
Fall-Through = No
DEFAULT Auth-Type := Reject
Reply-Message = "you are not authorized"
So what happens is the user sends his request, the user ID is looked
up in AD and then the groups are looked up for that user, in the order
listed in the users file, until a match is found. If a match is found,
it passes to the Auth-Type for authentication otherwise sends back a reject.
Note, this is a basic POC config.
As another note, I found a python module (pyrad, not py-radius) very helpful
in debugging this. radtest is nice, but I don't like entering my pin in he
clear
on a shared unix box. Here's a script I used for that (merged the good of the
py-radius
example with the pyrad example):
-cut --
#!/usr/bin/python
import socket, sys
import pyrad.packet
from getpass import getpass
from pyrad.client import Client
from pyrad.dictionary import Dictionary
secret = ''
uname,passwd = None,None
while not secret: secret = getpass('RADIUS Secret? ')
while not uname: uname = raw_input("Username? ")
while not passwd: passwd = getpass("Password? ")
srv=Client(server="localhost",
secret=secret,
dict=Dictionary("/path/to/dictionary"))
print "read dictionary"
req=srv.CreateAuthPacket(code=pyrad.packet.AccessRequest,
User_Name=uname)
req["User-Password"]=req.PwCrypt(passwd)
req["Service-Type"] = "Login-User"
try:
print "Sending authentication request"
reply=srv.SendPacket(req)
except pyrad.client.Timeout:
print "RADIUS server does not reply"
sys.exit(1)
except socket.error, error:
print "Network error: " + error[1]
sys.exit(1)
if reply.code==pyrad.packet.AccessAccept:
print "Access accepted"
else:
print "Access denied"
print "Attributes returned by server:"
for i in reply.keys():
print "%s: %s" % (i, reply[i])
---cut ---
R. Marc
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius capable of url-redirect
I'm afraid I still can't get this to work at all. I decided to pare down my
test to its simplest form. Basically I created a test user with the AVPair
configuration as below. Which is basically what Cisco describes in its
documentation (but with ACS).
# test user
test_login Cleartext-Password := "test_pass"
Cisco-AVPair +=
"url-redirect=http://www.cisco.com/index.html";,
Service-Type = Outbound-User
So essentially this user should indeed trigger the controller with that
AVPair configuration. Later I plan on dynamically triggering it when someone
authenticated using TTLs. (I've also tried "=" instead of "+=" for the
AVPair).
Nathan Van Fleet
> -Original Message-
> From: freeradius-users-
> bounces+nmcdavit=alcor.concordia...@lists.freeradius.org
> [mailto:freeradius-users-
> bounces+nmcdavit=alcor.concordia...@lists.freeradius.org] On Behalf Of
> Alan Buxey
> Sent: Thursday, September 09, 2010 2:24 PM
> To: FreeRadius users mailing list
> Subject: Re: Freeradius capable of url-redirect
>
> Hi,
> > I have in post-auth:
> >
> > If(outer.NAS-IP-Address == x.x.x.x)
> > {
> > Cisco-AVPair += "http:url-redirect=http://www.cisco.com";
> > }
>
> huh? you are checking for a condition and then trying to 'run' that Cisco
> attribute. what you want to do is SET that attribute...eg
>
> if(outer.NAS-IP-Address == x.x.x.x)
> {
> update request {
> Cisco-AVPair += "http:url-redirect=http://www.cisco.com";
> }
> }
>
>
> or somesuch.
>
> alan
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
I think it depends on the OS, if a OS is trusting and accepts everything up the stack from Layer 2 if the MAC address matches it could start to get confused and cause all sorts of issues. If the device keeps some kind of state table for connections and rejects all others there may not be to much of an issue. Naturally in the switched environment it would not work at all. As far a Mac auth, we do that here as well, basically for printers and such and as you stated you just enter the MAC address for the password then push out the tunnel Group ID, tunnelmediumtype and tunnel-type. Of course this is on a switched network but for our Wireless it works remarkably similar yet again we use username/password authentication on that. We do not have to worry to much about session hijacking or MAC spoofing on the wireless side because we use WPA2 with AES and dot1x on the auth side. One thing you may want to do is have a default unprotected vlan that is the default network, have it go directly web page with instructions on connecting with a secure connection. If you care anything about your users/customers I would say at least offer them some kind of protection, it is just to easy to sniff unprotected wireless networks. -- Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE >>> On Wednesday, February 02, 2011 at 12:00 PM, in message <8860_1296676852_4D49B7F4_8860_589_1_D9B37353831173459FDAA836D3B43499AF0FA683@WA PMBXV0.waddell.com>, Gary Gatten wrote: > On shared medium, I don't *think* dupe macs will cause much problem, unless > maybe a congestion algorithm tweaks traffic to/from that mac. I'm not an > expert in that area, just speaking from experience. > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Active Directory and authorize section
2011/2/2 Brett Littrell > Hi Brian, > > Thanks for explaining that, guess that makes sense for performance, > load all the info right away and just wait for authentication to complete > before sending from memory and not doing another query. > > Sorry, did not mean to derail this thread but I a appreciate the > insight. > > Brett Littrell > Network Manager > MUSD > CISSP, CCSP, CCVP, MCNE > > > >>> On Wednesday, February 02, 2011 at 9:01 AM, in message < > 20110202170140.ga12...@talktalkplc.com>, Brian Candler < > b.cand...@pobox.com> wrote: > On Wed, Feb 02, 2011 at 07:23:39AM -0800, Brett Littrell wrote: > >Very interesting, I would have thought Authenticate came first > then > >Authorize since you need to authenticate in order to be authorized. > > The RADIUS protocol kind of fuzzes the two concepts: an Accept-Request is > both a request for authentication and authorization. An Access-Reject > could > mean either that you weren't authenticated, or that you're not authorized > for the service you wanted. > > FreeRADIUS runs boths sections of its config before sending the reply, > because generally authentication needs some data to authenticate, and that > data normally comes from the same place as the authorization data. > > >If > >that is the case and say you pull the vlan ids from ldap, or some > other > >directory, how would Freeradius know what those values are prior to > >knowing who you are? > > It knows who you *claim* to be (User-Name), so can use that to look up the > reply attributes. It doesn't know you actually *are* that person yet, but > it won't send back an Access-Accept until it does. > > >Or are you saying that the way the program loads > >the config the authorize section simply gets read first? > > The authorize section gets executed first; I don't think it makes any > difference what order you put them in the config file. > > Regards, > > Brian. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > -- Att, Maiquel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
Thanks for the tip, Schilling.
We wanted to provide a "splash page" for unauthenticated access attempts.
This helps to answer a whole other list of questions on "how" to do that.
Jim
--- On Wed, 2/2/11, schilling wrote:
> From: schilling
> Subject: Re: MAC Authentication - Bad Idea?
> To: "FreeRadius users mailing list"
> Date: Wednesday, February 2, 2011, 11:32 AM
> We implemented MAC authentication
> with netreg at
> http://netreg.sourceforge.net. We used DHCP/DNS/HTTP
> piece from
> netreg. It's essence is DHCP/DHS/HTTP on one server.
> Basically there will be a vlan we called sandbox
> with ip
> helper-address pointing to sandbox.foo.edu. The DHCP
> is configured to
> have DNS pointing to sandbox.foo.edu too. bind is
> configured to
> resolve everything to sandbox.foo.edu. HTTP is configured
> with dynamic
> webpage as explained later on.
>
> The logic is like the following
> if (mac not in your database ) {
> send back a sandbox vlan
> #user open any webpage will get redirected to
> single server
> }
> else if (mac in your database) {
> if (user blocked ) {
> sendback sandbox VLAN
> }
> send back regular vlan name with additional
> attribute as you want
> }
>
> On the web server, if you are here, you are either
> unregistered or
> registered but blocked. We have dynamic webpage to do the
> following
> things
> #mac not registered
> #user webpage to get IP, then use IP to get MAC from DHCP
> lease file
> if (MAC not in database ) {
> webportal of login with (ldap, ssh,
> ftp) backend,
> mac address will be populated in the
> database.
> }
> #mac in database but blocked
> else {
> display the mac is blocked and
> call helpdesk
> }
>
> We use this to gain a lot of knowledge/experience on dot1x,
> and are
> now moving toward 802.1x.
>
> Schilling
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
On shared medium, I don't *think* dupe macs will cause much problem, unless maybe a congestion algorithm tweaks traffic to/from that mac. I'm not an expert in that area, just speaking from experience. - Original Message - From: Brian Candler [mailto:b.cand...@pobox.com] Sent: Wednesday, February 02, 2011 01:53 PM To: FreeRadius users mailing list Subject: Re: MAC Authentication - Bad Idea? On Wed, Feb 02, 2011 at 11:15:13AM -0800, Jim Rice wrote: > Do I need to be concerned with MAC spoofing? It's easy to do, so it will probably happen; this risk is weighed against providing a service which is easy for your customers to use. What happens if two people try to use the same MAC address simultaneously on your wireless network? I suspect it will break service for both of them, which means that it's actually not very useful for freeloading. They'd have to coordinate to use it at different times. You could also look for simultaneous users in your RADIUS accounting logs. Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
On Wed, Feb 02, 2011 at 11:15:13AM -0800, Jim Rice wrote: > Do I need to be concerned with MAC spoofing? It's easy to do, so it will probably happen; this risk is weighed against providing a service which is easy for your customers to use. What happens if two people try to use the same MAC address simultaneously on your wireless network? I suspect it will break service for both of them, which means that it's actually not very useful for freeloading. They'd have to coordinate to use it at different times. You could also look for simultaneous users in your RADIUS accounting logs. Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
We implemented MAC authentication with netreg at
http://netreg.sourceforge.net. We used DHCP/DNS/HTTP piece from
netreg. It's essence is DHCP/DHS/HTTP on one server.
Basically there will be a vlan we called sandbox with ip
helper-address pointing to sandbox.foo.edu. The DHCP is configured to
have DNS pointing to sandbox.foo.edu too. bind is configured to
resolve everything to sandbox.foo.edu. HTTP is configured with dynamic
webpage as explained later on.
The logic is like the following
if (mac not in your database ) {
send back a sandbox vlan
#user open any webpage will get redirected to single server
}
else if (mac in your database) {
if (user blocked ) {
sendback sandbox VLAN
}
send back regular vlan name with additional attribute as you want
}
On the web server, if you are here, you are either unregistered or
registered but blocked. We have dynamic webpage to do the following
things
#mac not registered
#user webpage to get IP, then use IP to get MAC from DHCP lease file
if (MAC not in database ) {
webportal of login with (ldap, ssh, ftp) backend,
mac address will be populated in the database.
}
#mac in database but blocked
else {
display the mac is blocked and call helpdesk
}
We use this to gain a lot of knowledge/experience on dot1x, and are
now moving toward 802.1x.
Schilling
On Wed, Feb 2, 2011 at 2:15 PM, Jim Rice wrote:
> Thanks, Alan.
>
> The MikroTik routers can be configured to send a variety of MAC address
> formats, the default is XX:XX:XX:XX:XX:XX
>
> It can also be set to include the same MAC address in the Password field,
> instead of NULL, but I do not see any added benefit to that.
>
>>> but had to set Auth-Type := Accept.
>>
>> Hmm... that's probably not the best way to do it,
>> but if it works...
>
> Is there a best (or better) way?
>
> Do I need to be concerned with MAC spoofing?
>
> Thanks again,
>
> Jim
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
Hi, > Do I need to be concerned with MAC spoofing? of course. theres also the issue that the link-layer is completely open and unencrypted to any eavedropping/dodgy activity alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MAC Authentication - Bad Idea?
What about ppp based auth? Many providers in the US still use this for xDSL service. If the CPE supports it, it's usually transparent to the users. G -Original Message- From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell@lists.freeradius.org] On Behalf Of Jim Rice Sent: Wednesday, February 02, 2011 1:15 PM To: FreeRadius users mailing list Subject: Re: MAC Authentication - Bad Idea? Thanks, Alan. The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that. >> but had to set Auth-Type := Accept. > > Hmm... that's probably not the best way to do it, > but if it works... Is there a best (or better) way? Do I need to be concerned with MAC spoofing? Thanks again, Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
Thanks, Alan. The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that. >> but had to set Auth-Type := Accept. > > Hmm... that's probably not the best way to do it, > but if it works... Is there a best (or better) way? Do I need to be concerned with MAC spoofing? Thanks again, Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC Authentication - Bad Idea?
Jim Rice wrote: > Still a newbie, but getting there... (Alan, do you ever sleep?) In a word: no. > I have been asked to implement MAC authentication for a local service > provider with a Canopy radio network and MikroTik routers. No, really. > > I was able to test this and received Accept-Accept after placing the MAC > address in the UserName (Password is ""), but had to set Auth-Type := Accept. Hmm... that's probably not the best way to do it, but if it works... I'd like to write a "MAC auth howto" guide for NAS implementors. It will mostly say "you're doing it wrong". Which isn't much of surprise, I guess. > I haven't found much in the way of documentation regarding MAC authentication > in some of the "dated" books I have on Radius and 802.1x, nor in the > FreeRadius docs. It all depends on what the NAS sends, unfortunately. And every NAS sends something different. > The goal is to provide for different classes of service, bandwidth > management, accounting, etc. I imagine some of this can be done through > vendor specific attributes to dynamically configure the routers (VLANs, data > rates, priority queues and such), based on which group a user belongs. > > Dumb question #1: Just because you can do a thing, it doesn't mean you > should. Can someone give me the "you idiot" speech and talk me out of this? Do MAC auth. Really. It's not hard, and it's useful. The main thing is to normalize the MACs from the NAS before you look them up in the DB. Again, every NAS sends something different. > Deploying client certificates to every device in their network seems an > administrative nightmare. Using usernames/passwords doesn't make sense since > most devices will always be connected. In the days of dial-up, users > understood having to "login" to connect. Today, not so much. > > So, are there better alternatives? Or am I still just a clueless newbie? Do MAC auth. Wait 2-3 years, upgrade to 802.1X everywhere. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
MAC Authentication - Bad Idea?
Greetings, Still a newbie, but getting there... (Alan, do you ever sleep?) I have been asked to implement MAC authentication for a local service provider with a Canopy radio network and MikroTik routers. No, really. I was able to test this and received Accept-Accept after placing the MAC address in the UserName (Password is ""), but had to set Auth-Type := Accept. I haven't found much in the way of documentation regarding MAC authentication in some of the "dated" books I have on Radius and 802.1x, nor in the FreeRadius docs. The goal is to provide for different classes of service, bandwidth management, accounting, etc. I imagine some of this can be done through vendor specific attributes to dynamically configure the routers (VLANs, data rates, priority queues and such), based on which group a user belongs. Dumb question #1: Just because you can do a thing, it doesn't mean you should. Can someone give me the "you idiot" speech and talk me out of this? Deploying client certificates to every device in their network seems an administrative nightmare. Using usernames/passwords doesn't make sense since most devices will always be connected. In the days of dial-up, users understood having to "login" to connect. Today, not so much. So, are there better alternatives? Or am I still just a clueless newbie? Thanks for your patience, Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Active Directory and authorize section
Hi Brian, Thanks for explaining that, guess that makes sense for performance, load all the info right away and just wait for authentication to complete before sending from memory and not doing another query. Sorry, did not mean to derail this thread but I a appreciate the insight. Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE >>> On Wednesday, February 02, 2011 at 9:01 AM, in message >>> <20110202170140.ga12...@talktalkplc.com>, Brian Candler >>> wrote: On Wed, Feb 02, 2011 at 07:23:39AM -0800, Brett Littrell wrote: >Very interesting, I would have thought Authenticate came first then >Authorize since you need to authenticate in order to be authorized. The RADIUS protocol kind of fuzzes the two concepts: an Accept-Request is both a request for authentication and authorization. An Access-Reject could mean either that you weren't authenticated, or that you're not authorized for the service you wanted. FreeRADIUS runs boths sections of its config before sending the reply, because generally authentication needs some data to authenticate, and that data normally comes from the same place as the authorization data. >If >that is the case and say you pull the vlan ids from ldap, or some other >directory, how would Freeradius know what those values are prior to >knowing who you are? It knows who you *claim* to be (User-Name), so can use that to look up the reply attributes. It doesn't know you actually *are* that person yet, but it won't send back an Access-Accept until it does. >Or are you saying that the way the program loads >the config the authorize section simply gets read first? The authorize section gets executed first; I don't think it makes any difference what order you put them in the config file. Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Active Directory and authorize section
On Wed, Feb 02, 2011 at 07:23:39AM -0800, Brett Littrell wrote: >Very interesting, I would have thought Authenticate came first then >Authorize since you need to authenticate in order to be authorized. The RADIUS protocol kind of fuzzes the two concepts: an Accept-Request is both a request for authentication and authorization. An Access-Reject could mean either that you weren't authenticated, or that you're not authorized for the service you wanted. FreeRADIUS runs boths sections of its config before sending the reply, because generally authentication needs some data to authenticate, and that data normally comes from the same place as the authorization data. >If >that is the case and say you pull the vlan ids from ldap, or some other >directory, how would Freeradius know what those values are prior to >knowing who you are? It knows who you *claim* to be (User-Name), so can use that to look up the reply attributes. It doesn't know you actually *are* that person yet, but it won't send back an Access-Accept until it does. >Or are you saying that the way the program loads >the config the authorize section simply gets read first? The authorize section gets executed first; I don't think it makes any difference what order you put them in the config file. Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS & Kerberos
not a single bit of EAP being triggered according to these logs. Look at the default server and how it used EAP and pushes request to inner-tunnel. You won't have any password details outside of the EAP tunnel and that ain't been created in your setup. Alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS & Kerberos
On 02/02/11 16:29, Thorsten Fischer wrote:
All,
I have a number of NASs - wireless APs running hostapd. I am setting up a
freeradius 2.1.10 server to control the authentication of
usern...@net.example.com to the wireless network; the decision is to be made by
a Kerberos server. The setup is not working as intended, which I think stems
either from my misunderstanding of the protocols involved or of how to set up
freeradius correctly. Or both.
Later, all authentication requests of usern...@example.com (without the net.)
are to be forwarded to another Radius server. There will likely be more
services integrated in the same vein later, so I would like to branch out into
separate virtual servers based on realm.
My understanding is that the communication between a u...@net.example.com and
freeradius needs to involve EAP-TTLS, because of the cleartext password which
is required to be passed on to kerberos. The required keytab is set up and
configured correctly. modules/krb5 is set up accordingly. bootstrap in
raddb/certs has been run to create self-signed certs.
I have an entry in the users file:
DEFAULTRealm == "net.example.com", Auth-Type = Kerberos
Yeah, that won't work; it is forcing the server to try Kerberos, even
when the request is EAP.
You want something like this in /etc/raddb/sites-enabled/inner-tunnel:
authorize {
...
...
# let the PAP module detect that it's PAP
pap
}
authenticate {
Auth-Type PAP {
# ...but check PAP via kerberos
krb5
}
}
...or:
authorize {
...
# if we get here, set Auth-Type
if (User-Password) {
update control {
# (unless a higher-up module has set it)
Auth-Type = Kerberos
}
}
}
authenticate {
Auth-Type Kerberos {
krb5
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TTLS & Kerberos
All,
I have a number of NASs - wireless APs running hostapd. I am setting up a
freeradius 2.1.10 server to control the authentication of
usern...@net.example.com to the wireless network; the decision is to be made by
a Kerberos server. The setup is not working as intended, which I think stems
either from my misunderstanding of the protocols involved or of how to set up
freeradius correctly. Or both.
Later, all authentication requests of usern...@example.com (without the net.)
are to be forwarded to another Radius server. There will likely be more
services integrated in the same vein later, so I would like to branch out into
separate virtual servers based on realm.
My understanding is that the communication between a u...@net.example.com and
freeradius needs to involve EAP-TTLS, because of the cleartext password which
is required to be passed on to kerberos. The required keytab is set up and
configured correctly. modules/krb5 is set up accordingly. bootstrap in
raddb/certs has been run to create self-signed certs.
I have an entry in the users file:
DEFAULTRealm == "net.example.com", Auth-Type = Kerberos
The realm is set up like this:
realm net.example.com {
virtual_server = net.example.com
}
And the virtual server as well as the inner-tunnel have Auth-Type Kerberos {
krb5 } in their authenticate section, right after Auth-Type PAP.
Key changes in eap.conf:
eap {
default_eap_type = ttls
ttls {
default_eap_type = md5
copy_request_to_tunnel = yes
use_tunneled_reply = yes
}
}
Local tests succeed as follows:
$ radtest -t pap thors...@net.example.com pwd 127.0.0.1 0 testing123
$ radtest -t eap-md5 thors...@net.example.com pwd 127.0.0.1 0 testing123
$ radtest -t pap thors...@net.example.com pwd 127.0.0.1:18120 0 testing123
In each of these cases, the reason for success is successful communication with
Kerberos, as exemplified by the following lines (and wrong kerberos passwords
let authentication fail):
Wed Feb 2 15:59:06 2011 : Info: Found Auth-Type = Kerberos
Wed Feb 2 15:59:06 2011 : Info: # Executing group from file
/etc/freeradius/sites-enabled/net.example.com
Wed Feb 2 15:59:06 2011 : Info: +- entering group Kerberos {...}
Wed Feb 2 15:59:06 2011 : Info: ++[krb5] returns ok
Wed Feb 2 15:59:06 2011 : Auth: Login OK: [thorsten] (from client localhost
port 0 via TLS tunnel)
However, tests with eapol_test locally as well as with the actual access points
fail:
$ cat eap-ttls.conf
network={
ssid="myssid"
key_mgmt=WPA-EAP
eap=TTLS
identity="thors...@net.example.com"
password="pwd"
phase2="auth=PAP"
}
$ eapol_test -c eap-ttls.conf -s testing123
produces:
rad_recv: Access-Request packet from host 127.0.0.1 port 60596, id=0, length=172
User-Name = "thors...@net.example.com"
NAS-IP-Address = 127.0.0.1
Calling-Station-Id = "02-00-00-00-00-01"
Framed-MTU = 1400
Calling-Station-Id ="02-00-00-00-00-01"
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = "CONNECT 11Mbps 802.11b"
EAP-Message =
0x02250174686f727374656e406e65742e742d6c6162732e74752d6265726c696e2e6465
Message-Authenticator = 0x3f0be4354cfc77a6285a0ad074341101
Wed Feb 2 15:33:32 2011 : Info: # Executing section authorize from file
/etc/freeradius/sites-enabled/default
Wed Feb 2 15:33:32 2011 : Info: +- entering group authorize {...}
Wed Feb 2 15:33:32 2011 : Info: ++[preprocess] returns ok
Wed Feb 2 15:33:32 2011 : Info: ++[chap] returns noop
Wed Feb 2 15:33:32 2011 : Info: ++[mschap] returns noop
Wed Feb 2 15:33:32 2011 : Info: ++[digest] returns noop
Wed Feb 2 15:33:32 2011 : Info: [suffix] Looking up realm "net.example.com"
for User-Name = "thors...@net.example.com"
Wed Feb 2 15:33:32 2011 : Info: [suffix] Found realm "net.example.com"
Wed Feb 2 15:33:32 2011 : Info: [suffix] Adding Stripped-User-Name = "thorsten"
Wed Feb 2 15:33:32 2011 : Info: [suffix] Adding Realm = "net.example.com"
Wed Feb 2 15:33:32 2011 : Info: [suffix] Proxying request from user thorsten
to realm net.example.com
Wed Feb 2 15:33:32 2011 : Info: [suffix] Preparing to proxy authentication
request to realm "net.example.com"
Wed Feb 2 15:33:32 2011 : Info: ++[suffix] returns updated
Wed Feb 2 15:33:32 2011 : Info: [eap] Request is supposed to be proxied to
Realm net.example.com. Not doing EAP.
Wed Feb 2 15:33:32 2011 : Info: ++[eap] returns noop
Wed Feb 2 15:33:32 2011 : Info: [files] users: Matched entry DEFAULT at line 71
Wed Feb 2 15:33:32 2011 : Info: ++[files] returns ok
Wed Feb 2 15:33:32 2011 : Info: ++[expiration] returns noop
Wed Feb 2 15:33:32 2011 : Info: ++[logintime] returns noop
Wed Feb 2 15:33:32 2011 : Info: ++[pap] returns noop
Wed Feb 2 15:33:32 2011 : Info: WARNING: Empty pre-proxy section. Using
default return values.
Wed Feb 2 15:33:32 2011 : Info: >>> Sending proxied request internally to
virtual server.
Wed Feb 2 15:33:32 2011 : In
Re: Active Directory and authorize section
I was thinking about this too. Do we need separate ldap call to retrieve certain attributes from AD, and then use ntlm_auth for authentication? Schilling On Wed, Feb 2, 2011 at 10:23 AM, Brett Littrell wrote: > Hey Brian, > > Very interesting, I would have thought Authenticate came first then > Authorize since you need to authenticate in order to be authorized. If that > is the case and say you pull the vlan ids from ldap, or some other > directory, how would Freeradius know what those values are prior to knowing > who you are? Or are you saying that the way the program loads the config > the authorize section simply gets read first? > > Brett Littrell > Network Manager > MUSD > CISSP, CCSP, CCVP, MCNE > > > >>> On Wednesday, February 02, 2011 at 12:05 AM, in message < > 20110202080557.ga2...@talktalkplc.com>, Brian Candler > wrote: > I'd say that's not exactly true, or is not very clear anyway. > > (1) freeradius always runs the authorize section first, then then > authenticate section > > (2) the authorize section is where you do any sort of database lookups > needed, both to determine the reply attributes to send (in case the user > does authenticate successfully), and at the same time to find any > information needed to perform user authentication, such as the expected > password (Cleartext-Password in the control list) > > (3) the authenticate section normally uses that extra info to perform the > authentication. If it fails, the reply attributes are stripped out and a > reject is sent. > > Using ntlm_auth is a special case, in that it can authenticate without > knowing the password: it delegates the whole authentication to a different > database. > > That's fine, but if you don't have anything in your authorize section then > you'll just be sending back an empty "Access-Accept" without any reply > attributes. In some applications this may be sufficient. > > This sort of delegation is rather like proxying, and indeed, you can run > IAS > on your AD box and just proxy to it. > > IAS has a limitation of 50 RADIUS client IPs (unless you have Windows > Server > Enterprise edition), but fortunately each freeradius server you put in > front > of it only counts as one client :-) > > Regards, > > Brian. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Active Directory and authorize section
Hey Brian, Very interesting, I would have thought Authenticate came first then Authorize since you need to authenticate in order to be authorized. If that is the case and say you pull the vlan ids from ldap, or some other directory, how would Freeradius know what those values are prior to knowing who you are? Or are you saying that the way the program loads the config the authorize section simply gets read first? Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE >>> On Wednesday, February 02, 2011 at 12:05 AM, in message >>> <20110202080557.ga2...@talktalkplc.com>, Brian Candler >>> wrote: I'd say that's not exactly true, or is not very clear anyway. (1) freeradius always runs the authorize section first, then then authenticate section (2) the authorize section is where you do any sort of database lookups needed, both to determine the reply attributes to send (in case the user does authenticate successfully), and at the same time to find any information needed to perform user authentication, such as the expected password (Cleartext-Password in the control list) (3) the authenticate section normally uses that extra info to perform the authentication. If it fails, the reply attributes are stripped out and a reject is sent. Using ntlm_auth is a special case, in that it can authenticate without knowing the password: it delegates the whole authentication to a different database. That's fine, but if you don't have anything in your authorize section then you'll just be sending back an empty "Access-Accept" without any reply attributes. In some applications this may be sufficient. This sort of delegation is rather like proxying, and indeed, you can run IAS on your AD box and just proxy to it. IAS has a limitation of 50 RADIUS client IPs (unless you have Windows Server Enterprise edition), but fortunately each freeradius server you put in front of it only counts as one client :-) Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to store clients.conf in LDAP?
On Wed, Feb 2, 2011 at 4:53 PM, c0re wrote:
> You will
> create Group objects based on the IP Address of the NAS and set the
> "Location" or "l" attribute to the NAS Huntgroup the NAS belongs to
> allow them to be centrally managed in LDAP.
> But what objectClass is it with "l" attribute?
I'm guessing you can just use any available attribute, and simply
adjust the LDAP query (from the original post) if you use another
attribute
#Set the Client-Shortname to be the Location "l" just like in the
Huntgroups, but this time to the shortname.
FreeRADIUS-Client-Shortname =
"%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?l?sub?cn=%{Packet-Src-IP-Address}}";
> When I tried to implement it I stuck with this. Any comments welcome!
Ask Peter directly?
--
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to store clients.conf in LDAP?
Actually it was here http://lists.freeradius.org/pipermail/freeradius-users/2010-October/msg00058.html But Peter Lambrechtsen uses Novell eDirectory, so from his howto Then create two OU's under Radius. Elements and Roles OU=Elements,OU=Radius,DC=ACME,DC=COM Elements will hold a record of every NAS in your Network. You will create Group objects based on the IP Address of the NAS and set the "Location" or "l" attribute to the NAS Huntgroup the NAS belongs to allow them to be centrally managed in LDAP. IE CN=10.1.2.3,OU=Elements,OU=Radius,DC=ACME,DC=COM With a "l" value of "CiscoRTR" for a Cisco Router that has a NAS-IP-Address or Source-IP-Address of 10.1.2.3. This will make more sense further on. But what objectClass is it with "l" attribute? When I tried to implement it I stuck with this. Any comments welcome! 2011/2/2 Fajar A. Nugraha : > On Wed, Feb 2, 2011 at 3:57 PM, c0re wrote: >> But when I add new device I always have to edit clients.conf, add new >> IP address and secret. I do not want to use 0.0.0.0 and same secret >> for all devices. >> >> Is it possible to store device secrets in openldap? If yes, please, >> point me to right direction. > > Try this from the list archive: > http://freeradius.1045715.n5.nabble.com/HOWTO-Centralised-LDAP-Authentication-Part-2-Using-dyamic-clients-instead-of-huntgroups-td3201125.html > > -- > Fajar > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to store clients.conf in LDAP?
On Wed, Feb 2, 2011 at 3:57 PM, c0re wrote: > But when I add new device I always have to edit clients.conf, add new > IP address and secret. I do not want to use 0.0.0.0 and same secret > for all devices. > > Is it possible to store device secrets in openldap? If yes, please, > point me to right direction. Try this from the list archive: http://freeradius.1045715.n5.nabble.com/HOWTO-Centralised-LDAP-Authentication-Part-2-Using-dyamic-clients-instead-of-huntgroups-td3201125.html -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to store clients.conf in LDAP?
c0re wrote: > Is it possible to store device secrets in openldap? If yes, please, > point me to right direction. Not really. And I think your configuration doesn't really do what you think it does. At the minimum, you should be using Packet-Src-IP-Address instead of NAS-IP-Address. See raddb/sites-available/dynamic-clients for examples of how to dynamically add clients. They can likely be read from LDAP with some customized configuration. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How to store clients.conf in LDAP?
Hello freeradius users!
I've configured authentication and authorization via freeradius that
looking in openldap for users and passwords.
In radius.conf in ldap section I used filter
filter =
"(&(cn=%{Stripped-User-Name:-%{User-Name}})(description=%{NAS-IP-Address}))"
So I only need to make description field with IP address of device to
give user access to some device.
But when I add new device I always have to edit clients.conf, add new
IP address and secret. I do not want to use 0.0.0.0 and same secret
for all devices.
Is it possible to store device secrets in openldap? If yes, please,
point me to right direction.
And may be it's possible change way how can I give access to devices
for users? I mean something like group
cn=someSwitch,ou=devices,dc=domain,dc=com, and this group has field
with IP address of device and something like "member: user1" or
"memberUid: cn=user1,ou=users,dc=domain,dc=com". I'm a bit confused
about how to implement it...
Thanks in advance for advices!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Active Directory and authorize section
On Tue, Feb 01, 2011 at 02:33:33PM -0800, Brett Littrell wrote: >The authenticate section is used to just verify that you are who >you are, via certs, username/password, token etc. The authorize >section is where you define the sources for all the information you >want FR to respond to. I'd say that's not exactly true, or is not very clear anyway. (1) freeradius always runs the authorize section first, then then authenticate section (2) the authorize section is where you do any sort of database lookups needed, both to determine the reply attributes to send (in case the user does authenticate successfully), and at the same time to find any information needed to perform user authentication, such as the expected password (Cleartext-Password in the control list) (3) the authenticate section normally uses that extra info to perform the authentication. If it fails, the reply attributes are stripped out and a reject is sent. Using ntlm_auth is a special case, in that it can authenticate without knowing the password: it delegates the whole authentication to a different database. That's fine, but if you don't have anything in your authorize section then you'll just be sending back an empty "Access-Accept" without any reply attributes. In some applications this may be sufficient. This sort of delegation is rather like proxying, and indeed, you can run IAS on your AD box and just proxy to it. IAS has a limitation of 50 RADIUS client IPs (unless you have Windows Server Enterprise edition), but fortunately each freeradius server you put in front of it only counts as one client :-) Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
