(RADIATOR) EAP TLS Configuration within AuthBy Group clause

Luca Bechelli luca at omnitechweb.it
Mon Mar 12 09:01:13 CST 2007





>Ciao Luca -

>Come va?

Bene, grazie!
E tu :-) ?

On 6 Mar 2007, at 05:38, Luca Bechelli wrote:

>>
>> Hi
>>
>> I need to configure EAP-TLS authentication over Radiator for some  
>> users of a
>> network.

>Can you explain exactly what you are wanting to do?

Network users have to authenticate themselves by using the certificate
installed on their own PC(via EAP-TLS). Any other mechanism is not
necessary(e.g. password).
The mechanism we have established, EAP-TLS is the only authentication method
for the final user, while LDAP access is required only to gain attributes
for the switch.

> Unfortunately I encountered some problems:

>Can you please send a copy of the configuration file and a trace 4  
>debug showing what is happening?

I attach a simple configuration file, using EAP-MD5 instead of EAP-TLS for
testing purpose:

(...)

<Realm DEFAULT>
        <AuthBy GROUP>

                AuthByPolicy ContinueUntilReject        

                <AuthBy FILE>
                        Filename %D/users
                        EAPType MD5-Challenge
                        
                </AuthBy>
                <AuthBy LDAP2>
                        # Tell Radiator how to talk to the LDAP server
                        Host            xx.xxx.xxx.xx
        
                        # You will only need these if your LDAP server
                        # requires authentication. These are the examples
                        # in a default OpenLDAP installation
                        # see /etc/openldap/slapd.conf
                        BaseDN          dc=example, dc=com, cn=Manager
                        AuthPassword    secret

                        # This the top of the search tree where users
                        # will be found. It should match the configuration
                        # of your server, see /etc/openldap/slapd.conf
                        BaseDN          dc=corejsf,dc=com

                        UsernameAttr    cn
              
                        NoCheckPassword

                        HoldServerConnection
                                        
                        Version 3
                        
                </AuthBy>
        </AuthBy>
(...)

(LDAP attributes have to be defined, so this example is only for testing
purposes)

Now, this is the result of the execution of radpwtst in "detailed" log:

*** Received from 127.0.0.1 port 32768 ....

Packet length = 117
01 6c 00 75 31 32 33 34 35 36 37 38 39 30 31 32
33 34 35 36 01 07 6d 69 6b 65 6d 06 06 00 00 00
02 04 06 cb 3f 9a 01 20 0e 32 30 33 2e 36 33 2e
31 35 34 2e 31 05 06 00 00 04 d2 1e 0b 31 32 33
34 35 36 37 38 39 1f 0b 39 38 37 36 35 34 33 32
31 3d 06 00 00 00 00 4f 0c 02 00 00 0a 01 6d 69
6b 65 6d 50 12 86 1a 5c 67 e4 4d 99 0a bb b3 46
ce 99 3d 7c 48
Code:       Access-Request
Identifier: 108
Authentic:  1234567890123456
Attributes:
        User-Name = "mikem"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Identifier = "203.63.154.1"
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port-Type = Async
        EAP-Message = <2><0><0><10><1>mikem
        Message-Authenticator =
<134><26>\g<228>M<153><10><187><179>F<206><153>=|H

Mon Mar 12 12:48:03 2007: DEBUG: Handling request with Handler
'Realm=DEFAULT'
Mon Mar 12 12:48:03 2007: DEBUG:  Deleting session for mikem, 203.63.154.1,
1234
Mon Mar 12 12:48:03 2007: DEBUG: Handling with Radius::AuthGROUP: 
Mon Mar 12 12:48:03 2007: DEBUG: Handling with Radius::AuthFILE: 
Mon Mar 12 12:48:03 2007: DEBUG: Handling with EAP: code 2, 0, 10
Mon Mar 12 12:48:03 2007: DEBUG: Response type 1
Mon Mar 12 12:48:03 2007: DEBUG: EAP result: 3, EAP MD5-Challenge
Mon Mar 12 12:48:03 2007: DEBUG: Handling with Radius::AuthLDAP2: 
Mon Mar 12 12:48:03 2007: DEBUG: Handling with EAP: code 2, 0, 10
Mon Mar 12 12:48:03 2007: DEBUG: Response type 1
Mon Mar 12 12:48:03 2007: DEBUG: EAP result: 1, EAP authentication is not
permitted.
Mon Mar 12 12:48:03 2007: DEBUG: AuthBy GROUP result: REJECT, EAP
authentication is not permitted.
Mon Mar 12 12:48:03 2007: INFO: Access rejected for mikem: EAP
authentication is not permitted.
Mon Mar 12 12:48:03 2007: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32768 ....

Packet length = 87
03 6c 00 57 d8 c8 82 cc e7 7e 9e b3 de 37 1b a4
3a de 8d d3 4f 21 01 01 00 1f 04 10 55 7e 61 e8
07 29 d5 ff 1f 11 cf 82 a0 f1 3e bf 72 65 64 68
61 64 45 53 34 50 12 e5 36 94 a3 bb 09 86 50 00
a0 74 97 f7 10 0a 25 12 10 52 65 71 75 65 73 74
20 44 65 6e 69 65 64
Code:       Access-Reject
Identifier: 108
Authentic:  1234567890123456
Attributes:
        EAP-Message =
<1><1><0><31><4><16>U~a<232><7>)<213><255><31><17><207><130><160><241>><191>redhadES4
        Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
        Reply-Message = "Request Denied"

(...)

This is the same result if I use EAP-TLS authentication instead of EAP-MD5.
For that reason, EAP authentication is required in a LDAP AutBy which always
return a negatitive result (in order to force the access ONLY to the valid
certificate owner), while subsequently the LDAP access is needed for
obtaining the attributes for the switch.
So we do this with two Radiator instances because AutBy Group doesn't work
with EAP.
Do you think it could be possible to find a method that allows us to do
everything with only one Radiator istance?
Something like your example below?

Thanks!

Luca

>Something like this:


># Handler to process "inner" request

><Handler TunnelledByPEAP = 1>
>	<AuthBy LDAP2>
>		.....
>	</AuthBy>
></Handler>
>
># Handler to process "outer" requests
>
><Handler>
>	<AuthBy FILE>
>		......
>		EAPType .....
>		......
>	</AuthBy>
></Handler>


-- 
View this message in context: http://www.nabble.com/EAP-TLS-Configuration-within-AuthBy-Group-clause-tf3350784.html#a9436159
Sent from the Radiator - General mailing list archive at Nabble.com.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list