Consultor Eletrônico



Kbase P11237: How to define AdminServer security
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   10/2/2009
Status: Verified

GOAL:

How to define AdminServer security

GOAL:

Can I define AdminServer security for individual users?

GOAL:

Can I define AdminServer security for Group access?

GOAL:

What's the purpose of the new AdminServer authorization options in 9.1D (-admingroup and -requireusername) ?

GOAL:

How to enable AdminServer authorization security after intallation

GOAL:

How to secure access of the AdminServer to specific users

GOAL:

How to make sure that a non-authorized user access an AdminServer via Progress Explorer tool

FACT(s) (Environment):

All Supported Operating Systems
Progress 9.1D
Progress 9.1E

FIX:

ngAdminServer Security At Install

Starting on Progress Version 9.1D, an optional functionality was implemented that allows access to the AdminServer based on a user?s membership in a group that has the appropriate privileges to perform AdminServer operations.

Checking a user?s group membership consists of the following two processes:
Authentication - Determines the user is valid by requiring username and password. This functionality exists prior to Progress Version 9.1D.
Authorization - Once authenticated, determines whether you can or cannot use the AdminServer.

During the installation process, administrators are asked if they wants to enable user authorization:
- If the administrator chooses not to use authorization, the AdminServer functionality works as it did in Progress Version 9.1C. That is, there is no group checking and no authorization of users.
- If the administrator chooses to use authorization, the installation prompts for the name of the group or list of groups. The default group is PSCAdmin. The AdminServer is then going to require authorization and authentication for all operations it performs, including startup and shutdown.

NOTE: On Windows, the AdminServer, by default, it is started up using a default account called LocalSystem. The AdminServer Authorization dialog box also has a username and password option, that, if selected, changes the LocalSystem to a specific username and password.

Groups are set up in the operating system, outside of the Progress environment; however, an administrator using Progress Version 9.1D can also set up groups in a minimal fashion (locally only) during the Progress install. It is up to the administrator to determine who belongs in which particular group. If, after the Progress installation, a user attempts to perform an operation and does not belong to a group with that privilege, users are informed that they are not authorized to perform that operation and will be referred to the system administrator for assistance.

Determining group membership is up to the administrator and is based on a variety of factors that differ from company to company, such as company policy, operating system, version number, procedures, etc.


Option To Require Authorization On the Command Line
If the administrator accepts the default installation and does not choose to use authorization, authorization can optionally be selected when starting up the AdminServer. The new command-line option for authorization with the AdminServer is AdminGroup (-admingroup) has the following syntax:

SYNTAX
-admingroup group[:group...]

For the AdminGroup startup parameter, there must be a minimum of one group. If multiple groups are listed, they are separated with a colon. The AdminServer will not start unless a minimum of one group exists. To perform AdminServer functions, the user has to be a valid account in one of the groups.

The following lists the user group authorization platform support:

On UNIX
- Any local or NIS group name
- Supports subgroups

On Windows
- Any local or Domain group name
- Supports global groups as members of local groups


Option To Require a Valid Username and Password

In Progress Version 9.1D, a user can require that when users are starting servers of the AdminServer (AppServer, SonicMQ, and WebSpeed) the ubroker.properties file must provide a valid username and password. This enhanced authentication for starting the AppServer, WebSpeed, and SonicMQ Adapter uses the ubroker.properties file hierarchy to find usernames and passwords. A new Progress Explorer password field (which Progress recommends as the preferred method for updating the ubroker.properties file) can be set to supply the u.sername?s password.

The new command-line option that tells the AppServer, WebSpeed, and SonicMQ to require a username and password from the ubroker.properties file is Require Username (-requireusername). Progress Version 9.1D still uses the manual password field generator if you do not use the Progress Explorer. The user runs <install-dir>\bin\genpassword. This gives the user an obfuscated password that the user can enter into the Progress Explorer. Alternately, but not recommended, the user can cut and paste this password into the ubroker.properties file.

The Require Username syntax is as follows:

SYNTAX
-requireusername.