I've been told by Merit Radius users that the the port limit=1 in the
users file limits that user to only one login per portmaster. IN a site
that supports multiple portmasters even that method of concurrent login
control is unacceptable. Myself, I'm a Livingston Radius user. Haven't
really had the urge to try Merit or Ascends(?) version.
> Charging them for the extra account will only make them stop.
> What main-stream terminal servers do not support RADIUS? Any NAS that
> I would use must, or its not a choice.
Hmmm...telebit is a holdover that we're currently using. So..are you
suggesting that an isp must all of a sudden replace all of its older
terminal servers to convert to radius? If so, economics are going to
dictate and in most cases its simply not going to happen. We're currently
in the process of switching the ciscos to radius. It sounds as if you're
just entering into the market. Radius is a fairly new scheme... I think
its entered into the limelight within the last year maybe last year and a
half. I may be worng but I think the very first version of radius was
released less than two years ago.. ISPs like ours have had to deal with
remote authentication for the last four years and longer.
> Are you suggesting the RADIUS server would poll the servers to verify?
> Is that why the latency would come into effect? I don't follow the
> latency errors issue?
No... I'm saying that if a code is implemented to check for concuirrent
logins that program would increase/decrease its response based by the
number of users online. The number of users online traditionally
increases from 4pm to 1am. The time it takes for the radius server to
individually poll and check each radius device would take too long during
busy hours. Theoretically the latency would force the radius device to use
the secondary authenticator.
>
> Hmmm At 10-to-1 thats 400 lines. If you have a 10% turnover per minute
Try 1 to 6..
> (which is pretty high) thats 40 authentications/minute or less than 1
> per second. If you are doing accounting on your authentcation server
> (I don't recommend it) then its times three, or 120/minute.
>
Hmmm... personal choicxe I guess. I'd rather have the radius device send
its accounting info to the authetication server. Saves on bandwidth usage
in long term also less chance of a security breach.
> With full concurrency control and port access control, RadiusNT running
> on
> a P100 w/40mb and SQL Server can authenticate (single thread) over 5
> authentications per second, or 300 authentications per minute (over what
> I
> guessed per minute for you). Multi-Threaded is only limited by the
> capacity of the RDBMS (more theads are not necessarily better).
Considering Microsoft puts a warning on its sql server packs about
drainage of resources by the sql server I have to say I don't believe
this. My own personal experience with NT server 4.0 4.1 3.5x has been
negative when it comes to system speed and usage percentages. Mainly
because nt is a gui. In a multiplatform, multiusage environment the
authentication server must be able to do more than just authenticate.
Then there's the programming aspects of nt. Which, quite frankly, suck.
but that's another story... suffice it to say I feel sorry for nt users.
>
> (If this performance looks poor to you, running in text mode, like
> most UNIX servers, RadiusNT auths ~20ms or around 50/second or
> 3000/minute).
>
> A background program walks the terminal servers and cleans up any
> mis-listed users. Since this is all Client/Server technology you can
> just put a couple more RadiusNT machines onto the network and spread
> your NAS load over them to really increase reliability. As you
> grow you can add clients to suport the load. Scaleability.
Sure... Figure in the cost. For what you spend in a couple of radiusNT
machines its not worth it. Scaleability id fine but remember you're in a
business. You can't just toss another machine on the circuit because of
load.
>
> The problem with everyone's login limiting schemes is that its
> based on a SINGLE server or some archaic directory/file layout to
> control users. Its not scaleable, has high latency, and inherent
> problems. Use a true RDBMS solution (where the RDMBS vendor has
> already solved all the problems you are trying to solve) and its
> MUCH simpler and works.
>
Sorry, but considering the response I have recieved by people with
multiple concurrent login problems your vendors solution is either not
working or you've misunderstood the nature of the problem.
> With that load you need a better machine or better RADIUS server.
> RadiusNT does NOT have this problem and we have customers with
> 10,000-20,000
Authentication is not the problem. Tracking concurrent logins during
authentication is the problem.
If you think NT is so good at handling this problem, I'm told Livingston
NT Radius source code is or will soon be avaliable. My challenge to you is
code a solution. I think then you'll have a better understanding of why NT
is really unprepared for wan management as well as you'll encounter some
of the problems wioth dealing in multi vendor authentication schemes. Its
nice to say, "Its not an option" but if you get hired by a company that
has a mix of everything and are told "Find a solution" then maybe you'll
understand.
> customers running very smoothly. No RADIUS server can ever do
> concurrency control accurately alone. It will always need something
> else.
Well finally we agree on something.
Rob