(RADIATOR) Newbie check items question....
The past few weeks have been a self-help course in Radius for me. When I came on board here at Techcom roughly a year and a half ago, I was hired on as a help desk rep. In that time, I have moved up to the position of system/network administrator. Suffice it to say that one of my stengths is that I am a quick learner. It doesn't hurt, either that I very much enjoy what I do. A lot of the systems that were in place when I came here were...well, for lack of a better term, bubble gum and duct taped together. I am slowly getting in order areas that have been neglected over time. One of the largest areas of neglect has been our Radius authentication, which is currently being handled by an NT server with one foot in the digital grave running 3Com SA. Up to now, RADIUS has been an area I have not had to deal with much at all. If RADIUS starts acting screwy, just reboot the machine and hope it comes back up. Last week's east-coast "blizzard" afforded me some time at home without ringing telephones and other distractions to work a bit on getting Radiator cofigured, as well as hammering out the necessary code to get RODOPI managing the MySQL database that will back Radiator. In looking over the examples in /goodies, the documenation regarding AuthBy SQL and the example database created with mysqlCreate.sql, I am a bit confused over one issue. How do "check attributes" come into during a RADIUS authentication? Again, I am a bit new to RADIUS and do not yet have a full grasp on the protocol. As I understand it, the NAS send a RADIUS request to the RADIUS server consisting of an encrypted username and password. That username and password is checked against an authentication database of some type and is either rejected or athenticated. An authentication is accompanied by attributes that give the NAS certain configuration parameters for that particular session. This brings me to ask the question, "Where do "check attributes" come into play." I assume these "check attributes" are sent by the NAS? But, what determines their value? Do I need to implement any "check attributes" in my config? How will I know if I do? At present, our needs are pretty basic and straight forward: - one 3Com Total Control hub - one domain - mostly 56K dialups, but a handfull of ISDN centrexes rolling in which require static IPs and no timeouts Thanks in advance to anyone who can offer an explanation and/or point me in the right direction here. -Danny === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Newbie check items question....
Hello Danny - On Wed, 02 Feb 2000, Danny Whitesel wrote: In looking over the examples in /goodies, the documenation regarding AuthBy SQL and the example database created with mysqlCreate.sql, I am a bit confused over one issue. How do "check attributes" come into during a RADIUS authentication? Again, I am a bit new to RADIUS and do not yet have a full grasp on the protocol. As I understand it, the NAS send a RADIUS request to the RADIUS server consisting of an encrypted username and password. That username and password is checked against an authentication database of some type and is either rejected or athenticated. An authentication is accompanied by attributes that give the NAS certain configuration parameters for that particular session. This brings me to ask the question, "Where do "check attributes" come into play." I assume these "check attributes" are sent by the NAS? But, what determines their value? Do I need to implement any "check attributes" in my config? How will I know if I do? At present, our needs are pretty basic and straight forward: - one 3Com Total Control hub - one domain - mostly 56K dialups, but a handfull of ISDN centrexes rolling in which require static IPs and no timeouts Check attributes do not necessarily have to be present in the incoming radius request, although they can be if a user is trying to telnet into a box for example, or dialling in to a particular phone number. Other check attributes from Radiator's point of view could be the number of concurrent channels the user is allowed to dial up, the time of day that he is allowed to dial up, etc. Have a look at section 13.1 in the Radiator 2.14.1 reference manual for a discussion on check items. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
