[EMAIL PROTECTED]
thank u for your reply.I have resolved this problem. you are right.FreeRADIUS can't find the oracle library. by the way,are you familair with OID.w wanna keep in touch with u. my msn:[EMAIL PROTECTED] bobby from beijing - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: not to return the detault attributes in reject?
kevin <[EMAIL PROTECTED]> wrote: > I just need to know how to send a reject packet not including default > attributes. > I have asked the same questions about 8 times but nobody answered clearly. Access-Reject packets can contain pretty much only Reply-Message. If you are seeing other attributes, then they're either VSA's (a bug that will be fixed in 1.0.5), or you're running a very old version of the server. Alan Dekok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
So that worked, group authentication. Thank you for pointing me in the right direction. BTW I do know how RADIUS and LDAP work. I'm not new to the technology, just FreeRADIUS in general. Thanks again. -Daniel On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > I see where I err in my ways. I'm setting the Auth-Type to LDAP > specifically in the users file as I have a Fall-Through configured: > > DEFAULT Auth-Type := LDAP > Fall-Through = 1 > > and the ldap_howto suggests using LDAP groups instead. > > I'm going to go back and set this up "the right way" instead of "the wrong > way" > > -Daniel > > > On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > > I didn't pull this configuration file out of my ass. I *AM* using > > default configs. > > > > More to follow... > > > > On 9/8/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > > > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > > > I'm not sure I understand why my approach is so incorrect. If I am > > > > wrong, please explain it to me. > > > > > > I would suggest reading the existing samples and documentation for > > > how to configure the server. They explain the correct way to do > > > things. The number of incorrect ways to do things is almost infinite. > > > > > > > My understanding is we've AUTHORIZED the request by pulling the > > > > password information off of the LDAP server and storing it in memory. > > > > > > Yes. > > > > > > > Then (according to my understanding of the radiusd.conf) in the > > > > authenticate {} block, we pick which modules in order will do the > > > > AUTHENTICATION part of the AAA session. One of the two modules will > > > > always fail. > > > > > > If, and ONLY if, you list BOTH modules in an "Auth-Type {}" section > > > in "authenticate". > > > > > > The solution is DON'T DO THAT. > > > > > > List them separately, as shown in the default config. > > > > > > Again, I'm a little surprised that this is so hard to configure, > > > given that the default config shows how to do it. It takes additional > > > effort to create a different configuration, which will then not work. > > > > > > > We first try the digest module and get this: > > > > Processing the authenticate section of radiusd.conf > > > > modcall: entering group Auth-Type for request 1 > > > > ERROR: No Digest-Nonce: Cannot perform Digest authentication > > > > modcall[authenticate]: module "digest" returns invalid for request 1 > > > > > > > > Then we move on to the next section of the Auth-Type LDAP > > > > configuration section of the authenticate {} block, and allow the LDAP > > > > module to take a crack at it and thus we have a sucessful > > > > authentication: > > > > > > Yes. Your configuration seems to work, but it's inefficient and > > > unnecessary. Rather that following the existing examples, you appear > > > to have randomly added hacks until it "works", with little > > > understanding of how the server is supposed to be configured. > > > > > > Please, use the default configuration where possible. It works, and > > > it was designed by people who understand LDAP, digest, and the server. > > > Your hacks may appear to work, but they are based on misunderstandings > > > and confusion. They WILL NOT be maintainable by you, or anyone else > > > going into the future. > > > > > > 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: not to return the detault attributes in reject?
Thor suggested it and I just put it to show that it did not work. Fall-Through = No did not work either. I just need to know how to send a reject packet not including default attributes. I have asked the same questions about 8 times but nobody answered clearly. Kevin. Chris Parker wrote: On Sep 8, 2005, at 2:59 PM, kevin wrote: It didn't work. DEFAULT Auth-Type := Reject Fall-Through = Yes DEFAULT Service-Type == Framed-User Framed-IP-Netmask=255.255.255.255, Service-Type = Framed-User, Idle-Timeout=1800, Session-Timeout=86000, Still return all attributes for the reject packet. Because you've told it to fall through. Change the 'Yes' to 'No' in your Reject profile. -Chris -- Chris Parker Director, Engineering StarNet A Service of US LEC (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential. - 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: Mixed-mode authentication enviornment
I see where I err in my ways. I'm setting the Auth-Type to LDAP specifically in the users file as I have a Fall-Through configured: DEFAULT Auth-Type := LDAP Fall-Through = 1 and the ldap_howto suggests using LDAP groups instead. I'm going to go back and set this up "the right way" instead of "the wrong way" -Daniel On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > I didn't pull this configuration file out of my ass. I *AM* using > default configs. > > More to follow... > > On 9/8/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > > I'm not sure I understand why my approach is so incorrect. If I am > > > wrong, please explain it to me. > > > > I would suggest reading the existing samples and documentation for > > how to configure the server. They explain the correct way to do > > things. The number of incorrect ways to do things is almost infinite. > > > > > My understanding is we've AUTHORIZED the request by pulling the > > > password information off of the LDAP server and storing it in memory. > > > > Yes. > > > > > Then (according to my understanding of the radiusd.conf) in the > > > authenticate {} block, we pick which modules in order will do the > > > AUTHENTICATION part of the AAA session. One of the two modules will > > > always fail. > > > > If, and ONLY if, you list BOTH modules in an "Auth-Type {}" section > > in "authenticate". > > > > The solution is DON'T DO THAT. > > > > List them separately, as shown in the default config. > > > > Again, I'm a little surprised that this is so hard to configure, > > given that the default config shows how to do it. It takes additional > > effort to create a different configuration, which will then not work. > > > > > We first try the digest module and get this: > > > Processing the authenticate section of radiusd.conf > > > modcall: entering group Auth-Type for request 1 > > > ERROR: No Digest-Nonce: Cannot perform Digest authentication > > > modcall[authenticate]: module "digest" returns invalid for request 1 > > > > > > Then we move on to the next section of the Auth-Type LDAP > > > configuration section of the authenticate {} block, and allow the LDAP > > > module to take a crack at it and thus we have a sucessful > > > authentication: > > > > Yes. Your configuration seems to work, but it's inefficient and > > unnecessary. Rather that following the existing examples, you appear > > to have randomly added hacks until it "works", with little > > understanding of how the server is supposed to be configured. > > > > Please, use the default configuration where possible. It works, and > > it was designed by people who understand LDAP, digest, and the server. > > Your hacks may appear to work, but they are based on misunderstandings > > and confusion. They WILL NOT be maintainable by you, or anyone else > > going into the future. > > > > 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: Mixed-mode authentication enviornment
I didn't pull this configuration file out of my ass. I *AM* using default configs. More to follow... On 9/8/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > I'm not sure I understand why my approach is so incorrect. If I am > > wrong, please explain it to me. > > I would suggest reading the existing samples and documentation for > how to configure the server. They explain the correct way to do > things. The number of incorrect ways to do things is almost infinite. > > > My understanding is we've AUTHORIZED the request by pulling the > > password information off of the LDAP server and storing it in memory. > > Yes. > > > Then (according to my understanding of the radiusd.conf) in the > > authenticate {} block, we pick which modules in order will do the > > AUTHENTICATION part of the AAA session. One of the two modules will > > always fail. > > If, and ONLY if, you list BOTH modules in an "Auth-Type {}" section > in "authenticate". > > The solution is DON'T DO THAT. > > List them separately, as shown in the default config. > > Again, I'm a little surprised that this is so hard to configure, > given that the default config shows how to do it. It takes additional > effort to create a different configuration, which will then not work. > > > We first try the digest module and get this: > > Processing the authenticate section of radiusd.conf > > modcall: entering group Auth-Type for request 1 > > ERROR: No Digest-Nonce: Cannot perform Digest authentication > > modcall[authenticate]: module "digest" returns invalid for request 1 > > > > Then we move on to the next section of the Auth-Type LDAP > > configuration section of the authenticate {} block, and allow the LDAP > > module to take a crack at it and thus we have a sucessful > > authentication: > > Yes. Your configuration seems to work, but it's inefficient and > unnecessary. Rather that following the existing examples, you appear > to have randomly added hacks until it "works", with little > understanding of how the server is supposed to be configured. > > Please, use the default configuration where possible. It works, and > it was designed by people who understand LDAP, digest, and the server. > Your hacks may appear to work, but they are based on misunderstandings > and confusion. They WILL NOT be maintainable by you, or anyone else > going into the future. > > 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: Mixed-mode authentication enviornment
Daniel Corbe <[EMAIL PROTECTED]> wrote: > I'm not sure I understand why my approach is so incorrect. If I am > wrong, please explain it to me. I would suggest reading the existing samples and documentation for how to configure the server. They explain the correct way to do things. The number of incorrect ways to do things is almost infinite. > My understanding is we've AUTHORIZED the request by pulling the > password information off of the LDAP server and storing it in memory. Yes. > Then (according to my understanding of the radiusd.conf) in the > authenticate {} block, we pick which modules in order will do the > AUTHENTICATION part of the AAA session. One of the two modules will > always fail. If, and ONLY if, you list BOTH modules in an "Auth-Type {}" section in "authenticate". The solution is DON'T DO THAT. List them separately, as shown in the default config. Again, I'm a little surprised that this is so hard to configure, given that the default config shows how to do it. It takes additional effort to create a different configuration, which will then not work. > We first try the digest module and get this: > Processing the authenticate section of radiusd.conf > modcall: entering group Auth-Type for request 1 > ERROR: No Digest-Nonce: Cannot perform Digest authentication > modcall[authenticate]: module "digest" returns invalid for request 1 > > Then we move on to the next section of the Auth-Type LDAP > configuration section of the authenticate {} block, and allow the LDAP > module to take a crack at it and thus we have a sucessful > authentication: Yes. Your configuration seems to work, but it's inefficient and unnecessary. Rather that following the existing examples, you appear to have randomly added hacks until it "works", with little understanding of how the server is supposed to be configured. Please, use the default configuration where possible. It works, and it was designed by people who understand LDAP, digest, and the server. Your hacks may appear to work, but they are based on misunderstandings and confusion. They WILL NOT be maintainable by you, or anyone else going into the future. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Daniel Corbe <[EMAIL PROTECTED]> wrote: > To Recap, here are exerpts from my radius config: ... > And here is the end result: ... > rlm_digest: Adding Auth-Type = DIGEST ... > rad_check_password: Found Auth-Type LDAP There appears to be some discrepancy. Find out what's setting Auth-Type to LDAP, and delete that. It's breaking digest authentication. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: one question
"Richie Lee" <[EMAIL PROTECTED]> wrote: > My company is a security vendor company(www.fortinet.com). How to add > dictionary.fortinet to the server's list of vendor dictionaries in later > freeradius version? Does anyone know it? Email it to the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: one question
Title: RE: one question Hi Richie, Simply look in the /usr/local/share/freeradius/dictionary file. It includes a load of $INCLUDE lines pointing to each of the dictionary.foo files. All you need to do is add $INCLUDE dictionary.fortinet to that file and make sure that the file dictionary.fortinet is in the correct format and is located in the same directory. Rgds, Guy -Original Message- From: [EMAIL PROTECTED] on behalf of Richie Lee Sent: Thu 09/08/05 7:58 PM To: freeradius-users@lists.freeradius.org Subject: one question My company is a security vendor company(www.fortinet.com). How to add dictionary.fortinet to the server's list of vendor dictionaries in later freeradius version? Does anyone know it? _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: not to return the detault attributes in reject?
On Sep 8, 2005, at 2:59 PM, kevin wrote: It didn't work. DEFAULT Auth-Type := Reject Fall-Through = Yes DEFAULT Service-Type == Framed-User Framed-IP-Netmask=255.255.255.255, Service-Type = Framed-User, Idle-Timeout=1800, Session-Timeout=86000, Still return all attributes for the reject packet. Because you've told it to fall through. Change the 'Yes' to 'No' in your Reject profile. -Chris -- Chris Parker Director, Engineering StarNet A Service of US LEC (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Some questions about freeRADIUS implementation, PLEASE HELP ME!!
Title: RE: Some questions about freeRADIUS implementation,PLEASE HELP ME!! Here my doubt: I am using EAP-TLS I generated a client Certificate with CN "redes" then I add at LDAP database a user with these atributes cn: redes uid: redes radiusGroupName: academicos ..others Attributes but without userpassword and in the users file i add: DEFAULT Ldap-Group == academicos, Simultaneous-Use := 1 Aruba-User-Role = "STAFF", A user with client certificate can access at Wireless network and get the Role STAFF perfectly, but the process of authentication and authorization seems like very very redundant, is normal that?. I attach the file of process auth. [GD] Hi Alfonso, The authentication and authorization are different things. Authentication is asking may this user connect. Authorization is asking once this user has connected (i.e. Authentication has passed) what may they do (e.g. what type of user are they [student/staff], what VLAN should they be associated with, what is their access level [e.g. on Cisco routers = 1 to 15]) That allows you to provide more than a simple yes/no answer to the request to login. Rgds, Guy This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: not to return the detault attributes in reject?
It didn't work. DEFAULT Auth-Type := Reject Fall-Through = Yes DEFAULT Service-Type == Framed-User Framed-IP-Netmask=255.255.255.255, Service-Type = Framed-User, Idle-Timeout=1800, Session-Timeout=86000, Still return all attributes for the reject packet. I am really curious nobody issued that freeradius should return the default attributes regardless of accept/reject. Anybody? Please... kevin Thor Spruyt wrote: kevin wrote: Still not sure how to handle with rlm_exec. Can anybody give me more details? Maybe another solution.. in users file TART with: DEFAULT Auth-Type := Reject Fall-Through = Yes kevin Thor Spruyt wrote: kevin wrote: How can I return Reject-Packet without default attributes? It seems that the default attributes in the users file are returned regardless of Accept or Reject. I don't want to give a hint to hacker who can try a lot of rejects. Is there a way? Somebody suggested Exec-Program-Wait = "reject.sh" before. But, it didn't work for me. rlm_exec - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
need somehelp plz
hi all i.am new in radius system and i need help to make auth by mac address for my users and thanks Click here to donate to the Hurricane Katrina relief effort.- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Not going past "Sending Access-Challenge"
Adam Tauno Williams wrote: >> I'm trying to setup RADIUS/WPA authentication using PEAP as >> described in - >> http://www.ibiblio.org/pub/Linux/docs/HOWTO/8021X-HOWTO - but I >> never seem to get past the "Sending Access-Challenge" after I enter >> my username and password on the client. User is simply an entry in >> the users file with a clear text password. I've gone over the >> config several times, but nothing jumps out at me as an error >> message. Alan DeKok wrote: > The problem most likely is that the AP isn't seeing the response, or >it isn't liking the response. Check the IP addresses that the packet >use, via "tcpdump". Okay, I've etherealled the connection and I see an "Access-Request" from the WAP to the RADIUS server, then an "Access-Challenge" from the RADIUS serve to the WAP, and nothing else. What should the WAP's response to an "Access-Challenge" response be? The WAP is 192.168.1.42 and the RADIUS server is 192.168.1.47 No. TimeSourceDestination Protocol Info 8 0.839425192.168.1.42 192.168.1.47 RADIUS Access-Request(1) (id=26, l=133) Frame 8 (175 bytes on wire, 175 bytes captured) Ethernet II, Src: noor.morrison.iserv.net (00:0f:3d:43:6a:3c), Dst: tor.morrison.iserv.net (00:0d:60:0f:fd:4a) Internet Protocol, Src: 192.168.1.42 (192.168.1.42), Dst: 192.168.1.47 (192.168.1.47) User Datagram Protocol, Src Port: groove-dpp (1211), Dst Port: radius (1812) Radius Protocol Code: Access-Request (1) Packet identifier: 0x1a (26) Length: 133 Authenticator: 14E77EEE7405E31F02AB6A803EB478A1 Attribute Value Pairs AVP: l=10 t=User-Name(1): awilliam AVP: l=6 t=NAS-IP-Address(4): 192.168.1.42 AVP: l=6 t=NAS-Port(5): 0 AVP: l=19 t=Called-Station-Id(30): 00-0F-3D-43-6A-3C AVP: l=19 t=Calling-Station-Id(31): 00-14-A5-30-BC-27 AVP: l=8 t=NAS-Identifier(32): wap001 AVP: l=6 t=Framed-MTU(12): 1380 AVP: l=6 t=NAS-Port-Type(61): Wireless-802.11(19) AVP: l=15 t=EAP-Message(79) Last Segment[1] Length: 13 EAP fragment Extensible Authentication Protocol Code: Response (2) Id: 1 Length: 13 Type: Identity [RFC3748] (1) Identity (8 bytes): awilliam AVP: l=18 t=Message-Authenticator(80): 92C34CC691D9BC0D5B49F180B2F4EA59 Length: 16 Message-Authenticator: 92C34CC691D9BC0D5B49F180B2F4EA59 No. TimeSourceDestination Protocol Info 15 0.842887192.168.1.47 192.168.1.42 RADIUS Access-challenge(11) (id=26, l=83) Frame 15 (125 bytes on wire, 125 bytes captured) Ethernet II, Src: tor.morrison.iserv.net (00:0d:60:0f:fd:4a), Dst: noor.morrison.iserv.net (00:0f:3d:43:6a:3c) Internet Protocol, Src: 192.168.1.47 (192.168.1.47), Dst: 192.168.1.42 (192.168.1.42) User Datagram Protocol, Src Port: radius (1812), Dst Port: groove-dpp (1211) Radius Protocol Code: Access-challenge (11) Packet identifier: 0x1a (26) Length: 83 Authenticator: DE3DC989610D986213D85EF526EA47BD Attribute Value Pairs AVP: l=19 t=Reply-Message(18): EAPTEST Hello, %u Length: 17 Reply-Message: EAPTEST Hello, %u AVP: l=8 t=EAP-Message(79) Last Segment[1] Length: 6 EAP fragment Extensible Authentication Protocol Code: Request (1) Id: 2 Length: 6 Type: PEAP [Palekar] (25) Flags(0x20): Start PEAP version 0 AVP: l=18 t=Message-Authenticator(80): 36719CCCEE09502EA6C644C5EEC62B87 Length: 16 Message-Authenticator: 36719CCCEE09502EA6C644C5EEC62B87 AVP: l=18 t=State(24): 4CA90CA7DE0086900AEB2E8BB35E773A Length: 16 State: 4CA90CA7DE0086900AEB2E8BB35E773A No. TimeSourceDestination Protocol Info 16 0.879314192.168.1.42 192.168.1.47 RADIUS Access-Request(1) (id=27, l=218) Frame 16 (260 bytes on wire, 260 bytes captured) Ethernet II, Src: noor.morrison.iserv.net (00:0f:3d:43:6a:3c), Dst: tor.morrison.iserv.net (00:0d:60:0f:fd:4a) Internet Protocol, Src: 192.168.1.42 (192.168.1.42), Dst: 192.168.1.47 (192.168.1.47) User Datagram Protocol, Src Port: groove-dpp (1211), Dst Port: radius (1812) Radius Protocol Code: Access-Request (1) Packet identifier: 0x1b (27) Length: 218 Authenticator: FBD53DBF46F4F69697F2427EDE5176A3 Attribute Value Pairs AVP: l=10 t=User-Name(1): awilliam AVP: l=6 t=NAS-IP-Address(4): 192.168.1.42 AVP: l=6 t=NAS-Port(5): 0 AVP: l=19 t=Called-Station-Id(30): 00-0F-3D-43-6A-3C AVP: l=19 t=Calling-Station-Id(31): 00-14-A5-30-BC-27 AVP: l=8 t=NAS-Identifier(32): wap001 AVP: l=6
Re: Mixed-mode authentication enviornment
I'm not sure I understand why my approach is so incorrect. If I am wrong, please explain it to me. My understanding is we've AUTHORIZED the request by pulling the password information off of the LDAP server and storing it in memory. Then (according to my understanding of the radiusd.conf) in the authenticate {} block, we pick which modules in order will do the AUTHENTICATION part of the AAA session. One of the two modules will always fail. We first try the digest module and get this: Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 1 ERROR: No Digest-Nonce: Cannot perform Digest authentication modcall[authenticate]: module "digest" returns invalid for request 1 Then we move on to the next section of the Auth-Type LDAP configuration section of the authenticate {} block, and allow the LDAP module to take a crack at it and thus we have a sucessful authentication: rlm_ldap: - authenticate rlm_ldap: login attempt by "dcorbe" with password "cgpe845Z" rlm_ldap: user DN: uid=dcorbe,ou=People,dc=corbe,dc=net rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1 rlm_ldap: bind as uid=dcorbe,ou=People,dc=corbe,dc=net/cgpe845Z to 127.0.0.1:389 rlm_ldap: waiting for bind result ... request 1 done rlm_ldap: Bind was successful rlm_ldap: user dcorbe authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 1 modcall: group Auth-Type returns ok for request 1 Sending Access-Accept of id 129 to 127.0.0.1:63703 -Daniel On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > Alan, > > It achieved the desired effect. Quite simply, authentication against > LDAP now works when DIGEST is present and when it is not. > > I've built my radiusd.conf file based off the examples provided with > the default installation. > > I do not want a broken radius server on my hands as that will create > more problems in the long run. I'm still unsure as to what the > correct approach is. In the interests of finding the correct > approach, I will undo what I have done and paste the results of the > debug output. > > To Recap, here are exerpts from my radius config: > > modules { > ldap { > ldap_debug = 0x0028 > server = "127.0.0.1" > identity = "cn=Manager,dc=corbe,dc=net" > password = "abcBABY123" > basedn = "ou=People,dc=corbe,dc=net" > filter = "(&(objectclass=posixAccount)(uid=dcorbe))" > base_filter = "" > > # set this to 'yes' to use TLS encrypted connections > # to the LDAP database by using the StartTLS extended > # operation. > # The StartTLS operation is supposed to be used with normal > # ldap connections instead of using ldaps (port 689) > connections > start_tls = no > > # tls_cacertfile= /path/to/cacert.pem > # tls_cacertdir = /path/to/ca/dir/ > # tls_certfile = /path/to/radius.crt > # tls_keyfile = /path/to/radius.key > # tls_randfile = /path/to/rnd > # tls_require_cert = "demand" > > # default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA" > # profile_attribute = "radiusProfileDn" > #access_attr = "dialupAccess" > > # Mapping of RADIUS dictionary attributes to LDAP > # directory attributes. > dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap > > ldap_connections_number = 5 > > # > # NOTICE: The password_header directive is NOT case > insensitive > # > # password_header = "{clear}" > # > # Set: > # password_attribute = nspmPassword > # > # to get the user's password from a Novell eDirectory > # backend. This will work *only if* freeRADIUS is > # configured to build with --with-edir option. > # > # > # The server can usually figure this out on its own, and pull > # the correct User-Password or NT-Password from the database. > # profile_attribute = "radiusProfileDn" > #access_attr = "dialupAccess" > > # Mapping of RADIUS dictionary attributes to LDAP > # directory attributes. > dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap > > ldap_connections_number = 5 > # > # Note that NT-Passwords MUST be stored as a 32-digit hex > # string, and MUST start off with "0x", such as: > # > # 0x000102030405060708090a0b0c0d0e0f >
one question
My company is a security vendor company(www.fortinet.com). How to add dictionary.fortinet to the server's list of vendor dictionaries in later freeradius version? Does anyone know it? _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Alan, It achieved the desired effect. Quite simply, authentication against LDAP now works when DIGEST is present and when it is not. I've built my radiusd.conf file based off the examples provided with the default installation. I do not want a broken radius server on my hands as that will create more problems in the long run. I'm still unsure as to what the correct approach is. In the interests of finding the correct approach, I will undo what I have done and paste the results of the debug output. To Recap, here are exerpts from my radius config: modules { ldap { ldap_debug = 0x0028 server = "127.0.0.1" identity = "cn=Manager,dc=corbe,dc=net" password = "abcBABY123" basedn = "ou=People,dc=corbe,dc=net" filter = "(&(objectclass=posixAccount)(uid=dcorbe))" base_filter = "" # set this to 'yes' to use TLS encrypted connections # to the LDAP database by using the StartTLS extended # operation. # The StartTLS operation is supposed to be used with normal # ldap connections instead of using ldaps (port 689) connections start_tls = no # tls_cacertfile= /path/to/cacert.pem # tls_cacertdir = /path/to/ca/dir/ # tls_certfile = /path/to/radius.crt # tls_keyfile = /path/to/radius.key # tls_randfile = /path/to/rnd # tls_require_cert = "demand" # default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA" # profile_attribute = "radiusProfileDn" #access_attr = "dialupAccess" # Mapping of RADIUS dictionary attributes to LDAP # directory attributes. dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap ldap_connections_number = 5 # # NOTICE: The password_header directive is NOT case insensitive # # password_header = "{clear}" # # Set: # password_attribute = nspmPassword # # to get the user's password from a Novell eDirectory # backend. This will work *only if* freeRADIUS is # configured to build with --with-edir option. # # # The server can usually figure this out on its own, and pull # the correct User-Password or NT-Password from the database. # profile_attribute = "radiusProfileDn" #access_attr = "dialupAccess" # Mapping of RADIUS dictionary attributes to LDAP # directory attributes. dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap ldap_connections_number = 5 # # Note that NT-Passwords MUST be stored as a 32-digit hex # string, and MUST start off with "0x", such as: # # 0x000102030405060708090a0b0c0d0e0f # # Without the leading "0x", NT-Passwords will not work. # This goes for NT-Passwords stored in SQL, too. # password_attribute = userPassword # # Un-comment the following to disable Novell eDirectory account # policy check and intruder detection. This will work *only if* # FreeRADIUS is configured to build with --with-edir option. # # edir_account_policy_check=no # # groupname_attribute = cn # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" # groupmembership_attribute = radiusGroupName timeout = 4 timelimit = 3 net_timeout = 1 # compare_check_items = yes # do_xlat = yes # access_attr_used_for_allow = yes } # # The 'digest' module currently has no configuration. # # "Digest" authentication against a Cisco SIP server. # See 'doc/rfc/draft-sterman-aaa-sip-00.txt' for details # on performing digest authentication for Cisco SIP servers. # digest { } } authorize { # # If you have a Cisco SIP server authenticating against # FreeRADIUS, uncomment the following line, and the 'digest' # line in the 'authenticate' section. digest # # The ldap module will set Auth-Type to LDAP if it has not # already been set ldap } authenticate {
RE: Some questions about freeRADIUS implementation, PLEASE HELP ME!!
Hi, Davies , Thanks for your Help, I have another question. > >2. At the second stage we will implement a PKI and > >we'll use EAP-TLS and my doubt is about > > LDAP data base and simultaneous-use, for example > >with EAP-PEAP I add the next lines to users file : > > > >... > >DEFAULTLdap-Group == group1, > Simultaneous-Use > >:= 1 > > Aruba-User-Role = "ESTUDIANTE", > > > >DEFAULTLdap-Group == group2, > Simultaneous-Use > >:= 1 > > Aruba-User-Role = "PROFESORES", > >DEFAULT > >. > > > >And work perfectly, But what happen if we use > EAP-TLS > >--> client certificates, exists any way to obtain > the > >same results? > > If you are providing each client with a certificate > signed by your CA and the RADIUS servers both have > the certificate of the root CA, then they'll be able > to authenticate the clients based on the signature > of the root CA. LDAP is used for authorization > anyway so you'll use that independently based on the > username in the certificate CN. > > >,if it is affirmative, how can I do it (some > >references, howto's) > >!!because when I use EAP-TLS I don't need to add > >nothing at users file nor in LDAP data base!!. > > You can add authorization in the LDAP database. It > is not used (by EAP-TLS or PEAP/MS-CHAPv2) for > authentication. Note, if you're using > PEAP/MS-CHAPv2 and LDAP and you want to store the > password in the LDAP database, it *must* be in plain > text. > Here my doubt: I am using EAP-TLS I generated a client Certificate with CN "redes" then I add at LDAP database a user with these atributes cn: redes uid: redes radiusGroupName: academicos ..others Attributes but without userpassword and in the users file i add: DEFAULTLdap-Group == academicos, Simultaneous-Use := 1 Aruba-User-Role = "STAFF", A user with client certificate can access at Wireless network and get the Role STAFF perfectly, but the process of authentication and authorization seems like very very redundant, is normal that?. I attach the file of process auth. thanks Alfonso Celestino DGSCA,UNAM ___ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/radius/etc/raddb/proxy.conf Config: including file: /usr/local/radius/etc/raddb/clients.conf Config: including file: /usr/local/radius/etc/raddb/snmp.conf Config: including file: /usr/local/radius/etc/raddb/eap.conf Config: including file: /usr/local/radius/etc/raddb/sql.conf main: prefix = "/usr/local/radius" main: localstatedir = "/usr/local/radius/var" main: logdir = "/usr/local/radius/var/log/radius" main: libdir = "/usr/local/radius/lib" main: radacctdir = "/usr/local/radius/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/usr/local/radius/var/log/radius/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/usr/local/radius/var/run/radiusd/radiusd.pid" main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/radius/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = yes proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/radius/lib Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "(null)" exec: packet_type = "(null)" rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP pap: encryption_scheme = "crypt" Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = no mschap: require_strong = no mschap: with_ntdomain_hack = no mschap: passwd = "(null)" mschap: authtype = "MS-CHAP" mschap: ntlm_auth = "(null)" Module: Instantiated mschap (mschap) Modul
Re: Digest test
"Iandc Davies" <[EMAIL PROTECTED]> wrote: > Have run the test as suggested in the doc/rlm_digest file and have got an > odd output message from freeradius saying it can't find the Digest-Nonce > element. ... > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 0 > modcall[authorize]: module "preprocess" returns ok for request 0 > modcall[authorize]: module "attr_filter" returns noop for request 0 > modcall[authorize]: module "chap" returns noop for request 0 > rlm_realm: No '@' in User-Name = "test", looking up realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 0 > rlm_eap: No EAP-Message, not doing EAP > modcall[authorize]: module "eap" returns noop for request 0 > users: Matched entry test at line 19 > modcall[authorize]: module "files" returns ok for request 0 > rlm_checkval: Could not find item named Calling-Station-Id in request > rlm_checkval: Could not find attribute named Calling-Station-Id in check > pairs > modcall[authorize]: module "checkval" returns notfound for request 0 > modcall: group authorize returns ok for request 0 You haven't listed the "digest" module in the "authorize" section. Please do so. Also, you SHOULD NOT set "Auth-Type = Digest". Once you list "digest" in the "authorize" section, the server will do that for you. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Daniel Corbe <[EMAIL PROTECTED]> wrote: > Yes.. what I did below worked. It worked for reasons other than what you believe. The configuration you posted is, quite simply, wrong. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Daniel Corbe <[EMAIL PROTECTED]> wrote: > That? > > It's already uncommented. It would help if you had said that in your original message. Posting PART of what you've done makes it sound like the problem is caused by only doing part of the work, rather than all o fit. And please post the debug output. Nothing else will help solve the problem. > It's already uncommented. There's a seperate entry for Auth-Type LDAP > { } in the authorize { } block. Should I do something along the lines > of... > > authorize { > Auth-Type LDAP { > digest No. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Some questions about freeRADIUS implementation, PLEASE HELP ME!!
Hi Alfonso, See inline... >-Original Message- >We decide to use freeRADIUS as Radius Server on a Big >wireless Network (in a university ) >with about five hundred APs, but there are some >questions (maybe basic questions) >I need from your help to understand them better. > >1. About certificates >In the first stage we will use EAP-PEAP authentication >with Primary and backup Radius Servers. >I think to do next: >At the Primary Server, I will generate the root, >Primary Server and Backup Server certificates, > then I will copy the root and Backup Server >certificates to Backup server, That's correct?. >or I have to generate one more time the root and >backup server certificates >in the backup server. No, you don't need another root. I'd normally run the CA (root) on a different (highly secured) box but that's not mandatory. You really only need one (well backed up) root server. You also need to distribute the root cert to all the clients. They will use the root cert (used to sign the RADIUS servers' certs) to authenticate the RADIUS servers. If the root cert has been signed by a global root CA, then the clients only need the certificate from the global root CA. >2. At the second stage we will implement a PKI and >we'll use EAP-TLS and my doubt is about > LDAP data base and simultaneous-use, for example >with EAP-PEAP I add the next lines to users file : > >... >DEFAULTLdap-Group == group1, Simultaneous-Use >:= 1 > Aruba-User-Role = "ESTUDIANTE", > >DEFAULTLdap-Group == group2, Simultaneous-Use >:= 1 > Aruba-User-Role = "PROFESORES", >DEFAULT >. > >And work perfectly, But what happen if we use EAP-TLS >--> client certificates, exists any way to obtain the >same results? If you are providing each client with a certificate signed by your CA and the RADIUS servers both have the certificate of the root CA, then they'll be able to authenticate the clients based on the signature of the root CA. LDAP is used for authorization anyway so you'll use that independently based on the username in the certificate CN. >,if it is affirmative, how can I do it (some >references, howto's) >!!because when I use EAP-TLS I don't need to add >nothing at users file nor in LDAP data base!!. You can add authorization in the LDAP database. It is not used (by EAP-TLS or PEAP/MS-CHAPv2) for authentication. Note, if you're using PEAP/MS-CHAPv2 and LDAP and you want to store the password in the LDAP database, it *must* be in plain text. > >3. Finaly exists some advantages If I use Solaris >instead a Normal PC with Linux(Debian). Hardware and OS support, maybe. There are certainly PCs out there that can match a (probably much more expensive) Solaris box for performance. You'll need to ensure that you've got GCC compiled for your Solaris box (AFAIK, it's not supplied in the base OS) so it's a bit of a pain to get going. In that respect, a good Linux or BSD distribution on a high spec server PC may be the better bet. >Your help will be very important for me!! >Thanks in advance > >NOTE: simultaneous-use work perfectly with some NAS, >with ARUBA NAS don't do it, but I thing need some >little changes in the checkrad.pl script. > >Alfonso Celestino >DGSCA,UNAM > > >__ >Correo Yahoo! >Espacio para todos tus mensajes, antivirus y antispam ¡gratis! >Regístrate ya - http://correo.yahoo.com.mx/ >- >List info/subscribe/unsubscribe? See >http://www.freeradius.org/list/users.html > This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Some questions about freeRADIUS implementation, PLEASE HELP ME!!
Hi, I need your help We decide to use freeRADIUS as Radius Server on a Big wireless Network (in a university ) with about five hundred APs, but there are some questions (maybe basic questions) I need from your help to understand them better. 1. About certificates In the first stage we will use EAP-PEAP authentication with Primary and backup Radius Servers. I think to do next: At the Primary Server, I will generate the root, Primary Server and Backup Server certificates, then I will copy the root and Backup Server certificates to Backup server, That's correct?. or I have to generate one more time the root and backup server certificates in the backup server. 2. At the second stage we will implement a PKI and we'll use EAP-TLS and my doubt is about LDAP data base and simultaneous-use, for example with EAP-PEAP I add the next lines to users file : ... DEFAULTLdap-Group == group1, Simultaneous-Use := 1 Aruba-User-Role = "ESTUDIANTE", DEFAULTLdap-Group == group2, Simultaneous-Use := 1 Aruba-User-Role = "PROFESORES", DEFAULT . And work perfectly, But what happen if we use EAP-TLS --> client certificates, exists any way to obtain the same results? ,if it is affirmative, how can I do it (some references, howto's) !!because when I use EAP-TLS I don't need to add nothing at users file nor in LDAP data base!!. 3. Finaly exists some advantages If I use Solaris instead a Normal PC with Linux(Debian). Your help will be very important for me!! Thanks in advance NOTE: simultaneous-use work perfectly with some NAS, with ARUBA NAS don't do it, but I thing need some little changes in the checkrad.pl script. Alfonso Celestino DGSCA,UNAM __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
"Jonathan De Graeve" <[EMAIL PROTECTED]> wrote: > Is this also possible with EAP or MS-CHAP authentication? Is WHAT possible? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius
Is it also possible to add multiple 'Huntgroup-Name's into the database? In my first test it doesn't seemed to be possible -- Jonathan De Graeve Network/System Administrator Imelda vzw Informatica Dienst 015/50.52.98 -Oorspronkelijk bericht- Van: Tobias Frank [mailto:[EMAIL PROTECTED] Verzonden: donderdag 8 september 2005 12:36 Aan: Jonathan De Graeve Onderwerp: Re: Freeradius Hello again Jonathan De Graeve schrieb: > > What I want to do is distinct users from NASSes. Lets say, users in the > mysqlgroup IT can connect to the NASSES 1 & 2 & 3 while patients only > can connect to NAS 3. This can be done with huntgroups but don't know > how to do this with an SQL based implementation forget my last mail. it is quite simpler. create your huntgroups and insert into radcheck (username, attribute, op, value) values ('Tobi', 'Huntgroup-Name', '==', 'IT'); -- Synergy Systems GmbH Tobias Frank Leiter Entwicklung Konrad-Zuse-Platz 8 81829 München Fon +49 (0)89 89080-500 Fax +49 (0)89 89080-600 mailto:[EMAIL PROTECTED] Best Connections - www.synergysystems.de - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius timeout
Callis wrote: > I see a lot of radius timeout on my cisco router while the > ping times is < 10ms and my radius timeout is set to 50. Is there any error message in file "radius.log" ? -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Handling Radius Events with Client
Ali Koyuncu wrote: > Hi to all, Did you read the rules before subscribing? http://www.freeradius.org/list/users.html HTML is forbidden on the mailing list, and moreover it's difficult to distinguish your message from spam: X-XS4ALL-Spam-Score: 3.454 (***) HTML_40_50, HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED, HTML_MESSAGE, MSGID_FROM_MTA_HEADER, RCVD_IN_SPEWS, X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH > Let's say we have a switch and two (free) Radius servers backing up each > other. I want to implement a client, that listens to the call-related events > (such as accest-accept, call started, call finished, failed, and etc.) > received from the target Radius server, and process these data based on some > rules. Here comes my questions: > > 1. Is it possible to handle Radius call-relaed events over UDP or TCP? -- > because i am newbie to the subject, please excuse me if i am asking > something stupid. > 2. If it's, how? Any sample source code can be provided? You can run a client program each time FreeRADIUS receives a request with the module "rlm_exec". Look for examples in radiusd.conf. You may also be interested in modules "rlm_perl" or "rlm_python". Nicolas Baradakis -- A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting annoying in email? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroups and bad_logins
Jonathan De Graeve wrote: > What I want to do is the following: > > NAS1: 10.1.1.1 > NAS2: 10.1.1.2 > > SQL usergroups: patients, it > > IT may connect to NAS1&2, patients only to NAS2. I've been looking on > the internet how to do this but didn't found it. In your case, I'd suggest you try the following: 1. In your SQL database, add a field "NASIPAddress" to the tables radcheck, radreply... 2. Then insert one row for each attribute of the users allowed to log on NAS2, and two rows for attributes of the users allowed to log on both NAS1 and NAS2. 3. In the file "sql.conf", add "AND NASIPAddress = '%{NAS-IP-Adresse}'" in the "WHERE" clause of the authorize_* queries. > I also have problems with the bad_login perlscript. When I run this > script, it doesn't do anything (just hangs with no given output) I think the script is just waiting for new requests to be received. I note you may also use a post-auth query to log failed login in a SQL database. (it has already been explained many times on the mailing list) -- Nicolas Baradakis PS: HTML is forbidden on the mailing list, please follow the house-rules http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Handling Radius Events with Client
Hi to all, Let's say we have a switch and two (free) Radius servers backing up each other. I want to implement a client, that listens to the call-related events (such as accest-accept, call started, call finished, failed, and etc.) received from the target Radius server, and process these data based on some rules. Here comes my questions: 1. Is it possible to handle Radius call-relaed events over UDP or TCP? -- because i am newbie to the subject, please excuse me if i am asking something stupid. 2. If it's, how? Any sample source code can be provided? Thank you and regards, Ali Koyuncu R&D Director "I'm not Anti-Business, I'm Anti-Idiot! (Dilbert)" - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radius timeout
Hi all I have freeradius-1.0.1-1 (with Petr Nixon's patch) running on FC-3 and using a postgresql backend to collect cisco AAA (stop only) records. My cisco IOS is 12.3(2)T2. I see a lot of radius timeout on my cisco router while the ping times is < 10ms and my radius timeout is set to 50. I even went further to connect the radius server and the router back to back with a cross cable and still have some timeouts. What could be wrong with my configs? Any help will be appreciated. Thank you. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Yes.. what I did below worked. -Daniel On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > # > # If you have a Cisco SIP server authenticating against > # FreeRADIUS, uncomment the following line, and the 'digest' > # line in the 'authorize' section. > digest > > That? > > It's already uncommented. There's a seperate entry for Auth-Type LDAP > { } in the authorize { } block. Should I do something along the lines > of... > > authorize { > Auth-Type LDAP { > digest > ldap > } > } > > ?? > > -Daniel > > > On 9/7/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > > I'm manually setting Auth-Type to DIGEST on the LDAP Server. > > > > As I said, DON'T. > > > > > This is all radiusd.conf has to say about digest: > > ... > > > > No. You missed one "digest" entry, in the "authenticate" section. > > The text you quoted tells you this: > > > > > # If you have a Cisco SIP server authenticating against > > > # FreeRADIUS, uncomment the following line, and the 'digest' > > > # line in the 'authenticate' section. > > > > Follow those instructions. > > > > 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: Mixed-mode authentication enviornment
Also, please note; The SIP server is NOT sending the Auth-Type attribute. On 9/8/05, Daniel Corbe <[EMAIL PROTECTED]> wrote: > # > # If you have a Cisco SIP server authenticating against > # FreeRADIUS, uncomment the following line, and the 'digest' > # line in the 'authorize' section. > digest > > That? > > It's already uncommented. There's a seperate entry for Auth-Type LDAP > { } in the authorize { } block. Should I do something along the lines > of... > > authorize { > Auth-Type LDAP { > digest > ldap > } > } > > ?? > > -Daniel > > > On 9/7/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > > I'm manually setting Auth-Type to DIGEST on the LDAP Server. > > > > As I said, DON'T. > > > > > This is all radiusd.conf has to say about digest: > > ... > > > > No. You missed one "digest" entry, in the "authenticate" section. > > The text you quoted tells you this: > > > > > # If you have a Cisco SIP server authenticating against > > > # FreeRADIUS, uncomment the following line, and the 'digest' > > > # line in the 'authenticate' section. > > > > Follow those instructions. > > > > 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: Mixed-mode authentication enviornment
# # If you have a Cisco SIP server authenticating against # FreeRADIUS, uncomment the following line, and the 'digest' # line in the 'authorize' section. digest That? It's already uncommented. There's a seperate entry for Auth-Type LDAP { } in the authorize { } block. Should I do something along the lines of... authorize { Auth-Type LDAP { digest ldap } } ?? -Daniel On 9/7/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > Daniel Corbe <[EMAIL PROTECTED]> wrote: > > I'm manually setting Auth-Type to DIGEST on the LDAP Server. > > As I said, DON'T. > > > This is all radiusd.conf has to say about digest: > ... > > No. You missed one "digest" entry, in the "authenticate" section. > The text you quoted tells you this: > > > # If you have a Cisco SIP server authenticating against > > # FreeRADIUS, uncomment the following line, and the 'digest' > > # line in the 'authenticate' section. > > Follow those instructions. > > 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: Mixed-mode authentication enviornment
Is this also possible with EAP or MS-CHAP authentication? J. -- Jonathan De Graeve Network/System Administrator Imelda vzw Informatica Dienst 015/50.52.98 -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Alan DeKok Verzonden: woensdag 7 september 2005 23:59 Aan: FreeRadius users mailing list Onderwerp: Re: Mixed-mode authentication enviornment Daniel Corbe <[EMAIL PROTECTED]> wrote: > Since the SIP server requires DIGEST authentication, the Auth-Type > attribute is present and it is set to DIGEST which forces FreeRADIUS > to attempt a digest authentication. Once this fails an Access-Reject > packet is sent back to the RADIUS client You don't say who's setting Auth-Type. In the example config, the "digest" module sets it. If you're setting it yourself, there's a high likelihood that something will go wrong. > Is there a way to configure FreeRADIUS so it first attempts a DIGEST > authentication, and when that fails, we go ahead and attempt normal > authentication? No. That doesn't make sense. There IS a way to configure the server to try digest authentication only when the RADIUS packet contains digest attributes. Uncomment the lines referring to "digest" in radiusd.conf. 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