|
Secure4Access (GUARDIAN) FAQ
Installation
Do all the users have to be off
the system to install Secure4Access?
Does the system have to be rebooted
after Secure4Access is installed?
Are all users affected after an
install?
Do system files need to be backed
up before installing Secure4Access? (i.e. /etc/passwd, group, shadow,
and shells files)
Do system programs have to be
disabled to try the evaluation copy of Secure4Access? (i.e. passwd, yppasswd,
chsh)
I tried to run the installation
script but I received the following error: "The Secure4Access installation
script must be run from the root account". I did an su to root
after I logged in, so why doesn't the script recognize me as root?
I just installed the software
yesterday but when I try to start the menu program, I get: "Software
has expired"! Why?
What if a previous version of
Secure4Access is already installed?
How is Secure4Access installed in a
NIS network environment?
What if the NIS master goes down,
does Secure4Access go down too?
Why does an attempt to log in
to a workstation or X-terminal abort after the account/password
entry, when logging into the same account on a dumb terminal or
via telnet works correctly?
Is there anything special that
needs to be done for different UNIX platforms?
Menu Program
How do I start the Menu program?
The graphical menu program doesn't
start, the character-based version comes up instead. Why?
While attempting to start the GUI
version it displays many, many errors, and finally comes up in black
and white. What causes this?
Do users need root access
to run the Menu program?
Will giving users root access to
run the Menu program give them root access to the whole system?
Do I need to create new
accounts for all my users to bring them under Secure4Access control?
Why does the user keep getting shell
prompts when running the character-based version of the menu program?
I just got the demo, installed it;
got into the Character-Based version and it says to use 'exec' to
store, or 'exit'. I don't have those keys...
After changing the password on a
NIS account, I went back in to change another field and got an error;
"Profile inconsistent with system files (1)". Why?
General Troubleshooting
My users have a tendency to walk away
from their desks without logging off. I'm worried about this creating
an opportunity for someone else to come along and do some damage.
Can Secure4Access solve this problem?
Suddenly my Secure4Access controlled account
is doing the most bizarre stuff. What can I do? What should I try?
I installed the demo, created an account,
and tried to log in. I received a message "No system access
allowed at present".
Login FAQ
I keep getting, "Login denied
- Invalid Username/Password pair" when I try to log in with
my Secure4Access account. Why?
When I try to login, I get this
error message: "Login denied - Login not allowed on this host".
What is wrong?
After I rebooted my system, Secure4Access
would not accept logins. Users were getting the message 'Timeout
while waiting for response from Secure4Access server.' I could see that
s4accsrv was running. After about 20 minutes, the problem went
away. Why?
Occasionally, users get the message
'Timeout while waiting for response from Secure4Access server.' It seems
to happen when the network is down, but the users are local. Why
is it happening?
Where do I get information to help
me troubleshoot an error?
Where are the logs located and what
does each one do?
Contact
How can I contact S4Software for support?
Installation FAQs:
Do all the users have to be off the system to install
Secure4Access?
No! Secure4Access does not modify the kernel or automatically
put user accounts under Secure4Access control during installation. So
users can stay on the system while Secure4Access is being installed.
Does the system have to be rebooted after Secure4Access
is installed?
No! Secure4Access can be installed on the system, without
taking it down, without requiring users to log out - basically without
a hassle. There is no need to reboot after Secure4Access is installed
either. Secure4Access does not modify the kernel.
Are all users affected after an install?
No. Secure4Access only controls those users that you
specify. To place a user under Secure4Access control, you must create
a Secure4Access Account profile with the user Login Program defined as
/bin/gsh. Once UNIX validation is complete, UNIX will start the
log in program (specified in the 'passwd' file), in this case gsh.
At this point, Secure4Access will validate the login, do any additional
checks specified in the profile and start the user's initial program
or shell.
Do system files need to be backed up before installing
Secure4Access? (i.e. /etc/passwd, group, shadow, and shells files)
Secure4Access recognizes the need to have sensitive
files backed up before doing any major modifications. So, Secure4Access's
installation script automatically makes backup copies of these files
on the system, by creating duplicate copies of the files with the
.pre_gd extension appended to the name. If necessary, these backup
files can be easily recovered by removing their .pre_gd extension.
Do system programs have to be disabled to try the
evaluation copy of Secure4Access? (i.e. passwd, yppasswd, chsh)
No! While an evaluation copy of Secure4Access is in
use, non-Secure4Access users will need access to these programs. The
Secure4Access installation script will ask if these are to be disabled;
answer "No" for a demonstration copy. As part of a permanent
installation, when all users are put under Secure4Access control, it
is recommended that these programs be disabled, to improve security.
I tried to run the installation script but I received
the following error: "The Secure4Access installation script must
be run from the root account". I did an su to root after I
logged in, so why doesn't the script recognize me as root?
The user trying to install Secure4Access does not have
root privileges. It may be that they are logged in as 'root' but
neither their logname nor their user environment variables are set
to 'root'. Set one or the other option to root and continue.
I just installed the software yesterday but when
I try to start the menu program, I get: "Software has expired"!
Why?
Secure4Access comes with a temporary set of keys that
are pre-expired. Use the command /bin/secure4/s4access -v
to get the primary reset codes. Forward these codes to S4Software by calling
(858) 560-8112; by faxing (858) 560-8114 or by email to support@s4software.com.
What if a previous version of Secure4Access is already
installed?
In general, new versions are distinguished by increments
in the tents digit (e.g. 5.0, 5.1) and are installed in separate
directories. Updates are distinguished by increments in the hundredths
digit and are installed in the same directory (e.g. 5.01 and 5.02
are minor updates and would be installed in the /bin/secure4/s4access_5.1
directory).
How is Secure4Access installed in a NIS network environment?
The Secure4Access installation script performs special
steps if Secure4Access is to interface with NIS or NIS+. Be sure that
NIS(+) and NFS are functioning correctly and that the NIS (+) master
server is active before using the installation script
If Secure4Access is being installed on a network, install
it first on the NIS master server, then on the alternate server
(where a copy of the Secure4Access profile directory is to be installed),
and then on any other slave servers or client machines.
What if the NIS master goes down, does Secure4Access
go down too?
The Secure4Access slave server is capable of taking
over as the NIS master server if the NIS master becomes unavailable,
assuming NIS is configured to support this. If it is necessary for
the slave to rebuild a map (e.g. because of a password change),
it first builds a map source file from the existing map because
a slave server cannot depend on map source files to be current.
Why does an attempt to log in to a workstation or
X-terminal abort after the account/password entry, when logging
into the same account on a dumb terminal or via telnet works correctly?
Most implementations of an X environment require
that a modified X startup file be installed. This option is offered
by the Secure4Access installation script, but is not always done.
Check the to see if the file was properly modified
during the installation process. To determine whether the file was
properly modified, look for the proper Xsession file in the /bin/secure4/s4access.dir
directory. One or more Xsession files will exist (session.xdm,
Xsession.cde, etc.) Installation instructions are in the
file, so it is easy to check to see if it has already been installed,
and if not, follow the directions at the top to the file to install
it by hand.
Is there anything special that needs to be done for
different UNIX platforms?
There may be additional steps that need to be taken
for particular features of Secure4Access to work on different UNIX platforms.
The installation instructions that are shipped with the software
in PDF, discuss this in more detail. It is recommended that the
Installation Instructions be extracted from the tar file before
beginning the installation of the Secure4Access software.
To extract the Installation instructions:
tar -xvf gd5_<ostype> GD_INSTALL.pdf
Where <ostype> is the UNIX operation system
Menu FAQs
How do I start the Menu program?
To start the Secure4Access menu program after installing
the software and inputting valid demonstration keys, you will first
need to log in as root. (If it is not possible to login as root,
contact S4Software prior to running the menu program for assistance).
Once logged in as root, use the following steps
to run the GUI menu program:
cd /bin/secure4
./s4access
The graphical menu program doesn't start, the character-based
version comes up instead. Why?
The user's DISPLAY environment variable is not set.
Set the DISPLAY environment variable or invoke Secure4Access
using the -display switch:
s4access -display <hostname>:0.0
While attempting to start the GUI version it displays
a series of errors, and finally comes up in black and white. What
causes this?
The color map is being used by another application(s)
(e.g. Netscape).
Terminate the program(s), which are using the color map.
GUI appears to be hung up; mouse clicks
on the main menu bar don't work, etc.
There is probably a Secure4Access window, which is requesting a
selection, confirmation, etc. Look around for it - it may be hiding
behind another window.
This problem arises because of the window selection policy. Change
the mouse behavior so windows activate automatically instead of
by mouse click.
Do users need root access to run the Menu
program?
Although you must initially be root to run the
menu program, the Secure4Access software package offers a specific security
option for controlling use of the menu programs. By default, a user
must have a valid Secure4Access profile with the Security Manager option
set, and have an effective user ID (UID) of 0. In order to allow
users to bring up the system when none of the accounts have this
option, the software release includes a Security Manager version
of the profile for the root account.
There are additional options to configure Secure4Access Menu Program
security, such as a non-root Security Manager (setuid) option, ability
to partition manager privileges and protect profile fields. See
Chapter 11 and Appendix A of the Secure4Access Reference Manual for more
details.
Will giving users root access to run the Menu program
give them root access to the whole system?
When running Secure4Access in setuid mode the interrupt
key sequence (<ctrl>i) is non-functional. This
prevents the user from accessing a shell with a UID of 0. If the
non-root Security Managers are not familiar with UNIX, consider
using the rpthome configuration file option to prevent the modification
of key system files.
The setuid configuration file option
allows the Secure4Access menu program to be run by the non-root
Security Manager. In this mode, the user must enter a valid password
before the menu program will start; hence it cannot be used with
the command-line mode.
Do I need to create new accounts for all
my users to bring them under Secure4Access control?
No! Secure4Access offers two options for bringing
existing accounts under Secure4Access control. On an individual
basis, accounts existing in the system 'passwd' file may be modified
using the "Edit A User Account" option to specify
the Secure4Access shell (/bin/gsh) as their login program and to
create a Secure4Access profile. For installing multiple users into
Secure4Access, the Install Accounts Into Secure4Access batch option
may be used. This option determines if a Secure4Access profile exists
and if not will install the accounts by changing the login program
to /bin/gsh and creating a Secure4Access profile.
The GUI version of Secure4Access can't seem to find my accounts.
Sometimes it displays the account name in the scrolled list, but
then comes back with a message which says 'Account name not found
in password file.'
Although the account is highlighted, it does not
appear in the selection box.
Click on the account name to cause it to appear in the selection
box.
Why does the user keep getting shell prompts when
running the character-based version of the menu program?
The <Tab> key has been used to move between
fields. The <Tab> key starts a shell process.
Type exit to return to the menu program. Change the
shell key, if necessary, by using the configuration file option
shellkey described in Appendix A of the Secure4Access Reference
Manual.
I just got the demo, installed it; got into the Character-Based
version and it says to use 'exec' to store, or 'exit'. I don't have
those keys...
Secure4Access uses a standard set of keys to simplify
many frequently performed operations. Depending upon the keyboard
configuration, these functions can be invoked by using function
keys, or special keyboard characters. The following table outlines
the various key mappings for commonly used terminals.
Standard Keys and Functions
Click here
for key table
After changing the password on a NIS account, I
went back in to change another field and got an error; "Profile
inconsistent with system files (1)". Why?
Because the NIS processes (ypbind
and ypserv) cache entries, it may sometimes appear
that an account change was not made, when in fact it was correctly
updated (and can be demonstrated by logging into the account with
the new password). The following two examples are the most common
cases.
Edit a NIS account using the Secure4Access menu program.
Further attempts to edit the account will show that there is a 'password/profile'
mismatch. This problem can be avoided by exiting and restarting
the menu program, or by waiting for approximately 6 minutes, by
which time NIS will have realized that the maps have been modified.
If a user changes their account password via s4accpwd,
then desires to do so again within 6 minutes of the previous change,
the user will be given a message stating that the old password was
incorrect. A similar situation occurs when adding multiple members
to a UNIX group. The only current workaround for this is to wait
for the 6 minutes until NIS figures out that the change has occurred.
General Troubleshooting
My users have a tendency to walk away from their
desks without logging off. I'm worried about this creating an opportunity
for someone else to come along and do some damage. Can Secure4Access
solve this problem?
Yes! Secure4Access provides you with an option
to lock or terminate a user's session if it remains inactive for
the period of time defined in their user profile. Callouts to user-defined
scripts can be performed at the start and end of the inactivity
period and prior to termination due to inactivity. The latter can
be useful for insuring that applications are terminated gracefully.
A utility is also provided for users to lock the X session manually
before they leave their terminal.
Suddenly my Secure4Access controlled account does
something unexpected or unwanted. What can I do? What should I try?
Whenever a Secure4Access controlled account performs
irregularly, the first thing to try is removing it from Secure4Access
control. The problem may persist; in which case Secure4Access is
not causing it.
I installed the demo, created an account, and tried
to log in. I received a message "No system access allowed at
present".
When the message 'No system access allowed at present'
is displayed, it indicates that the Secure4Access server daemon (s4accsrv)
is not running. It can also mean the permissions on s4am.serve
are incorrect.
LOGIN FAQS
I keep getting, "Login denied - Invalid Username/Password
pair" when I try to log in with my Secure4Access account. Why?
Possible reasons for this error message are:
a) Either the username or password were entered incorrectly for
the account
b) The account has been inactivated through the Secure4Access menu program
c) There is no Secure4Access profile for the account even though the
account is installed into Secure4Access
d) Host restrictions have been defined for the user and they are
not allowed to log in to the specified host
When I try to login, I get this error message: "Login
denied - Login not allowed on this host". What is wrong?
An attempt was made to access a host, which was
not listed in Login hosts in the account's profile. If this account
needs access to this host, it must be listed in Login hosts. More
information on this option can be found in Chapter 3 of the Secure4Access
Manual.
After I rebooted my system, Secure4Access would not accept logins. Users
were getting the message 'Timeout while waiting for response from
Secure4Access server.' I could see that s4accsrv was running.
After about 20 minutes, the problem went away. Why?
The system audit file is probably huge. Consult
the appropriate Appendix in the Secure4Access Installation Instructions
for the name of this file. Secure4Access searches it for failed login
information every time s4accsrv is started. You should
probably institute a policy of backing up the audit file(s) then
clearing it out on a regular basis. Consult your OS support for
information on how best to do this.
Occasionally, users get the message 'Timeout while
waiting for response from Secure4Access server.' It seems to happen when
the network is down, but the users are local. Why is it happening?
The system is probably not set up to fail over
to /etc/hosts when no response from DNS is received.
Both the s4accsrv and s4accusr processes
do a gethostbyname and will time out if the operating
system cannot resolve the hostname.
Where do I get information to help me troubleshoot
an error?
Secure4Access maintains three audit files to track
system activity which are always a good place to start when troubleshooting.
The combined log file, s4access.clg, is a binary format
log of all Secure4Access activity. Use the report option "Audit
Log Report:" to view the contents of this log. The ASCII text
file, s4access.log, keeps a record of Secure4Access
related activity including profile changes, login attempts, etc...
The s4access.syslog file keeps information on successful
and failed login attempts and login group related access information.
Use the "User Activity Report" or the "System Logging
Report" to view this log. When enabled, these logs keep a complete
record of system access and failed login attempts in addition to
all operations that modify any profiles. This is the best starting
point for troubleshooting problems.
Where are the logs located and what does each one
do?
The Secure4Access log file (s4access.log)
is in printable form, and is used to keep a record of all profile
changes, server daemon activity, error messages, and any unusual
login attempts. This file can be found in the same directory as
the Secure4Access profiles and can be read using any UNIX read command
(i.e. more, tail, etc...)
The Secure4Access syslog file (s4access.syslog)
is a binary log file that resides in the profile directory that
records all logins, connect time and other system utilization data.
The syslog feature is disabled by default. It can be enabled by
using the syslog=y configuration option or by using
the menu program server control menu. Use the "User Activity
Report" or the "System Logging Report" to view this
log. This report can only be viewed using the Secure4Access menu program.
The Secure4Access combined log file (s4access.clg)
is in binary form and also resides in the profile directory by default.
It is a combination of the other two Secure4Access log files, the
s4access.log and the s4access.syslog.
It is used to keep a record of all actions performed by all of the
Secure4Access modules (the menu program, the daemons...). This report
can only be viewed using the Secure4Access menu program, using the
"Audit Log Report" option.
Contact Support
Contacting S4Software for technical assistance:
S4Software can be contacted by calling (858) 560-8112 (8:00 a.m.
to 5:00 p.m. US Pacific Time)
Or by sending a fax to (858) 560-8114
Or by sending email to support@s4software.com
Please have the following information available
or include it in the fax or email:
The S4Software product and revision level (i.e. Secure4Access 5.10, Secure4Privilege 2.0)
Type of UNIX platform and revision level (i.e. Solaris 2.8)
The EXACT error message received
A description of how the error occurred, the steps that have been
taken to try to resolve it and any other relevant information
The Secure4Access log file (/usr/secure4/secure4.upf/s4access.log)
entries
The core file if one was generated
The /bin/secure4/s4am.errors.<hostname> file if one exists
The user profile of any involved users
The Company's name
The name, address, phone number and email of the person to contact
|