T.R | Title | User | Personal Name | Date | Lines |
---|
539.1 | | IROCZ::D_NELSON | Dave Nelson LKG1-3/A11 226-5358 | Tue Apr 15 1997 16:30 | 28 |
| RE: .0
> I am not quite sure what "proxy authentication" means in this context.
In broad terms, "proxy authentication" means that a DECserver (a RADIUS
client) asks DRAS server (a RADIUS server) to authenticate some user. The
DRAS server may be able to perform that authentication locally. If it
can't, then it may use proxy authentication. The reasons it can't authenticate
the user might be that the user is registered with some other DRAS server (in
another "domain") or with some foreign autentication server (not RADIUS, e.g.
SecurID). In this case the DRAS server acts as client to that other server.
Perhaps it acts as as RADIUS client, asking another RADIUS server somewhere to
authenticate the same user. Or perhaps it acts as as SecurID client, asking
an ACE/Server somewhere to authenticate the same user. In any event, the
DRAS server acts as a "middle man", both a server and a client. Once it
gets the response from the other authentication server, it responds to the
original authentication request from the DECserver.
In your particular context, just substitute an Alta Vista Firewall Server for
the ACE/Server, in the forgoing example.
Regards,
Dave
P.S. I haven't indicated that I think that this will work. I've just
indicated how it _might_ work. :-)
|
539.2 | Client -> firewall -> firewall -> Server | CSC32::R_BUCK | Authenticated and assimilated | Wed Apr 16 1997 11:40 | 26 |
| Dave,
Thanks for your reply. As always, you have provided a great deal of
usefull information!!
Fiannly spoke with the customer that raised the original question. His
basic configuration is that the DECserver, (NAS box), will be on the
'outside' of a double firewall configuration. Host systems, including
the DRAS server, will be on the 'inside'. He will be using the Alta
Vista Firewall product. So his configuration does not seem to fit the
"proxy authentication" model. More like adding one or more routers
between a DRAS client and server.
What I told him is that the DRAS authentication should work through the
firewall providing it does not specifically block the ports used by
DRAS. We also discussed the possibility of changing and/or
redirecting to differnt port numbers.
A second, somewhat unrelated question was whether or not the DECserver
could load software through the firewall. I stated that support for
BOOTP is usually implemented in routers by setting a parameter for a
"Helper". If the firewall software allows something similar, then it
should work.
Randall Buck
MCS - Network Support
|
539.3 | | IROCZ::D_NELSON | Dave Nelson LKG1-3/A11 226-5358 | Wed Apr 16 1997 11:53 | 31 |
| RE: .2
> His basic configuration is that the DECserver, (NAS box), will be on the
> 'outside' of a double firewall configuration. Host systems, including
> the DRAS server, will be on the 'inside'.
Ah, that's very different.
> What I told him is that the DRAS authentication should work through the
> firewall providing it does not specifically block the ports used by
> DRAS. We also discussed the possibility of changing and/or
> redirecting to differnt port numbers.
Yes. As long as the firewalls pass UDP trafffic destined for the RADIUS port
in both directions, this should work. Yoy may also be able to restrict this
traffic to a desintation/origination address of the DRAS server (on the "clean"
side of the firewalls). With DRAS V1.1 and DNAS V2.2, you will be able to
specify which UDP port number gets used. Prior to those versions, you are
restricted to using port 1645 for RADIUS and 1646 for RADIUS Accounting.
> I stated that support for BOOTP is usually implemented in routers by
> setting a parameter for a "Helper". If the firewall software allows
> something similar, then it should work.
This might be somethine of a security hole in the firewalls, since BOOTP uses
broadcast addresses.
Regards,
Dave
|