[RADIATOR] (RADIATOR) AuthBy LSA Error when using groups

Tue Jul 8 02:47:03 CDT 2008

Hello Kristof -

As described in my previous mail, the problem with 3 seconds is that  
it is a typical timeout value for a RADIUS client, and in this case  
it causes a problem.

The EAP protocol is a series of requests and responses between the  
client device, the access point or NAS, and the RADIUS server.

When we see AD responding in less than 1 second, all is well. However  
when AD takes 3 seconds or more, the RADIUS client sends a retry in  
the middle of the EAP sequence and Radiator correctly reports an  
error. Yes AD is eventually sending an accept, but in between time  
the client has timed out and sent a retry.

regards

Hugh

On 7 Jul 2008, at 22:49, <kristof.vandenouweland at thomsonreuters.com>  
<kristof.vandenouweland at thomsonreuters.com> wrote:

> Hi Hugh,
>
> Sorry for the late respons. I've been ill last week.
>
> Now, the response of our AD server should not be a problem. I don't  
> see
> any other applications having troubles with this so i guess (hope) its
> not this one.
>
> Lets assume that the 1 seconds response for an LSA accept is within  
> the
> timelimit, then the radius should accept the package, not? The LSA  
> does
> accept the package, which is seen in the logs, but it's when its givin
> back to the previous step that the problem begins. So can the  
> problem be
> situated somewhere else?
>
> For the client, i don't think the timeout is the problem. We used the
> software during a test which tested client devices in a 'bad'
> environment, (Much interference, sudden los of AP's so that another AP
> takes it over.) and the laptop did not had a problem with that  
> although
> some connections took about 15 seconds to be established.
>
> The 3 seconds i don't care because the user is not in one of the group
> specified so they should have a reject anyway.
>
> Also, i added the DomainController part to the LSA authby handler and
> added the address of one of our less used DC's. When we check the logs
> of the device, we noticed that in 60% of the cases, the request are
> still made to the primary controller. Should something else be  
> added to
> the DomainController part expect the IP?
>
> Cheers
>
> Kind regards,
> Met vriendelijke groet,
>
> Kristof Van Den Ouweland
> System Engineer
> Thomson CompuMark
> Tel  +32 3 2207 640
> Fax +32 3 2207 631
> kristof.vandenouweland at thomsonreuters.com
>
>
> -----Original Message-----
> From: radiator-bounces at open.com.au [mailto:radiator- 
> bounces at open.com.au]
> On Behalf Of Hugh Irvine
> Sent: Sunday, June 29, 2008 05:18
> To: Van Den Ouweland, Kristof (Prof II&RS)
> Cc: radiator at open.com.au
> Subject: Re: [RADIATOR] (RADIATOR) AuthBy LSA Error when using groups
>
>
> Hello Kristof -
>
> Thanks for the additional information - it helps a great deal.
>
>  From what I can see, in the successful cases the AD server queried by
> the AuthBy LSA clause is taking about 1 second to respond.
>
> In the unsuccessful cases, the AD server is taking about 3 seconds to
> respond, and this is causing the client to timeout and resend the
> request which is what is causing Radiator to report an error.
>
> Clearly when you specify Group's in the AuthBy LSA clause the AD  
> server
> is taking much longer to reply and this is the problem.
>
> You can either increase the timeout on the client device, or  
> preferably,
> improve the response time of your AD server.
>
> I'm afraid I don't know anything about WM6 - is there anyone on the  
> list
> who can help?
>
> hope that helps
>
> regards
>
> Hugh
>
>
> On 27 Jun 2008, at 17:29, <kristof.vandenouweland at thomsonreuters.com>
> <kristof.vandenouweland at thomsonreuters.com> wrote:
>
>> Hi Hugh,
>>
>> Here another logfile which shows first some sucesses, than restart  
>> and
>
>> then some faileres (so that's the part were I added the Group
>> statements from the Authby LSA lines)
>>
>> Thanks for the intell
>>
>>
>> nb. Another question if you would know this: We have some mobile
>> devices here which operator on WM6 but they are not able to connect.
>> Now, default WM6 is not able to disable the validation of the Server
>> Certificate but there seems to be a 'hack' which allows this. So with
>> Hack i mean a change in the registry. If i remeber correctly, this is
>> in HLKM\...\comm\eap\25\ and then add the ValidateServCert line  
>> with a
>
>> value if 0. This unfortunaly does not work.
>> A second try was to install the app securew2 which allows multiple
>> profiles and more options for wireless. (Something like a Intel pro
>> wireless software for the intell based laptops) from which i can
>> uncheck the validation.
>> Unfortunaly, this application has some problems with Cisco wireless
>> AP's and HTC's.
>>
>> Do you (or prehaps  someoneelse who is following this thread) know of
>> another possibilty to get access for such devices? (Device = TYTN I
>> and TYTN II)  I tested it with an HP mobile device (which was from a
>> private
>> user) and there the connection was stable.
>>
>> Thanks
>>
>> Kind regards,
>> Met vriendelijke groet,
>>
>> Kristof Van Den Ouweland
>> System Engineer
>> Thomson CompuMark
>> Tel  +32 3 2207 640
>> Fax +32 3 2207 631
>> kristof.vandenouweland at thomsonreuters.com
>>
>>
>> -----Original Message-----
>> From: Hugh Irvine [mailto:hugh at open.com.au]
>> Sent: Friday, June 27, 2008 03:12 @ morning
>> To: Van Den Ouweland, Kristof (Prof II&RS)
>> Cc: radiator at open.com.au
>> Subject: Re: [RADIATOR] (RADIATOR) AuthBy LSA Error when using groups
>>
>>
>> Hello Kristof -
>>
>> Thanks for your mail.
>>
>> The debug you sent shows an error in the AuthBy FILE clause in the
>> default Handler:
>>
>> ......
>>
>> Thu Jun 26 09:54:26 2008: DEBUG: Packet dump:
>> *** Received from 10.223.143.54 port 32769 ....
>> Code:       Access-Request
>> Identifier: 105
>> Authentic:
>> <173><181><173>qD<186><243>1<151><13><200>s<248><209><165><171>
>> Attributes:
>> 	User-Name = "XPP243"
>> 	Calling-Station-Id = "00-13-E8-58-43-A9"
>> 	Called-Station-Id = "00-19-07-8C-8E-C0:tcm-work"
>> 	NAS-Port = 1
>> 	NAS-IP-Address = 10.223.143.54
>> 	NAS-Identifier = "wlan1"
>> 	Airespace-WLAN-Id = 2
>> 	Service-Type = Framed-User
>> 	Framed-MTU = 1300
>> 	NAS-Port-Type = Wireless-IEEE-802-11
>> 	Tunnel-Type = 0:VLAN
>> 	Tunnel-Medium-Type = 0:802
>> 	Tunnel-Private-Group-ID = 10
>> 	EAP-Message = <2><7><0><144><25><0><23><3><1><0>
>> <151><21>~<176>,|
>> Zy<231><180><163>=7<14>A<130>L<219><188><178>]<160><23><166><235>1
>> [<189>Mtq<155><23><3><1><0>`k
>> {<215><200><163><25><247><235>S<189>o<13><164>S%0<2>]<188><216>}
>> <160><227>E<0><192><197><201>!W<214><224><<28><151>N<238>v
>> $g0<205><225>U<143>R<253>Vl<160>t^K<15>u<26>&<148>f<4>.<143><230><244 
>> >
>> )<
>>
>> 9><225>2jt<27><160><182><195><31>/<190><242>9gJ
>> s^<23><193><178>7<3><170><189><29><4>=R<217>
>> 	Message-Authenticator =
>> <15><212><183><131><14>v<238><254><215><15><<227>&g<170><162>
>>
>> Thu Jun 26 09:54:26 2008: DEBUG: Handling request with Handler ''
>> Thu Jun 26 09:54:26 2008: DEBUG:  Deleting session for XPP243,
>> 10.223.143.54, 1 Thu Jun 26 09:54:26 2008: DEBUG: Handling with
>> Radius::AuthFILE:
>> Thu Jun 26 09:54:26 2008: DEBUG: Handling with EAP: code 2, 7,  
>> 144, 25
>
>> Thu Jun 26 09:54:26 2008: DEBUG: Response type 25 Thu Jun 26 09:54:26
>> 2008: ERR: EAP PEAP TLS read failed:  2480: 1 - error:1408F119:SSL
>> routines:SSL3_GET_RECORD:decryption failed or bad record mac
>>
>> Thu Jun 26 09:54:26 2008: DEBUG: EAP result: 1, EAP PEAP TLS read
>> failed Thu Jun 26 09:54:26 2008: DEBUG: AuthBy FILE result: REJECT,
>> EAP PEAP TLS read failed Thu Jun 26 09:54:26 2008: INFO: Access
>> rejected for
>> XPP243: EAP PEAP TLS read failed Thu Jun 26 09:54:26 2008: DEBUG:
>> Packet
>> dump:
>> *** Sending to 10.223.143.54 port 32769 ....
>> Code:       Access-Reject
>> Identifier: 105
>> Authentic:
>> <173><181><173>qD<186><243>1<151><13><200>s<248><209><165><171>
>> Attributes:
>> 	Reply-Message = "Request Denied"
>>
>>
>> This doesn't have anything to do with a Group specification in the
>> AuthBy LSA clause.
>>
>> Can you please send a more complete debug showing both success  
>> without
>
>> Group's and failure with Group's?
>>
>> regards
>>
>> Hugh
>>
>>
>> On 26 Jun 2008, at 19:58, <kristof.vandenouweland at thomsonreuters.com>
>> <kristof.vandenouweland at thomsonreuters.com> wrote:
>>
>>> Hi All,
>>>
>>> We've successfully set up a configuration for Radiator using
>>> PEAP/MSCHAPV2 and then LSA
>>>
>>> Now the strange thing is, from the moment we add the Group property
>>> to
>>
>>> the LSA authentication to check wether the user is in a group and so
>>> may connect, the repsonse givin back seems to be wrong and causes a
>>> TLS READ error (see log) which results in a REJECTED message
>>>
>>> I've tried non-existing groups to see wether he can dedect them  
>>> which
>
>>> than add the following line :
>>>
>>>   Thu Jun 26 09:45:47 2008: DEBUG: Radius::AuthLSA looks for match
>>> with
>>> TLR\u0093289 [TLR\u0093289]
>>>   Thu Jun 26 09:45:52 2008: DEBUG: Radius::AuthLSA REJECT: AuthBy  
>>> LSA
>
>>> User is not a member of any Group: TLR\u0093289 [TLR\u0093289]
>>>   Thu Jun 26 09:45:52 2008: DEBUG: AuthBy LSA result: REJECT, AuthBy
>>> LSA User is not a member of any Group
>>>   Thu Jun 26 09:45:52 2008: INFO: Access rejected for TLR\u0093289:
>>> AuthBy LSA User is not a member of any Group
>>>
>>>    :  and then result in an REJECTED, which is off course normal.
>>> (Just
>>> to point that he can dedect groups)
>>>
>>> Rejection message encoutering:
>>>
>>>   Thu Jun 26 09:45:52 2008: DEBUG: EAP TLS SSL_accept result: -1, 1,
>>> 8465
>>>   Thu Jun 26 09:45:53 2008: ERR: EAP TLS error: -1, 1, 8465,  2832:
>>> 1 -
>>> error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected record
>>>
>>>   Thu Jun 26 09:45:53 2008: DEBUG: EAP result: 1, EAP PEAP TLS error
>>>   Thu Jun 26 09:45:53 2008: DEBUG: AuthBy FILE result: REJECT, EAP
>>> PEAP TLS error
>>>   Thu Jun 26 09:45:53 2008: INFO: Access rejected for XPP243: EAP
>>> PEAP
>>
>>> TLS error
>>>
>>>
>>> If we remove the groups, everything is back to normal and functions
>>> fine.
>>>
>>>
>>> Did someone encounter this problem and found a solution?
>>>
>>> Much appreciated
>>>
>>> See config below and log in attachment
>>>
>>> Kind regards,
>>> Met vriendelijke groet,
>>>
>>> Kristof Van Den Ouweland
>>> -------------------------------------------------------------------- 
>>> -
>>> -
>>
>>> --
>>> -------------------
>>>
>>> DbDir %D
>>> Trace 4
>>> LogStdout
>>> AuthPort 1812
>>> AcctPort 1813
>>> LogFile c:\Radiator\logs\%Y-%m-logfile.log
>>> PidFile %D/radiusd.pid
>>> DictionaryFile c:\Radiator\dictionary
>>>
>>> <Client 10.223.143.54>
>>>         Secret  somehting
>>>         DupInterval 0
>>> 		
>>> </Client>
>>>
>>>
>>> <Client LOCALHOST>
>>> 	Secret somethingelse
>>> 	DupInterval 0	
>>> 	Identifier LOCALHOST
>>> 	
>>> </Client>
>>>
>>> <AuthLog FILE>
>>> 	Identifier logger1
>>> 	Filename c:\Radiator\authenticationlogs\%Y-%m-authlog.log
>>> 	LogSuccess 1
>>> 	LogFailure 1
>>> </AuthLog>
>>>
>>> <Handler Client-Identifier=LOCALHOST>
>>>
>>>                 # Connection to LDAP Thomson TLR AD
>>>                 <AuthBy LSA>
>>> 				  #EAPType MSCHAP-v2
>>>
>>> 					#Only users in these groups are
>>> allowed to have access to the WLAN
>>> 					#Group CME-grpDomainAdmins
>>> 					#Group CME-grpWLANAccess
>>> 					
>>> 				
>>>                 </AuthBy>
>>> </Handler>
>>>
>>> <Handler ConvertedFromEAPMSCHAPV2=1>
>>>
>>> 	        <AuthBy RADIUS>
>>> 			Host localhost
>>>        		        Secret somethingelse
>>>                 	AuthPort 1812
>>>                 	AcctPort 1813
>>>                 	StripFromRequest ConvertedFromEAPMSCHAPV2
>>> 					
>>>         	</AuthBy>
>>> 			
>>> </Handler>
>>>
>>> <Handler TunnelledByPEAP=1>
>>>         <AuthBy FILE>
>>>             EAPType MSCHAP-V2
>>>             EAP_PEAP_MSCHAP_Convert 1	
>>>         </AuthBy>
>>> </Handler>
>>>
>>> <Handler>
>>>         <AuthBy FILE>
>>> 			Filename c:/Radiator/users
>>>             EAPType PEAP, TTLS
>>>             EAPTLS_CAFile c:/Radiator/certificates/demoCA/cacert.pem
>>>             EAPTLS_CertificateFile
>>> c:/Radiator/certificates/signed-newcert.pem
>>>             EAPTLS_CertificateType PEM
>>>             EAPTLS_PrivateKeyFile c:/Radiator/certificates/ 
>>> newkey.pem
>>>             EAPTLS_PrivateKeyPassword somethingdifferent
>>>             EAPTLS_MaxFragmentSize 2048
>>>             EAPAnonymous anonymous
>>>             EAPTLS_PEAPVersion 0
>>> 	RejectEmptyPassword
>>> 	EAPTLS_PEAPBrokenV1Label
>>> 			
>>>         </AuthBy>
>>> 		
>>> 		AuthLog logger1
>>>
>>> </Handler><log_radius_exmaple.txt>
>>
>>
>>
>> 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?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>> --
>> 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.
>>
>>
>>
>> <2008-06-logfile.log>
>
>
>
> 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?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> --
> 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
> 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?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

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