Matthew P wrote:
> btw. the "unlang-way" is quite more flexible than the "legacy-module-way"
Yes. That's why it was written. But there is still a need for the
modules.
> Was this problem even possible to solve without using unlang? (using
> freeradius 1.x for an example)
Likely not.
Al
Thanks for the clarification, Alan. Looks like a client corresponds to users'
equipment (laptop in your example) OUTSIDE of my firewall. This means the NAS
would be my BSD-based Pfsense gateway. I googled and found out that Pfsense
supports FreeRADIUS, which answers my next question, "How do
Hi,
> I’m new to FreeRADIUS and I still don’t have a good sense of who talks to
> who. I’ve attached a small PDF-format diagram of what I’m trying to
> accomplish and my IDEA of who talks to who. Any links or feedback would be
> appreciated…
clients (eg users laptops) talk to NAS (eg wifi ac
Greetings All,
I'm new to FreeRADIUS and I still don't have a good sense of who talks to
who. I've attached a small PDF-format diagram of what I'm trying to
accomplish and my IDEA of who talks to who. Any links or feedback would be
appreciated.
Cheers!
Thomas
FreeRADIUS Communication.
> $ man unlang
>
> This says "put the string %{1} as the value of Stripped-User-Name".
>
> See the "data types' section of the manual page, and the "strings" section.
Got it ;)
Thanks for your help, fixed now.
btw. the "unlang-way" is quite more flexible than the "legacy-module-way"
Was this pr
Next step must be ktrace(8)/kdump(8) or GDB [1].
~BAS
So it turns out, since April, there have been two distinctive types of
crashes.
The unexplained SIGHUP, which we eventually tracked down to faulty
logging configurations (now using SYSLOG instead of file logging), and
an ongoing Sig
Hi Alan,
Thanks for the simplifications - I've put those in.
I have done lots more reading and testing and found that any attribute I check
for in a group file which has type ipaddr fails. I cannot see why this is.
When debug displays the attributes and their values there are no quotes around
ip
My apologies, I tried to be concise but I now realize that I shouldn't.
The "realms" module is referenced as "suffix" in my (default) config, so
I didn't notice I forgot to include that module in one of the server
configs. I included the realm module before that condition and indeed
now it works.
WWF wrote:
> however, I still have an important question. Our vendor asked us to
> return some attributes which are listed in WiMAX Forum Standard as
> return 0-n or 1-n. That is, in a single access-accept packet, there may
> 2 or 3 value for attribute like "Packet-Flow-Descriptor",
> "Time-Of-Day-
Velpi wrote:
> Mon Jul 5 13:53:47 2010 : Info: ++? if (Realm == NULL)
> Mon Jul 5 13:53:47 2010 : Info: (Attribute Realm was not found)
1) You are not running in debugging mode as suggested in the FAQ,
README, INSTALL, "man" page, and daily on this list.
2) You are not posting the full
>> is it possible to configure an instant reject for a certain realm
>> I'd like to set this for the NULL realm to disable
>> usernames without a suffix. (any other suggestion to accomplish this is
>> welcomed too!)
>
> You can put this into the "authorize" section, after the "realm" modules:
>
Hello, all!
Now I use fr 2.19 for our WiMAX network. It works well now! Thanks for all who
have helped us on this maillist.
however, I still have an important question. Our vendor asked us to return some
attributes which are listed in WiMAX Forum Standard as return 0-n or 1-n. That
is, in a sin
Velpi wrote:
> is it possible to configure an instant reject for a certain realm
Yes.
> (in proxy.conf)?
No.
The "proxy.conf" file defines realms, home servers, etc. It contains
no directives for processing requests.
> I'd like to set this for the NULL realm to disable
> usernames with
Just for information: It also does not work with the most recent version of
samba 3.5.4.
It definitely works with 3.0.30.
Norbert Wegener
An: FreeRadius users mailing list
Betreff: Re: AW: mschap/peap question
Wegener, Norbert wrote:
> I installed samba 3..4.8 and it produces the same errors
Hi,
is it possible to configure an instant reject for a certain realm (in
proxy.conf)? I'd like to set this for the NULL realm to disable
usernames without a suffix. (any other suggestion to accomplish this is
welcomed too!)
Thanks!
--
/-
| Jan "Velpi
Hi,
no...you havent added it. look, heres the debug you supplied
> It is the related part in configuration file:
> ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key
> --domain=%{mschap:NT-Domain:-xjtu} --username=%{mschap:User-Name}
> --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT
Yes. I did the same thing in 2.19. But it looks not works.
--- 10年7月5日，周一, Alan DeKok 写道：
发件人: Alan DeKok
主题: Re: ntlm_auth fails for none domain
收件人: "FreeRadius users mailing list"
日期: 2010年7月5日,周一,下午4:08
John wrote:
>
> Yes. I did not supply the domain into in the usename.
> But "xjtu
John wrote:
>
> Yes. I did not supply the domain into in the usename.
> But "xjtu" is our default domain, I set it in mschap ntlm_auth
> parameters. If I use old freeRADIUS-1.1.6, mschap module will supply
> "xjtu" as domain if no domain info in username.
>
> --domain=%{mschap:NT-Domain:-xjtu}
It is debug info when I use freeRADIUS-1.1.6.
rad_recv: Access-Request packet from host 10.155.20.85:32790, id=171,
length=125
--> Service-Type = Authorize-Only
--> NAS-Port-Type = Wireless-802.11
--> User-Name = "hhe"
--> MS-CHAP-Challenge = 0x837a4fb32a47a5bda0c24d5e4329fcdc
Yes. I did not supply the domain into in the usename.
But "xjtu" is our default domain, I set it in mschap ntlm_auth parameters. If
I use old freeRADIUS-1.1.6, mschap module will supply "xjtu" as domain if no
domain info in username.
--domain=%{mschap:NT-Domain:-xjtu}
--- 10年7月2日，周五, A
20 matches
Mail list logo
