Hi all,
we are using more terminal servers (2x Patton2800,
3x Cisco, 2xTC HiPer, 2xTC NETCard)
all authorized by Merit Radius 3.6B starting
from about 3 years ago without problems.
Usernames and passwords (cca 4000) we have only
in radius "users" files separated by prefix
for each node. All used for PPP with PAP.
All was working OK until we want move from
plain text passwords to encrypted passwords
now. Seems to be easy - just change item
"Password=" to "Encrypted-Password="
and replace these password by encrypted ones.
I have changed it so (I have a script which
generate users files when needed from DB
so only little change in this script).
After this change - all these devices are
authorizing with encrypted passwords
without problems :-) - but TC :-(
HiPer TC - first authenticating no user call
at all... all authentications "FAILED".
As I find soon it was caused by configuration
authentication protocol = ANY and
authentication preference = DEFAULT,
I change it to =PAP, =PAP and now it seems to
be working...
NETCard TC - from begining was authenticating
OK but NIGHTMARES came after a few hours -
time to time radiusd started to answer all
authentication requests as FAILED (also requests
from non-TC nodes!). Only rescue from this state
was kill and start again of radiusd. This state
back again in time interval from a tens of second
to tens of minutes after re-starting radiusd.
Interesting also that radiusd accounting working
still without problems in this state and also
any user trying to login found in logfile -
but unfortunately as FAILED of course :-(.
When I next day check radiusd logfiles
and find some dependency on these 21 crashes
I found that every endless "FAILED" responses
started exclusively by FAILED login of 3 same
users on one of these our 2 TC Netcard nodes.
Also I found that these users have set
"using encrypted passwords" on they WinNT4
workstations or W95 (it means CHAP I thing).
What strange NETCard send to radiusd what
totaly confuse it???
So I try to change on NETCard PPP configuration
like on HiPer above (...=PAP,...=PAP).
After it I had tried by dialing from my
friend (WNT,W95 fan :-) new configuration
- esspecialy all these dirty CHAP,MS-CHAP
setups and try to confuse my radius. Result
of many dirty test setups seems to be a good
- on these dirty calls TC never send even
auth.request to radiusd at all and every call
ended by timeout for dialing client.
Also in logfile appeared change - there are
no more any entry about so dirty call, only
OK or FAILED of PAP authentications. But
next day after some hours radiusd blocked again!!!
Did anybody seen similar problem? What is
buggy working with encrypted passwords
and confusing - radius or NETcard?
Notice that with plain text passwords and NETCard
was never blocked into so state. Merit Radius 3.6B
compiled and runing on Linux RH6.1 with kernel
2.2.13. Also interesting that same version of
radius compiled and runing on Linux Slackware 3.5
kernel 2.0.35 working as "old backup radius"
never blocked - even using same "encrypted"
passwords. These 3 problematic users did not
block same radiusd on Slackware system!!!
Only FAILED and all was continue working
without blocking!!! But system is overall
old and I want to upgrade it :-( want not
to leave radiusd there. So maybe also
worst implementation of Merit radiusd on RH6.1
due to difference in system libraries etc...
Due to all other types of terminal servers
working with same configuration properly
I thing that there may be something
special on NETCard RADIUS protocol what Merit
radius cannot process properly and what
take place only in case when authenticating
encrypted passwords.
Are using someone other good-known,
recomended or better configuration?
On TC I have vendor extension disabled
and also in "clients" file NETCard nodes
presented only as NAT (should be better
USR:NAT?), radius version set to 1 on
both ends, USR_CCA in radiusd not compiled
- is all it right or may be better?
With plain passwords above was working good
for me but maybe now should be altered...
Any help welcomed!
Thanks :-)
Pavel
-
To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
