EAP processing again
Hi, Ok i read all of the debug output, and i think i can understand mechanism. However could you confirm (or not) what i understand ? In case of an EAP/TTLS connexion : - Freeradius get a request, with a particular attribut : EAP-Message - Entering authorize section, only EAP one matches because of EAP attribut => Auth-Type is set to EAP - Entering authenticate section, Freeradius sent a challenge to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and a new Message-Authenticator - Entering authorize section, EAP matches - Entering authenticate section. EAP matches (Auth-Type = EAP). Freeradius sent response to client (negociating ?) - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel setup is set - Entering authenticate section. EAP matches (Auth-Type = EAP). TTLS type found, beginning with TLS. SSL working, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Negociating SSL, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, session establisshed, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Session establisshed, entering inner-tunnel section. A this time, no more EAP request/send, only new authorise/authenticate in the tunnel. - Entering inner-tunnel authorize section, LDAP matches - Entering LDAP section : bind successful, login is authenticated - Access-Accept is send to client If i'm right, i'm asking some questions : - in the first step of the connexion, what is exactly the job of authorize section ? Does it only set auth-type when finding any "clue" in the request ? - when connexion is in the tunnel step, a "reduced" request is sent ( without EAP attributes). This request is checked by the inner-tunnel authorize section which will set the auth-type, right ? Here the auth-type found is LDAP. If i follow the entire log, i can see - entering authorize - finding Ldap Auth - entering LDAP section, and then bind... But i can't see entering authenticate section as we can see in the firt step with EAP It's quite hard to explain, but * Outside tunnel : request -> authorize section -> Foudn type EAP -> authenticate section -> EAP working * Inside tunnel : request -> authorize section -> Foudn type LDAP -> LDAP working Why is there an "authenticate section" for EAP and a direct use of LDAP section for LDAP ? -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57
Emmanuel BILLOT wrote:
Ok i read all of the debug output, and i think i can understand mechanism. However could you confirm (or not) what i understand ?
I'm trying to figure out why you need to understand it. The details of the EAP flow are complex. You don't need to understand them. You just configure the server.
In case of an EAP/TTLS connexion :
- Freeradius get a request, with a particular attribut : EAP-Message - Entering authorize section, only EAP one matches because of EAP attribut => Auth-Type is set to EAP - Entering authenticate section, Freeradius sent a challenge to client
If you're going to be technical, the *EAP* module creates an EAP-Message, a State, and then tells the server to send a challenge to the client. You can't go halfway on the details. Either ignore the details entirely, or understand them fully. Any intermediate step is a disaster.
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and a new Message-Authenticator
*All* Message-Authenticators are unique to the packet. It's used to sign packets. It is *not* used for anything in EAP. The State attribute is used to match a challenge. The EAP module uses it to match the packet to an ongoing EAP conversation.
- Entering authorize section, EAP matches - Entering authenticate section. EAP matches (Auth-Type = EAP). Freeradius sent response to client (negociating ?)
Again, the EAP module runs. It finds an EAP sub-module to run, and hands over control to it.
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel setup is set - Entering authenticate section. EAP matches (Auth-Type = EAP). TTLS type found, beginning with TLS. SSL working, sending response to client
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Negociating SSL, sending response to client
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, sending response to client
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, session establisshed, sending response to client
That's all largely correct. But again, I have to question *why* you care.
- Client answer
- Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Session establisshed, entering inner-tunnel section. A this time, no more EAP request/send, only new authorise/authenticate in the tunnel.
No. As I said before, the TLS tunnel contains authentication data. That data is used to create a "fake" request. That fake request is run through the "inner-tunnel" virtual server. The purpose of the "inner-tunnel" virtual server is to virtualize the configuration. PEAP and TTLS can share the same "inner-tunnel". You can treat the "inner-tunnel" just as if it received a normal RADIUS packet. The other RADIUS servers do *not* have this feature. The "inner-tunnel" authentication is handled by various special-purpose magic. That makes the configuration more complex and hard to understand.
- Entering inner-tunnel authorize section, LDAP matches
No. The *entire" authorize section is processed. Whatever modules are their do things to the request.
- Entering LDAP section : bind successful, login is authenticated
No. After authorize, the "authenticate" section is called. This used whatever Auth-Type was set in the "authorize" section.
- Access-Accept is send to client
Absolutely not. You've missed a LARGE part of the debug output. The inner-tunnel returns "Access-Accept". The default (outer) virtual server then continues it's work. This often means a number of more EAP exchanges with the client. Once the outer EAP session is done, the server returns an Access-Accept to the client.
If i'm right, i'm asking some questions : - in the first step of the connexion, what is exactly the job of authorize section ? Does it only set auth-type when finding any "clue" in the request ?
That's the job of the authorize section. It sets Auth-Type, and *anything else* you need it to do.
- when connexion is in the tunnel step, a "reduced" request is sent ( without EAP attributes).
No. As I said, this is the data from inside of the TLS tunnel. This *may* contain EAP. It's just like HTTPS versus HTTP. You connect to a web server via HTTPS. There's a lot of SSL magic involved. Once the tunnel is set up, you JUST USE HTTP over the tunnel.
This request is checked by the inner-tunnel authorize section which will set the auth-type, right ? Here the auth-type found is LDAP.
The authorize section does the same thing everywhere. There's no difference in handling between the inner-tunnel and outer "authorize" sections. The *contents* are different. The *packets* they receive are different. But they do the same thing.
If i follow the entire log, i can see - entering authorize - finding Ldap Auth - entering LDAP section, and then bind... But i can't see entering authenticate section as we can see in the firt step with EAP
Then you missed it.
It's quite hard to explain, but * Outside tunnel : request -> authorize section -> Foudn type EAP -> authenticate section -> EAP working * Inside tunnel : request -> authorize section -> Foudn type LDAP -> LDAP working
Why is there an "authenticate section" for EAP
Because it's needed.
and a direct use of LDAP section for LDAP ?
There isn't. Read the debug output. Alan DeKok.
Le 13/06/2012 10:55, Alan DeKok a écrit :
rs do*not* have this feature. The "inner-tunnel" authentication is handled by various special-purpose magic. That makes the configuration more complex a Thanks a lot for the time you spent on this request. I will not understand all, but i think (i hope) i can roughly follow the mechanism. I often try to known what a product do for configuring it. Maybe it is a mistake...
Here are the last lines of a successful connexion. It begins with the last outside tunnel authenticate section, just before entering inner-tunnel parsing. I obviously believe you about all what you said, but i can't find an explicite authenticate section between * ldap authorization and * entering LDAP. It's quite possible (likely) that i don't read correctly the output, please don't be offended about my questions. I only try to understand. ... # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 61 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request User-Name = "user1" User-Password = "toutou" FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "user1" User-Password = "toutou" FreeRADIUS-Proxied-To = 127.0.0.1 server inner-tunnel {************************************************************* entering tunnel ? # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel +- entering group authorize {...} ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "user1", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[control] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop [ldap] performing user authorization for user1*********************************************************** ldap authorization [ldap] expand: %{Stripped-User-Name} -> [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> user1 [ldap] expand: %{Stripped-User-Name} -> [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> user1 [ldap] expand: (|(uid=%{%{Stripped-User-Name}:-%{User-Name}})(mail=%{%{Stripped-User-Name}:-%{User-Name}})) -> (|(uid=user1)(mail=user1)) [ldap] expand: ou=ac-orleans-tours,ou=education,o=gouv,c=fr -> ou=ac-orleans-tours,ou=education,o=gouv,c=fr [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] attempting LDAP reconnection [ldap] (re)connect to replica.in.ac-orleans-tours.fr:389, authentication 0 [ldap] bind as / to replica.in.ac-orleans-tours.fr:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in ou=ac-orleans-tours,ou=education,o=gouv,c=fr, with filter (|(uid=user1)(mail=user1)) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] Setting Auth-Type = LDAP*********************************************************************** ldap authorization successful [ldap] user user1 authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop Found Auth-Type = LDAP # Executing group from file /etc/raddb/sites-enabled/inner-tunnel +- entering group LDAP {...}************************************************************* entering LDAP [ldap] login attempt by "user1" with password "toutou" [ldap] user DN: uid=user1,ou=personnels EN,ou=ac-orleans-tours,ou=education,o=gouv,c=fr [ldap] (re)connect to replica.in.ac-orleans-tours.fr:389, authentication 1 [ldap] bind as uid=user1,ou=personnels EN,ou=ac-orleans-tours,ou=education,o=gouv,c=fr/toutou to replica.in.ac-orleans-tours.fr:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] user user1 authenticated succesfully ++[ldap] returns ok WARNING: Empty post-auth section. Using default return values. # Executing section post-auth from file /etc/raddb/sites-enabled/inner-tunnel } # server inner-tunnel [ttls] Got tunneled reply code 2 [ttls] Got tunneled Access-Accept [eap] Freeing handler ++[eap] returns ok # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 230 to 172.30.145.70 port 32769 MS-MPPE-Recv-Key = 0xffc75d74e5bf1ac3d87ad519d6717eb47335013ecdf9d90b911054432b3a14f9 MS-MPPE-Send-Key = 0xc56881775c6929ffb64a59e4f9cbac06d99eb03ab5925f182555d2ec3af2b91e EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "user1" Finished request 6. Going to the next request Waking up in 4.6 seconds. rad_recv: Accounting-Request packet from host 172.30.145.70 port 32769, id=249, length=192 User-Name = "user1" NAS-Port = 2 NAS-IP-Address = 172.30.145.70 NAS-Identifier = "wifi-admin" Airespace-Wlan-Id = 1 Acct-Session-Id = "4fd83d9f/00:1d:e0:21:7b:31/94" Acct-Authentic = RADIUS Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "164" Acct-Status-Type = Interim-Update Acct-Input-Octets = 16133 Acct-Output-Octets = 21904 Acct-Input-Packets = 458 Acct-Output-Packets = 238 Acct-Session-Time = 47 Acct-Delay-Time = 0 Calling-Station-Id = "192.168.234.10" Called-Station-Id = "172.30.145.70" # Executing section preacct from file /etc/raddb/sites-enabled/default +- entering group preacct {...} ++[preprocess] returns ok [acct_unique] Hashing 'NAS-Port = 2,Client-IP-Address = 172.30.145.70,NAS-IP-Address = 172.30.145.70,Acct-Session-Id = "4fd83d9f/00:1d:e0:21:7b:31/94",User-Name = "user1"' [acct_unique] Acct-Unique-Session-ID = "9fcc14215b25e276". ++[acct_unique] returns ok [suffix] No '@' in User-Name = "user1", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[files] returns noop # Executing section accounting from file /etc/raddb/sites-enabled/default +- entering group accounting {...} [detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/172.30.145.70/detail-20120613 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/172.30.145.70/detail-20120613 [detail] expand: %t -> Wed Jun 13 09:14:29 2012 ++[detail] returns ok ++[unix] returns noop [radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp [radutmp] expand: %{User-Name} -> user1 ++[radutmp] returns ok ++[exec] returns noop [attr_filter.accounting_response] expand: %{User-Name} -> user1 attr_filter: Matched entry DEFAULT at line 12 ++[attr_filter.accounting_response] returns updated Sending Accounting-Response of id 249 to 172.30.145.70 port 32769 Finished request 7. Cleaning up request 7 ID 249 with timestamp +40 Going to the next request Waking up in 4.6 seconds. Cleaning up request 0 ID 224 with timestamp +39 Cleaning up request 1 ID 225 with timestamp +39 Cleaning up request 2 ID 226 with timestamp +39 Cleaning up request 3 ID 227 with timestamp +39 Cleaning up request 4 ID 228 with timestamp +39 Waking up in 0.3 seconds. Cleaning up request 5 ID 229 with timestamp +40 Cleaning up request 6 ID 230 with timestamp +40 Ready to process requests. -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57
Emmanuel BILLOT wrote:
I will not understand all, but i think (i hope) i can roughly follow the mechanism. I often try to known what a product do for configuring it. Maybe it is a mistake...
It's often a mistake. Explanations complex ideas often means getting deep into secondary topics. It's simpler and faster just to believe that it works.
Here are the last lines of a successful connexion. It begins with the last outside tunnel authenticate section, just before entering inner-tunnel parsing. I obviously believe you about all what you said, but i can't find an explicite authenticate section between * ldap authorization and * entering LDAP.
The LDAP group it's entering is in the authenticate section. Alan DeKok.
participants (2)
-
Alan DeKok -
Emmanuel BILLOT