S4Software Home  
Contact
Search
Products About Us Products Services Partners Events  
 

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 (619) 574-5375 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 (619) 574-5375 (8:00 a.m. to 5:00 p.m. US Pacific Time)
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

 
Contact Support
S4Privilege Support FAQ
S4Audit Support FAQ
Support Plans