Sorry, we don't do requests. But we can help. *You* write the example
and post the debug if things are not going well and we will tell you how
to fix it. You can place the result of the query in a temporary
attribute like Tmp-String-0 := "%{sql:SELECT whatever... It should be
authorize section.
I
Greetings,
I have a best practices question. I am currently building a freeradius+LVS
cluster to replace an existing radius server. In the process I am trying to
do things as solidly as possible. Part of this process is tidying up the
users file. In the process I noticed a rule that made me a littl
> This is impossible. It is *designed* to be impossible. If it was
> possible, malicious networks could tell users that "authentication
> succeeded", and then attack the users.
I'm not sure you grasped what I was after - imagine a 802.1x wired switch,
supplicants and RADIUS server configured
> If this is a wired port then just force an Access-Accept, yes it breaks
> the RFC but if your NAS doesn't inspect the contents of the EAP-Message
> then it'll work.
I would think that would work, I just don't know how to do that! It's really
easy to create a module that returns "ok" or "han
Hi,
> I would think that would work, I just don't know how to do that! It's really
> easy to create a module that returns "ok" or "handled" but, despite hours of
> pouring through the unlange manpages and documentation on rlm_example,
> rlm_perl, and rlm_exec, I cannot seem to create a module t
Danny Paul wrote:
> I'm not sure you grasped what I was after
Yes, I understood. This kind of request has come up before on this list.
For *wireless*, it's impossible, because the supplicant && NAS use
encryption keys derived from the EAP-TLS exchange. No exchange means no
keys.
For wir
Danny Paul wrote:
> I would think that would work, I just don't know how to do that! It's
> really easy to create a module that returns "ok" or "handled" but,
> despite hours of pouring through the unlange manpages and documentation
> on rlm_example, rlm_perl, and rlm_exec, I cannot seem to create
Elizabeth Steinke wrote:
> I tested this rule with radtest (Making the necessary modifications and
> it worked fine.
>
> DEFAULT Huntgroup-Name = "vpn-pix",Ldap-Group = "CN=somevpn...",
> Auth-Type := ntlm_auth_plaintext
> DEFAULT Huntgroup-Name = "vpn-pix",Ldap-Group != "CN=somevpn...",
> Auth-T
>The purpose of the rule is to handle incoming requests from a cisco pix for
>VPN authentication. It is supposed to validate it using ntlm_auth. There are
>two ntlm_auth definitions in the radiusd.conf. One handles MS-CHAP and one
>is for ntlm_auth_plaintext.
>I tested this rule with radtest (Makin
Fantastic!
Thanks so much. unlang looks pretty interesting. Ill need to do more
reading. Is there a book coming out on freeradius 2 soon? I've gotten alot
of good info from the oreilly freeradius 1 book.
Thanks!
Liz
On Sun, Oct 19, 2008 at 11:17 AM, Alan DeKok <[EMAIL PROTECTED]>wrote:
> Elizab
Greetings!
I'm having an odd problem trying to implement load balancing/redundancy. I
have added the following lines to my radiusd.conf
authorize {...
#
# We want redundant ldap lookups
##
redundant-load-balance {
ldap1
ldap2
}
##
# end redundancy
##
}
modules (...
ldap ldap1
Same huntgroup - different ldaps; you can't have DEFAULT lines rejecting
users then. Comment them out and see if it works.
Ivan Kalik
Kalik Informatika ISP
Dana 19/10/2008, "Elizabeth Steinke" <[EMAIL PROTECTED]> piše:
>Greetings!
>I'm having an odd problem trying to implement load balancing/re
Hi!
I commented out the deny rule and it exhibits the same behavior. I am at a
loss on this on.
2008/10/19 <[EMAIL PROTECTED]>
> Same huntgroup - different ldaps; you can't have DEFAULT lines rejecting
> users then. Comment them out and see if it works.
>
> Ivan Kalik
> Kalik Informatika ISP
>
HI Alan,
what If radtest localhost also doesn't work either?
here the iptables output
#iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 127.0.0.10.0.0.0/0
ACCEPT all -- 192.168.1.2 0.0.0.0/0
ACCEPT
Greetings!
I have a suggestion ,If you want to see if the packets are getting to the
host try running
tcp -X udp
also
tcpdump -X host
then try a request and see if the packets show up.
On Sun, Oct 19, 2008 at 7:38 PM, saman saman <[EMAIL PROTECTED]> wrote:
>
> HI Alan,
> what If radtest loc
Since we have other applications that don't and probably never will preform
redundant LDAP lookups I'm thinking I will just an LDAP VIP to the LVS
server.
I am still willing to try an solutions in my lab for the sake of having it
in the list archives :)
2008/10/19 Elizabeth Steinke <[EMAIL PROTEC
a few more suggestions :)
What is in your rules file?
Can you telnet to localhost port 1812, how about 127.0.0.1 1812 (broken
hosts file mebbe)
also try this
lsof -i |grep -i radius
you should see radius listening
Liz
On Sun, Oct 19, 2008 at 7:38 PM, saman saman <[EMAIL PROTECTED]> wrote:
>
saman saman wrote:
> what If radtest localhost also doesn't work either?
> here the iptables output
...
> #radtest John hello localhost 0 testing
OK... you've looked at the server in debugging mode when it's not
receiving packets. You've looked at the firewall. You've looked at the
debug outpu
18 matches
Mail list logo
