Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Re: ascend-users-digest V96 #1626
- To: ascend-users@max.bungi.com
- Subject: (ASCEND) Re: ascend-users-digest V96 #1626
- From: Joel Wittenberg <joelw@ascend.com>
- Date: Thu, 3 Jun 1999 14:27:56 -0700
- In-Reply-To: <199906032043.NAA11309@max.bungi.com>; from owner-ascend-users-digest@max.bungi.com on Thu, Jun 03, 1999 at 01:43:35PM -0700
- References: <199906032043.NAA11309@max.bungi.com>
- Sender: owner-ascend-users@max.bungi.com
As has already been mentioned, the problem presumably stems from the fact
that the MS client cannot be configured to refuse CHAP if it is offered to
it, and the NAS (the MAX) is configured to Either, which means it is
_required_ by the PPP rfc to offer CHAP before offering to do CHAP. This
is not itself a problem since with both ends agreeing on CHAP you should be
okay, except for one thing - CHAP requires that the authenticating entity
have a clear-text representation of the password. A local profile will
meet this requirement, as will a Radius profile which includes the
password. What won't work is using a Radius profile entry which does not
include the clear text password (e.g., it references a Unix passwd file
entry, or in some other fashion contains an encrypted password). Since
apparently you have some clients which do want to use CHAP, then assuming
that the MS clients are using a Radius auth record without a plain-text
password, you have the option of making a (very limited) set of MS
clients use local profiles, or modifying the relevent Radius profiles to
use a clear-text password entry, OR, in very recent Ascend SW releases
(and I'm not sure which ones; perhaps only including releases which are
not suitable for you. I do know that the feature I am about to describe
is slated for general availabilty, but that won't necessarily help you
right now), IF you are using (or can use) CLID authentication in addition
to name/pwd authentication, you can include a Reply-Attribute in the CLID
auth record which will override (for this call only) the default
None/Pap/Chap/Either setting in the Max Answer profile. This
Ascend-Specific (and therefore VSA-only) attribute was added specifically
to address the situation just described. Please contact your sales rep to
see if it is available in a release suitable for your needs. The Radius
attribute and associated values are:
#
# Note that this attribute uses the same id as an RFC assigned
# attribute and therefore must be used only as a VSA.
#
ATTRIBUTE Ascend-Auth-Type 81 integer
# Ascend Auth Values
VALUE Ascend-Auth-Type Auth-None 0
VALUE Ascend-Auth-Type Auth-Default 1
VALUE Ascend-Auth-Type Auth-Any 2
VALUE Ascend-Auth-Type Auth-PAP 3
VALUE Ascend-Auth-Type Auth-CHAP 4
VALUE Ascend-Auth-Type Auth-MS-CHAP 5
Thus, returning an Ascend-Auth-Type = Auth-PAP in the CLID authorisation
will allow this call to use PAP for name/pwd auth regardless of the Answer
profile Recv Auth setting. You must configure the MAX to use VSAs for
this attribute to be recognised (note that configuring the MAX to use VSAs
means that it will NOT recognise non-RFC-standard attributes which are not
explictly marked as an Ascend-VSA. Also, the Radius server must recognise
incoming Ascend-VSAs since the Max will also send all non-RFC-standard
Ascend attributes as Ascend-VSAs).
I hope this information helps you.
/joel
Quoting owner-ascend-users-digest@max.bungi.com (owner-ascend-users-digest@max.bungi.com):
> From: Cyril Jaouich <twiggy@twiggy.spider.org>
> Date: Fri, 4 Jun 1999 02:06:50 -0400 (EDT)
> Subject: Re: (ASCEND) Ethernet -> Answer -> PPP Options -> Recv Auth=PAP vs. Either
>
> On Wed, 2 Jun 1999, Phillip Vandry wrote:
>
> > > Hello All:
> > >
> > > For some reason users dialing into my
> > > MAX using PAP cannot authenticate when MAX
> > > Recv Auth is set to Either. Woks fine when
> > > set to PAP.
> >
> > Your RADIUS server probably does not support CHAP on some or all accounts,
> > and the clients are trying to use CHAP, since they are given the choice.
> >
> > The only solution is to disable CHAP.
>
> Well the problem is an M$ problem, non-windows dial-in will be
> okay with Either because they can be set to PAP first, but Microsoft has
> MS-CHAP (a CHAP version) that will be used before the configured
> authentication protocol. AFAIK there is no way to disable MS-CHAP auth in
> windows products, we ran into the same problem with having Cisco ISDN
> CHAP customers and our regular user base (mostly windows).
>
> Get Linux :)
>
> Cyril Jaouich [CJ837]
> - ---------------------
> AT&T Canada Internetworking specialist
> - --------------------------------------
> Only 5064 hours before Y2K, will you be compliant?
--
joel wittenberg
joelw@ascend.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>