[RADIATOR] Authby LSA help

Hugh Irvine hugh at open.com.au
Tue Aug 24 19:06:21 CDT 2010


Hello Mark -

Could you please try the following configuration file?

…..

# This is where we authenticate a PEAP inner request, which will be an EAP
# request. The username of the inner request will be anonymous, although
# the identity of the EAP request will be the real username we are
# trying to authenticate.

# Added EAPAnonymous %{User-Name} to the outer AuthBy
# This will send the outer username  as the inner username 
# (instead of "anonymous")
 
<Handler TunnelledByPEAP=1>
 <AuthBy LSA>
 Domain ADS
 UsernameMatchesWithoutRealm 
 EAPType MSCHAP-V2
 </AuthBy>
</Handler>
 
# The original PEAP request from a NAS will be sent to a matching
# Realm or Handler in the usual way, where it will be unpacked and 
# the inner authentication extracted.
# The inner authentication request will be sent again to a matching
# Realm or Handler. The special check item TunnelledByPEAP=1 can be used to select
# a specific handler, or else you can use EAPAnonymous to set a username and realm
# which can be used to select a Realm clause for the inner request.
# This allows you to select an inner authentication method based on Realm, and/or the
# fact that they were tunnelled. You can therfore act just as a PEAP server, or also 
# act as the AAA/H home server, and authenticate PEAP requests locally or proxy
# them to another remote server based on the realm of the inner authenticaiton request.
# In this basic example, both the inner and outer authentication are authenticated
# from a file by AuthBy FILE
 
<Handler Realm=ntu.ac.uk>
 <AuthBy FILE>
  Filename %D/users
  # This tells the PEAP client what types of inner EAP requests
  # we will honour
  EAPType PEAP, TTLS
  EAPTLS_CAFile %D/certificates/demoCA/cacert.pem
  EAPTLS_CertificateFile %D/certificates/cert-srv.pem
  EAPTLS_CertificateType PEM
  EAPTLS_PrivateKeyFile %D/certificates/cert-srv.pem
  EAPTLS_PrivateKeyPassword whatever
  EAPTLS_MaxFragmentSize 1000
  AutoMPPEKeys
  SSLeayTrace 4
  EAPTLS_PEAPVersion 0
  EAPAnonymous %{User-Name}
 </AuthBy>
</Handler>
 
…..

 
thanks and regards

Hugh


On 25 Aug 2010, at 00:58, Pearson, Mark wrote:

> Hugh, I have simplified the config a little and fixed a few things but
> now get the errors as seen in log2.txt. I have added the Domain ADS as
> the radiator server is not in the ADS domain where the accounts live.
> Does this need to be the FQDN ? In other words how does the Radiator
> server know where to send the LDAP requests ?
> 
> I notice that Michael Harlow was getting similar errors so I added
> UsernameMatchesWithoutRealm but its made no difference. 
> 
> 
> regards
> Mark Pearson
> Senior Technical Support Analyst
> Information Systems
> Nottingham Trent University
> 
> tel: 0115 8488287
> 
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au] 
> Sent: 24 August 2010 01:13
> To: Pearson, Mark
> Cc: radiator at open.com.au
> Subject: Re: [RADIATOR] Authby LSA help
> 
> 
> Hello Mark -
> 
> Can you please send me a copy of the full configuration file and a trace
> 4 debug showing the startup messages and a more complete log showing the
> whole sequence?
> 
> thanks and regards
> 
> Hugh
> 
> 
> On 21 Aug 2010, at 01:10, Pearson, Mark wrote:
> 
>> Hi, I currently have Radiator for Windows 4.3.1 and I want to
> authenticate clients against windows AD 2003. I am assuming that I use
> Authby LSA to do this. I want to use PEAP as the authententication type.
> The config below comes after all the client stuff etc and I have a user
> Anonymous in the %D/users database. I have included a section of log
> that includes the error. Any help on correct configuration will be
> appreciated.
>> 
>> 
>> <Handler TunnelledByPEAP=1>
>> # Authenticate with Windows LSA
>> <AuthBy LSA>
>>  UsernameMatchesWithoutRealm
>>  # This tells the PEAP client what types of inner EAP requests
>>  # we will honour
>> EAPType MSCHAP-V2
>> </AuthBy>
>> </Handler>
>> 
>> 
>> # The original PEAP request from a NAS will be sent to a matching # 
>> Realm or Handler in the usual way, where it will be unpacked and the 
>> inner authentication # extracted.
>> # The inner authentication request will be sent again to a matching # 
>> Realm or Handler. The special check item TunnelledByPEAP=1 can be used
> 
>> to select # a specific handler, or else you can use EAPAnonymous to 
>> set a username and realm # which can be used to select a Realm clause
> for the inner request.
>> # This allows you to select an inner authentication method based on 
>> Realm, and/or the # fact that they were tunnelled. You can therfore 
>> act just as a PEAP server, or also # act as the AAA/H home server, and
> 
>> authenticate PEAP requests locally or proxy # them to another remote
> server based on the realm of the inner authenticaiton request.
>> # In this basic example, both the inner and outer authentication are 
>> authenticated # from a file by AuthBy FILE
>> 
>> <Handler Realm=ntu.ac.uk>
>> <AuthBy FILE>
>>  # The username of the outer authentication
>>  #  must be in this file to get anywhere. In this example,
>>  # it requires an entry for 'anonymous' which is the standard
> username 
>>  # in the outer requests, and it also requires an entry for the
>>  # actual user name who is trying to connect (ie the 'Login name'
> entered
>>  # in the Funk Odyssey 'Edit Profile Properties' page
>>  Filename %D/users
>> 
>>  # EAPType sets the EAP type(s) that Radiator will honour.
>>  # Options are: MD5-Challenge, One-Time-Password
>>  # Generic-Token, TLS, TTLS, PEAP, MSCHAP-V2
>>  # Multiple types can be comma separated. With the default (most
>>  # preferred) type given first
>>  EAPType PEAP
>> 
>>  EAPTLS_CAFile %D/certificates/demoCA/cacert.pem
>>  EAPTLS_CertificateFile %D/certificates/cert-srv.pem
>>  EAPTLS_CertificateType PEM
>>  EAPTLS_PrivateKeyFile %D/certificates/cert-srv.pem
>>  EAPTLS_PrivateKeyPassword whatever
>>  EAPTLS_MaxFragmentSize 1000
>>  AutoMPPEKeys
>>  SSLeayTrace 4
>>  EAPTLS_PEAPVersion 1
>>  EAPTLS_PEAPBrokenV1Label
>> </AuthBy>
>> </Handler>
>> 
>> 
>> Section of log where error occurs
>> 
>> Thu Aug 19 16:37:40 2010: DEBUG: Handling request with Handler
> 'TunnelledByPEAP=1'
>> Thu Aug 19 16:37:40 2010: DEBUG:  Deleting session for anonymous, 
>> 10.15.100.4, 29 Thu Aug 19 16:37:40 2010: DEBUG: Handling with
> Radius::AuthLSA:
>> Thu Aug 19 16:37:40 2010: DEBUG: Handling with EAP: code 2, 8, 80, 26 
>> Thu Aug 19 16:37:40 2010: DEBUG: Response type 26 Thu Aug 19 16:37:40 
>> 2010: DEBUG: Radius::AuthLSA looks for match with com3pearsmw 
>> [anonymous] Thu Aug 19 16:37:40 2010: DEBUG: Radius::AuthLSA ACCEPT: :
> 
>> com3pearsmw [anonymous] Thu Aug 19 16:37:40 2010: WARNING: Could not
> LogonUserNetworkMSCHAP (V2): 3221225508, 2228600, The handle is invalid.
>> 
>> 
>> Thu Aug 19 16:37:40 2010: DEBUG: EAP result: 1, EAP MSCHAP-V2 
>> Authentication failure Thu Aug 19 16:37:40 2010: DEBUG: AuthBy LSA 
>> result: REJECT, EAP MSCHAP-V2 Authentication failure Thu Aug 19 
>> 16:37:40 2010: INFO: Access rejected for anonymous: EAP MSCHAP-V2
> Authentication failure Thu Aug 19 16:37:40 2010: DEBUG: Returned PEAP
> tunnelled packet dump:
>> Code:       Access-Reject
>> regards
>> Mark Pearson
>> Senior Technical Support Analyst
>> Information Systems
>> Nottingham Trent University
>> 
>> tel: 0115 8488287
>> 
>> 
>> regards
>> Mark Pearson
>> Senior Technical Support Analyst
>> Information Systems
>> Nottingham Trent University
>> 
>> tel: 0115 8488287
>> 
>> 
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> 
> 
> 
> 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.
> 
> 
> 
> 
> 
> This email is intended solely for the addressee.  It may contain private and confidential information.  If you are not the intended addressee, please take no action based on it nor show a copy to anyone.  In this case, please reply to this email to highlight the error.  Opinions and information in this email that do not relate to the official business of Nottingham Trent University shall be understood as neither given nor endorsed by the University.
> Nottingham Trent University has taken steps to ensure that this email and any attachments are virus-free, but we do advise that the recipient should check that the email and its attachments are actually virus free.  This is in keeping with good computing practice.
> 
> 
> <log2.txt><radius2.cfg>



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.





More information about the radiator mailing list