RE: how to change the radius default "testing123" password
Alan, That was actually the problem. I surrounded the new password in quotes, and didn't like that. Once I removed the quotes, it worked! Clint -Original Message- From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org [mailto:freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Wednesday, October 02, 2013 3:31 PM To: FreeRadius users mailing list Subject: RE: how to change the radius default "testing123" password hi, pretty definitive. incorrect shared secret - are you SURE that you havent got any white spaces etc lurking around? keep the shared secret in quotes if in doubt 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: control flow in FreeRADIUS authorize section
On 2 Oct 2013, at 22:57, a.l.m.bu...@lboro.ac.uk wrote:
> Hi,
>
>> A simple thing:
>>
>>
>>
>> update control {
>> Tmp-String-0 := "stop"
>> }
>> ...
>>
>>
>>
>>
>> if (Tmp-String-0 != "stop") {
>>
>> }
>>
>> That should work. Ugly, but functional.
>
> this is pretty much what I was going to suggest. ugly, yes. but sometimes
> simple is best.
> and its much easier for a non unlang'y person to understand the logic! :)
Nah, the appearance of obscurity is another mans job security :p
Arran Cudbard-Bell
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radwho not working
I would like to display the active Radius connections. When I run radwho I get the following results (showing nothing but the titles) even though I know I have an active connection: # radwho Login Name What TTY When FromLocation # - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: how to change the radius default "testing123" password
hi, pretty definitive. incorrect shared secret - are you SURE that you havent got any white spaces etc lurking around? keep the shared secret in quotes if in doubt alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: how to change the radius default "testing123" password
Hi Alan, Ok, I figured out why I wasn't able to change the "testing123" password. I was surrounding the new random password in quotes. Once I removed the quotes, it worked. Clint -Original Message- From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org [mailto:freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, October 02, 2013 2:02 PM To: FreeRadius users mailing list Subject: Re: how to change the radius default "testing123" password Clint Petty wrote: > Hi Alan, > > Thanks for your reply. However, I have already changed the instances of the > password "testing123" in the following files: > > StrongSwan:/etc/strongswan/strongswan.conf That's good. > Radius:/etc/raddb/proxy.conf That's not good. The secret there is for home servers, not clients. I suggest changing it back. > Radius:/etc/raddb/sites-available/dynamic-clients > Radius:/etc/raddb/sites-available/originate-coa > Radius:/etc/raddb/sites-available/robust-proxy-accounting That's not good. Those files are NOT used by the running server. I suggest changing it back. > Radius:/etc/raddb/clients.conf That's good. > After restarting the strongswan and radiusd service, I was not able to > authenticate to my LDAP server, and had to change the entries back to > "testing123"? What am I missing here? Well, it should work. What does the debug output say? That should tell you *exactly* what's going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: how to change the radius default "testing123" password
Hi, > Thanks for your reply. However, I have already changed the instances of the > password "testing123" in the following files: if you are dealing with a shared secret between a NAS and the FreeRADIUS server, there are only 2 thigns to configure 1) the shared secret on the NAS - I would guess this is storngswan.conf for you 2) the shared secret in the clients.conf file - this is whats used to reference the incoming request from the NAS all other parts are system components eg proxy.conf has a default internal one - and if you were proxying to OTHER RADIUS servers, then you would change their entries IF you has set them to testing123 - most people wouldnt - they would use their own choices. of course, when thigns go wrong, run in full debug mode and see whats printed out when you connect via the NAS alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: control flow in FreeRADIUS authorize section
Hi,
> A simple thing:
>
>
>
> update control {
> Tmp-String-0 := "stop"
> }
> ...
>
>
>
>
> if (Tmp-String-0 != "stop") {
>
> }
>
> That should work. Ugly, but functional.
this is pretty much what I was going to suggest. ugly, yes. but sometimes
simple is best.
and its much easier for a non unlang'y person to understand the logic! :)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: how to change the radius default "testing123" password
Hi Alan, Ok, I just changed the StrongSwan:/etc/strongswan/strongswan.conf & the Radius:/etc/raddb/clients.conf files, and left the other files with reference to "testing123" alone. Restarted the strongswan & radiusd services, and get the same error from my iphone, "VPN Connection - User authentication failed". I started radiusd -X (debug mode), and get the following: rad_recv: Access-Request packet from host xx.xx.xx.79 port 49922, id=198, length=137 Received packet from xx.xx.xx.79 with invalid Message-Authenticator! (Shared secret is incorrect.) Dropping packet without response. Going to the next request Waking up in 0.9 seconds. Cleaning up request 7 ID 198 with timestamp +296 Ready to process requests. Repeats four times. -Original Message- From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org [mailto:freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, October 02, 2013 2:02 PM To: FreeRadius users mailing list Subject: Re: how to change the radius default "testing123" password Clint Petty wrote: > Hi Alan, > > Thanks for your reply. However, I have already changed the instances of the > password "testing123" in the following files: > > StrongSwan:/etc/strongswan/strongswan.conf That's good. > Radius:/etc/raddb/proxy.conf That's not good. The secret there is for home servers, not clients. I suggest changing it back. > Radius:/etc/raddb/sites-available/dynamic-clients > Radius:/etc/raddb/sites-available/originate-coa > Radius:/etc/raddb/sites-available/robust-proxy-accounting That's not good. Those files are NOT used by the running server. I suggest changing it back. > Radius:/etc/raddb/clients.conf That's good. > After restarting the strongswan and radiusd service, I was not able to > authenticate to my LDAP server, and had to change the entries back to > "testing123"? What am I missing here? Well, it should work. What does the debug output say? That should tell you *exactly* what's going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: control flow in FreeRADIUS authorize section
> We want to stop executing the in the first two cases
> ("infected" and "tempsus"), effectively doing something like a return.
Where you have ok in the case stanzas, put
ok {
ok = return
}
-Arran
Arran Cudbard-Bell
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: control flow in FreeRADIUS authorize section
Bruce Bauman wrote:
> We want to stop executing the in the first two
> cases ("infected" and "tempsus"), effectively doing something like a return.
There is a "return" code. See doc/configurable_failover.rst:
ok {
ok = return
}
That may work. The issue is that there's really no multi-level "stop"
or "break". i.e. "stop doing ANYTHING, no matter how deeply nested you
are un the conditions.
The unlang code isn't really meant to do that, sorry.
> I've read the documentation a hundred times and can't figure out how to
> do what I want - everything I've tried doesn't work.
>
> If someone could give me a simple hint to point me in the right
> direction it would be greatly appreciated.
A simple thing:
update control {
Tmp-String-0 := "stop"
}
...
if (Tmp-String-0 != "stop") {
}
That should work. Ugly, but functional.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
st...@comitcon.be wrote: > It is fairly clear that the experts claim they have the knowledge , but > are guarding it. Ah, yes. That's why I've wrote tons of documentation for the server, and have answered questions daily for 15 years. I'm trying to hide RADIUS knowledge. > I am secondly not lecturing you on how to use Radius, Nonsense. You lectured me on the use-case for rlm_raw. > but you are "expert" > are neither teaching me, by referring me to files I have read multiple > times. Well, you didn't say that. If you don't say what you're doing, it's a form of lying. > For the record > The IP address of a client is added using dynamic. I have set the lifetime > to 60 (and the file states seconds), but it is not removed after 1 minute > or even more. show client list in radmin also keeps showing it. Well, it works for me. Did you try sending another packet after 60 seconds? What happened? > So you admit you are frustrated? With all best respect, I love people > being helpfull, willing to test and try out. But if the immediate respons > is "not recommended", well don't bother responding because people might > have proper reasons for using it this way. I see. You're not a RADIUS expert, so you ask a question. When a RADIUS expert answers you, you disagree, and think they're wrong. And you say *I* am unhelpful? > Learn to adjust to the needs of the real world. This is not a student pet > thing here. I am merely walking the boundaries of what the system is > doing. You know, I could make the system check in using perl/php and > update the IP address as I am using SQL as a backend. Same deal. But no, I > don't see a purpose on a security level on doing it with rlm_raw / dynamic > clients etc... That's why you're not a RADIUS expert, and I am. > You know, I just needed to find out if the lifetime 60 will work because I > don't see it. The changelog of FR actually state at a certain revision it > was defaulted to 1 hour in case of lacking. Maybe there is a minimum? I just checked. There isn't. > an expert who refuses to set up a system Where the HELL did you get that idea from? And what kind of entitlement do you have? I'm supposed to do things for free to check that you've likely misconfigured things? Are you paying me? Do you even know how open source works? > (might not even be in real life, > but a matter as experimenting?) Sorry from an expert I expect atleast the > full reasons (or links) to the security issues which are claimed. Secondly > an expert would give me the response to the simple question. I expect that I can have technical discussions without people getting upset when I tell then they're wrong. That's what makes me an expert, and makes you banned from the list. I'm willing to learn from others. You're not. > Now this you can call rude. I was being polite in the previous mails. Refusing to follow instructions is rude. Complaining when I tell you you're wrong is rude. Refusing to learn is rude. Goodbye. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
control flow in FreeRADIUS authorize section
We are getting unexpected behavior from FreeRADIUS 2.2.x (built from current
git).
We want to check if a user is BLOCKED first, and only then do we want to
perform some other checks.
Our current config looks like this:
authorize {
#auth_log # uncomment for debugging
# try to rewrite calling station ID to be sane
rewrite_calling_station_id
rewrite_username_lowercase
# set VLANs for infected or tempsuspension roles
IPSblocks_SQL {
# handle failures
notfound = 999
reject = 999
}
switch reply:RU-block-description {
case "infected" {
if(Airespace-Wlan-Id){
update reply {
Cisco-AVPair +=
"url-redirect=http://ruwireless.rutgers.edu/index.php?page=infected";
Airespace-ACL-Name = "Cisco_infected"
}
}
else {
update reply {
# try VLAN assignment
Tunnel-Type := "VLAN"
Tunnel-Medium-Type := "IEEE-802"
Tunnel-Private-Group-Id := 1666
}
}
# force accept regardless of password
update control {
Auth-Type := "Accept"
}
ok
}
case "tempsus" {
update reply {
# try VLAN assignment
Tunnel-Type := "VLAN"
Tunnel-Medium-Type := "IEEE-802"
Tunnel-Private-Group-Id := 1666
}
# force accept regardless of password
update control {
Auth-Type := "Accept"
}
ok
}
# default is to do nothing
}
The IPSblocks_SQL does set RU-block description correctly, and the case
statement behaves as expected.
We want to stop executing the in the first two cases
("infected" and "tempsus"), effectively doing something like a return.
I've read the documentation a hundred times and can't figure out how to do what
I want - everything I've tried doesn't work.
If someone could give me a simple hint to point me in the right direction it
would be greatly appreciated.
-- Bruce
Bruce Bauman - Systems Administrator
Rutgers University Office of Information Technology
Campus Computing Services - Central Systems and Services
Office ~ (848) 445-6363
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: how to change the radius default "testing123" password
Clint Petty wrote: > Hi Alan, > > Thanks for your reply. However, I have already changed the instances of the > password "testing123" in the following files: > > StrongSwan:/etc/strongswan/strongswan.conf That's good. > Radius:/etc/raddb/proxy.conf That's not good. The secret there is for home servers, not clients. I suggest changing it back. > Radius:/etc/raddb/sites-available/dynamic-clients > Radius:/etc/raddb/sites-available/originate-coa > Radius:/etc/raddb/sites-available/robust-proxy-accounting That's not good. Those files are NOT used by the running server. I suggest changing it back. > Radius:/etc/raddb/clients.conf That's good. > After restarting the strongswan and radiusd service, I was not able to > authenticate to my LDAP server, and had to change the entries back to > "testing123"? What am I missing here? Well, it should work. What does the debug output say? That should tell you *exactly* what's going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
> > On 2 Oct 2013, at 19:06, st...@comitcon.be wrote: > >> Alan >> >> first of all thank you for replying although I must sense quite some >> hostility in your replies. On the other hand, I have read previous >> emails >> coming from your end and this appears to be the way you respond. > > Firstly, you ignored what Alan said, there are multiple ways of achieving > what you want. > > * VPN - Establish an IPSEC/PPP tunnel. Use policy driven IP assignment to > ensure that the same addresses get assigned to the same NAS. > > * TLS - RADSEC use the global client 0.0.0.0/0 and use RADSEC to > authenticate > NAS. Different certificates can be installed on different NAS, all > signed by a common CA. > > * Global client - If you don't care about security use a single client > definition and use the same shared secret. If this is behind a nat > you know the public IP addresses the UDP frames will come from. > Used a global client before. The main reason is also that I hacked into daloradius so we can ping trace the local NAS boxes and log into them using ssh. So a global client would not allow me (in the interface for my end operator) to go to the separate boxes. No we don't care on security for the NAS themselves (it is a fully respinned WRT version) > Getting the attributes you want from the request means partially decoding > the request. This is a bad thing to do in DDOS situations where you just > want > to discard packets from unknown clients as quickly as possible. > True, I have explained this to the person requesting this and they agree with this. I am not in favor too, don't get me wrong. > It's also a security risk where traffic is ingressing from outside of your > network. > >> Secondly I have read the documentation, but RTFM still appears to be the >> common way of responding (even after using Linux for over 15 years). >> >> Thirdly , the case below is a true real life situation, which does not >> only occur only for me, but also for other. Even though the module is >> not >> officially supported (maybe for the reason there are) it is in today's >> world . You can decide, be a bernstein (like qmail) or adopt to a real >> life situation. (Btw, if this was such uncommon, how come I find as many >> question on it as there are. If YFI is actually supporting this, there >> must be a need. Even if it is not meant like that. > > Because people are given problems to solve outside their technical > capacity, > they fail to understand the underlying issue, and come up the solution > that fits with their limited understanding of the problem and RADIUS. > I wont go into this argument... There might be other factors limiting them so they need to downsize the solution. It's always balancing the pros and cons. > Or they understand the problem but are using NAS which has not been > properly specced for the deployment scenario. > >> it does not state >> a) lifetime >> b) anything else usefull. > > What would you like included in that debug message, it's pretty trivial > to change... The lifetime / expiration would help me debugging the lifetime option as this is where I don't see it discarded after 1 minute. >> >> Now I am running radmin show client list and see the IP appear. I am now >> testing when it disappear. >> >> Please refrain from responding if it will only be a load of 'you did not >> do this or that', while you have no clue on what I read or already have >> done. If the response is coming to the basic question >> "how can I check the lifetime of a dynamic client" feel free. >> >> Elsewise, let's keep this clean for people willing to find the proper >> solution. > > The proper solution is one of the two posted above. I hate to pull the > experience card, but i've been working with RADIUS the entirety of my > professional career. I train people who work at telcos on RADIUS > security and RADIUS cluster management. The way you're trying to do this > is wrong. > The main issues is that the solution we provide will not work properly using the first 2. It is very limited on speed and we are dropping below an acceptable rate in traffic... Yes we have tried it but it really becomes flacky... Global client is a solution, but I explained above why I wanted to use this to atleast define multiple nas boxes. Any box is allowed on the radius to put it bluntly I understand the risks and discussed this with the requestor. But it was talking the ups with the downs. Best regards Steve > -Arran > > Arran Cudbard-Bell > FreeRADIUS Development Team > > - > 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: lifetime of dynamic clients
Replied in between > st...@comitcon.be wrote: >> first of all thank you for replying although I must sense quite some >> hostility in your replies. On the other hand, I have read previous >> emails >> coming from your end and this appears to be the way you respond. > > Perhaps you could read the *content* of my messages, instead of > inventing some emotional projection. > Half of what you actually stated is reading the manual. >> Secondly I have read the documentation, but RTFM still appears to be the >> common way of responding (even after using Linux for over 15 years). > > So you read the documentation saying that clients are defined by IP > addresses, and then asked whether or not clients are defined by NAS or > by user. > That is a) not the question b) I was trying to clear confusion on clients. > Did you (a) NOT read the documentation, or (b) read it and not > understand it, or (c) read it, understand it, and ask a misleading > question? > Correct I might have a asked a misleading question, considering I added commands I send, how it is configured and your first response is 'not recommended' >> Thirdly , the case below is a true real life situation, which does not >> only occur only for me, but also for other. Even though the module is >> not >> officially supported (maybe for the reason there are) it is in today's >> world . You can decide, be a bernstein (like qmail) or adopt to a real >> life situation. (Btw, if this was such uncommon, how come I find as many >> question on it as there are. If YFI is actually supporting this, there >> must be a need. Even if it is not meant like that. > > People do all kinds of crazy things. That doesn't mean those things > are a good idea. It's fairly conceited for you, a non-expert, to > lecture me about RADIUS. > It is fairly clear that the experts claim they have the knowledge , but are guarding it. But considering I am using linux since '95 I am quite used to by now. Unfortunately, it is remarks and conceiled 'RTFM's that keep people from using OSS. Whether or not YFI is doing stuff with is crazy, it is what is needed in the current day and age. You can decide it is crazy, but I prefer a working crazy solution, next to a non-solution. I am secondly not lecturing you on how to use Radius, but you are "expert" are neither teaching me, by referring me to files I have read multiple times. Trust me, I do not jump into something without considering, testing and playing. Actually before working and trying this on a test system, I spend multiple days just installing, reading etc... >> Fourhtly, the issue I have has nothing to do with the whole running of >> rlm_raw or any alike. Authentication works fine and as expected. > > I'm not really clear on the issue you're having, because your > statements are contradictory. > For the record The IP address of a client is added using dynamic. I have set the lifetime to 60 (and the file states seconds), but it is not removed after 1 minute or even more. show client list in radmin also keeps showing it. Therefor I was actually looking at finding the contents of the cache. > Am I allowed to get frustrated at that? So you admit you are frustrated? With all best respect, I love people being helpfull, willing to test and try out. But if the immediate respons is "not recommended", well don't bother responding because people might have proper reasons for using it this way. The question was also asked to this mailinglist and not only you. There might be others who are using this in a similar fashion. > >> And yes I have read the statements on caching , what is used and even >> the >> disclaimer that only the src ip is supported. So don't become >> patronising >> that I didn't. > > Learn how to deal with people telling you you're wrong. It's a skill > many adults have. > Learn to adjust to the needs of the real world. This is not a student pet thing here. I am merely walking the boundaries of what the system is doing. You know, I could make the system check in using perl/php and update the IP address as I am using SQL as a backend. Same deal. But no, I don't see a purpose on a security level on doing it with rlm_raw / dynamic clients etc... >> I also scrobbled google for quite some time and I have read >> the debug more than you can think. But guess what? If the only output >> after authentication is >> adding client xxx.xxx.xxx.xxx with shared secret >> >> it does not state >> a) lifetime >> b) anything else usefull. > > It shows the IP of the client. It does NOT say "adding client keyed > by Called-Station-Id" > > See? The debug output says what it means, and means what it says. > Because you're unwilling to take it at face value, you think it's useless. > You know, I just needed to find out if the lifetime 60 will work because I don't see it. The changelog of FR actually state at a certain revision it was defaulted to 1 hour in case of lacking. Maybe there is a minimum? > That says more
RE: how to change the radius default "testing123" password
Hi Alan, Thanks for your reply. However, I have already changed the instances of the password "testing123" in the following files: StrongSwan:/etc/strongswan/strongswan.conf Radius:/etc/raddb/proxy.conf Radius:/etc/raddb/sites-available/dynamic-clients Radius:/etc/raddb/sites-available/originate-coa Radius:/etc/raddb/sites-available/robust-proxy-accounting Radius:/etc/raddb/clients.conf After restarting the strongswan and radiusd service, I was not able to authenticate to my LDAP server, and had to change the entries back to "testing123"? What am I missing here? -Original Message- From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org [mailto:freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, October 02, 2013 12:50 PM To: FreeRadius users mailing list Subject: Re: how to change the radius default "testing123" password cpetty wrote: > How can I change the radius default "testing123" password? Is there a > command I need to run to do this? Edit raddb/clients.conf. Look for "testing123". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
On 2 Oct 2013, at 19:06, st...@comitcon.be wrote: > Alan > > first of all thank you for replying although I must sense quite some > hostility in your replies. On the other hand, I have read previous emails > coming from your end and this appears to be the way you respond. Firstly, you ignored what Alan said, there are multiple ways of achieving what you want. * VPN - Establish an IPSEC/PPP tunnel. Use policy driven IP assignment to ensure that the same addresses get assigned to the same NAS. * TLS - RADSEC use the global client 0.0.0.0/0 and use RADSEC to authenticate NAS. Different certificates can be installed on different NAS, all signed by a common CA. * Global client - If you don't care about security use a single client definition and use the same shared secret. If this is behind a nat you know the public IP addresses the UDP frames will come from. Getting the attributes you want from the request means partially decoding the request. This is a bad thing to do in DDOS situations where you just want to discard packets from unknown clients as quickly as possible. It's also a security risk where traffic is ingressing from outside of your network. > Secondly I have read the documentation, but RTFM still appears to be the > common way of responding (even after using Linux for over 15 years). > > Thirdly , the case below is a true real life situation, which does not > only occur only for me, but also for other. Even though the module is not > officially supported (maybe for the reason there are) it is in today's > world . You can decide, be a bernstein (like qmail) or adopt to a real > life situation. (Btw, if this was such uncommon, how come I find as many > question on it as there are. If YFI is actually supporting this, there > must be a need. Even if it is not meant like that. Because people are given problems to solve outside their technical capacity, they fail to understand the underlying issue, and come up the solution that fits with their limited understanding of the problem and RADIUS. Or they understand the problem but are using NAS which has not been properly specced for the deployment scenario. > it does not state > a) lifetime > b) anything else usefull. What would you like included in that debug message, it's pretty trivial to change... > > Now I am running radmin show client list and see the IP appear. I am now > testing when it disappear. > > Please refrain from responding if it will only be a load of 'you did not > do this or that', while you have no clue on what I read or already have > done. If the response is coming to the basic question > "how can I check the lifetime of a dynamic client" feel free. > > Elsewise, let's keep this clean for people willing to find the proper > solution. The proper solution is one of the two posted above. I hate to pull the experience card, but i've been working with RADIUS the entirety of my professional career. I train people who work at telcos on RADIUS security and RADIUS cluster management. The way you're trying to do this is wrong. -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Digest Authentication with a Cisco device
Philip Walenta wrote: > I'm trying to do what might be an odd configuration. > > I'm attempting to digest auth users without caring about their > "User-name" attribute. That should work. > So in other words I want to auth on the "Digest-User-Name = "testuser"" > that comes in as part of the Digest-Attributes and a password. You should be able to do that. > So in the users file I have "DEFAULT Cleartext-password := > "password"" That will allow ANY user to authenticate using ANY authentication method, and with that password. > I created a partial digest file but it appears to be ignored on every test: > Digest-User-Name = "testuser" > Digest-Algorithm = "MD5" > Digest-QOP = "auth" I don't know what that means. What file is this? Why did you create it? What's reading it? > In the debug I see: > [digest] A1 = testuser:sp.eng:passwod > > I can change to username to anything I want and as long as the password > is correct the user will auth. That seems to be doing what you want. > Am I attempting something impossible or doing it incorrectly? I'm not entirely sure what you're doing, so I can't really answer that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
st...@comitcon.be wrote: > first of all thank you for replying although I must sense quite some > hostility in your replies. On the other hand, I have read previous emails > coming from your end and this appears to be the way you respond. Perhaps you could read the *content* of my messages, instead of inventing some emotional projection. > Secondly I have read the documentation, but RTFM still appears to be the > common way of responding (even after using Linux for over 15 years). So you read the documentation saying that clients are defined by IP addresses, and then asked whether or not clients are defined by NAS or by user. Did you (a) NOT read the documentation, or (b) read it and not understand it, or (c) read it, understand it, and ask a misleading question? > Thirdly , the case below is a true real life situation, which does not > only occur only for me, but also for other. Even though the module is not > officially supported (maybe for the reason there are) it is in today's > world . You can decide, be a bernstein (like qmail) or adopt to a real > life situation. (Btw, if this was such uncommon, how come I find as many > question on it as there are. If YFI is actually supporting this, there > must be a need. Even if it is not meant like that. People do all kinds of crazy things. That doesn't mean those things are a good idea. It's fairly conceited for you, a non-expert, to lecture me about RADIUS. > Fourhtly, the issue I have has nothing to do with the whole running of > rlm_raw or any alike. Authentication works fine and as expected. I'm not really clear on the issue you're having, because your statements are contradictory. Am I allowed to get frustrated at that? > And yes I have read the statements on caching , what is used and even the > disclaimer that only the src ip is supported. So don't become patronising > that I didn't. Learn how to deal with people telling you you're wrong. It's a skill many adults have. > I also scrobbled google for quite some time and I have read > the debug more than you can think. But guess what? If the only output > after authentication is > adding client xxx.xxx.xxx.xxx with shared secret > > it does not state > a) lifetime > b) anything else usefull. It shows the IP of the client. It does NOT say "adding client keyed by Called-Station-Id" See? The debug output says what it means, and means what it says. Because you're unwilling to take it at face value, you think it's useless. That says more about you than anything else. > Now I am running radmin show client list and see the IP appear. I am now > testing when it disappear. > > Please refrain from responding if it will only be a load of 'you did not > do this or that', while you have no clue on what I read or already have > done. You have no business making that demand. See the last paragraph of this message for my response. You asked a question and you got told an answer. When you made mistakes, they were pointed out. We CANNOT help you if your questions are unclear, or if your statements are contradictory. You have NO BUSINESS getting offended when people try to help you. > If the response is coming to the basic question > "how can I check the lifetime of a dynamic client" feel free. > > Elsewise, let's keep this clean for people willing to find the proper > solution. Read the documentation. Follow instructions. Don't argue with the experts. It's not hard. If you fail to follow instructions, or if you keep arguing about the instructions, or if you keep complaining when I answer your questions, you will be unsubscribed and permanently banned from this list. Such behavior is anti-social, rude, and will NOT be tolerated. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
st...@comitcon.be wrote: > For those interested: > > Information gotten from > > http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients > > In regards to the usage of Called_Station_Id, rlm_raw and SQL checks. Which notes that rlm_raw doesn't come with the server. The reason is simple. It's not necessary, and a security risk. There have been a number of requests to include rlm_raw, and the answer has been (and will always be) "no". There are alternatives which are more secure, and generally better. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: how to change the radius default "testing123" password
Clint Petty wrote: > How can I change the radius default "testing123" password? Is there a > command I need to run to do this? Edit raddb/clients.conf. Look for "testing123". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
how to change the radius default "testing123" password
I changed all instances of the password "testing123", to a random password on both the StrongSwan server and the Radius server, and restarted the strongswan and radiusd services. However, this broke the connection to authenticate to the LDAP server, so I had to put it back to "testing123" to get it to work again. How can I change the radius default "testing123" password? Is there a command I need to run to do this? Thanks for any help with this. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Digest Authentication with a Cisco device
I'm trying to do what might be an odd configuration. I'm attempting to digest auth users without caring about their "User-name" attribute. So in other words I want to auth on the "Digest-User-Name = "testuser"" that comes in as part of the Digest-Attributes and a password. So in the users file I have "DEFAULT Cleartext-password := "password"" I created a partial digest file but it appears to be ignored on every test: Digest-User-Name = "testuser" Digest-Algorithm = "MD5" Digest-QOP = "auth" In the debug I see: [digest] A1 = testuser:sp.eng:passwod I can change to username to anything I want and as long as the password is correct the user will auth. Am I attempting something impossible or doing it incorrectly? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
Alan first of all thank you for replying although I must sense quite some hostility in your replies. On the other hand, I have read previous emails coming from your end and this appears to be the way you respond. Secondly I have read the documentation, but RTFM still appears to be the common way of responding (even after using Linux for over 15 years). Thirdly , the case below is a true real life situation, which does not only occur only for me, but also for other. Even though the module is not officially supported (maybe for the reason there are) it is in today's world . You can decide, be a bernstein (like qmail) or adopt to a real life situation. (Btw, if this was such uncommon, how come I find as many question on it as there are. If YFI is actually supporting this, there must be a need. Even if it is not meant like that. Fourhtly, the issue I have has nothing to do with the whole running of rlm_raw or any alike. Authentication works fine and as expected. And yes I have read the statements on caching , what is used and even the disclaimer that only the src ip is supported. So don't become patronising that I didn't. I also scrobbled google for quite some time and I have read the debug more than you can think. But guess what? If the only output after authentication is adding client xxx.xxx.xxx.xxx with shared secret it does not state a) lifetime b) anything else usefull. Now I am running radmin show client list and see the IP appear. I am now testing when it disappear. Please refrain from responding if it will only be a load of 'you did not do this or that', while you have no clue on what I read or already have done. If the response is coming to the basic question "how can I check the lifetime of a dynamic client" feel free. Elsewise, let's keep this clean for people willing to find the proper solution. Best regards Steve >> 1. FreeRadius lacks the ability to actually run Nas's behind a link with >> a >> dynamic IP. Although not recommended, this software does not support a >> proper way of dealing with this. > > Nonsense. This is a fundamental limitation of the RADIUS protocol. > > If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614) > >> This is indeed a fake. I have added this in mysql in the nas table under >> the field community (described in ify /yfi setup). The connection >> actually >> works. I can (ab)use this field as much as desired > > Because RADIUS depends on source IP. > >>> Of course. RADIUS depends on IP addresses, not on Called-Station-Id. >>> This is documented in the "dynamic_clients" configuration. Right at >>> the top of the virtual server. >> >> Yes, I have read the documentation (multiple sources, google etc...) I >> was >> just wondering what happens when you use the raw module. > > It's not distributed with the server. So it's not a supported module. > And no, I don't use it. > > And no, you haven't read the documentation. The files I mentioned > *clearly* states that the dynamic clients use and cache the source IP. > They say NOTHING about checking the Called-Station-Id for each packet. > >> Is a client defined by a NAS or a user? > > RADIUS clients are defined by source IP. The documentation you > allegedly read makes this clear. So there's no need to ask the above > question... because the documentation already answers it. > >> The output shows indeed when it goes through the the dynamic server >> section and once it is authenticated it only runs through the default >> (which is understandable) > > So... *nothing* else in the debug output is useful to you. > > I guess you've read it as carefully as you've read the documentation. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
For those interested: Information gotten from http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients In regards to the usage of Called_Station_Id, rlm_raw and SQL checks. Kind regards Steve > >> 1. FreeRadius lacks the ability to actually run Nas's behind a link with >> a >> dynamic IP. Although not recommended, this software does not support a >> proper way of dealing with this. > > Nonsense. This is a fundamental limitation of the RADIUS protocol. > > If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614) > >> This is indeed a fake. I have added this in mysql in the nas table under >> the field community (described in ify /yfi setup). The connection >> actually >> works. I can (ab)use this field as much as desired > > Because RADIUS depends on source IP. > >>> Of course. RADIUS depends on IP addresses, not on Called-Station-Id. >>> This is documented in the "dynamic_clients" configuration. Right at >>> the top of the virtual server. >> >> Yes, I have read the documentation (multiple sources, google etc...) I >> was >> just wondering what happens when you use the raw module. > > It's not distributed with the server. So it's not a supported module. > And no, I don't use it. > > And no, you haven't read the documentation. The files I mentioned > *clearly* states that the dynamic clients use and cache the source IP. > They say NOTHING about checking the Called-Station-Id for each packet. > >> Is a client defined by a NAS or a user? > > RADIUS clients are defined by source IP. The documentation you > allegedly read makes this clear. So there's no need to ask the above > question... because the documentation already answers it. > >> The output shows indeed when it goes through the the dynamic server >> section and once it is authenticated it only runs through the default >> (which is understandable) > > So... *nothing* else in the debug output is useful to you. > > I guess you've read it as carefully as you've read the documentation. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
> 1. FreeRadius lacks the ability to actually run Nas's behind a link with a > dynamic IP. Although not recommended, this software does not support a > proper way of dealing with this. Nonsense. This is a fundamental limitation of the RADIUS protocol. If you want to use dynamic IPs, use a VPN, or TLS (RFC 6614) > This is indeed a fake. I have added this in mysql in the nas table under > the field community (described in ify /yfi setup). The connection actually > works. I can (ab)use this field as much as desired Because RADIUS depends on source IP. >> Of course. RADIUS depends on IP addresses, not on Called-Station-Id. >> This is documented in the "dynamic_clients" configuration. Right at >> the top of the virtual server. > > Yes, I have read the documentation (multiple sources, google etc...) I was > just wondering what happens when you use the raw module. It's not distributed with the server. So it's not a supported module. And no, I don't use it. And no, you haven't read the documentation. The files I mentioned *clearly* states that the dynamic clients use and cache the source IP. They say NOTHING about checking the Called-Station-Id for each packet. > Is a client defined by a NAS or a user? RADIUS clients are defined by source IP. The documentation you allegedly read makes this clear. So there's no need to ask the above question... because the documentation already answers it. > The output shows indeed when it goes through the the dynamic server > section and once it is authenticated it only runs through the default > (which is understandable) So... *nothing* else in the debug output is useful to you. I guess you've read it as carefully as you've read the documentation. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Password gets changed while proxying
On 02/10/13 17:30, JB wrote: Yes, we double checked the secret. Well, you missed something. There is no other reasonable explanation for the behaviour you're seeing. In *theory* it could be broken MD5 libraries at one end, but that's so unlikely that the possibility can be discarded. You have the shared secret wrong. Check again, using a new shared secret with unambiguous characters i.e. only letters and numbers. Once you've got it working with a simple secret, then change to a complex one. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
Dear Alan see my comments below > st...@comitcon.be wrote: >> I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a >> working dynamic client configuration where I use Called_Station_ID to >> authenticate / validate that a NAS is allowed to use this radius server. > > That's not a recommended configuration. 1. FreeRadius lacks the ability to actually run Nas's behind a link with a dynamic IP. Although not recommended, this software does not support a proper way of dealing with this. > >> I wait for a couple of minutes >> and I executed the following command of client A: >> echo "NAS-IP-Address=10.1.2.236, >> Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," >> | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' >> 'mysecret' >> >> This has a faulty Called-Station-Id in it. I would assume that it would >> not allow me to connect. But this appears to still work. This is indeed a fake. I have added this in mysql in the nas table under the field community (described in ify /yfi setup). The connection actually works. I can (ab)use this field as much as desired > > Of course. RADIUS depends on IP addresses, not on Called-Station-Id. > This is documented in the "dynamic_clients" configuration. Right at > the top of the virtual server. Yes, I have read the documentation (multiple sources, google etc...) I was just wondering what happens when you use the raw module. > >> I am wondering >> - The first time the IP address of client A is added to the list of >> known >> client >> - So the second time , it will check first in the list if the IP is >> known, >> if so it won't go checking using the process defined in dynamic clients? > > That's what the documentation says. Again, yep, read the docs... It is also stated in the yfi docs in the remarks below their dynamic client section. > >> But no matter how long I wait, it appears that the cache if not cleared. >> >> I have added a lifetime of 60 in the dynamic client conf, so I would >> assume that if I wait for a minute, the IP of client A would not be >> known, >> and it would go through checking again. > > That's how it works. > >> Am I wrong in this? If not can I read the cache to find out why it is >> keeping that record? > > You can use "radmin" to query the server about a client. It won't > show you the lifetime of that client. But it will show you if the > client still exists. > Is a client defined by a NAS or a user? Because I need to figure out how or when the dynamic client is remove from the cache? > And as always, run the server in debugging more. READ the output. It > tells you exactly what's going on, and why. > The output shows indeed when it goes through the the dynamic server section and once it is authenticated it only runs through the default (which is understandable) Steve > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Password gets changed while proxying
Yes, we double checked the secret. Am 02.10.2013 um 18:20 schrieb Francois Gaudreault : > Are you sure the RADIUS secret is the right one? > > > On Wed, Oct 2, 2013 at 12:14 PM, JB wrote: > Hi! > > We're proxying auth requests to another RADIUS service and encounter the > following problem: > The password seems to get changed somewhere along the way. > In our case, a 9 character password arrives as 16 character garbage at the > home server, which then -of course- rejects the access request. > Unfortunately, we don't have direct access to the home server, but the > provider is convinced that the password gets mangled on our side. > > I can see the correct password in our FreeRADIUS debug logs. > Other than preprocess, there's no module, which theoretically could change > the password, before the proxy realm . > > My guess is that this is some sort of double encoding problem… > Or maybe that the password doesn't get decoded properly on their side? > > Has anyone encountered a similar situation? > > Thanks! > JB - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Password gets changed while proxying
> > Has anyone encountered a similar situation? Yes, it's called getting the shared secret wrong between two of your servers. To prove this, enable Message-Authenticator validation on the home server. I believe recent versions of FreeRADIUS will include the Message-Authenticator attribute by default. You should see that the home server now refuses to process the request, instead of continuing with a garbled password. Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Password gets changed while proxying
On 02/10/13 17:14, JB wrote: Hi! We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request. You've got the shared secret wrong. This causes password decryption to fail. If you were using Message-Authenticator (as you, and indeed everyone, should be) the entire packet would fail the MA check and be dropped; but since you're not, only the fields encrypted by the shared secret are affected. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Password gets changed while proxying
Are you sure the RADIUS secret is the right one? On Wed, Oct 2, 2013 at 12:14 PM, JB wrote: > Hi! > > We're proxying auth requests to another RADIUS service and encounter the > following problem: > The password seems to get changed somewhere along the way. > In our case, a 9 character password arrives as 16 character garbage at the > home server, which then -of course- rejects the access request. > Unfortunately, we don't have direct access to the home server, but the > provider is convinced that the password gets mangled on our side. > > I can see the correct password in our FreeRADIUS debug logs. > Other than preprocess, there's no module, which theoretically could change > the password, before the proxy realm . > > My guess is that this is some sort of double encoding problem… > Or maybe that the password doesn't get decoded properly on their side? > > Has anyone encountered a similar situation? > > Thanks! > JB > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Password gets changed while proxying
Hi! We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request. Unfortunately, we don't have direct access to the home server, but the provider is convinced that the password gets mangled on our side. I can see the correct password in our FreeRADIUS debug logs. Other than preprocess, there's no module, which theoretically could change the password, before the proxy realm . My guess is that this is some sort of double encoding problem… Or maybe that the password doesn't get decoded properly on their side? Has anyone encountered a similar situation? Thanks! JB - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: lifetime of dynamic clients
st...@comitcon.be wrote: > I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a > working dynamic client configuration where I use Called_Station_ID to > authenticate / validate that a NAS is allowed to use this radius server. That's not a recommended configuration. > I wait for a couple of minutes > and I executed the following command of client A: > echo "NAS-IP-Address=10.1.2.236, > Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," > | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' > 'mysecret' > > This has a faulty Called-Station-Id in it. I would assume that it would > not allow me to connect. But this appears to still work. Of course. RADIUS depends on IP addresses, not on Called-Station-Id. This is documented in the "dynamic_clients" configuration. Right at the top of the virtual server. > I am wondering > - The first time the IP address of client A is added to the list of known > client > - So the second time , it will check first in the list if the IP is known, > if so it won't go checking using the process defined in dynamic clients? That's what the documentation says. > But no matter how long I wait, it appears that the cache if not cleared. > > I have added a lifetime of 60 in the dynamic client conf, so I would > assume that if I wait for a minute, the IP of client A would not be known, > and it would go through checking again. That's how it works. > Am I wrong in this? If not can I read the cache to find out why it is > keeping that record? You can use "radmin" to query the server about a client. It won't show you the lifetime of that client. But it will show you if the client still exists. And as always, run the server in debugging more. READ the output. It tells you exactly what's going on, and why. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HTTP; JMS Access
George Innocent wrote: > I seek your support and advice to resolve this incidence relating to the > Radius server used for authentification. > > There is a user created on the Radius that is used by Netcool for the > synch with the SAM server. > > The user authenticates successfully but there is failure of connection > on the JMS and http with the error message below when RADIUS is used. That error has nothing to do with FreeRADIUS. See the documentation for the other software. It should tell you how to use it with RADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
lifetime of dynamic clients
Dear all, I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a working dynamic client configuration where I use Called_Station_ID to authenticate / validate that a NAS is allowed to use this radius server. I test using the following command on client A echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:ee,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret' I can see in the logs that is is checking the first time I log on and it is properly giving the message adding client xxx.xxx.xxx.xxx with shared secret. Now, when I executed the same command on a different machine Client B, it runs through it again. (Same command, I only had 1 nas added to it ) It adds the new 'client' to the dynamic clients. I wait for a couple of minutes and I executed the following command of client A: echo "NAS-IP-Address=10.1.2.236, Called-Station-Id=00:40:96:aa:bb:cc,User-Name='testradius',User-Password='test'," | radclient -c '1' -n '3' -r '3' -t '3' -x '46.18.36.232:1812' 'auth' 'mysecret' This has a faulty Called-Station-Id in it. I would assume that it would not allow me to connect. But this appears to still work. I am wondering - The first time the IP address of client A is added to the list of known client - So the second time , it will check first in the list if the IP is known, if so it won't go checking using the process defined in dynamic clients? But no matter how long I wait, it appears that the cache if not cleared. I have added a lifetime of 60 in the dynamic client conf, so I would assume that if I wait for a minute, the IP of client A would not be known, and it would go through checking again. Am I wrong in this? If not can I read the cache to find out why it is keeping that record? Kind regards Steve - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HTTP; JMS Access
I seek your support and advice to resolve this incidence relating to the Radius server used for authentification. There is a user created on the Radius that is used by Netcool for the synch with the SAM server. The user authenticates successfully but there is failure of connection on the JMS and http with the error message below when RADIUS is used. · george (admin account) : Found message of type FATALERROR: Probe failed to subscribe for notifications. Caused by: javax.jms.JMSSecurityException: SAM-O Access Violation - knoll (SAM-O account) : Exception in NSHeadResyncIntervalThread - Failed to establish HTTP connection for resync The user created on Radius as below: knoll Cleartext-Password :="airtel!23" Service-Type= Framed-User, Framed-Protocol = PPP, Sam-security-group-name = "SAM-O" Is there any parameters that have to be enabled or assigned for this user to be able to have the functions assigned to it. -- Regards: George Innocent. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
