Hello Surajh, thanks for your note.
On Wed, 18 Dec 2002 20:15, Surajh Surjoo [ MTN Sandhurst ] wrote: > Unfortunatley, we make extensive use of default users as we do not care > what username or password the enduser enters, as long as he connects to our > server. We are a mobile cellular operator and allow users onto our > Ericsson GGSN on the Internet APN...payment is per kilobyte transferred and > we have the users MSISDN to bill. > > So Please DO NOT put a limit on the number of DEFAULT users, as this will > severly affect our operations! OK, we have instead added a new parameter DefaultLimit that allows you to impose a limit if you wish, but which defaults to no limit. OK? Cheers. > > thanks > > Surajh Surjoo > Systems Engineer - Data > Mobile: 0832129829 > Mobile Fax: 083 8 2129829 > Office Fax: 011 3018811 > Office Tel: 011 3016000 > [EMAIL PROTECTED] > > "Imagination is more important than Knowledge" - Albert Einstein > > > -----Original Message----- > From: Mike McCauley [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 18 December 2002 10:32 AM > To: Toomas K�rner; Hugh Irvine > Cc: [EMAIL PROTECTED] > Subject: Re: (RADIATOR) Bug? > > > Hello Toomas, > > On Wed, 18 Dec 2002 18:41, Toomas K�rner wrote: > > Hi all, > > > > Sorry, my bad .... > > I looked at the code, understanded it and looked at the manual again and > > realized that NoDefault is affective in case of REJECT and NOT only in > > case on Not found. That started my little snowball. Only real idea that > > grew out of this is that maybe $defaultNumber should have a limit. With > > my loop I created 52000 request's to SQL and I can't think a reason why > > someone should need so many defaults and would allow them in so big cost > > of load. I think 512 should by way enough. > > OK, we have added a limit of 512 DEFAULT users for the next release. > Thanks for the suggestion. > > Cheers. > > > Rgds and appologies. > > Toomas K�rner > > > > ----- Original Message ----- > > From: "Hugh Irvine" <[EMAIL PROTECTED]> > > To: "Toomas K�rner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Friday, December 13, 2002 11:50 PM > > Subject: Re: (RADIATOR) Bug? > > > > > Hello Toomas - > > > > > > The fundamental issue is the architecture of Radiator itself and > > > specifically the AuthBy clauses, all of which fundamentally implement a > > > "find_user" routine which is why you see the problem that you do. > > > > > > You are correct that what I show below is a workaround, ie. the first > > > AuthBy uses a couple of DEFAULT entries so that "find_user" works, then > > > passes off the request using the Auth-Type construct to an AuthBy > > > clause in which you can do anything you like. > > > > > > The extra processing overhead is minimal, as the AuthBy FILE will cache > > > the DEFAULT lines in memory and will simply do a couple of memory > > > lookups. > > > > > > I encourage you to have a look at the code in "Radius/AuthGeneric.pm" > > > and "Radius/AuthSQL.pm" to see what goes on. > > > > > > I have also copied this mail to Mike for his additional comments. > > > > > > regards > > > > > > Hugh > > > > > > > > > On Friday, Dec 13, 2002, at 22:26 Australia/Melbourne, Toomas K�rner > > > > > > wrote: > > > > Hi, > > > > > > > > So, AuthBy's like: > > > > ######################################## > > > > <AuthBy SQL> > > > > Identifier AuthBlacklistCheck > > > > DBSource dbi:mysql: > > > > DBUsername > > > > DBAuth > > > > AuthSelect select MACADDRESS, REPLYMESSAGE from macblacklist where \ > > > > MACADDRESS like '%{Calling-Station-Id}' and \ > > > > ACTIVE = 'Yes' > > > > > > > > AuthColumnDef 0, Service-Type,check > > > > AuthColumnDef 1, Reply-Message,reply > > > > > > > > NoDefault > > > > AcceptIfMissing > > > > </AuthBy> > > > > ######################################## > > > > and > > > > ######################################## > > > > <AuthBy SQL> > > > > Identifier AuthUser > > > > DBSource dbi:mysql: > > > > DBUsername > > > > DBAuth > > > > > > > > AuthSelect select ACTIVE, WNACCESS, CHECKATTR, PASSWORD,\ > > > > REPLYATTR \ > > > > from xxxxxx where USERNAME ='%n' > > > > > > > > AuthColumnDef 0, ETC-Admin-Active, check > > > > AuthColumnDef 1, ETC-Admin-Wireless, check > > > > AuthColumnDef 2, GENERIC, check > > > > AuthColumnDef 3, User-Password, check > > > > AuthColumnDef 4, GENERIC, reply > > > > > > > > DefaultSimultaneousUse 1 > > > > NoDefault > > > > RejectEmptyPassword > > > > > > > > AccountingTable log > > > > AcctColumnDef DATE,Timestamp ,formatted-date,'%Y-%m-%d' > > > > . > > > > . > > > > . > > > > </AuthBy> > > > > ######################################## > > > > and realm like > > > > ######################################## > > > > <Realm admin> > > > > RewriteUsername s/^([^@]+).*/$1/ > > > > AuthByPolicy ContinueUntilReject > > > > AuthBy AuthBlacklistCheck > > > > AuthBy AuthUser > > > > </Realm admin> > > > > ######################################## > > > > is impossible because AuthBlacklistCheck has nothing to do with > > > > usernames > > > > and that freaks it out to go to loop with DEFAULT? I think that this > > > > is more > > > > than configuration issue and configuration that you gave me is more > > > > like a > > > > workaround that probably takes more load. If this is true that if no > > > > such > > > > thing as username is received from sql results in a new query with > > > > default > > > > username then it is impossible to use radiator for authentication of > > > > layer > > > > 2. If you are confused what I mean by Layer 2 authentication, this is > > > > checking layer 2 information for given request and if that succeeds > > > > then go > > > > forward with username authentication. > > > > > > > > Also from the Archive: 17. oct. 2002 to [EMAIL PROTECTED] you said: > > > > { > > > > The reason for doing it this way is because the AuthBy processing is > > > > looking for a user, which the AuthBy SQL clause is not doing. > > > > } > > > > I don't want to do anything with user in that AuthBy, I just want to > > > > verify > > > > 2L information. Is that a limitation in Radiator? > > > > > > > > Rgds. > > > > Toomas > > > > > > > > ----- Original Message ----- > > > > From: "Hugh Irvine" <[EMAIL PROTECTED]> > > > > To: "Toomas K�rner" <[EMAIL PROTECTED]> > > > > Cc: <[EMAIL PROTECTED]> > > > > Sent: Friday, December 13, 2002 12:59 AM > > > > Subject: Re: (RADIATOR) Bug? > > > > > > > >> Hello Toomas - > > > >> > > > >> This is not a bug really - it is more a configuration issue. > > > >> > > > >> The problem that you show below is due to the fact that the AuthBy > > > >> is looking for the username, and you are overriding it to look for > > > >> something else. This leads to the AuthBy continuing to look for > > > >> DEFAULT... . > > > >> > > > >> The correct way to build a configuration file to do blacklist > > > >> checking is to use cascaded AuthBy clauses. > > > >> > > > >> Something like this: > > > >> > > > >> # define AuthBy clauses > > > >> > > > >> <AuthBy SQL> > > > >> Identifier CheckMACAddress > > > >> ...... > > > >> </AuthBy> > > > >> > > > >> <AuthBy FILE> > > > >> Identifier CheckBlacklist > > > >> Filename %D/blacklist > > > >> </AuthBy> > > > >> > > > >> ...... > > > >> > > > >> # define Realms or Handlers > > > >> > > > >> <Realm ...> > > > >> AuthByPolicy ContinueWhileAccept > > > >> ..... > > > >> AuthBy CheckBlacklist > > > >> ..... > > > >> </Realm> > > > >> > > > >> ..... > > > >> > > > >> The SQL table would contain something like this: > > > >> > > > >> MACADDRESS ACTION > > > >> nn.nn.nn.nn.nn.nn Auth-Type = Reject > > > >> oo.oo.oo.oo.oo.oo Auth-Type = Reject > > > >> > > > >> ..... > > > >> > > > >> The file "blacklist" would contain this: > > > >> > > > >> # blacklist > > > >> > > > >> DEFAULT Auth-Type = CheckMACAddress > > > >> > > > >> DEFAULT Auth-Type = Accept > > > >> > > > >> This topic has been discussed on the list many times, so check the > > > >> archive if you are interested. > > > >> > > > >> www.open.com.au/archives/radiator > > > >> > > > >> regards > > > >> > > > >> Hugh > > > >> > > > >> > > > >> On Thursday, Dec 12, 2002, at 21:38 Australia/Melbourne, Toomas > > > >> K�rner > > > >> > > > >> wrote: > > > >>> Hi > > > >>> > > > >>> When I have config like: > > > >>> > > > >>> <Realm plah> > > > >>> AuthByPolicy ContinueUntilReject > > > >>> AuthBy Identifier_of_some_authby_that_gives_reject > > > >>> <AuthBy SQL> > > > >>> plahplah > > > >>> </AuthBy> > > > >>> </Realm plah> > > > >>> > > > >>> This kind a conf results loop in > > > >>> Identifier_of_some_authby_that_gives_reject > > > >>> and never goes to AuthBy SQL. > > > >>> > > > >>> debug 4 of such config (it had other problems as well but it > > > >>> shouldnt have > > > >>> gone to loop because MACADDRESS like '00-50-04-E8-B4-AF' was > > > >>> found). > > > >>> > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match > > > >>> with DEFAULT52061 > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item > > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match > > > >>> 'Login-User' in > > > >>> request > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS, > > > >>> REPLYMESSAGE > > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and > > > >>> ACTIVE > > > >>> = > > > >>> 'Yes' > > > >>> > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match > > > >>> with DEFAULT52062 > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item > > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match > > > >>> 'Login-User' in > > > >>> request > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS, > > > >>> REPLYMESSAGE > > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and > > > >>> ACTIVE > > > >>> = > > > >>> 'Yes' > > > >>> > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match > > > >>> with DEFAULT52063 > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item > > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match > > > >>> 'Login-User' in > > > >>> request > > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS, > > > >>> REPLYMESSAGE > > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and > > > >>> ACTIVE > > > >>> = > > > >>> 'Yes' > > > >>> > > > >>> Anyway I think it would be good idea to add a keyword RejectIfFound > > > >>> to > > > >>> features for blacklist buliding pruposes. > > > >>> > > > >>> Rgds. > > > >>> Toomas K�rner > > > >>> > > > >>> === > > > >>> 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. > > > > > > > > === > > > > 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. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 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 etc on Unix, Windows, MacOS etc. === 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.
