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:[email protected]]
> Sent: 24 August 2010 01:13
> To: Pearson, Mark
> Cc: [email protected]
> 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
>> [email protected]
>> 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.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
