Re: MAC address restriction with EAP-TLS
Ivan Kalik t...@kalik.net wrote: We are currently using EAP-TLS authentication with FreeRADIUS at the place where I work right now. Management would like to be able to restrict the use of a given certificate for this authentication to specific MAC addresses. In other words, for each certificate, the desire is to tie that certificate to one or a couple MAC addresses, and to say that that certificate may only be used if it is coming from those specific MAC addresses. If the certificate is used from a different MAC address, then authentication should fail. I have tried to look for info on this on the web to no avail. I also understand that EAP-TLS authentication generally needs to be left out of the users file. But the only way that I can think of to restrict MAC addresses would be to place some kind of line involving a Calling-Station-ID in the users file. So I am at a loss. If you put something like: username Calling-Station-Id != whatever, Auth-Type := Reject user will not be able to connect. Ivan Kalik Kalik Informatika ISP So how would I do the same thing for a certificate instead of a username? Ther will be a username in EAP-TLS request too. From everything that I have been able to read, the user name in a EAP-TLS request should come from the CN value of the certificate. Does this sound correct? Thanks. John Guthrie guth...@counterexample.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC address restriction with EAP-TLS
Ivan Kalik t...@kalik.net wrote:
We are currently using EAP-TLS authentication with FreeRADIUS at the place
where I work right now. Management would like to be able to restrict the use
of a given certificate for this authentication to specific MAC addresses. In
other words, for each certificate, the desire is to tie that certificate to
one or a couple MAC addresses, and to say that that certificate may only be
used if it is coming from those specific MAC addresses. If the certificate
is
used from a different MAC address, then authentication should fail.
I have tried to look for info on this on the web to no avail. I also
understand that EAP-TLS authentication generally needs to be left out of the
users file. But the only way that I can think of to restrict MAC addresses
would be to place some kind of line involving a Calling-Station-ID in the
users
file. So I am at a loss.
If you put something like:
username Calling-Station-Id != whatever, Auth-Type := Reject
user will not be able to connect.
Ivan Kalik
Kalik Informatika ISP
So how would I do the same thing for a certificate instead of a username? Or
would I use something like the CN value on the certificate as the username?
Alternatively, could I use something involving %{User-Name} and
%{Calling-Station-Id} in the check_cert_cn parameter in eap.conf?
Thank you very much for your help.
John Guthrie
guth...@counterexample.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
MAC address restriction with EAP-TLS
Hello all, We are currently using EAP-TLS authentication with FreeRADIUS at the place where I work right now. Management would like to be able to restrict the use of a given certificate for this authentication to specific MAC addresses. In other words, for each certificate, the desire is to tie that certificate to one or a couple MAC addresses, and to say that that certificate may only be used if it is coming from those specific MAC addresses. If the certificate is used from a different MAC address, then authentication should fail. I have tried to look for info on this on the web to no avail. I also understand that EAP-TLS authentication generally needs to be left out of the users file. But the only way that I can think of to restrict MAC addresses would be to place some kind of line involving a Calling-Station-ID in the users file. So I am at a loss. Does anyone have any suggstions? We are currently using 1.1.3. Thank you very much. John Guthrie guth...@counterexample.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How do I not set Auth-Type?
Hello all,
I have a configuration where I allow users to get onto the wireless
network by authenticating with EAP-TLS or with EAP-GTC inside of
EAP-TTLS. If they have a cert, then they authenticate with EAP-TLS, and
if they have a password, then they authenticate with EAP-TTLS/EAP-GTC
which in turn authenticates against Kerberos. In addition, there are
some admins who need to log into the access point's command shell. I
would like these to be authenticated against the same Kerberos server,
but everyone else should get rejected.
As it turns out, I have a configuration that accomplishes all of this
*perfectly*. In radiusd.conf, I have:
modules {
...
krb5 {
}
...
}
...
authenticate {
...
Auth-Type Kerberos {
krb5
}
...
}
Then, in the users file, I have:
admin1 NAS-Port-Type == Virtual, Auth-Type = Kerberos
admin2 NAS-Port-Type == Virtual, Auth-Type = Kerberos
...
DEFAULT NAS-Port-Type == Virtual, Auth-Type := Reject
# This authenticates wireless users
DEFAULT NAS-Port-Type == Wireless-802.11, Auth-Type = Kerberos
I should stress, this accomplishes *exactly* what I want. That said, it
also involves explicit setting of Auth-Type. I have seen in more than
one place that this is a Bad Thing(TM). My first question is how do I
accomplish what the above configuration does without this explicit
Auth-Type setting? (Or is the above configuration marginally acceptable
because it only sets Auth-Type when it isn't already set?) Should I
only be defining one authentication module that involves User-PAssword?
More generally, suppose that you have two different authentication
modules, say unix and krb5, that use User-Password. How does FreeRADIUS
tell which users are supposed to use unix and which are supposed to use
krb5? (Assuming that you want some to use one, and some to use the
other.) That is, how does RADIUS know what the right thing is in that
case with being told explicitly?
Thanks in advance.
P.S. Before anyone says anything, I have read the documentation. More
than once. It could very easily be that I have missed something totally
obvious though.
--
John Guthrie
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How do I not set Auth-Type?
On Fri, 2007-03-16 at 09:40 +0100, Alan DeKok wrote: John T. Guthrie wrote: As it turns out, I have a configuration that accomplishes all of this *perfectly*. If it works... Well, it's been doing what I want it to do for about 7+ months, so I'd say that qualifies as working. ;-) Now granted, its expansion capabilities could very easily limited... I should stress, this accomplishes *exactly* what I want. That said, it also involves explicit setting of Auth-Type. I have seen in more than one place that this is a Bad Thing(TM). It's a bad thing because 90% or more of the times people set Auth-Type, they get it wrong. It's easiest to have a blanket statement saying Don't do that. And your configuration could be made simpler. You seem to always set I agree with this completely. Auth-Type = Kerberos, so that only needs to be set once, not for every user. Then, if you have a number of admins, the rules should be *role* based, not *name* based. i.e. use rlm_passwd to create an admin group, and then do: DEFAULT NAS-Port-Type == Virtual, Local-Group != admin, Auth-Type := Reject Thank you very much! This will go a long ways toward helping me clean up my config. My first question is how do I accomplish what the above configuration does without this explicit Auth-Type setting? You probably don't. (Or is the above configuration marginally acceptable because it only sets Auth-Type when it isn't already set?) Should I only be defining one authentication module that involves User-PAssword? Yes, and no. More generally, suppose that you have two different authentication modules, say unix and krb5, that use User-Password. How does FreeRADIUS tell which users are supposed to use unix and which are supposed to use krb5? In the CVS head (which has been fixed), the unix module no longer authenticates anyone. Instead, it looks users up in /etc/passwd, and adds Crypt-Password to the config items. Then, rlm_pap authenticates them. This is *much* more flexible. (Assuming that you want some to use one, and some to use the other.) That is, how does RADIUS know what the right thing is in that case with being told explicitly? RADIUS doesn't know how to do the right thing, FreeRADIUS does, because we've put a lot of work into making it smart. :) Fair enough. ;-) In most cases, the choice of authentication protocols is simple: Look in the Access-Request packet... it's requesting a particular authentication protocol. So setting the authentication to any *other* method means that authentication will fail. When finding the authentication *credentials* (i.e. password, etc.), it's also usually pretty easy. Look up the user in /etc/passwd, or LDAP, or whatever. If the user is found, take the credentials from there, and associate them with the request. Then, you have an authentication protocol, and authentication credentials, so knowing what to do for the act of authentication is simple. The confusion comes when people misconstrue back-ends for authentication protocols. i.e. doing EAP to an LDAP server. It gets more complicated when using something like Kerberos, which does not supply authentication credentials. Instead, Kerberos is an oracle http://deployingradius.com/documents/protocols/oracles.html i.e. in a certain sense, you're proxying the authentication request to the Kerberos server. So it's a very different manner of setting Auth-Type than forcing LDAP when the Access-Request contains EAP. P.S. Before anyone says anything, I have read the documentation. More than once. It could very easily be that I have missed something totally obvious though. I'll try to clarify this in my book. So are you saying that FreeRADIUS sometimes needs some assistance when dealing with authentication oracles? That is, it needs to be told when to use them? Moreover, is the problem in this case how to tell FreeRADIUS about that without setting an explicit Auth-Type? From what you said above, it seems that is not likely. This would seem to agree with what I've found in experimentation, namely take the configuration in the users file: user1 If I try to use the command (assuming the password for user1 is pass_for_user1): radtest user1 pass_for_user1 radius_server 17 radius_secret Then radiusd -X complains: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [user1] (from client net_tester port 17) (I have similar issues with the access point. Namely, it does not set Auth-Type.) However, it works if I use something like: user1Auth-Type = Kerberos (Note that I did not use Auth-Type := Kerberos.) In addition, if anyone can figure out a clear way to configure this in the server, I'd like to know... I would love to help out with this if at all possible. Thanks again
RE: restricting users access to clients?
On Wed, 2007-03-14 at 16:08 -0300, Matt Ashfield wrote: Ok, the users file it is! Thanks! I guess I was hoping for a link to an example of some sort. Because the user who would be given access is not explicitly defined in the users file (the users is defined in LDAP), I'm not sure how to setup a rule for that person. Thanks again, Cheers Matt [EMAIL PROTECTED] You would want to use the special username DEFAULT. (Check the man page for users(5).) What I did (although this might be slightly hackish.) is I took a look at the attributes in the request that was being sent by the supplicant. I looked for attributes that were different between the wireless users and the network equipment users. For example, you might want to do something like: admin1 NAS-Port-Type == Virtual, Auth-Type = LDAP admin2 NAS-Port-Type == Virtual, Auth-Type = LDAP # This matches everyone else DEFAULT NAS-Port-Type == Virtual, Auth-Type := Reject # This will match all wireless users DEFAULT NAS-Port-Type == Wireless-802.11, Auth-Type = LDAP Of course, this will mean that your network admins will *only* be able to login via LDAP. You may need to configure some kind of Fall-Through if you want users to authenticate using some other mechanism in addition to LDAP. So this is not without its limitations, but this should give you some ideas to start from. -- John Guthrie [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kerberos module config
On Tue, 2007-03-13 at 17:31 +0100, Alan DeKok wrote:
John T. Guthrie wrote:
Well, when all else fails, read the documentation. I just checked the
wiki on the website, and it says that the answer to my question is yes.
However, I went ahead and wrote a patch to the radiusd.conf.in file in
the source code to add in ome documentation for configuring Kerberos.
Where would be the best place to post that patch.
This list is OK for small patches.
Alan DeKok.
Alan,
Here is the patch that I mentioned. This is a patch against the
radiusd.conf.in file in 1.1.5.
Thanks.
--
John Guthrie
[EMAIL PROTECTED]
--- radiusd.conf.in.orig 2007-02-04 10:28:46.0 -0500
+++ radiusd.conf.in 2007-03-13 23:49:31.0 -0400
@@ -660,6 +660,20 @@
radwtmp = ${logdir}/radwtmp
}
+ # Kerberos 5
+ # The documentation doesn't give us much.
+ # See www.mail-archive.com/freeradius-users@lists.cistron.nl/msg21439.html
+ #
+ # You will also need to uncomment the Auth-Type Kerberos in the
+ # 'authenticate' section below.
+ #krb5 {
+ # keytab containing the key used by rlm_krb5
+ #keytab = /path/to/keytab
+
+ # principal that is used by rlm_krb5
+ #service_principal = radius/some.host.com
+ #}
+
# Extensible Authentication Protocol
#
# For all EAP related authentications.
@@ -1954,6 +1968,19 @@
# ldap
# }
+ # Uncomment this if you want to use Kerberos 5 for authentication.
+ # You will also need to uncomment the 'krb5' module above.
+ # Note that use of Kerberos requires that the User-Name and
+ # User-Password attributes be set in the request packet. This means
+ # that a client that is trying to authenticate using a digest-like
+ # scheme will not be able be authenticated using this mechanism.
+ #
+ # You will need to use an Auth-Type of Kerberos, not krb5 to
+ # reference this in the users file.
+# Auth-Type Kerberos {
+# krb5
+# }
+
#
# Allow EAP authentication.
eap
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Kreberos module config
Hello all,
I was just looking through the Kerberos code in rlm_krb5.c, and I found
this little code snippet:
static CONF_PARSER module_config[] = {
{ keytab, PW_TYPE_STRING_PTR,
offsetof(rlm_krb5_t,keytab), NULL, NULL },
{ service_principal, PW_TYPE_STRING_PTR,
offsetof(rlm_krb5_t,service_princ), NULL, NULL },
{ NULL, -1, 0, NULL, NULL }
};
Does this mean that the kerberos module can be configured with both a
keytab and a service principal? (In which case, is the default service
principal the string host?)
Thanks.
--
John Guthrie
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ssl help
On Mon, 2007-03-12 at 13:52 -0400, Hillary Marek wrote: I am trying to set up a Fedora Core 6 computer as a FreeRadius Server. It is currently running, and authenticating via mac address. I also want to set the same computer up as a CA using openssl. When I run the CA script, I get the following output: CA certificate filename (or enter to create) Making CA certificate ... Generating a 1024 bit RSA private key ..++ ..++ writing new private key to './CAtop/private/./cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [US]: State or Province Name (full name) [**]: * []: Organization Name (eg, company) [**]: Organizational Unit Name (eg, section) [MIS]: Hillary Marek []: [EMAIL PROTECTED] []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for ./CAtop/private/./cakey.pem: I am unable to access the ../../CA/newcerts directory ../../CA/newcerts: No such file or directory It seems to run finde until that last error. Any ideas? All answers are appreciated. By the CA script, I assume you are talking about the script /etc/pki/tls/misc/CA, correct? Whether you are using that or the CA.pl script, both scripts make the assumption the the CA directory is called ../../CA. (Of course, that assumption only has a chance of being true if you run the scripts from within the /etc/pki/tls/misc directory.) If you changed the dir variable in the openssl.cnf file, then these things would be out of sync, which can cause problems. It looks like you might have change the dir variable to ./CAtop, is that correct? If so, then I think you need to change the CATOP variable in the CA script to be the same thing. -- John Guthrie [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kerberos module config
On Mon, 2007-03-12 at 12:45 -0400, John T. Guthrie wrote:
Hello all,
I was just looking through the Kerberos code in rlm_krb5.c, and I found
this little code snippet:
static CONF_PARSER module_config[] = {
{ keytab, PW_TYPE_STRING_PTR,
offsetof(rlm_krb5_t,keytab), NULL, NULL },
{ service_principal, PW_TYPE_STRING_PTR,
offsetof(rlm_krb5_t,service_princ), NULL, NULL },
{ NULL, -1, 0, NULL, NULL }
};
Does this mean that the kerberos module can be configured with both a
keytab and a service principal? (In which case, is the default service
principal the string host?)
Thanks.
Well, when all else fails, read the documentation. I just checked the
wiki on the website, and it says that the answer to my question is yes.
However, I went ahead and wrote a patch to the radiusd.conf.in file in
the source code to add in ome documentation for configuring Kerberos.
Where would be the best place to post that patch.
Thanks.
--
John Guthrie
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
