date:20121119

[RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

2012-11-19 Thread Murat Bilal

Hi all,

I have very simple conf as below:


Key somekey
  AddToRequest NAS-Identifier=TACACS
GroupMemberAttr OSC-AVPAIR
 AuthorizeGroup group1 permit service=shell cmd=show cmd-arg=.*
AuthorizeGroup group1 permit service=shell cmd\* {autocmd="telnet 
169.163.226.81"}
AuthorizeGroup group1 permit service=ppp protocol=ip {inacl=101 
outacl=102}
AuthorizeGroupAttr permit service=shell cmd\* {priv-lvl=15}
AuthorizeGroupAttr permit service=shell  cmd\* {priv-lvl=1}
AuthorizeGroupAttr permit .* {}




 Identifier SQLTAC
# See the reference manual. You will also have to
# change the one in  below
# so its the same
DBSourcedbi:mysql:radius:localhost
DBUsername  raduser
DBAuth  raduser
#AuthSelect select PASSWORD 'Auth-Type=AuthSQL from SUBSCRIBERS where 
USERNAME=%0 in 'GroupList="group1 group2 group3 group8"'
# AuthSelect select PASSWORD 'Auth-Type=AuthSQL from SUBSCRIBERS where 
USERNAME=%0 in ($GroupMembershipQuery)
# You can customise the SQL query used to get user details with the
# AuthSelect parameter:
#  AuthSelect select PASSWORD from SUBSCRIBERS where USERNAME=%0
# You can use statement caching and bound variables with 
AuthSelectParam:
#  AuthSelect select PASSWORD from SUBSCRIBERS where USERNAME=?
#  AuthSelectParam %u
# You can control what is done with each field returned from the
#  AuthSelect query with the AuthColumnDef parameter:
  AuthColumnDef 1, OSC-Group-Identifier, reply

# You may want to tailor these for your ACCOUNTING table
# You can add your own columns to store whatever you like
AccountingTable ACCOUNTING
AcctColumnDef   USERNAME,User-Name
AcctColumnDef   TIME_STAMP,Timestamp,integer
AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
AcctColumnDef   NASIDENTIFIER,NAS-Identifier
AcctColumnDef   NASPORT,NAS-Port,integer
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
 GroupMembershipQuery select GROUPNAME from GROUPS where USERNAME=%0 
and GROUPNAME=%1


#GroupMembershipQueryParam %0
#GroupMembershipQueryParam %1






This conf works very well with AuthBy FILE.When I try AuthBy SQL I got the 
group DEFAULT. No matching AuthorizeGroup rule error,and cannot make TACACS 
authorization.

In the reference manual it says GroupMembershipQuery checks to validate both 
the username and appropriate group membership. But as I can see it cannot do 
that and cannot return a reply for group identifier.

Please help.I check the refence manuel but nothing to find.





MURAT BİLAL
Services Engineer

Ericsson Turkey
CU Customer Support
Cyber Plaza C Blok Kat:1 No:146
Cyberpark 6800 Bilkent/Ankara
Mobile +90 554 898 98 43
murat.bi...@ericsson.com
www.ericsson.com


[cid:image001.png@01CDC63D.7B2BB8A0]

This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

<>___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier ''

Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':



(2 seconds delay)



Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : sip:557100050994
[sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"





I was expecting if the DB take too much time to answer it failover to the
second AuthBy.  Maybe I’m doing something wrong?

Can someone help me here?



Regards,

Ricardo.-
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Michael

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:


Hello,

I'm trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/users_tranum







The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return 
a column.


This is the log for a Request to this Handler:

Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier ''


Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 , 
10.0.0.82, 0


Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':

(2 seconds delay)

Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"

I was expecting if the DB take too much time to answer it failover to 
the second AuthBy.  Maybe I'm doing something wrong?


Can someone help me here?

Regards,

Ricardo.-



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

Hello Michael.

I have modified the AuthByPolicy fro mContinueWhileIgnore for



And now it jumps to the second AuthBy, but is not marking the DB as fail
(and therefor doing the Backooff Time), this is the log.

What I’m doing wrong?



Mon Nov 19 16:41:05 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 34896 

Code:   Access-Request

Identifier: 112

Authentic:  <31><23>t<202><197><247>5<185><138><147><198>*<22><184><216>x

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:41:05 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier
'AuthFailover'

Mon Nov 19 16:41:05 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:41:05 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:07 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:09 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user:
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:09 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:11 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:13 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:13 2012: DEBUG: AuthBy SQL result: REJECT, No such user

Mon Nov 19 16:41:13 2012: DEBUG: Handling with Radius::AuthFILE:

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: :
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:13 2012: DEBUG: AuthBy FILE result: ACCEPT,

Mon Nov 19 16:41:13 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:41:13 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 34896 

Code:   Access-Accept

Identifier: 112

Authentic:  @<165><188><181>;<242>-<251><184><200>q<174>`<239><24>k

Attributes:

SIP-AVP = "tranum:sip:0212345678@10.0.0.82"

SIP-AVP = "channels:1"



Thanks,
Ricardo.-



*De:* Michael [mailto:ri...@vianet.ca]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au
*Asunto:* Re: [RADIATOR] SQL Timeout



looks like your first AuthBy SQL is answering accept.  is this maybe
because you don't have any 'check' options at all?  Then if accept, never
process the AuthBy FILE because of ContunueWhileIgnore.

For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier ''

Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

I miss the change : ContinueWhileIgnore for ContinueWhileReject



*De:* Michael [mailto:ri...@vianet.ca]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au
*Asunto:* Re: [RADIATOR] SQL Timeout



looks like your first AuthBy SQL is answering accept.  is this maybe
because you don't have any 'check' options at all?  Then if accept, never
process the AuthBy FILE because of ContunueWhileIgnore.

For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier ''

Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':



(2 seconds delay)



Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : sip:557100050994[
sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"





I was expecting if the DB take too much time to answer it failover to the
second AuthBy.  Maybe I’m doing something wrong?

Can someone help me here?



Regards,

Ricardo.-




___

radiator mailing list

radiator@open.com.au

http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Michael

I think you would have to query a 2nd time within 60 seconds in order to 
see the BackOff in the log.



On 19/11/12 02:44 PM, Ricardo Martinez wrote:


Hello Michael.

I have modified the AuthByPolicy fro mContinueWhileIgnore for

And now it jumps to the second AuthBy, but is not marking the DB as 
fail (and therefor doing the Backooff Time), this is the log.


What I’m doing wrong?

Mon Nov 19 16:41:05 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 34896 

Code:   Access-Request

Identifier: 112

Authentic: <31><23>t<202><197><247>5<185><138><147><198>*<22><184><216>x

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:41:05 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier 'AuthFailover'


Mon Nov 19 16:41:05 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:41:05 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 , 
10.0.0.82, 0


Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:07 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user: 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:41:09 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:11 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy SQL result: REJECT, No such user

Mon Nov 19 16:41:13 2012: DEBUG: Handling with Radius::AuthFILE:

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy FILE result: ACCEPT,

Mon Nov 19 16:41:13 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:41:13 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 34896 

Code:   Access-Accept

Identifier: 112

Authentic:  @<165><188><181>;<242>-<251><184><200>q<174>`<239><24>k

Attributes:

SIP-AVP = "tranum:sip:0212345678@10.0.0.82 
"


SIP-AVP = "channels:1"

Thanks,
Ricardo.-

*De:*Michael [mailto:ri...@vianet.ca ]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au 
*Asunto:* Re: [RADIATOR] SQL Timeout

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/users_tranum







The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return 
a column.


This is the log for a Request to this Handler:

Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

I’m doing 3 or even 4 querys for each one and keeps connecting to the mySQL
server and not doing the BackOff.



The Timeout parameter seems to be very clear about the behavior :

*5.31.4 Timeout*

This optional parameter specifies a timeout interval in seconds that
Radiator will wait

for when trying to contact the SQL server specified by DBAuth. If the
server does not

respond within the Timeout period, Radiator will consider the SQL server to
be failed,

and will stop trying to contact the SQL server until the FailureBackoffTime
is expired.

Defaults to 60 seconds.



Question : When it says “…Radiator will wait for when trying to contact the
SQL server…” this means that a *select* is a CONTACT???



So, I don’t understand why the Radiator is not doing the Backoff.

Any ideas?





Identifier AuthFailover

RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueUntilAccept



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  1



AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











Ricardo.-
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Heikki Vatiainen

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says “…Radiator will wait for when trying to contact
> the SQL server…” this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that
returned error and not the contact just before it, FailureBackoffTime is
not triggered.

> So, I don’t understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection
attempt. When this happens you will see it start the backoff timer.

Thanks,
Heikki

-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

2012-11-19 Thread Heikki Vatiainen

On 11/19/2012 10:13 AM, Murat Bilal wrote:

> 

> GroupMemberAttr OSC-AVPAIR

Hello Murat,

note that you have set GroupMemberAttr to OSC-AVPAIR here.

> 
> 

>   AuthColumnDef 1, OSC-Group-Identifier, reply

Here you are adding OSC-Group-Identifier to the reply. Maybe this should
be OSC-AVPAIR or alternatively you should have GropMemberAttr set to
OSC-Group-Identifier in ServerTACACSPLUS.

Also, since you have not changed AuthSelect from the default, you should
select it to something like

  AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS

and define
  AuthColumnDef 0, User-Password, check
  AuthColumnDef 1, OSC-Group-Identifier, reply

This will check the request password and and the desired group name to
reply if password check succeeds.

Thanks,
Heikki

-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

Is there another more safe way to do the BackOff.  What I'm trying to do
is when a SQLquery is Timeout by Radiator mark the server as "down" and do
the next AuthBy Clause.
I saw a pair of question about the same issue near 2002 :
http://www.open.com.au/pipermail/radiator/2002-October/005289.html

Please help me here.

I'm using :
Radiator 4.9
perl, v5.10.1 (*) built for x86_64-linux-thread-multi
DBI : 1 .622
DBD:mysql  4.022

Regards,
Ricardo.-

-Mensaje original-
De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
nombre de Heikki Vatiainen
Enviado el: lunes, 19 de noviembre de 2012 18:21
Para: radiator@open.com.au
Asunto: Re: [RADIATOR] SQL Timeout

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says ".Radiator will wait for when trying to
> contact the SQL server." this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that returned
error and not the contact just before it, FailureBackoffTime is not
triggered.

> So, I don't understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection attempt.
When this happens you will see it start the backoff timer.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

2012-11-19 Thread Ricardo Martinez

There is also other post about the same issue :

http://www.open.com.au/pipermail/radiator/2011-April/017237.html

-Mensaje original-
De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
Enviado el: lunes, 19 de noviembre de 2012 18:36
Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
Asunto: RE: [RADIATOR] SQL Timeout

Is there another more safe way to do the BackOff.  What I'm trying to do
is when a SQLquery is Timeout by Radiator mark the server as "down" and do
the next AuthBy Clause.
I saw a pair of question about the same issue near 2002 :
http://www.open.com.au/pipermail/radiator/2002-October/005289.html

Please help me here.

I'm using :
Radiator 4.9
perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
DBD:mysql  4.022

Regards,
Ricardo.-

-Mensaje original-
De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
18:21
Para: radiator@open.com.au
Asunto: Re: [RADIATOR] SQL Timeout

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says ".Radiator will wait for when trying to
> contact the SQL server." this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that returned
error and not the contact just before it, FailureBackoffTime is not
triggered.

> So, I don't understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection attempt.
When this happens you will see it start the backoff timer.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

2012-11-19 Thread Murat Bilal

Hi ,

I try this :  

AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS
and define
  AuthColumnDef 0, User-Password, check
  AuthColumnDef 1, OSC-Group-Identifier, reply

I got ERR: Execute failed for 'select PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Unknown column 'TACACSGROUPID' in 'field list'

In my Subscribers table there is no column like this.Do I need to change mysql 
schema ?

-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
Behalf Of Heikki Vatiainen
Sent: 19 Kasım 2012 Pazartesi 23:33
To: radiator@open.com.au
Subject: Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

On 11/19/2012 10:13 AM, Murat Bilal wrote:

> 

> GroupMemberAttr OSC-AVPAIR

Hello Murat,

note that you have set GroupMemberAttr to OSC-AVPAIR here.

> 
> 

>   AuthColumnDef 1, OSC-Group-Identifier, reply

Here you are adding OSC-Group-Identifier to the reply. Maybe this should be 
OSC-AVPAIR or alternatively you should have GropMemberAttr set to 
OSC-Group-Identifier in ServerTACACSPLUS.

Also, since you have not changed AuthSelect from the default, you should select 
it to something like

  AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS

and define
  AuthColumnDef 0, User-Password, check
  AuthColumnDef 1, OSC-Group-Identifier, reply

This will check the request password and and the desired group name to reply if 
password check succeeds.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server anywhere. 
SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, 
TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, 
RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, 
Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

2012-11-19 Thread Heikki Vatiainen

On 11/20/2012 09:18 AM, Murat Bilal wrote:

> AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS
> and define
>   AuthColumnDef 0, User-Password, check
>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> I got ERR: Execute failed for 'select PASSWORD,TACACSGROUPID from 
> SUBSCRIBERS': Unknown column 'TACACSGROUPID' in 'field list'
> 
> In my Subscribers table there is no column like this.Do I need to change 
> mysql schema ?

Yes. That was just a configuration example of how to get values to reply
attributes from SQL. Your DB table needs to have the appropriate columns
too.

Thanks,
Heikki


> -Original Message-
> From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
> Behalf Of Heikki Vatiainen
> Sent: 19 Kasım 2012 Pazartesi 23:33
> To: radiator@open.com.au
> Subject: Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule
> 
> On 11/19/2012 10:13 AM, Murat Bilal wrote:
> 
>> 
> 
>> GroupMemberAttr OSC-AVPAIR
> 
> Hello Murat,
> 
> note that you have set GroupMemberAttr to OSC-AVPAIR here.
> 
>> 
>> 
> 
>>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> Here you are adding OSC-Group-Identifier to the reply. Maybe this should be 
> OSC-AVPAIR or alternatively you should have GropMemberAttr set to 
> OSC-Group-Identifier in ServerTACACSPLUS.
> 
> Also, since you have not changed AuthSelect from the default, you should 
> select it to something like
> 
>   AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS
> 
> and define
>   AuthColumnDef 0, User-Password, check
>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> This will check the request password and and the desired group name to reply 
> if password check succeeds.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen 
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, 
> PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full 
> source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 


-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

2012-11-19 Thread Murat Bilal

After changing my schema.I insert a user murat with passw murat and  
TACACSGROUPID group3.Debug gets crazy.Endless loop as shown below:

Radius::AuthSQL REJECT: Bad Password: DEFAULT4303 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Query to 'dbi:mysql:radius:localhost': 'select 
PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL looks for match with 
DEFAULT4304 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL REJECT: Bad Password: 
DEFAULT4304 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Query to 'dbi:mysql:radius:localhost': 'select 
PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL looks for match with 
DEFAULT4305 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL REJECT: Bad Password: 
DEFAULT4305 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Query to 'dbi:mysql:radius:localhost': 'select 
PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL looks for match with 
DEFAULT4306 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL REJECT: Bad Password: 
DEFAULT4306 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Query to 'dbi:mysql:radius:localhost': 'select 
PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL looks for match with 
DEFAULT4307 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL REJECT: Bad Password: 
DEFAULT4307 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Query to 'dbi:mysql:radius:localhost': 'select 
PASSWORD,TACACSGROUPID from SUBSCRIBERS': 
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL looks for match with 
DEFAULT4308 [murat]
Tue Nov 20 09:52:31 2012: DEBUG: Radius::AuthSQL REJECT: Bad Password: 
DEFAULT4308 [murat]^C

-Original Message-
From: Heikki Vatiainen [mailto:h...@open.com.au] 
Sent: 20 Kasım 2012 Salı 09:21
To: Murat Bilal
Cc: radiator@open.com.au
Subject: Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

On 11/20/2012 09:18 AM, Murat Bilal wrote:

> AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS and define
>   AuthColumnDef 0, User-Password, check
>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> I got ERR: Execute failed for 'select PASSWORD,TACACSGROUPID from 
> SUBSCRIBERS': Unknown column 'TACACSGROUPID' in 'field list'
> 
> In my Subscribers table there is no column like this.Do I need to change 
> mysql schema ?

Yes. That was just a configuration example of how to get values to reply 
attributes from SQL. Your DB table needs to have the appropriate columns too.

Thanks,
Heikki


> -Original Message-
> From: radiator-boun...@open.com.au 
> [mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen
> Sent: 19 Kasım 2012 Pazartesi 23:33
> To: radiator@open.com.au
> Subject: Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule
> 
> On 11/19/2012 10:13 AM, Murat Bilal wrote:
> 
>> 
> 
>> GroupMemberAttr OSC-AVPAIR
> 
> Hello Murat,
> 
> note that you have set GroupMemberAttr to OSC-AVPAIR here.
> 
>> 
>> 
> 
>>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> Here you are adding OSC-Group-Identifier to the reply. Maybe this should be 
> OSC-AVPAIR or alternatively you should have GropMemberAttr set to 
> OSC-Group-Identifier in ServerTACACSPLUS.
> 
> Also, since you have not changed AuthSelect from the default, you 
> should select it to something like
> 
>   AuthSelect select PASSWORD,TACACSGROUPID from SUBSCRIBERS
> 
> and define
>   AuthColumnDef 0, User-Password, check
>   AuthColumnDef 1, OSC-Group-Identifier, reply
> 
> This will check the request password and and the desired group name to reply 
> if password check succeeds.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen 
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, 
> PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full 
> source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 


--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server anywhere. 
SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, 
TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, 
RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, 
Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

[RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] SQL Timeout

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

Re: [RADIATOR] group DEFAULT. No matching AuthorizeGroup rule

14 matches

Site Navigation

Mail list logo

Footer information