(RADIATOR) EAP TLS Configuration within AuthBy Group clause

Hugh Irvine hugh at open.com.au
Mon Mar 12 18:51:11 CST 2007


Ciao Luca -

Si tutti va bene....

	http://www.grandprix.com.au/

Alore -

I suggest you add "NoEAP" to your AuthBy LDAP2 clause:



<Realm DEFAULT>
         <AuthBy GROUP>

                 AuthByPolicy ContinueUntilReject

                 <AuthBy FILE>

                         Filename %D/users
                         EAPType MD5-Challenge

                 </AuthBy>

                 <AuthBy LDAP2>

			NoEAP

                         # 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>
(...)


Please let me know how that works.

ciao

Hugo


On 13 Mar 2007, at 02:01, Luca Bechelli wrote:

>
>
>
>
>> 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.



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
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