OK..
I didn't hear no bell.. :) Let's go one more round.
The administrators utilize centralized management, using a RADIUS
derivative. That way, the user base can be managed via NT or UNIX, and the
group and user profiles are managed at the RADIUS level. Guess what this
works, has worked, and is very simple. Put the box anywhere on the
network, as long the there is a some sort of ACL in front and in back of
the box.. :)
/m
At 04:52 PM 7/14/00 -0700, [EMAIL PROTECTED] wrote:
>This dicussion is getting more interesting every post. I certainly agree
>with the KISS principle. As far as I'm concerned security is the inverse
>of complexity. Authenticating users at the boundary is a simple approach
>but has it's own limitations. In my experience, external access via
>Citrix was most commonly used to grant access to systems that didn't lend
>themselves well to other types of access methods (i.e. Web, Telnet,
>etc.). Most were older Windows based applications and one was access to
>an IBM mainframe. The latter supported a periodic state audit requirement.
>
>Citrix supplies a simple way to access a non Web enabled programs with
>reasonable amount of security, good performance, and a minimual amount of
>client setup hassles. It also works across several types of clients (so
>in my example above could support auditors using Apples) and it's
>relatively straight forward for the users. They click on an icon, get a
>login screen and interface they are familar with.
>
>Authenticating users at the boundary can also provides reasonable security
>with a minimual amount of client setup but it only grants someone access
>into the network. They still need the Citrix piece to be able to use the
>application efficiently. Thus we have introduced complexity to the
>solution. The client now has two pieces of software that need to be
>installed, configured and maintained. And the user now has to go through
>two authentication processes.
>
>My preference for this type of configuration is to put the Citrix box in
>the DMZ, not make it part of the domain, install all the apps the users
>need to get to and only grant the apps access to the hosts and services on
>the internal network that are required for it to function properly. I'd
>still hardened the server and Citrix along with any apps that have
>security functions. But I can tell you from experience that the system
>admins will hate this arrangement because they have to manage users on the
>Citrix box locally.
>
>-- Bill Stackpole, CISSP
>
>
>
>[EMAIL PROTECTED]
>Sent by: [EMAIL PROTECTED]
>
>07/14/00 11:32 AM
>
> To: Frank Knobbe <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED]
> Subject: RE: Citrx Metaframe/NT4-TSE
>
>Yes, but the toke
>
>At 12:49 PM 7/14/00 -0500, Frank Knobbe wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >
> >It seems to me that a lot of security consultants have lost a sense
> >of reality and common sense. I don't mean you in particular, but a
> >lot of folks just go way overboard in securing systems, up to a level
> >were security is so tight, they restrict themselves too much and
> >cause problems, or of course spend too much time on it. You method of
> >allowing the world access to the ICA port but securing the TS system
> >on a configuration level could be likened to leaving the front door
> >unlocked, but requiring keys and sign-in sheets and escorts and
> >whatnot for each room in the building. My suggestion of restricting
> >access to the ICA port but being a little more lax in the security on
> >the system itself is more like enforcing access on the front door
> >with a secure lock, but leaving the rooms inside the building easier
> >accessible.
>
>Actually if you going down the token authentication route, then
>implementing keycards with granular access is within the scope of token
>authentication scheme.
>Hey, some of us used to pump gas for a living, and understand why the
>restroom doors should be locked at all times.. :)
>
>The basis of your points are around the C-I-A triangle. Confidentiality,
>Integrity and Availability. An organizations fits within the boundaries of
>the triangle, more on one end then the other or somewhere in the
>middle. Your solution is more on the availability side of the house then
>integrity. That is ok. But as the vendor "Snake Oil" and "Vaporware
>Announcements" becoming worse and promises featuring newer and slicker
>stuff is not even close to the horizon.
>
>So stick to the KISS method, and most likely you will see in the end it is
>the simpler solution..
>
>:)
>
>/m
>
>
>
> >Now look around where you work. Unless you are in a high
> >security facility (i.e. research lab, military facility, etc), you
> >will agree that your front door is tight, but your office doors
> >(although shut) are not locked. You can also easily see why
> >(especially when you have to unlock your restroom every time you need
> >to go :)
> >
> >In addition, using your method would require additional security
> >configurations and security checks every time you change something on
> >the TS, i.e. installing a new, performing upgrades, etc. My method
> >let's you do that quicker.
> >
> >Now, I'm as paranoid as you are about folks getting into my system.
> >But I also see the value of easier maintenance and support. I hope
> >that this message will not light up an old holy war. These are just
> >my opinions (imagine standard disclaimer here).
> >
> >Regards,
> >Frank
> >
> >
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: PGP Personal Privacy 6.5.1
> >Comment: PGP or S/MIME (X.509) encrypted email preferred.
> >
> >iQA/AwUBOW9Sr0RKym0LjhFcEQJwDQCghHyXoXn9xYOvSK1/lig9ydHnFXkAoNM+
> >jCnGg55PNMoxrbqW/ytq61tx
> >=wU8i
> >-----END PGP SIGNATURE-----
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
