Re: wired 802.1x supplicent open source where i can get it?
Hi, Guy Davies a écrit : Hi Alan, The supplicant is the software on the device trying to connect, rather than the server. Unless FreeRADIUS has moved in a totally different direction from when I was using it frequently, it is purely a RADIUS server (the authentication server in the 802.1x process). FreeRADIUS will certainly help the original poster because it implements many of the EAP methods required. He will also need an Ethernet switch that acts as an 802.1x authenticator. I don't know if wpa_supplicant can also support wired 802.1x authentication, but it would certainly be a good place to start when looking to develop one. I did not test it, but I wonder that wpa_supplicant may work since you have to setup on which interface it works. For my part, if your wired interface supports WPA/WPA2, it should work with the use of a 802.1x compliant switch. Rgds, Guy On 03/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Hi, I am satyanarayana,we are working to implement 802.1x wired supplicent , But Tried a lot by checking somany sites But i didn't get that open source. If any body knows the site are any details Please send to me. freeradius is an existing supplicant which can do wired and wireless 802.1X www.freeradius.org do you want to IMPLEMENT 802.1X AAA, or do you want to create your own wired supplicant client and/or server?? 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 -- *Hospices Civils de Beaune* *Patrice OLIVER* /Chef de Projet Ville Hôpital/ /Responsable Réseau Sécurité/ BP 104 21203 BEAUNE Cedex Tél. 03 80 24 44 09 Fax. 03 80 24 45 90 Ce message, y compris les pièces jointes, est établi à l'attention exclusive de son ou ses destinataires et est confidentiel. Toute utilisation non conforme à sa destination, toute diffusion ou publication, totale ou partielle, est interdite sauf autorisation expresse de l'expéditeur. Si vous n'êtes pas le destinataire de ce message, merci d'avertir l'expéditeur de l'erreur de distribution puis de le détruire. Tout message électronique est susceptible d'altération et son intégrité ne peut être assurée. L'expéditeur décline toute responsabilité dans l'hypothèse où il aurait été modifié ou falsifié. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Login rejected. Error 691.
On Dec 4, 2007 1:19 PM, Alan DeKok [EMAIL PROTECTED] wrote: pungki arianto wrote: How can I create clear text password for user? Is there any documentation that I have to read for setting that? Yes. Lots. The FAQ, config files, etc. I read the FAQ from http://wiki.freeradius.org/index.php/FAQ#Debugging_it_yourself but the Cleartext-Password attribute is only for freeradius 1.1.6 / 1.1.7 or 2.0.0pre2. I'm using freeRadius 1.1.2 and Cleartext-Password attribut is not known by the server. Does this version (1.1.2) support Cleartext-Password? -Pungki - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Login rejected. Error 691.
On Dec 4, 2007 10:32 AM, pungki arianto [EMAIL PROTECTED] wrote: I read the FAQ from http://wiki.freeradius.org/index.php/FAQ#Debugging_it_yourself but the Cleartext-Password attribute is only for freeradius 1.1.6 / 1.1.7 or 2.0.0pre2. I'm using freeRadius 1.1.2 and Cleartext-Password attribut is not known by the server. Does this version (1.1.2) support Cleartext-Password? Use User-Password instead. Regards, Liran Tal. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
xpextensions question
Is there any further HOWTO or somebody who can give me detailed instruction on how to get PEAP authentication done with a WinXP Client? I've installed the microsoft hotfix for SP2, but I don't see what to do with this xpextensions file. Thanks in advance - Bernd - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: xpextensions question
Place it in the /certs directory. It will be used by CA.all script to generate certificates usable with XP supplicant. Ivan Kalik Kalik Informatika ISP Dana 4/12/2007, Bernd [EMAIL PROTECTED] piše: Is there any further HOWTO or somebody who can give me detailed instruction on how to get PEAP authentication done with a WinXP Client? I've installed the microsoft hotfix for SP2, but I don't see what to do with this xpextensions file. Thanks in advance - Bernd - 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: xpextensions question
Bernd wrote: Is there any further HOWTO or somebody who can give me detailed instruction on how to get PEAP authentication done with a WinXP Client? I've installed the microsoft hotfix for SP2, but I don't see what to do with this xpextensions file. See the Wiki and the comments in eap.conf in 1.1.7. The xpextensions issues are discussed there. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
John Paul wrote: The issue is that if a machine is authenticated and the server that did the authentication is down, the switch will contact the other server and the EAP conversation will fail, causing authentication to fail. Research indicates that this is because the client and server have agreed upon session specific symmetric keys that the new server does not know about. I don't think it's because of the establishment of symmetric session keys. Once a user has been authenticated, the *next* authentication session is completely independent. I think it's that if fail-over happens in the *middle* of an EAP authentication, the new server won't have been participating in the TLS setup. Therefore, it doesn't know about the EAP conversation, and it rejects the session. It's not happening in the middle of the conversation. Server 1 will send an Access-Accept packet and the switch enables the port. Then if server 1 goes down and you attempt to reauthenticate the port, the switch tries server 2. That is when it fails. When I tested this the first time, authentications to server 1 worked and to server 2 did not. When I couldn't figure it out, I turned the test machines off and left for the day. The next day I had server 1 turned off - I turned the test machines on and authentications to server 2 worked fine, but would not work on server 1 once I powered it on. The common denominator here was that authentications work against the first server it tries but not any others. That's why I postulated that there must be some sort of session resumption going on. Is there a way to tell FreeRadius to tear down the session once the user has been authenticated so that the next authentication will work if using a different server? If not, is anyone working on a patch or other change to enable this? I'll be happy to write the patch but am unfamiliar with the code. Can you tell me roughly where to look? Please check first that the server isn't establishing session keys. Since FreeRADIUS doesn't do fast session resumption, I have no idea how session specific symmetric keys could affect anything. Was a shot in the dark based on some googling I had done awhile back. I assumed FreeRadius and Windows were agreeing on some sort of fast session resumption that would include symmetric encryption keys. i.e. authentication one user via EAP. Stop ALL other authentications. Turn off one RADIUS server, so it fails over to the other. Try to re-authenticate that one user. The user *should* be authenticated. That's how I've been testing it and it's not working, see above description. If I run the servers in debug mode (radiusd -X) the output starts to get different at line 420 of the middle of the conversation. The working server waits 6 seconds and then continues processing the next Access-Request packet: (Note that these servers are in a test environment, so there are no additional access-request packets reaching the servers, just the packets from the testing machine) Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.22.30.170:1812, id=29, length=171 NAS-IP-Address = 172.22.30.170 NAS-Port = 50016 NAS-Port-Type = Ethernet .. while the non-working server cleans up the request, then receives an Access-Request packet: Sending Access-Challenge of id 37 to 172.22.30.170 port 1812 EAP-Message = 0x011300061920 Message-Authenticator = 0x State = 0x466470a3816b19a56b24e71b7dff8089 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 37 with timestamp 47556860 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 172.22.30.170:1812, id=38, length=171 NAS-IP-Address = 172.22.30.170 NAS-Port = 50016 NAS-Port-Type = Ethernet . I can send the debugs in their entirety if you would like but thought I'd keep them off the list for now. What else could be going on here? Thanks for looking at this, if I can send you anything else please let me know. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
John Paul wrote: When I tested this the first time, authentications to server 1 worked and to server 2 did not. When I couldn't figure it out, I turned the test machines off and left for the day. The next day I had server 1 turned off - I turned the test machines on and authentications to server 2 worked fine, but would not work on server 1 once I powered it on. The common denominator here was that authentications work against the first server it tries but not any others. That's why I postulated that there must be some sort of session resumption going on. FreeRADIUS does not do session resumption. If the supplicant tries to do session resumption, I don't know what will happen. You should ensure that the supplicant has session resumption disabled. Was a shot in the dark based on some googling I had done awhile back. I assumed FreeRadius and Windows were agreeing on some sort of fast session resumption that would include symmetric encryption keys. Windows may support session resumption. FreeRADIUS does not. There are patches to enable this, but they have not, as yet, been integrated. In any case, they won't help you to fail over from one server to another. If the Windows client has session resumption enable, *should* notice that session resumption has failed, and re-authenticate from scratch. I suspect that the issue is fast session resumption on the Windows box. Turn it off. If that doesn't fix it, the Windows client is broken. Try another one. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
Debug the switch. It's quite likely that it isn't marking the radius server that is down as dead but it tries it again when it recieves the challenge. Ivan Kalik Kalik informatika ISP Dana 4/12/2007, John Paul [EMAIL PROTECTED] piše: John Paul wrote: The issue is that if a machine is authenticated and the server that did the authentication is down, the switch will contact the other server and the EAP conversation will fail, causing authentication to fail. Research indicates that this is because the client and server have agreed upon session specific symmetric keys that the new server does not know about. I don't think it's because of the establishment of symmetric session keys. Once a user has been authenticated, the *next* authentication session is completely independent. I think it's that if fail-over happens in the *middle* of an EAP authentication, the new server won't have been participating in the TLS setup. Therefore, it doesn't know about the EAP conversation, and it rejects the session. It's not happening in the middle of the conversation. Server 1 will send an Access-Accept packet and the switch enables the port. Then if server 1 goes down and you attempt to reauthenticate the port, the switch tries server 2. That is when it fails. When I tested this the first time, authentications to server 1 worked and to server 2 did not. When I couldn't figure it out, I turned the test machines off and left for the day. The next day I had server 1 turned off - I turned the test machines on and authentications to server 2 worked fine, but would not work on server 1 once I powered it on. The common denominator here was that authentications work against the first server it tries but not any others. That's why I postulated that there must be some sort of session resumption going on. Is there a way to tell FreeRadius to tear down the session once the user has been authenticated so that the next authentication will work if using a different server? If not, is anyone working on a patch or other change to enable this? I'll be happy to write the patch but am unfamiliar with the code. Can you tell me roughly where to look? Please check first that the server isn't establishing session keys. Since FreeRADIUS doesn't do fast session resumption, I have no idea how session specific symmetric keys could affect anything. Was a shot in the dark based on some googling I had done awhile back. I assumed FreeRadius and Windows were agreeing on some sort of fast session resumption that would include symmetric encryption keys. i.e. authentication one user via EAP. Stop ALL other authentications. Turn off one RADIUS server, so it fails over to the other. Try to re-authenticate that one user. The user *should* be authenticated. That's how I've been testing it and it's not working, see above description. If I run the servers in debug mode (radiusd -X) the output starts to get different at line 420 of the middle of the conversation. The working server waits 6 seconds and then continues processing the next Access-Request packet: (Note that these servers are in a test environment, so there are no additional access-request packets reaching the servers, just the packets from the testing machine) Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.22.30.170:1812, id=29, length=171 NAS-IP-Address = 172.22.30.170 NAS-Port = 50016 NAS-Port-Type = Ethernet ... while the non-working server cleans up the request, then receives an Access-Request packet: Sending Access-Challenge of id 37 to 172.22.30.170 port 1812 EAP-Message = 0x011300061920 Message-Authenticator = 0x State = 0x466470a3816b19a56b24e71b7dff8089 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 37 with timestamp 47556860 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 172.22.30.170:1812, id=38, length=171 NAS-IP-Address = 172.22.30.170 NAS-Port = 50016 NAS-Port-Type = Ethernet .. I can send the debugs in their entirety if you would like but thought I'd keep them off the list for now. What else could be going on here? Thanks for looking at this, if I can send you anything else please let me know. - 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: EAP-TLS and PEAP redundancy options
FreeRADIUS does not do session resumption. If the supplicant tries to do session resumption, I don't know what will happen. You should ensure that the supplicant has session resumption disabled. Windows does support it but it's switched off by default and I have verified this Windows may support session resumption. FreeRADIUS does not. There are patches to enable this, but they have not, as yet, been integrated. In any case, they won't help you to fail over from one server to another. I'm not interested in doing fast session resumption, I'd just as soon have the client start fresh every time. If the Windows client has session resumption enable, *should* notice that session resumption has failed, and re-authenticate from scratch. I would think it would too, but it does not seem to, even after it is given several minutes to get its act together I suspect that the issue is fast session resumption on the Windows box. Turn it off. It is indeed turned off If that doesn't fix it, the Windows client is broken. Try another one. I'll be happy to try another client - is there one you would recommend or suggest that I try - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
John Paul wrote: John Paul wrote: The issue is that if a machine is authenticated and the server that did the authentication is down, the switch will contact the other server and the EAP conversation will fail, causing authentication to fail. Research indicates that this is because the client and server have agreed upon session specific symmetric keys that the new server does not know about. I don't think it's because of the establishment of symmetric session keys. Once a user has been authenticated, the *next* authentication session is completely independent. I think it's that if fail-over happens in the *middle* of an EAP authentication, the new server won't have been participating in the TLS setup. Therefore, it doesn't know about the EAP conversation, and it rejects the session. It's not happening in the middle of the conversation. Server 1 will send an Access-Accept packet and the switch enables the port. Then if server 1 goes down and you attempt to reauthenticate the port, the switch tries server 2. That is when it fails. It is more likely that server 2 simply isn't configured correctly. Please post full debug (run radiusd -X) output for the working (initial) request on server 1 and the failing (subsequent) request on server 2. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Configuring LDAP for query ONLY...
Hi,
Is it possible to altogether avoid authenticate
section and just do ldap lookups in the authorize
section?
authorize {
ldap {
notfound = reject
}
}
The problem is in the authenticate section, radius
gets the userDN from the authorize and tries to bind
ldap with password which we don't have.
I also tried in users file
Ldap-UserDN := `cn=Manager,dc=eng,dc=com/answer2`
But for some reason it is not working.
Please help.
Let me know if you need more information or please
guide me to any documentation.
Thanks and Regards,
Eric.
--- Eric Martell [EMAIL PROTECTED] wrote:
I am little bit confused as how to configure
radiusd.conf in the authorize and/or authenticate
section. So password is going to act like ldap
attribute.
We are going to pass, username and ldap attribute
(home phone #) as input for each user.
The way it is configured now is in the modules,
ldap {
server = 10.11.12.2
identity = cn=Manager,dc=eng,dc=com
password = answer2
basedn = dc=eng,dc=com
filter =
((uid=%{Stripped-User-Name:-%{User-Name}})(phone=1231313128))
// just for testing
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
}
authorize {
..
..
..
ldap
...
}
authenticate {
Auth-Type LDAP {
ldap
}
}
In the logs it says:
rlm_ldap: - authorize
rlm_ldap: performing user authorization for test1
radius_xlat: '((uid=test1)(phone=1231313128))'
radius_xlat: 'dc=eng,dc=com'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: bind as cn=Manager,dc=eng,dc=com/answer2
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in dc=eng,dc=com, with
filter ((uid=test1)(phone=1231313128))
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user test1 authorized to use remote access
this is good
But in the authenticate section
rlm_ldap: - authenticate
rlm_ldap: login attempt by test1 with password
1231313128
rlm_ldap: user DN: id=1967816, dc=eng,dc=com
rlm_ldap: bind as id=1967816,
dc=eng,dc=com/1231313128
rlm_ldap: waiting for bind result ...
rlm_ldap: id=1967816, dc=eng,dc=com bind to
10.11.12.2:389 failed Inappropriate authentication
rlm_ldap: ldap_connect() failed
Not sure why it is trying to bind as id=1967816,
dc=eng,dc=com/1231313128
The only thing I want to do it, just authorize the
ldap and pass the user through.
Please let me know if I am missing something.
Thanks so much.
Regards,
Erik.
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
unsubscribe
Denise Fernandes WG-TEL FCCN Av. do Brasil, n.º 101 - Lisboa Telef. +351 218440100 Fax +351 218472167 www.fccn.pt BLOCKED::http://www.fccn.pt/ Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Configuring LDAP for query ONLY...
Thanks so much Phil. I am using freeradius-1.0.4
I am going to install the latest version and will try
your suggestion.
Thanks and Regards.
Eric.
--- Phil Mayers [EMAIL PROTECTED] wrote:
Eric Martell wrote:
Hi,
Is it possible to altogether avoid authenticate
section and just do ldap lookups in the authorize
section?
authorize {
ldap {
notfound = reject
}
}
The problem is in the authenticate section, radius
gets the userDN from the authorize and tries to
bind
ldap with password which we don't have.
I also tried in users file
Ldap-UserDN := `cn=Manager,dc=eng,dc=com/answer2`
Assuming you are using a recent version of
FreeRadius, you can do one of
the following:
modules {
ldap {
...
set_auth_type = no
}
}
authorize {
preprocess
ldap
pap
}
authenticate {
Auth-Type PAP {
pap
}
}
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
Phil Mayers wrote: There are patches to enable this, but they have not, as yet, been integrated. In any case, they won't help you to fail over from one server to another. If/when those patches get integrated, it would be highly useful to support failover between servers. I guess the requirements for this would be: Bleah. I guess it's possible, but it's pretty ugly. 1. Expose the openssl session cache config, so that distcache can be configured to share the SSL sessions between servers As always, patches are welcome. :) On a related note, sharing the RADIUS packets between servers would be a good idea. It would avoid duplicate handling of Access-Request or Accounting-Request. 2. Implement some way of attaching the PEAP/TTLS tunnel state to the session cache, or otherwise be reachable by the other FreeRadius server, so that when resumption occurs the inner info can be (re)used for authorization. You can register callbacks to store OpenSSL contexts somewhere outside of main memory. It's not hard, but it requires someone to write the code. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS and PEAP redundancy options
On 12/4/2007 at 10:01 AM, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Debug the switch. It's quite likely that it isn't marking the radius server that is down as dead but it tries it again when it recieves the challenge. Bingo, we have a winner. The switch was attempting to contact the downed server after the failover server had sent an access challenge back to the client. I'm not sure why this made it fail but it did. If I set the switch's radius server deadtime this seems to have fixed the issue. Thanks for everyone's help. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
