NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/lou/sun/336

Text File | 1992-12-31 | 10.0 KB | 253 lines

Newsgroups: lou.sun
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!tulane!daemon
From: [e-mail] ()
    id AA22498; Wed, 30 Dec 92 22: 25:14 PST
Subject: 48.15 SunFlash: SunSHIELD ARM: Questions & Answers
Original-Message-Id: <[e-mail]>
Message-ID: <[e-mail]>
Precedence: junk
Sender: [e-mail]
Reply-To: <[e-mail]>
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Errors-To: <[e-mail]>
Distribution: lou
Date: Thu, 31 Dec 1992 07:24:41 GMT
Return-Path: <[e-mail]>
Approved: tulane
Content-Length: 9533
Nntp-Posting-Host-[nntpd-5705]: rex
Lines: 232

----------------------------------------------------------------------------
                                                        The Florida SunFlash

                   SunSHIELD ARM: Questions & Answers

SunFLASH Vol 48 #15                           December 1992
----------------------------------------------------------------------------
The following is an internal memo written for the Sun field sales force.
-johnj
----------------------------------------------------------------------------

This memo, which is in Q&A format, positions Sun SHIELD Account
Resource Management (ARM).  SunSoft and SMCC Marketing have provided
this to assist our sales force in planning the most efficient use of
ARM with their customers.  We also wanted to reiterate the fact that
SunSoft is committed to providing security functionality within its
Solaris environment - as demonstrated by SunSoft FREELY supplying Sun
SHIELD Automated Security Enhancement Tool (ASET) as part of Solaris
2.0.

We hope this memo is useful in planning your use of ARM now and in
the future.

Regards,
The SMCC Security Team

--------------------------------------------------------------------

FROM: SunSoft and SMCC Product Marketing
RE:   Positioning ARM: Questions & Answers
DATE: October, 1992

SunSHIELD ARM is an unbundled security product released on Solaris 1.0 in
September 1991.  To date, Sun has sold many copies of ARM to
security conscious customers.  The purpose of this document is to
clarify ARM product positioning and to answer your most frequently
asked questions about the intended use of ARM and target environments.


                                 TOPICS

                ** Availability On Solaris Releases  **
                     ** Supported Configurations **
                        ** Configuration Tips **
                          ** Compatibility **
                          ** ARM Directions **



** Availability On Solaris Releases  **

Q. Why should we care about ARM?

A. ARM enhances Solaris security to provide account login protection and
   access control.  Security conscious customers need the password management
   and access control features provided by ARM.

Q. What Solaris releases support ARM?

A. ARM (combined with ASET) is an unbundled software package available on
   Solaris 1.0 (SunOS 4.1.1).  ARM has been release tested on Solaris 1.0
   release only.  It works on Solaris 1.0.1 (SunOS 4.1.2) with the
   patch available on the SunOS 4.1.2 CD.  Read the Release Notes for the
   Solaris/SunOS releases for patch information.

Q. When are ARM and ASET available on Solaris 2.x?

A. ASET is already bundled in Solaris 2.0.  SunSoft is targeting a
   Solaris 2.x ARM release in CY 1993.




** Supported Configurations **


Q. Is there a maximum supported configuration?

A. Yes.  ARM was designed for use in small workgroups.  The current release
   is intended for use in ARM domains that do not exceed 20-30 systems and
   about 100 users, depending on the application environment. We urge that
   you recommend to customers that they restrict the size of their ARM
   domains to be within these limits.

Q. Why do you recommend such a configuration limit for the ARM domain?

A. ARM login could slow down considerably (could take several minutes) when
   ARM is deployed in large domains of several hundred users who could login
   to their systems simultaneously.  The internal design of ARM is not suited
   for optimum performance in such a large scale deployment.

Q. Is the configuration limit enforced by the current ARM product?

A. No.  ARM does not currently check the attempted use of the product in
   large configurations.  Because the limitation really depends on specific
   usage characteristics in customer environments, SunSoft did not hard code
   such a limit or state it in the ARM documentation.



** Configuration Tips **


Q. Anything we should know about installing ARM?

A. Read the Release Notes first!  These notes identify some of the problems
   you might run into when installing ARM and the recovery procedures.

Q. For best performance, where should I run the ARM server?

A. You should run the ARM server on the most powerful system you have,
   with lots of memory and disk.  We recommend a minimum system spec
   of a SPARCstation 2 with 32 MB memory and 424 MB disk.

   Make sure that 20 MB disk space is available in /var where the armd_*
   files reside.  These files could also be moved to a separate (20 MB)
   directory by configuring armd policy.

   The ARM server is very much CPU and network (RPC) intensive, so make sure
   that you are NOT running another network intensive application on the
   ARM server (e.g. Database application, NIS server, or a distributed
   application that does a lot of rsh, rcp, or RPC).

Q. What is the performance impact of site usage patterns on ARM?

A. ARM extensively uses RPC internally.  Simultaneous logins by large numbers
   (several hundreds) of users seriously impacts ARM performance.  The impact
   is much less severe if the logins are distributed over a few minutes.

Q. What are the usage pitfalls and 'gotchas' to avoid?

A. Avoid cron jobs or scripts that do large amounts of remote execution
   with rsh to avoid degrading an ARM environment.  The scripts could
   be changed to use rexec.  Another workaround is to limit the number of
   remote commands executed in the script to less than 10 per minute.

Q. What is your recommendation for large sites?

A. Large sites that want to use ARM should break down the site into workgroups
   and set up separate ARM domains for workgroups, limiting  the size of a
   domain to 20-30 systems and/or 100 users. Large sites should also restrict
   the use of large amounts of rsh and rcp in ARM environments.



** Compatibility **


Q. Is ARM compatible with C2 security?

A. Yes.  ARM and C2 can be used together.  If you are installing a C2 security
   patch, follow the directions for the patch to make sure that the system
   files provided in ARM (e.g. login, su) are not overwritten by the patch.
   ARM should be installed before the C2 patch is installed.

Q. Is ARM compatible with NIS?

A. Yes.  ARM domains can be defined within NIS domains.  However, ARM does
   not work across different NIS domains.

Q. Does ARM password aging work across NIS domains?

A. No.  ARM password aging works within the ARM domain, which can be defined
   within a NIS domain.  Thus the ARM password aging works across all the
   hosts in the ARM domain, unlike SunOS or SVr4 password aging that works
   only for a single host or server.

Q. Does ARM work with Secure RPC?

A. Yes.  We recommend that you configure ARM to use Secure RPC for added
   network security.  However, you should bear in mind that ARM extensively
   uses RPC, and Secure RPC could slow you down in large configurations.
   Also, Secure RPC in Solaris 1.x does not work across NIS domains.
   This is fixed with NIS+ in Solaris 2.0 and the Solaris 2.x release of
   ARM will benefit from it.



** ARM Directions **


Q. Will ARM be unbundled or bundled in Solaris 2.x?

A. Our current goal is to bundle ARM in a future Solaris release.
   ARM may be available unbundled prior to being part of Solaris.

Q. Is there a third party alternative to ARM for Solaris?

A. Currently ARM is it.  Similar security features can be found in
   Computer Associates' CA-UNICENTER product being ported to Solaris.

Q. How does ARM fit into SunSoft's Federated Security plans?

A. SunSoft announced Federated Security as a part of Federated Services
   in their ONC+ announcement.  They announced their plans for pluggable RPC
   authentication and generic security services.  They are planning to
   fit ARM into a pluggable authentication model in a future release.

Q. When will the ARM performance/scalability limitations go away?

A. SunSoft is aware of the need to make ARM functionality scale better for
   deployment in large sites.  Commercial customers like ARM's functionality,
   but they want it to be more robust and scalable.  To meet this
   expectation, a total redesign of the ARM product is needed.  Currently,
   there is a plan to do this redesign in order to meet the needs
   of our customers in CY 1993.

Q. When will you add capability to configure a secondary policy/status
   server within an ARM Domain for robustness and resilience?

A. Presently when the master ARM policy/status server goes down, users
   within the ARM domain are not able to login to any machine in the network.
   Solving this problem involves a major redesign and enhancement for ARM.
   SunSoft is planning fix this in the future ARM release.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For information send mail to [e-mail].
Subscription requests should be sent to [e-mail].
Archives are on solar.nova.edu, paris.cs.miami.edu, uunet.uu.net,
src.doc.ic.ac.uk and ftp.adelaide.edu.au

All prices, availability, and other statements relating to Sun or third
party products are valid in the U.S. only. Please contact your local
Sales Representative for details of pricing and product availability in
your region. Descriptions of, or references to products or publications
within SunFlash does not imply an endorsement of that product or
publication by Sun Microsystems.

John McLaughlin, SunFlash editor, [e-mail]. [phone].

TRACE: To: [e-mail] Errors-to: [e-mail]