Hello friends
i have following doubts regarding integration of
cisco Secure ACS and secureID ACE/server , i would
really appriate if someone help me with these.
1) Is it possible to use dialback /callback
selectively for few selected users with
cisco Secure ACS and secure ID ACE/server while using
secureID authentication methods for users , if yes
then what will happen as far as secureID tokens based
authentication is concern while dial back happenes ?
how dial back will work with secureID tokens ?
2) i have cisco Secure ACS and secureID
ACE/server,now if i want to use secureID
authentication method for all the dial in user then
where i will have to create these users , in ACE
server or in cisco ACS ?
3) combination of point 1 and point 2 mentioned
above
is possible ?
friends please try to reply me as soon as
possible,
Thanks & Regards
Prashant Desai
--- "Paul D. Robertson" <[EMAIL PROTECTED]> wrote:
> On Fri, 11 May 2001, Nilesh Naik wrote:
>
> > hello friends
>
> Hi,
>
> >
> > we have 3-4 branch offices and for our
> employees
> > who keeps on travelling , we want a secured remote
> > access environment the remote access environment.
> for
> > which we have decided to deploy ciscoSecure ACS
> along
> > with the secureID Ace/Server
> >
> > follwing is the mixed list of my queries and our
> > requirment , please guide me
> >
> > requirements :
> >
> > 1) dial back/call back once user gets
> authenticated.
>
> I'm not sure where you are in the world, but
> dial-back after
> authentication has some definite weaknesses:
>
> 1. Setting up call forwarding on the line to forward
> to another number for
> inbound calls. This isn't possible for an oubound
> dialer to check, so if
> the attacker knows which number to do this on, it's
> normally a small
> social engineering exercise at the local telco, or 2
> minutes with a butt
> set at the location's network interface (NI) jack.
> In the US, if you
> include residential access for administrators, the
> NI (unless it's a very
> old house that's had no phone work in the last 20 or
> so years) is outside
> the house stuck to the side or back of the building
> where it's easily
> accessible.
>
> 2. If you don't use a fully pinnned out serial
> cable, it's possible to
> spoof hangup if the modem at the dial back end
> doesn't support DTR. If
> dial back is to reverse toll charges, this probably
> isn't a big deal for
> you, but if it's to provide some sort of line
> authentication, then it can
> be an issue. Some modems don't hang up quickly
> (such as older Adtran ISU
> 128 ISDN modems) and need DTR to be off for much
> longer than the
> traditional < 1 second.
>
> There are 3 fixes for this:
>
> 1. Require an additional authentication step after
> the dial back happens.
>
> 2. Use ANI (expensive!) to validate the dialing
> number prior to initiating
> dial back.
>
> 3. Use CNID to validate the dialing number prior to
> initiating dial back
> (I've heard it's possible to spoof caller-ID if the
> device latches on to a
> second identifier after going off hook- I'm not sure
> how feasable this is
> from a remote location, or if it requires local line
> accesss though.)
>
> You could also just live with the risk. If it's
> dynamic dial-back, then
> remember that things like hotels that don't allow
> direct inbound dial
> access to rooms will break your access mechanism.
>
> > 2) traditional userID/password authentication
> with an
> > additional level of security provided by
> SecureIDtoken
> > server and secureID tokens.
> > 3) this addtional layer of security provided by
> > secureID tokens and token server will be only used
> in
> > the case of remote access.
> >
> >
> > queries :
> > 1) Is it possible to use token based
> authentication
> > with traditional radius authentication ,
> > what i mean is user will have to enter
> > username/password two times once for Radius and
> > second time
> > user will enter username/OTP passcode
> > generated by
> > SecureID authenticators,
>
> [I'm possibly misreading this- the second time
> through I got a
> different interpretation-- apologies if I've missed
> cleaning it up to one
> interpretation anywhere.]
>
> You can use the Secure-ID ACE server for RADIUS
> authentication (with
> the caveat that it requires one minute between
> authentications for a
> single user) for token users. Users in the ACE
> server can have either a
> token or username/password authentication method.
>
> If token users always use tokens, and password users
> always use passwords,
> then it's an easy to set up and administer system.
> If you need "sometimes
> they use tokens, sometimes passwords" then it's much
> more difficult.
>
> > This(above) should also happen with
> > dialback/callback , is it possible ? if yes then
> how
> > this authentication will work ?
>
> I know in the past some vendors have touted
> re-authentication with
> dial-back. I don't recall which vendors though.
> Dialback should be a
> fucntion of the access path, not the authentication
> method. You'll
> probably need a second authentication method if you
> pre-auth the dialup
> though, as the one minute interval complicates
> dial-back using the token
> for both dial-in and dial-back auth.
>
> > is the above recommended ? if no what is
> > recommended ?
>
> It depends on the requirements. They're not
> perfectly clear to me at this
> point. Re-reading this has made me decide you meant
> something different
> than what I originally read, so please look at my
> answers about the two
> authentication server quesitons and seperate that
> from the dial-back
> issue, then maybe it'll be easier for you to narrow
> down your questions.
>
> >
> > 2) we have decided that we are going to deploy
> > ciscosecure ACS with SDI secureID ACE/server.
>
> Your local Cisco rep. will be able to answer all
> your questions on their
> product. Just don't forget that the ACE server can
> act as a RADIUS server
> when looking at authentication methods. It seems to
> me that you're
> deploying two devices that do essentially the same
> thing, one of which is
> necessary to use SecureID. You should also be able
> to contact RSA and
> have both vendors tell you how their products meet
> your requirements.
>
> > then where we should create the users ? since
> now
> > we have droped the idea of using LDAP central
> > directory to store user ID/password whichwe
> were
> > planning to use for authentication and so , i have
> > mentioned in my previous mail .
> >
> > 1) for traditional radius authentication
> with
> > normal
> > uid/password .
> > and
> > 2) for token based authentication with
> > sameuid/OTP
> > passcode generated by secureID authenticators
> >
>
> I'm not sure why you need both? If you mean for
> different users, then you
> can put user/password entries into the ACE server,
> though you'd have to
> check with RSA to see how that affects the number of
> users you have to
> license.
>
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
