[Emerald] "CHAP"?

Andrew Stinson ( (no email) )
Wed, 4 Aug 1999 09:16:29 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01BEDE5A.08F2B7E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We recently set RADIUS auth. to ODBC only and noticed a rise in the =
number of "Bad password" (under description) and also noticed "CHAP" as =
the data for most of these in RadLog. Is this common? If so, what does =
it mean?

Also, we have noticed that we can have a username duplicated in Emerald =
(i.e. a PPP named joeuser and an e-mail joeuser@a_different_domain =
e-mail account) and the PPP account will sometimes work. There doesn't =
seem to be a pattern to the authentication, except that in peak times, =
or times where clean-up is being run on the database, it doesn't seem to =
be able to auth. If anyone's found out why/how this works, and if it =
could be fixed to be more stable, let us know. We have a lot of dup =
users with e-mails in different domains, and don't want to have to =
change the PPP accounts so they can connect. (Just to make sure i'm =
clear on this, the e-mails work fine, it's just the PPP account having =
trouble).

One more thing <G>, we are trying to get a disaster recovery plan =
together should our server/database crash. We are running SQL 7.0 and =
have tried restoring sample databases on a different server, but have =
had no luck. The other server just doesn't recognize the backup set. =
How does everything else backup and restore their SQL databases? =
(Restore it to a completely new server, not on the same server). Any =
help would be greatly appreciated and would help us sleep a whole lot =
easier!

TIA
-------------------------------------------------------------------------=
---------------------------------------------
Andrew Stinson Apex 2000 Internet Services =
Corporation =20
mailto:astinson@apex2000.net http://www.apex2000.net (915) 570-1676
-------------------------------------------------------------------------=
---------------------------------------------

------=_NextPart_000_0035_01BEDE5A.08F2B7E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

We recently set RADIUS auth. to ODBC only and =noticed a rise=20in the number of "Bad password" (under description) and also noticed=20"CHAP" as the data for most of these in RadLog.  Is this =common? If=20so, what does it mean?
 
Also, we have noticed that we can have a username =duplicated=20in Emerald (i.e. a PPP named joeuser and an e-mail =joeuser@a_different_domain=20e-mail account) and the PPP account will sometimes work.  There =doesn't=20seem to be a pattern to the authentication, except that in peak times, =or times=20where clean-up is being run on the database, it doesn't seem to be able =to auth.=20If anyone's found out why/how this works, and if it could be fixed to be =more=20stable, let us know. We have a lot of dup users with e-mails in =different=20domains, and don't want to have to change the PPP accounts so they can =connect.=20(Just to make sure i'm clear on this, the e-mails work fine, it's just =the PPP=20account having trouble).
 
One more thing <G>,  we are trying to get =a=20disaster recovery plan together should our server/database crash. We are =running=20SQL 7.0 and have tried restoring sample databases on a=20different server, but have had no luck.  The other server just =doesn't=20recognize the backup set.   How does everything else backup =and=20restore their SQL databases? (Restore it to a completely new server, not =on the=20same server).   Any help would be greatly appreciated and =would help=20us sleep a whole lot easier!
 
 
TIA
----------------------------------------------------------------=------------------------------------------------------
  &nb=sp; =20Andrew=20Stinson           =          =20Apex 2000 Internet Services Corporation      =
mailto:astinson@apex2000.net&nb=sp; =20http://www.apex2000.net  =(915)=20570-1676
-------------------------------------------------------------=---------------------------------------------------------
------=_NextPart_000_0035_01BEDE5A.08F2B7E0--