I am running RHEL 5.3 and FreeRADIUS Version 2.1.8. When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this? Thanks, Brian Carpio
Hi,
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
probably because when run from the init script it cannot actually start the daemon (due to requirements to create the key etc). if everything is in place correctly beforehand then it will work. I guess the question , then, is - can the RPM do the required creation of example/test keys etc rather than require the admin to jump through the hoops - and thats a question for the distro maintainers. alan
Alan, Yes thanks for the reply you are correct it probably should go into the RPM I can rewrite the RHEL rpm to do this if I knew what to do? When I simply run radiusd -X the keys are created is there a "non interactive" option I can use to create the keys for the first time such as radiusd --create-keys (obviously that isn't it)... Or is there another way to create the keys? Brian Carpio On Tue, Jan 5, 2010 at 1:16 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
probably because when run from the init script it cannot actually start the daemon (due to requirements to create the key etc). if everything is in place correctly beforehand then it will work.
I guess the question , then, is - can the RPM do the required creation of example/test keys etc rather than require the admin to jump through the hoops - and thats a question for the distro maintainers.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 01/05/2010 03:35 PM, Brian Carpio wrote:
Alan,
Yes thanks for the reply you are correct it probably should go into the RPM I can rewrite the RHEL rpm to do this if I knew what to do? When I simply run radiusd -X the keys are created is there a "non interactive" option I can use to create the keys for the first time such as radiusd --create-keys (obviously that isn't it)...
Or is there another way to create the keys?
run /etc/raddb/certs/bootstrap It can be done in %post, but if and only if $1 == 1 for an explanation of why see this: http://www.ibm.com/developerworks/library/l-rpm3.html This would probably work, but I haven't tested it. %post if [ $1 = 1 ]; then /sbin/chkconfig --add radiusd /etc/raddb/certs/bootstrap fi -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi, I have Freeradius configured using a mysql backend. I want users to be able to connect only if their Calling-Station-Id is the same as the attribute I specify in the radcheck table in mysql. For example: |312|test@internet.quimefa.cu|Calling-Station-Id | == | "phonenumber" |298|test@internet.quimefa.cu|MD5-Password | := | password supposedly, I want to allow user test to only connect from this phonenumber, but when I really test the account I find that user test can connect from any phone number. So I really don't know what to do, I already tried to use different combinations of operators. Can anyone help me? in the radreply table I have this: |111|test@internet.quimefa.cu|Auth-Type|:=|Accept| thanks in advance.
Osmany <osmany@oc.quimefa.cu> escribió:
Hi,
I have Freeradius configured using a mysql backend. I want users to be able to connect only if their Calling-Station-Id is the same as the attribute I specify in the radcheck table in mysql. For example:
|312|test@internet.quimefa.cu|Calling-Station-Id | == | "phonenumber" |298|test@internet.quimefa.cu|MD5-Password | := | password
supposedly, I want to allow user test to only connect from this phonenumber, but when I really test the account I find that user test can connect from any phone number. So I really don't know what to do, I already tried to use different combinations of operators. Can anyone help me?
in the radreply table I have this:
|111|test@internet.quimefa.cu|Auth-Type|:=|Accept|
thanks in advance.
-
Try using += operator and the phonenumber if the number of the user is 8724466 put 7 at the begin , for example: 78724466. You can put radius in debug mode for check why is reject the access. Greetings Michel ---------------------------------------------- Webmail, servicio de correo electronico Casa de las Americas - La Habana, Cuba.
On Tue, 05 Jan 2010 20:05:07 -0500, michel@casa.co.cu wrote:
Osmany <osmany@oc.quimefa.cu> escribió:
Hi,
I have Freeradius configured using a mysql backend. I want users to be able to connect only if their Calling-Station-Id is the same as the attribute I specify in the radcheck table in mysql. For example:
|312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password
supposedly, I want to allow user test to only connect from this phonenumber, but when I really test the account I find that user test can connect from any phone number. So I really don't know what to do, I already tried to use different combinations of operators. Can anyone help me?
in the radreply table I have this:
|111|test@domain.com|Auth-Type|:=|Accept|
thanks in advance.
-
Try using += operator and the phonenumber if the number of the user is 8724466 put 7 at the begin , for example: 78724466.
You can put radius in debug mode for check why is reject the access.
I tried with the above configuration by putting the number 7 in front of the phone number and indeed the user test can only connect with that phone number. I guess that the NAS forwards the phone number including area code. Since that is working, now I want to add another phone number (another Calling-Station-Id) to the user test, so that the user can connect from only one phone number or the other. I tried using the += operator and the user can connect from any phone number. So my configuration works only if the user has only one Calling-Station-Id attribute, but I wanted to work with two Calling-Station-Id attributes also.
osmany@oc.quimefa.cu wrote:
On Tue, 05 Jan 2010 20:05:07 -0500, michel@casa.co.cu wrote:
Osmany <osmany@oc.quimefa.cu> escribió:
Hi,
I have Freeradius configured using a mysql backend. I want users to be able to connect only if their Calling-Station-Id is the same as the attribute I specify in the radcheck table in mysql. For example:
|312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password
supposedly, I want to allow user test to only connect from this phonenumber, but when I really test the account I find that user test can connect from any phone number. So I really don't know what to do, I already tried to use different combinations of operators. Can anyone help me?
in the radreply table I have this:
|111|test@domain.com|Auth-Type|:=|Accept|
thanks in advance.
-
Try using += operator and the phonenumber if the number of the user is 8724466 put 7 at the begin , for example: 78724466.
You can put radius in debug mode for check why is reject the access.
I tried with the above configuration by putting the number 7 in front of the phone number and indeed the user test can only connect with that phone number. I guess that the NAS forwards the phone number including area code. Since that is working, now I want to add another phone number (another Calling-Station-Id) to the user test, so that the user can connect from only one phone number or the other. I tried using the += operator and the user can connect from any phone number. So my configuration works only if the user has only one Calling-Station-Id attribute, but I wanted to work with two Calling-Station-Id attributes also. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Hello Osmany
If you would like this test user connect from another phone number, simply add another entry in the same table, just as you did before. Obviously, your NAS foward to freeradius the phone number from where it is trying to connect it . He told me that the user can connect from any phone number? Can you could post your configuration radius? The AAA section Greetings Michel
I tried with the above configuration by putting the number 7 in front of the phone number and indeed the user test can only connect with that phone number. I guess that the NAS forwards the phone number including area code. Since that is working, now I want to add another phone number (another Calling-Station-Id) to the user test, so that the user can connect from only one phone number or the other. I tried using the += operator and the user can connect from any phone number. So my configuration works only if the user has only one Calling-Station-Id attribute, but I wanted to work with two Calling-Station-Id attributes also. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Hello Osmany
If you would like this test user connect from another phone number, simply add another entry in the same table, just as you did before.
Add another entry with the Calling-Station-Id attribute? Let's see if I understand. After I add the other entry in the table it would look like this: |312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password |313|test@domain.com|Calling-Station-Id | += | "phonenumber" Let me just clarify that I tried this before and when I try to connect with this user, freeradius does not let me. When I run freeradius in debug mode I find this in the logs: rad_recv: Access-Request packet from host 192.168.25.50 port 17968, id=104, length=148 User-Name = "test@internet.quimefa.cu" User-Password = "test" NAS-IP-Address = 192.168.25.50 NAS-Port = 452 Service-Type = Framed-User Framed-Protocol = PPP Called-Station-Id = "60110" Calling-Station-Id = "72061490" NAS-Identifier = "Aguila" NAS-Port-Type = Async Connect-Info = "48000/31200 V90/V42bis/LAPM" +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok expand: %{User-Name} -> test@internet.quimefa.cu [sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' rlm_sql (sql): Reserving sql socket id: 2 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'test@internet.quimefa.cu' ORDER BY priority rlm_sql (sql): Released sql socket id: 2 [sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
Osmany <osmany@oc.quimefa.cu> writes:
If you would like this test user connect from another phone number, simply add another entry in the same table, just as you did before.
Add another entry with the Calling-Station-Id attribute? Let's see if I understand. After I add the other entry in the table it would look like this:
|312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password |313|test@domain.com|Calling-Station-Id | += | "phonenumber"
Let me just clarify that I tried this before and when I try to connect with this user, freeradius does not let me.
No, that won't work. All the check items must match for FreeRADIUS to consider the user. Testing the same attribute for equality with two different values is pointless. You'd either have to use groups, or much simpler: Use the regexp operator to match Calling-Station-Id against a regexp of all the values you want to allow. I.e Calling-Station-Id =~ phonenumber|phonenumber|etc This will also allow you to ignore leading digits (area codes etc), match on a seqence of numers, etc etc. Bjørn
On Wed, 2010-01-06 at 17:05 +0100, Bjørn Mork wrote:
Osmany <osmany@oc.quimefa.cu> writes:
If you would like this test user connect from another phone number, simply add another entry in the same table, just as you did before.
Add another entry with the Calling-Station-Id attribute? Let's see if I understand. After I add the other entry in the table it would look like this:
|312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password |313|test@domain.com|Calling-Station-Id | += | "phonenumber"
Let me just clarify that I tried this before and when I try to connect with this user, freeradius does not let me.
No, that won't work. All the check items must match for FreeRADIUS to consider the user. Testing the same attribute for equality with two different values is pointless.
You'd either have to use groups, or much simpler: Use the regexp operator to match Calling-Station-Id against a regexp of all the values you want to allow. I.e Calling-Station-Id =~ phonenumber|phonenumber|etc
This will also allow you to ignore leading digits (area codes etc), match on a seqence of numers, etc etc.
Bjørn That works fine if I try to connect from the phone numbers specified, but if I try to connect from any other phone number, it still lets me in. The point is that I don't want the user to be able to connect from any other phone number unless it is specified in the Calling-Station-Id attribute.
Osmany wrote:
I tried with the above configuration by putting the number 7 in front of the phone number and indeed the user test can only connect with that phone number. I guess that the NAS forwards the phone number including area code. Since that is working, now I want to add another phone number (another Calling-Station-Id) to the user test, so that the user can connect from only one phone number or the other. I tried using the += operator and the user can connect from any phone number. So my configuration works only if the user has only one Calling-Station-Id attribute, but I wanted to work with two Calling-Station-Id attributes also. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello Osmany
If you would like this test user connect from another phone number, simply add another entry in the same table, just as you did before.
Add another entry with the Calling-Station-Id attribute? Let's see if I understand. After I add the other entry in the table it would look like this:
|312|test@domain.com|Calling-Station-Id | == | "phonenumber" |298|test@domain.com|MD5-Password | := | password |313|test@domain.com|Calling-Station-Id | += | "phonenumber"
Let me just clarify that I tried this before and when I try to connect with this user, freeradius does not let me. When I run freeradius in debug mode I find this in the logs:
rad_recv: Access-Request packet from host 192.168.25.50 port 17968, id=104, length=148 User-Name = "test@internet.quimefa.cu" User-Password = "test" NAS-IP-Address = 192.168.25.50 NAS-Port = 452 Service-Type = Framed-User Framed-Protocol = PPP Called-Station-Id = "60110" Calling-Station-Id = "72061490" NAS-Identifier = "Aguila" NAS-Port-Type = Async Connect-Info = "48000/31200 V90/V42bis/LAPM" +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok expand: %{User-Name} -> test@internet.quimefa.cu [sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' rlm_sql (sql): Reserving sql socket id: 2 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'test@internet.quimefa.cu' ORDER BY priority rlm_sql (sql): Released sql socket id: 2 [sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
Try this way, remember the operator. |312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" However check that you return the error debugging. suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu" sql] User test@internet.quimefa.cu not found ++[sql] returns notfound For this reason, it is the user and should not assume that you connect it. But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number. Once again check the AAA section, where you define how it will look freeradius user.
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
Please read the manual. In this case, that's users(5): Attribute += Value Always matches as a check item, and adds the current attribute with value to the list of configuration items. As a reply item, it has an identical meaning, but the attribute is added to the reply items. This means that the 3 lines |312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" are identical to the single line |298|test@internet.quimefa.cu|MD5-Password | := | password and the user will be accepted regardless of Calling-Station-Id.
suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu"
This is normal, and no problem. You may define a realm using LOCAL authentication to avoid it, but it won't change anything except remove the debug message.
sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
The sql module returns notfound if the check items don't match. This is expected in this case as I explained: Two different equality tests on a single attribute will never match.
But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number.
The debug output showed that the user matched a DEFAULT entry in users. That's a perfectly normal configuration. In fact, there is no problem defining the same user in both "users" and sql (and possibly other modules as well). The control and reply lists of the matching entries just add up, and the final result is then evaluated. But I agree that for simplicity it's probably best to define the specific user entries in one place. And that's what Osmany has done. The DEFAULT entry is probably just adding something generic, which is common for all users. Bjørn
On Thu, 2010-01-07 at 11:32 +0100, Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
Please read the manual. In this case, that's users(5):
Attribute += Value Always matches as a check item, and adds the current attribute with value to the list of configuration items. As a reply item, it has an identical meaning, but the attribute is added to the reply items.
This means that the 3 lines
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
are identical to the single line
|298|test@internet.quimefa.cu|MD5-Password | := | password
and the user will be accepted regardless of Calling-Station-Id.
suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu"
This is normal, and no problem. You may define a realm using LOCAL authentication to avoid it, but it won't change anything except remove the debug message.
sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
The sql module returns notfound if the check items don't match. This is expected in this case as I explained: Two different equality tests on a single attribute will never match.
But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number.
This time I used: |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | =~ | 6480342|555555 and it still accepts the user from regardless of the phone number it's using. this is what comes up in the debug. rad_recv: Access-Request packet from host 192.168.25.10 port 17968, id=239, length=148 User-Name = "test@internet.quimefa.cu" User-Password = "password" NAS-IP-Address = 192.168.25.10 NAS-Port = 98 Service-Type = Framed-User Framed-Protocol = PPP Called-Station-Id = "60110" Calling-Station-Id = "72061490" NAS-Identifier = "BVISTA" NAS-Port-Type = Async Connect-Info = "41333/31200 V90/V42bis/LAPM" +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok expand: %{User-Name} -> test@internet.quimefa.cu [sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' rlm_sql (sql): Reserving sql socket id: 3 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: %{Calling-Station-Id} -> 72061490 [sql] User found in radcheck table expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'test@internet.quimefa.cu' ORDER BY priority rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Normalizing MD5-Password from hex encoding ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "password" [pap] Using MD5 encryption. [pap] User authenticated successfully ++[pap] returns ok +- entering group post-auth {...} expand: %{User-Name} -> test@internet.quimefa.cu [sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' as you can see the phone number that user test is using is different from the ones I have specified in the radcheck table and it comes up with the sql module returning ok and accepts the user in. I notice that the pap module also works and returns ok, but I read that this is mandatory, otherwise no user will be accepted no matter what.
Osmany <osmany@oc.quimefa.cu> writes:
This time I used:
|298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | =~ | 6480342|555555
and it still accepts the user from regardless of the phone number it's using. this is what comes up in the debug.
[..]
[sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' rlm_sql (sql): Reserving sql socket id: 3 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: %{Calling-Station-Id} -> 72061490 [sql] User found in radcheck table
I do not understand this. It can't happen if what you've got in the database is what you tell us above. Bjørn
This time I used:
|298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | =~ | 6480342|555555
and it still accepts the user from regardless of the phone number it's using. this is what comes up in the debug.
[..]
[sql] sql_set_user escaped user --> 'test@internet.quimefa.cu' rlm_sql (sql): Reserving sql socket id: 3 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'test@internet.quimefa.cu' ORDER BY id expand: %{Calling-Station-Id} -> 72061490 [sql] User found in radcheck table
I do not understand this. It can't happen if what you've got in the database is what you tell us above.
Bjørn
Try removing the radreply entry with auth-type := accept. Won't that allow the user in regardless of the check items? Ben
"Ben Wiechman" <wiechman.lists@gmail.com> writes:
Try removing the radreply entry with auth-type := accept. Won't that allow the user in regardless of the check items?
It should not be in the radreply table in any case so that should certainly be removed. But I don't think it makes any difference. The radcheck lookup should fail and the radreply table should therefore not be searched at all. Bjørn
Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
Please read the manual. In this case, that's users(5):
Attribute += Value Always matches as a check item, and adds the current attribute with value to the list of configuration items. As a reply item, it has an identical meaning, but the attribute is added to the reply items.
This means that the 3 lines
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
are identical to the single line
|298|test@internet.quimefa.cu|MD5-Password | := | password
and the user will be accepted regardless of Calling-Station-Id.
suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu"
This is normal, and no problem. You may define a realm using LOCAL authentication to avoid it, but it won't change anything except remove the debug message.
sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
The sql module returns notfound if the check items don't match. This is expected in this case as I explained: Two different equality tests on a single attribute will never match.
But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number.
The debug output showed that the user matched a DEFAULT entry in users. That's a perfectly normal configuration.
In fact, there is no problem defining the same user in both "users" and sql (and possibly other modules as well). The control and reply lists of the matching entries just add up, and the final result is then evaluated.
But I agree that for simplicity it's probably best to define the specific user entries in one place. And that's what Osmany has done. The DEFAULT entry is probably just adding something generic, which is common for all users.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the class, as we say in our country: "Every day you learn something new." There are no problems is to define a user, in fact he did on both sides, in the file "users" and database "sql". I would do it in one place, so you do not go crazy when you add a user or update any information of it, for example the phone number where you will be connected. Although the problem persists, the user can connect from any other phone number and may not be a problem of operator, but this by specifying the number in a single place, and not in the sql file "users". Assuming this well held on both sides and again I'm wrong, maybe in the section "authorize" I miss you to use the module "checkval. Even so if you could post your configuration, would be useful. Don't you think?
On Thu, 2010-01-07 at 08:42 -0500, Michel Bulgado wrote:
Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
Please read the manual. In this case, that's users(5):
Attribute += Value Always matches as a check item, and adds the current attribute with value to the list of configuration items. As a reply item, it has an identical meaning, but the attribute is added to the reply items.
This means that the 3 lines
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
are identical to the single line
|298|test@internet.quimefa.cu|MD5-Password | := | password
and the user will be accepted regardless of Calling-Station-Id.
suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu"
This is normal, and no problem. You may define a realm using LOCAL authentication to avoid it, but it won't change anything except remove the debug message.
sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
The sql module returns notfound if the check items don't match. This is expected in this case as I explained: Two different equality tests on a single attribute will never match.
But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number.
The debug output showed that the user matched a DEFAULT entry in users. That's a perfectly normal configuration.
In fact, there is no problem defining the same user in both "users" and sql (and possibly other modules as well). The control and reply lists of the matching entries just add up, and the final result is then evaluated.
But I agree that for simplicity it's probably best to define the specific user entries in one place. And that's what Osmany has done. The DEFAULT entry is probably just adding something generic, which is common for all users.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the class, as we say in our country: "Every day you learn something new."
There are no problems is to define a user, in fact he did on both sides, in the file "users" and database "sql". I would do it in one place, so you do not go crazy when you add a user or update any information of it, for example the phone number where you will be connected.
Although the problem persists, the user can connect from any other phone number and may not be a problem of operator, but this by specifying the number in a single place, and not in the sql file "users".
Assuming this well held on both sides and again I'm wrong, maybe in the section "authorize" I miss you to use the module "checkval.
Even so if you could post your configuration, would be useful.
Don't you think? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Indeed I think Bjorn's comments are very useful. Anyway, this is my authorize section in the sites-enabled/default file:
authorize { preprocess # auth_log # chap # mschap # digest # IPASS # suffix # ntdomain eap { ok = return } # unix # files sql # etc_smbpasswd # ldap # daily # checkval expiration logintime pap # Autz-Type Status-Server { # # } }
On Thu, 2010-01-07 at 09:06 -0500, Osmany wrote:
On Thu, 2010-01-07 at 08:42 -0500, Michel Bulgado wrote:
Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
It finally worked. I kept the user attributes and everything just like I mentioned above but I had one thing missing in the authorize section in the sites-enabled/default file. I had the checkval line commented out. I just uncommented it and that's it. I also went further but commenting all of the modules that I did not need in the authorize section as well as in the preacct section. so things like the suffix, mschap, chap, etc I commented out so that freeradius doesn't use these modules unnecessarily. so finally I have everything working just fine.
Osmany <osmany@oc.quimefa.cu> writes:
On Thu, 2010-01-07 at 09:06 -0500, Osmany wrote:
On Thu, 2010-01-07 at 08:42 -0500, Michel Bulgado wrote:
Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
It finally worked. I kept the user attributes and everything just like I mentioned above but I had one thing missing in the authorize section in the sites-enabled/default file. I had the checkval line commented out. I just uncommented it and that's it.
Great! Then I learned something today. Neat trick using the += operator to avoid that the sql module stops processing the request, while checkval seems to ignore the operator (except for =~ which is processed both as == and as =~). Bjørn
Hi,
I had the checkval line commented out. I just uncommented it and that's it. I also went further but commenting all of the modules that I did not need in the authorize section as well as in the preacct section. so things like the suffix, mschap, chap, etc I commented out so that freeradius doesn't use these modules unnecessarily. so finally I have everything working just fine.
good on you - well done! beware though, that in the ture you might need one of those modules (or mix of them) for some functions. just be aware of what they are and what they do. alan
On 01/05/2010 03:16 PM, Alan Buxey wrote:
Hi,
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
probably because when run from the init script it cannot actually start the daemon (due to requirements to create the key etc). if everything is in place correctly beforehand then it will work.
I guess the question , then, is - can the RPM do the required creation of example/test keys etc rather than require the admin to jump through the hoops - and thats a question for the distro maintainers.
The RPM could initially create the temporary certificates. There are two reasons why it doesn't at the moment. 1) It would deviate from everything written here on this list and the wiki. Discrepancies like that usually causes more problems than would be solved by it. People have a hard enough time following instructions in the first place (this list is pure evidence of that). If they then have to modify the instructions based on the distribution they'll be hopelessly confused :-( 2) The certificates created are *temporary* and *not* intended for production use. As such it's always a good idea to bring this crucial fact to the attention of the person installing the server. No better way to make them aware of this than forcing them to perform a manual step. Otherwise they'll blindly think everything is hokey-dokey and deploy the server with temporary self-signed certs. If you really think this is needs to change then file a bug. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
2) The certificates created are *temporary* and *not* intended for production use. As such it's always a good idea to bring this crucial fact to the attention of the person installing the server. No better way
yeah, explain the default install of Apache HTTPD with snakeoil localhost.localdomain certificate that I see oh so often ;-)
to make them aware of this than forcing them to perform a manual step. Otherwise they'll blindly think everything is hokey-dokey and deploy the server with temporary self-signed certs.
I agree with your comments though - the admin needs to know what they have installed and why/were it needs to be fixed. maybe server can log the fact its using a self-signed local/temp certificate? alan
On Wed, Jan 6, 2010 at 3:37 AM, John Dennis <jdennis@redhat.com> wrote:
2) The certificates created are *temporary* and *not* intended for production use. As such it's always a good idea to bring this crucial fact to the attention of the person installing the server. No better way to make them aware of this than forcing them to perform a manual step. Otherwise they'll blindly think everything is hokey-dokey and deploy the server with temporary self-signed certs.
RHEL's mod_ssl RPM creates and uses self-signed certs by default. For consistency reasons, both freeradius and mod_ssl should have the same behaviour regarding self-signed certs. -- Fajar
On Tue, Jan 05, 2010 at 03:37:25PM -0500, John Dennis wrote:
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
probably because when run from the init script it cannot actually start the daemon (due to requirements to create the key etc). if everything is in place correctly beforehand then it will work.
I guess the question , then, is - can the RPM do the required creation of example/test keys etc rather than require the admin to jump through the hoops - and thats a question for the distro maintainers.
The RPM could initially create the temporary certificates. There are two reasons why it doesn't at the moment.
1) It would deviate from everything written here on this list and the wiki. Discrepancies like that usually causes more problems than would be solved by it. People have a hard enough time following instructions in the first place (this list is pure evidence of that). If they then have to modify the instructions based on the distribution they'll be hopelessly confused :-(
2) The certificates created are *temporary* and *not* intended for production use. As such it's always a good idea to bring this crucial fact to the attention of the person installing the server. No better way to make them aware of this than forcing them to perform a manual step. Otherwise they'll blindly think everything is hokey-dokey and deploy the server with temporary self-signed certs.
If you really think this is needs to change then file a bug.
When I enabled EAP+SSL modules in the 2.1.8 Debian package, the eap.conf defaults kicked in, so I added the use of snakeoil certificates explicitly because I don't want to break all the new installations as well as upgrades. It would piss off users by default, and that kind of behavior would IMHO be significantly worse than either of those things you mentioned above. These changes didn't make it into 2.1.8 (git) before upstream release, but nevertheless you can see them at the patch tracker: http://patch-tracker.debian.org/package/freeradius/2.1.8+dfsg-1 -- 2. That which causes joy or happiness.
On 01/05/2010 06:09 PM, Josip Rodin wrote:
On Tue, Jan 05, 2010 at 03:37:25PM -0500, John Dennis wrote:
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
probably because when run from the init script it cannot actually start the daemon (due to requirements to create the key etc). if everything is in place correctly beforehand then it will work.
I guess the question , then, is - can the RPM do the required creation of example/test keys etc rather than require the admin to jump through the hoops - and thats a question for the distro maintainers.
The RPM could initially create the temporary certificates. There are two reasons why it doesn't at the moment.
1) It would deviate from everything written here on this list and the wiki. Discrepancies like that usually causes more problems than would be solved by it. People have a hard enough time following instructions in the first place (this list is pure evidence of that). If they then have to modify the instructions based on the distribution they'll be hopelessly confused :-(
2) The certificates created are *temporary* and *not* intended for production use. As such it's always a good idea to bring this crucial fact to the attention of the person installing the server. No better way to make them aware of this than forcing them to perform a manual step. Otherwise they'll blindly think everything is hokey-dokey and deploy the server with temporary self-signed certs.
If you really think this is needs to change then file a bug.
When I enabled EAP+SSL modules in the 2.1.8 Debian package, the eap.conf defaults kicked in, so I added the use of snakeoil certificates explicitly because I don't want to break all the new installations as well as upgrades. It would piss off users by default, and that kind of behavior would IMHO be significantly worse than either of those things you mentioned above.
These changes didn't make it into 2.1.8 (git) before upstream release, but nevertheless you can see them at the patch tracker: http://patch-tracker.debian.org/package/freeradius/2.1.8+dfsg-1
I've modified the RPM to run /etc/raddb/certs/bootstrap if it's the initial install (not an upgrade) and /etc/raddb/certs/server.pem does not exist. This should remove the need to run the server in debug mode initially. Actually I had opened a bug report to myself a few months ago to do automatic cert generation but I had forgotten about it, FWIW the bug was: https://bugzilla.redhat.com/show_bug.cgi?id=526559 -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
I've modified the RPM to run /etc/raddb/certs/bootstrap if it's the initial install (not an upgrade) and /etc/raddb/certs/server.pem does not exist. This should remove the need to run the server in debug mode initially.
Actually I had opened a bug report to myself a few months ago to do automatic cert generation but I had forgotten about it, FWIW the bug was:
cool - i think that will help a lot of people on their first usage. alan
Brian Carpio wrote:
I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
Install real certificates before starting it? Disable EAP completely in the config? Alan DeKok.
participants (12)
-
Alan Buxey -
Alan DeKok -
Ben Wiechman -
Bjørn Mork -
Brian Carpio -
Fajar A. Nugraha -
John Dennis -
Josip Rodin -
Michel Bulgado -
michel＠casa.co.cu
-
Osmany -
osmany＠oc.quimefa.cu