Re: (RADIATOR) Configuration info for radiator when using mysql
Hello Gopi - On Fri, 12 Apr 2002 14:46, Gopi Krishna wrote: Hello Hugh, Thank you for your help. I am not successful in testing the radius with mysql. I am new to both Perl and mysql. According to the manual, 1)I have Active state Perl in my Windows 2000 server system, 2)Installed DBI(Installed the Active state PPM package), 3)Installed DBM (Installed the Active state PPM package)and 4)mysql(3.23.49-win version) This all sounds fine. I created radius database in mysql. Both radiator and mysql are in the same system. When I try to invoke radiator from command prompt I am getting the error Access Denied which is pasted at the end of this mail.I am giving the sql.cfg as the config file for radiator i.e perl radiusd -config_file goodies\sql.cfg Is it correct??? There are two different things you have to be aware of. The first is the user and password that is the administrative user that is allowed to connect to the database. This must be configured in the MySQL server and is referenced in the Radiator configuration file in the DBUsername and DBAuth lines. The second is the contents of the SUBSCRIBERS table that is used to hold the user definitions for the users that are connecting to your NAS(s). The contents of the SUBSCRIBERS table needs to be maintained either by your own applications, or by our Radmin product, or you can use a third party billing system. Our setup is like this.We have devices with radius client which needs to be authenticated by radius server.These users are of the Service-Type = Login-User.It is in the standard radius packet format. Understood. I have few doubts: 1)How we create the users at mysql database??? Just by using Grant command or do we need to enter all the users in table? See above. 2)In doc/ref.html :23.3 mentioned: Use buildsql like this: buildsql -dbsource dbi:mysql:database -dbusername radius -dbauth password what for this? When I tried at mysql prompt it is giving error. The buildsql utility is a stand alone program that allows you to load a UNIX password file, or a standard radius users file into the SUBSCRIBERS table. Have a look at section 10 in the Radiator 3.0 reference manual. (doc/ref.html). 3)How can we invoke the radiator with both the configuration file and mysql. The Radiator configuration file contains the relevant information for connecting to the database in the DBSource, DBUsername and DBAuth statements in the AuthBy SQL clause. 4)what configuration is to be changed if radiator and mysql are in different systems. The DBSource line mentioned above simply needs to include the host to connect to - something like this: dbi:mysql[:database[:hostname[:port]]] I created the user radius with password password in mysql using grant command. I am enclosing the files sql.cfg and mysqlcreate. Could you please enlighten me bit datailed about this and correct me. As mentioned previously, please read through the Radiator reference manual at least once and have a look at the examples. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) creative AUTHBY SQLRADIUS?
maybe this isn't that creative, but i cannot seem to get the logic to
work. I have an AUTHBY RADIUS that works perfectly. However, it is too
slow. To make it faster Hugh told me to try the AUTHBY SQLRADIUS idea, and
so here I am.
I need an AUTHBY SQLRADIUDS / HostSelect that will be able to handle the
AUTHBY RADIUS below:
AuthBy RADIUS
Identifier CheckRemoteRadius
IgnoreAccounting
IgnoreReplySignature
ServerHasBrokenAddresses
RejectEmptyPassword
NoForwardAccounting
NoDefault
#USERNAME = username
#PASSWORD = password
Host xxx.xxx.xxx.xxx
Secret
AuthPort 1812
Retries 3
RetryTimeout 20
/Host
# FAILOVER SERVER
Host xxx.xxx.xxx.xxx
Secret
AuthPort 1812
Retries 3
RetryTimeout 20
/Host
ReplyHook file:/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy
# FILTER NAME: STATIC-ALLOW
AllowInReply Framed-IP-Address,Session-Timeout,Ascend-Data-Filter,Idle-Timeout
AddToReply
Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Netmask=255.255.255.255
/AuthBy
I have been able to get some information from the radiator documentation
and I have gotten this far:
AuthBy SQLRADIUS
Identifier CheckRemoteRadius
IgnoreAccounting
IgnoreReplySignature
ServerHasBrokenAddresses
RejectEmptyPassword
NoForwardAccounting
NoDefault
NumHosts 4
HostSelect select TARGET_%0_AUTH, SHARED_SECRET, PORT, RETRIES,
TIMEOUT from PROXY2 where TARGET_%0_AUTH and DNIS=
substring('%{Called-Station-Id',7,4) and REALM='' and STATUS=1;
replyHook
file:/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy
/AuthBy
However, I run across a couple problems:
1) When I restart radius I get this error: WARNING: No Hosts defined for
Radius::AuthSQLRADIUS at /etc/radius.cfg line 120. Did I forget
something? I am assuming I Need to tell the AUTHBY SQLRADIUS what database
to use...
2) Can I dynamically load the IP address that is allocated based on the
replyHook? Currently the IP address is allocated via the Handler. I need
a way to pick the IP address out of different pools in the AUTHBY SQLRADIUS.
3) Can I dynamically load the AllowInReply and AddToReply attributes? As
you see in the first AUTHBY RADIUS the attributes are there. However, in
the AUTHBY SQLRADIUS they are not. They would need to be assigned by the DNIS.
Any help would be greatly appreciated.
katen
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Ascend-Access-Event-Request.
Lately I have been getting an increase in these logs. Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring I know what the problem is, however the answer to the problem is alluding me very well. These are not ACCT, or AUTH packets. If they were, they would have a UserID by them. These do no. Doing more investigation, I find that all requests that have this problem are Code: Ascend-Access-Event-Request. I get these logs in my Radius Proxy servers (Prxy1, Prxy2). The proxy servers talk with two other Radiator machines. (AAA1, and AAA2) For the actual Auth, and Acct. These logs are from my prxy1 machine. Prxy2 logs very similar. Fri Apr 12 11:33:51 2002: DEBUG: Packet dump: *** Received from XXX.XXX.XXX.XXX port 7023 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:21 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:21 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2:1812 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring As we can see the Prxy's are working correctly. They did not receive a reply, so they retransmitted 5 times. Just what I have configured. Then it drops the packet, with no working host found. My Question is this. How can I get my Radiator AAA1, and AAA2 to listen to these requests. Right now the Prxy1, and Prxy2 listen, but the AAA's will not pick these requests up. There are no logs in AAA1, or AAA2 of this request even getting to them All four servers are at 2.19. The only thing I can think of, is Dictionary. I use a pure Ascend2 dictionary on the Prxy's, and a combination of Default Dictionary,Ascend2, and Cisco. on the AAA machines. Could this be my problem? Do I need the entire Ascned2 dictionary on the AAA's? Am I missing something? Any help is appreciated. Thanks Cortney Cortney Thompson [EMAIL PROTECTED] Opinions are mine and do not necessarily reflect those of wyoming.com LLC === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Ascend-Access-Event-Request.
It looks like the problem is that your servers AAA1 and AAA2 do not know what to do with an Ascend-Access-Event-Request. I found this explanation of the Ascend-Access-Event-Request on the web by doing a quick Google search: .. Ascend-Access-Event-Request (33) The MAX TNT can report the number of sessions by class to the RADIUS authentication server and to the RADIUS accounting server. The MAX TNT reports the number of sessions by sending an Ascend-Access-Event-Request (33) packet type at a user-defined interval specified by one of the following parameters: Auth-Sess-Interval in the Rad-Auth-Client subprofile of the External-Auth profile Acct-Sess-Interval in the Rad-Acct-Client subprofile of the External-Auth profile ... Since this just looks like extra accounting data that you have obviously been living without I would deal with it by using a handler clause at Prxy1 and Prxy2 that looks something like this: Handler Code=Ascend-Access-Event-Request AuthBy INTERNAL DefaultResultACCEPT /AuthBy /Handler Handler AuthBy RADIUS Secret somesecret Host AAA1 Host AAA2 /AuthBy /Handler You could change the DefaultResult to IGNORE or REJECT at your option. = Original Message From Cortney Thompson [EMAIL PROTECTED] = Lately I have been getting an increase in these logs. Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring I know what the problem is, however the answer to the problem is alluding me very well. These are not ACCT, or AUTH packets. If they were, they would have a UserID by them. These do no. Doing more investigation, I find that all requests that have this problem are Code: Ascend-Access-Event-Request. I get these logs in my Radius Proxy servers (Prxy1, Prxy2). The proxy servers talk with two other Radiator machines. (AAA1, and AAA2) For the actual Auth, and Acct. These logs are from my prxy1 machine. Prxy2 logs very similar. Fri Apr 12 11:33:51 2002: DEBUG: Packet dump: *** Received from XXX.XXX.XXX.XXX port 7023 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:21 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:21 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2:1812 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring As we can see the Prxy's are working correctly. They did not receive a reply, so they retransmitted 5 times. Just what I have configured. Then it drops the packet, with no working host found. My Question is this. How can I get my Radiator AAA1, and AAA2 to listen to these requests. Right now the Prxy1, and Prxy2 listen, but the AAA's will not pick these requests up. There are no logs in AAA1, or AAA2 of this request even getting to them All four servers are at 2.19. The only thing I can think of, is Dictionary. I use a pure Ascend2 dictionary on the Prxy's, and a combination of Default Dictionary,Ascend2, and Cisco. on the AAA machines. Could this be my problem? Do I need the entire Ascned2 dictionary on the AAA's? Am I missing something? Any help is appreciated. Thanks Cortney Cortney Thompson [EMAIL PROTECTED] Opinions are mine and do not necessarily reflect those of wyoming.com LLC === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To
Re: (RADIATOR) Ascend-Access-Event-Request.
Hello Frank, Hello Cortney - You should probably use DefaultResult ACCEPT, otherwise the NAS will continue to send the requests over an over again. regards Hugh On Sat, 13 Apr 2002 07:13, Frank Danielson wrote: It looks like the problem is that your servers AAA1 and AAA2 do not know what to do with an Ascend-Access-Event-Request. I found this explanation of the Ascend-Access-Event-Request on the web by doing a quick Google search: .. Ascend-Access-Event-Request (33) The MAX TNT can report the number of sessions by class to the RADIUS authentication server and to the RADIUS accounting server. The MAX TNT reports the number of sessions by sending an Ascend-Access-Event-Request (33) packet type at a user-defined interval specified by one of the following parameters: Auth-Sess-Interval in the Rad-Auth-Client subprofile of the External-Auth profile Acct-Sess-Interval in the Rad-Acct-Client subprofile of the External-Auth profile ... Since this just looks like extra accounting data that you have obviously been living without I would deal with it by using a handler clause at Prxy1 and Prxy2 that looks something like this: Handler Code=Ascend-Access-Event-Request AuthBy INTERNAL DefaultResultACCEPT /AuthBy /Handler Handler AuthBy RADIUS Secret somesecret Host AAA1 Host AAA2 /AuthBy /Handler You could change the DefaultResult to IGNORE or REJECT at your option. = Original Message From Cortney Thompson [EMAIL PROTECTED] = Lately I have been getting an increase in these logs. Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring I know what the problem is, however the answer to the problem is alluding me very well. These are not ACCT, or AUTH packets. If they were, they would have a UserID by them. These do no. Doing more investigation, I find that all requests that have this problem are Code: Ascend-Access-Event-Request. I get these logs in my Radius Proxy servers (Prxy1, Prxy2). The proxy servers talk with two other Radiator machines. (AAA1, and AAA2) For the actual Auth, and Acct. These logs are from my prxy1 machine. Prxy2 logs very similar. Fri Apr 12 11:33:51 2002: DEBUG: Packet dump: *** Received from XXX.XXX.XXX.XXX port 7023 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA1 port 1812 Code: Ascend-Access-Event-Request Identifier: 25 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:21 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA1 for (25) Fri Apr 12 11:34:21 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting Fri Apr 12 11:34:26 2002: DEBUG: Packet dump: *** Sending to AAA2 port 1812 Code: Ascend-Access-Event-Request Identifier: 1 Authentic: 15\2001637218=179u~0166233[211214 Attributes: NAS-IP-Address = XXX.XXX.XXX.XXX Port_Entry = 0001 Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5 retransmissions to AAA2:1812 for (1) Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working host to forward to. Ignoring As we can see the Prxy's are working correctly. They did not receive a reply, so they retransmitted 5 times. Just what I have configured. Then it drops the packet, with no working host found. My Question is this. How can I get my Radiator AAA1, and AAA2 to listen to these requests. Right now the Prxy1, and Prxy2 listen, but the AAA's will not pick these requests up. There are no logs in AAA1, or AAA2 of this request even getting to them All four servers are at 2.19. The only thing I can think of, is Dictionary. I use a pure Ascend2 dictionary on the Prxy's, and a combination of Default Dictionary,Ascend2, and Cisco. on the AAA machines. Could this be my problem? Do I need the entire
Re: (RADIATOR) creative AUTHBY SQLRADIUS?
Hello Steve -
I think you have misunderstood my suggestion. Using an AuthBy SQLRADIUS
clause will not speed up proxy operation - this is determined by the length
of time a given proxy target takes to respond. You question was whether there
was some way to speed up the evaluation of a long list of Handlers based on
Called-Station-Id, and my suggestions were to investigate either the AuthBy
SQLRADIUS clause, or the CalledStationId.pm module (contained in the goodies
directory). You will have to do some testing to ascertain whether or not
either of these will speed up the overall operation. I suggest you try a
simple example using the default configuration to see how long it takes
compared to your current setup.
In answer to your questions below,
1. you can specify a default host in the AuthBy SQLRADIUS clause - this is
just a warning, not an error
yes you need to specify the database with the usual DBSource, DBUsername and
DBSource lines
For the other questions, I think you need to do the testing described above
first to see whether or not the idea is worth pursuing.
regards
Hugh
On Sat, 13 Apr 2002 02:11, Steve Katen wrote:
maybe this isn't that creative, but i cannot seem to get the logic to
work. I have an AUTHBY RADIUS that works perfectly. However, it is too
slow. To make it faster Hugh told me to try the AUTHBY SQLRADIUS idea, and
so here I am.
I need an AUTHBY SQLRADIUDS / HostSelect that will be able to handle the
AUTHBY RADIUS below:
AuthBy RADIUS
Identifier CheckRemoteRadius
IgnoreAccounting
IgnoreReplySignature
ServerHasBrokenAddresses
RejectEmptyPassword
NoForwardAccounting
NoDefault
#USERNAME = username
#PASSWORD = password
Host xxx.xxx.xxx.xxx
Secret
AuthPort 1812
Retries 3
RetryTimeout 20
/Host
# FAILOVER SERVER
Host xxx.xxx.xxx.xxx
Secret
AuthPort 1812
Retries 3
RetryTimeout 20
/Host
ReplyHook
file:/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy # FILTER
NAME: STATIC-ALLOW
AllowInReply
Framed-IP-Address,Session-Timeout,Ascend-Data-Filter,Idle-Timeout
AddToReply
Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Netmask=255.255.255.255
/AuthBy
I have been able to get some information from the radiator documentation
and I have gotten this far:
AuthBy SQLRADIUS
Identifier CheckRemoteRadius
IgnoreAccounting
IgnoreReplySignature
ServerHasBrokenAddresses
RejectEmptyPassword
NoForwardAccounting
NoDefault
NumHosts 4
HostSelect select TARGET_%0_AUTH, SHARED_SECRET, PORT, RETRIES,
TIMEOUT from PROXY2 where TARGET_%0_AUTH and DNIS=
substring('%{Called-Station-Id',7,4) and REALM='' and STATUS=1;
replyHook
file:/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy
/AuthBy
However, I run across a couple problems:
1) When I restart radius I get this error: WARNING: No Hosts defined for
Radius::AuthSQLRADIUS at /etc/radius.cfg line 120. Did I forget
something? I am assuming I Need to tell the AUTHBY SQLRADIUS what database
to use...
2) Can I dynamically load the IP address that is allocated based on the
replyHook? Currently the IP address is allocated via the Handler. I need
a way to pick the IP address out of different pools in the AUTHBY
SQLRADIUS. 3) Can I dynamically load the AllowInReply and AddToReply
attributes? As you see in the first AUTHBY RADIUS the attributes are
there. However, in the AUTHBY SQLRADIUS they are not. They would need to
be assigned by the DNIS.
Any help would be greatly appreciated.
katen
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Platypus; AuthEMERALD; HonourServerPortAccess
We have recently decided to restrict logins on a particular RAS to ISDN
only.
Within our Realm using AuthBy EMERALD I added the HonourServerPortAccess
flag.
It appears that Radiator runs the PortAccessQuery (see AuthEMERALD.pm) and
either returns nothing (the users AccountType is not matched in the Server
Access table) or in our case returns a single row (the users AccountType is
ISDN and thus a row is returned)
The problem (well, not since I applied my crappy patch) is that when the row
returns nothing it still lets them on. We verified that the query returns
what we expect (either one row or no rows), running the query locally on our
M$SQL server. I eventually did this:
# diff AuthEMERALD.pm AuthEMERALD.pm.ORIGINAL
68a69
and sa.Port=%0
209,211d209
} else {
$self-log($main::LOG_DEBUG, ERROR Login Restricted By
ServerAccess);
return undef;
Removing the sa.Port=%0 is semi-irrelevant (I think), that just says we
don't really ever care about the NAS-Port
But why am I needing to add the else log it then return undef in? When I
looked at the code I assumed that line 185 (of the original code, release
3.0) should be doing that.
Any ideas?
Steve Brown
[EMAIL PROTECTED]
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
