Hi, I want to provide the possibility of anonymouse EAP, with inner User-name and password. So I think I have to add the user "annonymous" to the users-file with Auth-type = EAP, but how do I access the inner User-name, which I need for authentication/authorization? Thanks Florian -- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Martensstr. 1 91052 Erlangen Germany Tel.: +499131 8527813
Hello,
I want to provide the possibility of anonymouse EAP, with inner User-name and password.
If you already successfully used outer = inner identity and it worked, you don't need to change anything. the eap module doesn't care about the User-Name of the outer request, just try it out.
So I think I have to add the user "annonymous" to the users-file with Auth-type = EAP, but how do I access the inner User-name, which I need for authentication/authorization?
The inner request will magically show up after the tunnel has been decoded. It is a new request, and will have its own User-Name attribute. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
The inner request will magically show up after the tunnel has been decoded. It is a new request, and will have its own User-Name attribute.
Could you be mores specific as: * when did this feature appear ? * how does this differ from previous versions ? Indeed, I found out that with the latest release of FR, the debug isn't the same: previously (FR 1.0.1), I was able to read the Tunneled inner-request and attributes (with inner user name and password...) and the complete process of this 'new request' and now I don't this. Thanks in advance for any pointer that could help me understand the difference. Regards, Thibault
"Thibault Le Meur" <Thibault.LeMeur@supelec.fr> wrote:
Indeed, I found out that with the latest release of FR, the debug isn't the same: previously (FR 1.0.1), I was able to read the Tunneled inner-request and attributes (with inner user name and password...) and the complete process of this 'new request' and now I don't this.
Read eap.conf, and look for "copy_request_to_tunnel" Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
"Thibault Le Meur" <Thibault.LeMeur@supelec.fr> wrote:
Indeed, I found out that with the latest release of FR, the debug isn't the same: previously (FR 1.0.1), I was able to read the Tunneled inner-request and attributes (with inner user name and password...) and the complete process of this 'new request' and now I don't this.
Read eap.conf, and look for "copy_request_to_tunnel"
Well... I already have this set to yes because I need to match outer attributes while processing the tunneled-request. My setup is working quite well, but I just think the "radiusd -X" debug log has changed a bit since I am not seeing the decoded inner request packet in it: I can only see a message "Proceeding to decode tunneled attributes" and then the authorize section is run without printing the decoded attributes of the tunneled request to the debug log. I get this: ------------- rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. Processing the authorize section of radiusd.conf modcall: entering group authorize for request 6 modcall[authorize]: module "preprocess" returns ok for request 6 modcall[authorize]: module "mschap" returns noop for request 6 modcall[authorize]: module "eap" returns noop for request 6 users: Matched entry DEFAULT at line 17 rlm_ldap: Entering ldap_groupcmp() ... ------------- I might be wrong but I think older versions were printing the decoded inner request with _something_like_ that: ------------- rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. ... Service-Type = Framed-User User-Name = "My-inner-Identity" User-Password = "My-PAP-Passwd" Framed-MTU = 1492 State = 0x50f69e12347f8a811f1334fa392048e Called-Station-Id = "00-01-52-44-55-85:MySSID" Calling-Station-Id = "00-52-44-55-F7-38" NAS-Identifier = "MyAP" NAS-Port-Type = Wireless-802.11 ... ------------- Regards, Thibault
Hello, Am Freitag, 17. November 2006 12:56 schrieb Thibault Le Meur:
The inner request will magically show up after the tunnel has been decoded. It is a new request, and will have its own User-Name attribute.
Could you be mores specific as: * when did this feature appear ? * how does this differ from previous versions ?
Indeed, I found out that with the latest release of FR, the debug isn't the same: previously (FR 1.0.1), I was able to read the Tunneled inner-request and attributes (with inner user name and password...) and the complete process of this 'new request' and now I don't this.
Thanks in advance for any pointer that could help me understand the difference.
Well, I also noticed that debug output changed in recent versions. The difference is negligible though, you can still do the usual tricks like catching Client-IP-Address == 127.0.0.1 as before. The only thing that changed is that the new, inner request isn't printed in -X. But it's still there. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche - Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
Stefan Winter <stefan.winter@restena.lu> wrote:
as before. The only thing that changed is that the new, inner request isn't printed in -X. But it's still there.
Hmm... that should be fixed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Stefan Winter wrote:
Hello,
I want to provide the possibility of anonymouse EAP, with inner User-name and password.
If you already successfully used outer = inner identity and it worked, you don't need to change anything. the eap module doesn't care about the User-Name of the outer request, just try it out.
Hm, but I want to use "anonymus" as the outer username ( for eap) and my real username for the authentication/authorization.
So I think I have to add the user "annonymous" to the users-file with Auth-type = EAP, but how do I access the inner User-name, which I need for authentication/authorization?
The inner request will magically show up after the tunnel has been decoded. It is a new request, and will have its own User-Name attribute.
Hm, for me it does not work, my settings: users-file: #WLAN-anonymus: DEFAULT User-Name=~"^[Aa][Nn][Oo][Nn][Yy][Mm][Oo][Uu][Ss]$", Huntgroup-Name == WLAN Auth-Type:=EAP # Default-Wlan DEFAULT Auth-Type = pap, Huntgroup-Name == WLAN my log: rad_recv: Access-Request packet from host 131.188.4.190:20003, id=173, length=148 NAS-Port-Id = "2059/1" Calling-Station-Id = "00-12-17-78-DD-58" Called-Station-Id = "00-0B-0E-15-3D-80:FAU-STAFF" Service-Type = Framed-User EAP-Message = 0x0 User-Name = "anonymous" NAS-Port-Type = Wireless-802.11 NAS-Identifier = "Trapeze" NAS-IP-Address = 131.188.4.190 Message-Authenticator = 0x4 Fri Nov 17 12:03:14 2006 : Debug: Processing the authorize section of radiusd.conf Fri Nov 17 12:03:14 2006 : Debug: modcall: entering group authorize for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "preprocess" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling auth_log (rlm_detail) for request 0 Fri Nov 17 12:03:14 2006 : Debug: radius_xlat: '/var/log/radius/radacct/131.188.4.190/auth-detail-20061117' Fri Nov 17 12:03:14 2006 : Debug: rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var /log/radius/radacct/131.188.4.190/auth-detail-20061117 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from auth_log (rlm_detail) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "auth_log" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling chap (rlm_chap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from chap (rlm_chap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "chap" returns noop for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "mschap" returns noop for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: rlm_eap: EAP packet type response id 1 length 14 Fri Nov 17 12:03:14 2006 : Debug: rlm_eap: No EAP Start, assuming it's an on-going EAP conversation Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "eap" returns updated for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling files (rlm_files) for request 0 Fri Nov 17 12:03:14 2006 : Debug: users: Matched entry DEFAULT at line 157 Fri Nov 17 12:03:14 2006 : Debug: radius_xlat: 'anonymous' Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from files (rlm_files) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "files" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: rlm_ldap: - authorize Fri Nov 17 12:03:14 2006 : Debug: rlm_ldap: performing user authorization for anonymous --> HERE the valid user name is neede: Fri Nov 17 12:03:14 2006 : Debug: radius_xlat: '(&(fauRadiusService=WLAN)(fauRadiusId=anonymous))' any suggestions? Greetings Florian Prester
Greetings,
Stefan Winter
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Martensstr. 1 91052 Erlangen Germany Tel.: +499131 8527813
Hi Florian,
If you already successfully used outer = inner identity and it worked, you don't need to change anything. the eap module doesn't care about the User-Name of the outer request, just try it out.
Hm, but I want to use "anonymus" as the outer username ( for eap) and my real username for the authentication/authorization.
as I told you before: you need to do *nothing*. There is no need for a users file entry for the name anonymous. Forget about it.
The inner request will magically show up after the tunnel has been decoded. It is a new request, and will have its own User-Name attribute.
Hm, for me it does not work,
That may be, but then your problem is not related to a missing users entry for the outer request, but something completely different.
my settings:
users-file: #WLAN-anonymus: DEFAULT User-Name=~"^[Aa][Nn][Oo][Nn][Yy][Mm][Oo][Uu][Ss]$", Huntgroup-Name == WLAN Auth-Type:=EAP
Delete those lines. They are superfluous (though they dont seem to do any harm, unless one of your real user names would match the regex. In this case, this line would actually *break* things).
# Default-Wlan DEFAULT Auth-Type = pap, Huntgroup-Name == WLAN
And this one is wrong, very wrong. Setting Auth-Type to pap (PAP?) is neither necessary nor does it make things better. Delete it as well.
my log: rad_recv: Access-Request packet from host 131.188.4.190:20003, id=173, length=148 NAS-Port-Id = "2059/1" Calling-Station-Id = "00-12-17-78-DD-58" Called-Station-Id = "00-0B-0E-15-3D-80:FAU-STAFF" Service-Type = Framed-User EAP-Message = 0x0 User-Name = "anonymous" NAS-Port-Type = Wireless-802.11 NAS-Identifier = "Trapeze" NAS-IP-Address = 131.188.4.190 Message-Authenticator = 0x4 Fri Nov 17 12:03:14 2006 : Debug: Processing the authorize section of radiusd.conf Fri Nov 17 12:03:14 2006 : Debug: modcall: entering group authorize for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "preprocess" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling auth_log (rlm_detail) for request 0 Fri Nov 17 12:03:14 2006 : Debug: radius_xlat: '/var/log/radius/radacct/131.188.4.190/auth-detail-20061117' Fri Nov 17 12:03:14 2006 : Debug: rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var /log/radius/radacct/131.188.4.190/auth-detail-20061117 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from auth_log (rlm_detail) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "auth_log" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling chap (rlm_chap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from chap (rlm_chap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "chap" returns noop for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "mschap" returns noop for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: rlm_eap: EAP packet type response id 1 length 14 Fri Nov 17 12:03:14 2006 : Debug: rlm_eap: No EAP Start, assuming it's an on-going EAP conversation Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "eap" returns updated for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling files (rlm_files) for request 0 Fri Nov 17 12:03:14 2006 : Debug: users: Matched entry DEFAULT at line 157 Fri Nov 17 12:03:14 2006 : Debug: radius_xlat: 'anonymous' Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: returned from files (rlm_files) for request 0 Fri Nov 17 12:03:14 2006 : Debug: modcall[authorize]: module "files" returns ok for request 0 Fri Nov 17 12:03:14 2006 : Debug: modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Fri Nov 17 12:03:14 2006 : Debug: rlm_ldap: - authorize Fri Nov 17 12:03:14 2006 : Debug: rlm_ldap: performing user authorization for anonymous
Seems like the order in which the various modules get called is wrong. eap (and realm instances like suffix, if you use that) should be before ldap, is this the case? Posting the authorize {} and authenticate {} stanzas would certainly help. And, lastly, did you set copy_request_to_tunnel in eap.conf? Don't, because then your real inner user name gets overwritten by the outer one. Greetings, Stefan Winter -- -= visit http://www.webjumping.com =- This mail is guaranteed to be virus free because it was sent from a computer running Linux. -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche - Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
And, lastly, did you set copy_request_to_tunnel in eap.conf? Don't, because then your real inner user name gets overwritten by the outer one.
Strange... I've set copy_request_to_tunnel and I haven't seen my inner User-Name be overwritten ! Are you sure it would overwrite the inner User-Name attribute with the outer one ? Another question: if you don't set copy_request_to_tunnel, could you still have a rule in the users file matching the user's ldap group (for the users in the inner request) and the Called-Station-Id (from outer request) ? Thibault
"Thibault Le Meur" <Thibault.LeMeur@supelec.fr> wrote:
Strange... I've set copy_request_to_tunnel and I haven't seen my inner User-Name be overwritten !
Doing that would be wrong. FreeRADIUS doesn't do that.
And, lastly, did you set copy_request_to_tunnel in eap.conf? Don't, because then your real inner user name gets overwritten by the outer one.
No, absolutely not. That DOES NOT HAPPEN.
Another question: if you don't set copy_request_to_tunnel, could you still have a rule in the users file matching the user's ldap group (for the users in the inner request) and the Called-Station-Id (from outer request) ?
You could match LDAP group, because the username is in the inner request. You can't match Called-Station-Id, because it's in the outer request. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
"Thibault Le Meur" <Thibault.LeMeur@supelec.fr> wrote:
Strange... I've set copy_request_to_tunnel and I haven't seen my inner User-Name be overwritten !
Doing that would be wrong. FreeRADIUS doesn't do that.
I know, It would have broken my setup ;-)
And, lastly, did you set copy_request_to_tunnel in eap.conf? Don't, because then your real inner user name gets overwritten by the outer one.
No, absolutely not. That DOES NOT HAPPEN.
Another question: if you don't set copy_request_to_tunnel, could you still have a rule in the users file matching the user's ldap group (for the users in the inner request) and the Called-Station-Id (from outer request) ?
You could match LDAP group, because the username is in the inner request. You can't match Called-Station-Id, because it's in the outer request.
Ok, so I had correctly interpreted this copy_request_to_tunnel option. Thus I thin the previous debug output showing th decoded inner request was better to troubleshoot tunneled authentication schemes. Thanks again for this clarification, Thibault
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
Ok, so I had correctly interpreted this copy_request_to_tunnel option. Thus I thin the previous debug output showing th decoded inner request was better to troubleshoot tunneled authentication schemes.
The weird thing is that the code hasn't changed. I don't know why the behavior is different. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
Alan DeKok -
Florian Prester -
Stefan Winter -
Thibault Le Meur