Configuring Authentication

In this section:

Authentication is the process of validating user credentials. Individuals who use WebFOCUS may have user IDs and passwords managed by other systems. WebFOCUS Managed Reporting and the Reporting Server can each be configured to authenticate users to an external security system, or to trust that authentication has already taken place. Users benefit because they do not have to sign in multiple times or manage separate user ID/password combinations. If a user signs in to WebFOCUS with credentials from an outside security package, the package provides some type of authentication confirmation to the WebFOCUS Client or the Reporting Server. This information may be in the form of a browser cookie or a logon ticket and may be needed by the Reporting Server in order for it to access and retrieve the data required by the WebFOCUS application.

Depending on your operating environment, user credentials can be validated by:

Multiple security providers can be configured. You can configure additional providers using the Web Console Access Control page.
Top of page
x
Configuring a New Security Provider

Security providers must be configured from the Web Console Access Control page.

To switch to security provider LDAP, DBMS, or CUSTOM, you first need to add a new provider under the appropriate security provider on the Access Control tree. When you add a new provider, the server updates configuration file edaserve.cfg with provider blocks named LDAP_PROVIDER, DBMS_PROVIDER, or CUSTOM_PROVIDER. These blocks are inserted with all attributes that apply to the provider type between BEGIN and END dividers.

Security provider PTH is configured during installation of the server. The OPSYS security provider is always on the list of providers. In order to make it an active provider, the server must be authorized (privileged) to start with security OPSYS. There is no need for the additional step of creating a new provider as is needed for LDAP, DBMS, and CUSTOM providers. By default, the effective server administrator ID shown on the Manage Providers page is the server administrator ID. You can change this using the Access Control Settings page. Once the server is installed, you can start adding new PTH users and PTH groups, and you can assign PTH users to PTH groups.

Security provider CUSTOM supports using non-standard security storage. You can create DBMS tables to store users, groups, and passwords. You must then write procedures to read these tables and perform the basic security tasks. This security mechanism has to be created prior to configuring the CUSTOM security provider and must be available when the CUSTOM provider is added to the server provider configuration. It must perform the following standard security tasks:

Once the provider is added, you can change security providers from the Access Control page. Right-click the Security Providers folder and select Manage Providers to switch to a newly added provider. At this point, edaserve.cfg is updated with the security_provider attribute that specifies the provider name.

Multiple security providers can be configured. When you configure OPSYS as one of multiple security providers:

The Access Control Settings page lets you enter valid OS credentials.

When you configure multiple providers, you choose one to be primary on the Access Control Manage Providers page. Drop-down lists are available for assigning the other providers as secondary providers or inactive. The primary provider defines the security under which the server is running:

During connection to the server, all provider users are connected with a two-part user ID consisting of the provider name and the user ID, for example, MyLDAP\User1 or MyDBMS\User2, where MyLDAP or MyDBMS is the name of a configured secondary provider.

This naming convention is also used when users and groups are registered to server roles. Users and groups are registered with a two-part name. If the PTH provider is a secondary provider, PTH users and groups are registered (and used on connection) as PTH\userid and PTH\groupid.
Example: Security Provider Blocks in edaserve.cfg

The following is an example of a security_provider attribute and security provider block for starting the server with security LDAP (provider name MyLDAP):

security_provider = MyLDAP
LDAP_PROVIDER = MyLDAP
BEGIN
  ldap_host = ldaphost
  ldap_port = post 
  ldap_secure_connection = n
  ldap_user_base = dc=ibi,dc=com
  ldap_user_scope = subtree
  ldap_user_class = person
  ldap_user_attribute = uid
   .
   .
   .
END

The following is an example of a security_provider attribute and security provider block for starting the server with security DBMS (provider name MyDBMS):

security_provider = MyDBMS
DBMS_PROVIDER = MyDBMS
BEGIN
  security_dbms = MSSSQL
  security_connection =CON01
END
Top of page
x
Configuring OPSYS Authentication

In this section:

How to:

When security provider OPSYS is configured, the user credentials from the client connection are authenticated by the native security system of the operating system. The server then allocates a data access agent that impersonates the user so that access to files or other objects is controlled by the native system.

Profiles for operating-system users are supported on all platforms. On Windows, Active Directory groups are supported based on the win_primgroup_adsi setting.

Details about OPSYS security requirements are provided in the Server Installation manual, where specific sections are provided for each platform. Refer to this manual for installation instructions and platform-specific setup steps. The following is a summary of the OPSYS requirements:

Note that some system specific settings in the edaserve.cfg file are provided to allow further adjustments of the authentication mechanism. Those relevant for some UNIX systems are:

For Windows systems, the logon_method setting (for interactive, network, or batch) is relevant to explicit connections.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.
x
Procedure: How to Change the Impersonation User ID

When you first add an OPSYS security provider, the impersonation ID is created by copying the effective server administrator ID.

If you need to change the impersonation ID for an OPSYS security provider, do the following.

  1. Sign in to the server with Server Administrator privileges.
  2. Go to the Access Control page.
  3. Right-click the Access Control tree and select Settings from the context menu, or click Settings on the ribbon.

    The Access Control Settings page opens.

  4. Enter the user ID and password for the impersonation ID in the appropriate fields.
  5. Click Apply and Restart Server.
x
Procedure: How to Enable Primary Group Support for Windows Active Directory

When the Reporting Server runs on the Windows platform configured for an OPSYS security provider against an Active Directory, you can set the win_primgroup_adsi keyword to support Active Directory primary group notation. When you set the parameter to y, the server uses the primary group of the user as the name for the group profile and for some access controls under the Web Console. (Note that you can only set the primary group from Windows Active Directory interface to Users management.) In order to take advantage of this setting, you must ensure that the Windows machine that hosts the server resides in the same domain as the Active Directory.

  1. Access the Web Console with a server administrator user ID.
  2. Click Access Control.

    The Access Control page opens.

  3. Open the Security Providers folder in the navigation pane.
  4. Right-click OPSYS and select Properties.

    The OPSYS Security Configuration page opens.

  5. Select y from the win_primgroup_adsi drop-down menu.
  6. Click Save.
x
Procedure: How to Configure an OPSYS Security Provider

This procedure assumes that the server is already running configured for a non-OPSYS security provider.

  1. Access the Web Console with a server administrator user ID.
  2. Click Access Control.

    The Access Control page opens.

    The server security provider is displayed on the Access Control page.

  3. Right-click the Access Control folder in the navigation pane, and select Manage Providers.

    The Manage Providers page opens.

    Note: For more information about changing security providers, see Considerations for Changing the List of Security Providers From the Web Console.

  4. Click Save Provider’s Status.

    Note: If you change the privileges of tscom300, the server will start with security OPSYS by default. For more information, see the Server Installation manual.

  5. For z/OS Unified Server only. Starting with z/OS 1.7, the z/OS security package provides extended password support. If this option is enabled, you must add mixed_case_password=on to the edaserve configuration file before starting the server in configured for an OPSYS security provider. For HFS deployment, this file is in $EDACONF/etc and for PDS deployment it is in qualif.servertype.CONF.CFG, where servertype is determined by your license key.
  6. If the server is not running, start it using the instructions for your platform in the installation guide.

    The server will start configured for an OPSYS security provider.

  7. Examine the edaprint.log file. If it indicates errors, stop the server, correct the errors, then start it with security OPSYS.
  8. Restart your browser and connect to the Web Console. When prompted, enter a valid operating system user ID and password.

If you wish to register other users in a role or group or create new roles, first connect as a Server Administrator. Then, follow the instructions in Registering Users and Groups in a Role.

x
Preventing Unsecured Server Starts After Upgrades

If the environment variable EDAEXTSEC is explicitly set to OPSYS, and the server fails to start because it lacks system privileges to start configured for an OPSYS security provider, the server start aborts and error messages are written to the edaprint log file.

This feature prevents an unsecured server start after a software upgrade if any of the required post-upgrade reauthorization steps are missed on a UNIX, IBM i, or z/OS HFS deployment. This is not applicable to other platforms. The setting may be placed in any normal server start-up shell or profile that a site is using or in the server edaenv.cfg configuration file. The messages vary slightly by platform.

The edaprint messages are:

Configured security is 'ON' as set by EDAEXTSEC variable.

Server has no root privilege. (UNIX)

Server is not APF-authorized. (z/OS HFS)

TSCOM300.PGM has no QSECOFR authority. (IBM i)

Workspace initialization aborted.
(EDA13171) UNABLE TO START SERVER
x
Using Password Phrases for Authentication on z/OS

Starting with z/OS 1.8, IBM introduced password phrases which can be used for authentication, and starting with z/OS 1.10 password phrases can be used for TSO Logon as well. Password phrases can be from 14 to 100 characters long.

z/OS IDs can have both a password (1 to 8 bytes) and a passphrase (from 14 to 100 bytes). The two forms of credentials are independent. Changing one does not change the other. The server recognizes the type of credential being presented by its size (sizes between 9 and 13 are invalid on z/OS).

No special configuration is needed to enable password phrases.

When a users log into the Web Console, there are two possible ways they can change their passwords or passphrases:
x
Procedure: How to Change Passwords on the Web Console Logon Screen

By default, passwords cannot be changed on the Web Console Logon page because the following parameter is in effect:

password_change_wclogin = n 

To enable the option to change passwords when logging into the Web Console:

  1. Select Access Control from the Web Console menu bar.
  2. Right-click Access Control on the tree and select Settings from the context menu.
  3. Change the value of the password_change_wclogin parameter to y.

On the same configuration page, you can change the delimiter used to separate the user ID from the password or passphrase to any valid character accepted by the operating system. By default, the delimiter is a comma:

password_change_delimiter= ,

Once the option to change passwords on the Web Console Logon page is enabled, users can change their passwords or passphrases by entering the following in the password field of the Web Console Logon page (if the password delimiter has been changed, use that character between the old and new passwords instead of the comma):

old_password,new_password 

When password_change_wclogin = y, passwords and passphrases cannot contain the password delimiter character.

When password_change_wclogin = n (the default), the setting for password_change_delimiter is ignored, and passwords can contain all valid characters allowed by the operating system.
x
Configuring Linux and AIX Pluggable Authentication Modules (PAMs)

In a Linux or AIX environment, OPSYS security can be configured to use Pluggable Authentication Modules.
x
Procedure: How to Configure PAM Security on Linux and AIX
  1. Select Access Control on the Web Console menu bar.

    The Access Control Page opens.

  2. Right-click the OPSYS security provider and select Properties from the context menu.
  3. Select y from the security_pam drop-down list.

    This parameter is only applicable for the Linux and AIX operating systems. The parameter defines if the server uses the Pluggable Authentication Modules mechanism to implement security. If y, the server uses PAM calls, if n the server uses native UNIX security calls.

  4. Click Save and Restart Server.
Top of page
x
Configuring PTH Authentication

In this section:

How to:

By default, the server installation process establishes PTH security with a PTH server administrator user ID and password. If you deleted the PTH server administrator ID, you can reconfigure PTH security.

The PTH security provider only controls access to the Web Console. When the server is configured for this security provider, there is no impersonation by data agents or authentication of a non-Web Console connected user. From the operating system point of view, all server processes run as a single user ID, and access to the Web Console is controlled by authenticating names against those defined in the admin.cfg file unless authenticate_all_pthuser is set to y. The setting is available on the PTH Security Configuration page, which can be accessed by right-clicking PTH in the Security Providers folder on the Access Control navigation pane.

You must configure the Server Administrator password before starting a server configured for a PTH security provider, either by providing it at installation time or by configuring it in the Web Console. For details, see Registering Users and Groups in a Role.

The PTH security provider supports profiles for users and groups on all platforms.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.
x
Procedure: How to Configure a PTH Security Provider
  1. Select Access Control on the Web Console menu bar.
  2. Right-click the Access Control folder, and select Manage Providers.

    The Manage Providers page opens.

  3. Select the PTH drop-down list, and select Primary or Secondary. from the list of providers in the last Security Provider drop-down box and enter a Server Administrator ID and Password.
  4. Click Save Provider’s Status.

    Once the server has restarted, the PTH security provider has icons for adding and viewing its users and groups.

  5. If the server is not running, start it using the instructions for your platform.

    The server will start configured for a PTH security provider.

  6. Examine the edaprint.log file. If it indicates errors, stop the server, then start it with security OFF to correct the errors.
  7. Restart your browser and connect to the Web Console. When prompted, enter a valid PTH user ID and password.

If you wish to add other PTH users, first connect as a PTH user defined as server administrator. Then, follow the instructions in How to Manage Users and Groups With PTH Security.

Note: A common problem when switching from OPSYS to PTH is the existence of files in EDATEMP that cannot be removed due to insufficient privileges. To handle this problem, use edastart -cleardir (or member ICLRDIR on the z/OS platform) using an OPSYS security provider to clear the directory before switching.
x
Configuring Password Properties for a PTH Security Provider

When the Server Administrator creates or updates a user under a PTH security provider, by default the password never expires, can be any length, and are not case-sensitive.

The Server Administrator can configure a new or existing user password to expire after a specified number of days, can set a minimum length for passwords, and can enable case-sensitive passwords.
x
Procedure: How to Configure Password Properties for a PTH Security Provider

To assign an expiring password:

  1. Select Access Control.
  2. Right-click PTH and select Manage Users/Groups.

    The PTH Users and Groups Management page opens.

  3. If the user does not yet exist, create the user. Then, select the user on the list and click Properties.

    By default, the Password never expires box is checked.

  4. Uncheck the Password never expires box.

  5. Click OK.

    The current date is saved in admin.cfg as admin_passdate for this user. This is the last password change date.

  6. Click Save.
  7. Configure the number of days before passwords expire and whether they are case sensitive:
    1. Right-click the PTH Security Provider and select Properties.
    2. Set pthpass_lifetime to the number of days after which the password should expire.

    3. To make the passwords case-sensitive, select y from the pthpass_casesensitive drop-down list.
    4. To set a minimum length for passwords, enter a number of characters in the pthpass_length entry field.
    5. Click Save and Restart Server.

    When the password expires, the user gets a password expired message on the logon screen and is provided with a New Password field in order to enter a new password.

    At this time, the new password and new password change date are recorded in admin.cfg.

    Note that changing the password by selecting Change Password from the My Console menu also resets the password change date.

  8. Optionally, configure a warning message to begin displaying a specified number of days before the password expires.
x
Disabling a PTH Security Provider Account

You can disable an account that is registered in admin.cfg under the PTH security provider in order to prevent a user from signing in to the server with that account.

To disable a PTH account:

  1. Right-click PTH under the Security Providers folder, and select Manage Users/Groups from the context menu.

    The PTH Users and Groups Management page opens, listing all registered users on the left, and all registered groups on the right.

  2. Select a user and click Properties.

    The PTH User properties dialog box opens.

  3. Click Account disabled as shown in the following image:

  4. Click OK.

    A red x is displayed in the Disabled column for that user on the PTH Users and Groups Management page.

  5. Click Save.
Top of page
x
Configuring DBMS Authentication

In this section:

How to:

Reference:

With a DBMS security provider, there is no impersonation by data agents, but connection credentials are authenticated against a configured DBMS. This technique is called password passthru, as user IDs and passwords supplied by the client are passed to the DBMS for authentication.

A DBMS security provider supports profiles for users on all platforms. Profiles for groups are not supported.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.
x
Procedure: How to Configure DBMS Authentication

This procedure assumes that the server is already running.

  1. Access the Web Console with a server administrator user ID.
  2. From the Adapter pane, configure a DBMS adapter and connection.
  3. Select the Password Passthru security option on the Adapter configuration pane.

    Note that the Test button, which appears next to the Configure button, will not work until you configure the DBMS security provider. Do not restart the server at this point.

  4. Select Access Control. The Access Control page opens.

    The server security provider is displayed on the Access Control page.

  5. To add the DBMS provider, expand the Security Provider folder, right click DBMS, and choose New.
  6. Enter a name for the DBMS provider.
  7. Select a security_dbms from the drop-down list.

    This option identifies the database engine used to authenticate incoming requests.

  8. Select a security_connection from the drop-down list. This list shows all DBMS connections that are configured with Password Passthru.

    This option identifies the database connection used to authenticate incoming requests.

  9. At this point, it is a good idea to click the Test button to make sure the DBMS connection is working. You will be prompted for a password for the selected user ID. Click Continue. The DBMS will authenticate this ID. If it is a valid DBMS ID, a message will be returned indicating that authentication was successful. If the ID is not a valid DBMS ID, the DBMS will return messages indicating that authentication was not successful.
  10. Right-click the Access Control folder in the navigation pane, and select Manage Providers.

    The Manage Providers page opens.

  11. Select the DBMS drop-down list, and select Primary or Secondary.
  12. Supply the Server Administrator user ID. Alternatively, you can enter a new user ID that will be added to the admin.cfg file as a Server Administrator.
  13. Click Save Provider’s Status.

    Note: For more information about changing security providers, see Considerations for Changing the List of Security Providers From the Web Console.

  14. If the server is not running, start it using the instructions for your platform.

    The server will start configured for a DBMS security provider.

  15. Examine the edaprint.log file. If it indicates that there were any errors, stop the server and then start it with security OFF to correct the errors.
  16. Restart your browser and connect to the Web Console. When prompted, enter a valid DBMS user ID and password.

If you wish to add other DBMS users, first connect as a DBMS user defined as server administrator. Then, follow the instructions in Registering Users and Groups in a Role.

Note: A common problem when switching from OPSYS to a DBMS provider is the existence of files in EDATEMP that cannot be removed due to insufficient privileges. To handle this problem, use edastart -cleardir (or member ICLRDIR on the z/OS platform) with EDAEXTSEC=OPSYS to clear the directory before switching.
x
Reference: Usage Notes for DBMS Security
x
Reference: Password Pass-through and Security DBMS

Security DBMS (using password pass-through) is supported for the following engines:

x
Logon Ticket Authentication for Logging Onto the SAP Portal

Single sign-on (SSO) enables users to login to the SAP portal with their credentials and then access WebFOCUS components, such as the Reporting Server with the SAP R/3 and SAP BW adapters, the Web Console, and the WebFOCUS client (Managed Reporting) without a secondary logon. This is achieved in the following manner:

x
Procedure: How to Ensure Compliance With SSO Prerequisites for SAP BW and SAP R/3

Complete the following steps to ensure that prerequisites have been met:

  1. Export the public key certificate from the SAP portal into $EDACONF/etc.
  2. Set Server security to DBMS.
  3. Configure the SAP/BW or SAP R/3-ECC connection for Password-Passthru.
  4. Ensure that Security DBMS with Password-passthru to SAP/BW or SAP R/3-ECC is working.
  5. Ensure that SAP RFCSDK 6.40, SAP SSOEXT, and SAP SECULIB 5.4 are in the path. (Check your Operating System or consult a system administrator for details.)

Once prerequisites have been satisfied, complete the SSO verification procedure.
x
Procedure: How to Complete SSO Verification
  1. From the SAP portal (http://sapportal.mydomain.com:50000), execute a command that requires authentication (using a logon screen from the Portal).

    This generates an SSO cookie.

  2. Overwrite the SAP portal url with the one for the WebFOCUS Reporting Server, using the same domain (for example, http://iwayserv.mydomain.com:8101).

    At this point, no logon screen should pop up since the user is logged in and SSO login has been successfully verified.
Top of page
x
Configuring LDAP Authentication

How to:

Reference:

With an LDAP (Lightweight Directory Access Protocol) security provider, there is no impersonation by data agents, but connection credentials are authenticated against the established directory services. From the operating system point of view, all server processes run as a single user ID.

An LDAP security provider is presently supported on Windows, UNIX, IBM i, and the Unified Server (HFS and PDS deployments).

An LDAP security provider supports profiles for LDAP users and LDAP groups.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.
x
Procedure: How to Configure an LDAP Security Provider
  1. Sign in to the Reporting Server Web Console as a server administrator.
  2. Open the Access Control page.
  3. If this is the first LDAP security provider being configured:
    1. Right-click the LDAP folder under Security Providers, and select Properties from the context menu.
    2. Select the LDAP vendor from the drop-down list and click Continue.

      If you choose OpenLDAP on LINUX, you will see two additional fields, ldap_libldap and ldap_liblber. These parameters specify the names of the OpenLDAP libraries that the server module loads at run time. The path to the libraries should be available to the server at run time. You are prompted to specify the library name at run time. If you do not supply a different name a default library name is used.

  4. Under the Security Providers folder, right-click LDAP and select New.

    The LDAP Security Provider Configuration page opens.

  5. Enter or select values for the following Connection Properties.
    LDAP_PROVIDER

    Specifies a name for this provider.

    ldap_host

    Is a host identifier consisting of a host name or an IPv4 dotted string representing the IP address of a host running the LDAP server to connect to.

    Alternatively, it may contain a list of space-delimited host identifiers. Each host identifier may include a trailing colon and port number. In the case where more than one host identifier is specified, each host identifier in turn will be contacted until a connection can be established. For example: 

    directory.example.com 
192.0.2.0 
directory.example.com:1050 people.catalog.com 192.0.2.0
    ldap_port

    Is a positive integer that defines the TCP port number used to connect to the LDAP server. Note that ldap_port is ignored for any host identifier which includes a colon and port number. The server default port is 389 or 636 (for SSL connection).

    ldap_secure_connection

    Specifies whether the server uses a Secure Socket Layer (SSL) session with the LDAP server. Select No or Yes. The server default is No.

    An LDAP (Lightweight Directory Access Protocol) security provider supports Secure Sockets Layer (SSL) API calls to establish an SSL/TLS connection. Using server authentication only, the Reporting Server initiates API calls to verify that the LDAP server being connected to is the same server that provided certification.

    You can set the LDAP secure connection from the Web Console:

    • Select No, the default value, if you do not wish to enable SSL.
    • Select Yes to enable an encrypted Secure Sockets Layer (SSL) session with the LDAP server.

    If you have selected IBM, Sun, or Novell as the your ldap_lib_vendor, when you select Yes in the ldap_secure_conection field, additional options are added to the Connection tab:

    • For Sun and IBM, ldap_ssl_certificate is added.
    • For Novell, ldap_ssl_certificate and ldap_ssl_certification_encoding are added.

    ldap_ssl_certificate. Enter the name of the LDAP attribute used by the API to establish the SSL/TLS connection. The server employs server authentication only, checking through API calls that the LDAP server you are connecting to is the one that provided the certificate. Values depend on the LDAP vendor, as follows:

    • Novell API specifies the file name, including path, of the Trusted Root Certificate that the LDAP server provided for authentication.
    • Sun/Netscape API specifies the path to cert7.db, Netscape certificate database, excluding the file name, that the LDAP server provided for authentication.
    • IBM API specifies the file name, including the path, for ldapkey.kdb (IBM key database file that the LDAP server provided for authentication). The ldapkey.sth password stash file should be in the same directory. Note that in addition to IBM LDAP client libraries, Global Security Kit libraries are needed to make SSL work. On Windows machines, GSK must be installed.
    • Microsoft API ignores the ldap_ssl_certificate configuration parameter since it is not used in an Active Directory. The server certificate should be installed in a certificate store.

    ldap_ssl_certificate_encoding. For Novell, select the standard used to encode the certificate from the drop-down list. Encryption and file format depend on API vendor specifications. The options are B64 and DER.

    security

    Determines the type of bind used. Can be one of the following.

    Anonymous

    The bind is performed using no credentials. This is the internal default value.

    Windows security (NEGOTIATE)

    The reporting server authentication is performed against Active Directory utilizing a Windows-specific API.

    The bind is done under the Windows account that started the server.

    The windows machine that hosts the reporting server should be in the same domain as Active Directory.

    Explicit

    The bind is performed under the account that is defined by configuration parameters ldap_principal and ldap_credentials.

    Note: When connecting to Active Directory using Explicit or NEGOTIATE, ldap_user_attribute should have the value sAMAccountName or userPrincipalName.

    ldap_search_timeout

    Specifies the timeout in seconds for ldap_search. The server default value is 60 seconds.

    ldap_principal

    Specifies the DN of a service account with sufficient access rights to locate user entries in the directory. Consists of attribute=value pairs, separated by commas. This parameter is required when the LDAP provider is configured with a security setting that requires credentials in order to initiate a search for a user, group, or related information.

    ldap_credentials

    Contains the password of the service account defined in ldap_principal.

  6. Click Next. The server will try to connect and get User and Group properties. If it is not successful, you must manually edit User and group properties.
  7. If the server could not connect with just the Connection Properties, enter values for the User and Group properties.

    Note: If the properties for a specific category are not visible, click the down arrow on the separator bar for that category to display them.

    User properties

    ldap_user_base

    Specifies the DN of the entry that serves as the starting point for the search. Consists of attribute=value pairs, separated by commas.

    ldap_user_scope

    Specifies the scope with which the LDAP realm should search for users. Select Subtree, Onelevel, or Base:

    Subtree scope indicates that the LDAP realm should search everything under the base DN.

    Onelevel scope tells the LDAP server to only search entries one level down from the base DN.

    Base indicates that the search should be done at the search base only.

    The server default is Subtree.

    ldap_user_class

    Specifies the object class used when searching for user entries. The server default is person.

    ldap_user_attribute

    Specifies the LDAP attribute used when searching for user entries. uid is the default value for LDAP and sAMAccountName is the suggested value for Active Directory. One possible reason to change the default value would be to allow users to logon with an email address instead of a user ID. In this case, you might change the value to mail or userPrincipalName (if this corresponds with the name of the appropriate attribute in your directory).

    ldap_user_group_attribute

    Specifies the LDAP attribute used to identify a group in a user object.

    The Active Directory standard is Memberof.

    ldap_user_description

    Specifies the name of the attribute whose value contains description of an object (user, group). The server default is description.

    ldap_user_email

    Specifies the name of the attribute whose value contains the user email address. The server default is mail.

    Note: ldap_user_class, ldap_user_attribute, ldap_group_class, ldap_group_attribute are parameters that form a search filter.

    The search filter standard syntax conforms to the following structure: 

    (&(Property_Name=Property_Value)(Property_Name=Property_Value))

    If you change value of the ldap_user_class and ldap_group_class parameters to an asterisk (*), the search filter syntax can be reduced to the following simplified form (although group support will not work properly):

    (Property_Name=Property_Value)

    By specifying an asterisk for these parameters, you achieve simplified search filter syntax, but in effect, disable group support.

    Group properties

    ldap_group_base

    Specifies the DN of the entry that serves as the starting point for the search. The server default is the ldap_user_base value.

    ldap_group_scope

    Specifies the scope with which the LDAP realm should search for groups. Select Subtree, Onelevel, or Base:

    Subtree scope indicates that the LDAP realm should search everything under the base DN.

    Onelevel scope tells the LDAP server to only search entries one level down from the base DN.

    Base indicates that the search should be done at the search base only.

    The server default is Subtree.

    ldap_group_class

    Specifies the object class used when searching for group entries. The server default is groupofuniquenames. The Active Directory standard is group.

    ldap_group_attribute

    Specifies the LDAP attribute used to identify the name of the group. The server default is cn.

    ldap_member_attribute

    Specifies the LDAP attribute used to identify users in a group. The server default is uniqueMember. The Active Directory standard is Member.

    ldap_nested_groups

    Disables or enables LDAP nested groups support. Select No or Yes. The server default is No, which disables nested group support.

  8. To test the connection, click Test.

    A Test LDAP Connection logon window opens.

    1. Enter a valid user ID and password for this LDAP security provider.
    2. Click Continue.

    If your configuration and credentials are valid, a window opens telling you that you were successfully authenticated.

    If they are not valid, you will get a corresponding message.

  9. To save this configuration, click Save.

    The Change Effective Security Provider(s) page opens.

    1. Select a Security Provider name from the drop-down list.

      Note: Each time you select an LDAP Security Provider, another Security Provider drop-down box is generated.

    2. Enter or select the user ID of the Server Administrator. The user must be a valid server administrator in the LDAP database.
    3. If the server was not started configured for an LDAP security provider, the button at the bottom of the page says Apply and Stop Server. Click the button and manually start the server configured for an LDAP security provider.

      If the server is already running configured for an LDAP security provider, the button at the bottom of the page says Apply and Restart Server. Click the button and wait for the server to restart.

  10. If the server was started configured for an OPSYS security provider, click the Apply and Stop button. Otherwise, click the Apply and Restart button.
    • If you click Apply and Stop, the server stops; proceed with Step 9.
    • If you click Apply and Restart button, the server restarts configured for an LDAP security provider.

    Note: For more information about changing security providers, see Considerations for Changing the List of Security Providers From the Web Console.

  11. If the server is not running, start it using the instructions for your platform.

    The server will start configured to use an LDAP security provider.

  12. Examine the edaprint.log file. If it indicates errors, stop the server, then start it with security OFF to correct the errors.
  13. Restart your browser and connect to the Web Console. When prompted, enter a valid LDAP user ID and password.
  14. When you start the server using an LDAP security provider, you can select an LDAP Provider from the Security Provider drop-down list. By default, the primary (first) LDAP security provider is selected.

Note: A common problem when switching from OPSYS to LDAP is the existence of files in EDATEMP that cannot be removed due to insufficient privileges. To handle this problem, use edastart -cleardir (or member ICLRDIR on the z/OS platform) with EDAEXTSEC=OPSYS to clear the directory before switching.
x
Procedure: How to Remove an LDAP Security Provider From the Web Console
  1. Logon to the server with Server Administrator credentials.
  2. Select Access Control.

    The Access Control page opens.

  3. Right-click the security provider that you want to remove in the Security Providers folder and select Remove from the context menu.

    A dialog box opens asking you to confirm that you want to remove the provider.

  4. Click OK.
x
Reference: LDAP Vendor Library Prerequisites

Important: Although the Server supports a number of vendor libraries for each platform, as described in the following chart, Information Builders recommends that, whenever possible, you use the native libraries for your Operating System.

System Requirements. An LDAP Security provider requires the appropriate LDAP vendor library files to be available to the server at run time:

  1. If the LDAP vendor library files are not currently available on the server platform, download them from the appropriate vendor Web site, unzip them if necessary, and transfer them to the server platform.
  2. Edit the library path or (on Windows) the system path to include the location of the library files.

Windows: The LDAP vendor library files for Windows systems are:

Sun

IBM

Novell

Microsoft

libnspr4.dll
libplc4.dll
libplds4.dll
nsldap32v50.dll
nsldappr32v50.dll
nsldapssl32v50.dll
nss3.dll
sasl32.dll
ssl3.dll

(64 bit NA)

libidsldap.dll
libibmldapdbg.dll

ldapsdk.dll
ldapssl.dll

(64 bit NA)

wldap32.dll
advapi32.dll

IBM z/OS and IBM i: The LDAP vendor library files for IBM z/OS and IBM i systems are:

z/OS

statically linked

IBM i

statically linked

UNIX: The LDAP vendor library files for UNIX systems are:

OS

Vendor

Sun (Sun ONE Directory Server Resource Kit 5.2.1, except as noted)

IBM

Novell

OpenLDAP

AIX

libldap50.so
libnspr4.so
libnss3.so
libplc4.so
libplds4.so
libprldap50.so
libsasl.so
libssl3.so
libssldap50.so

(64 bit NA)

statically linked

libldapsdk.so

(64 bit NA)

N/A

HP

libldap50.sl
libnspr4.sl
libnss3.sl
libplc4.sl
libplds4.sl
libprldap50.sl
libsasl.sl
libssl3.sl
libssldap50.sl

(see notes following chart)

statically linked

(64 bit NA)

libldapsdk.sl
libldapssl.sl

(64 bit NA)

N/A

Linux

libldap50.so
libnspr4.so
libnss3.so
libplc4.so
libplds4.so
libprldap50.so
libsasl.so
libssl3.so
libssldap50.so

(64 bit NA)

libibmldap.so
libldapiconv.so

(64 bit NA)

libldapsdk.so
libldapssl.so

(64 bit NA)

libldap_r.so
liblber.so

SunOS 5.8

libldap50.so
libnspr4.so
libnss3.so
libplc4.so
libplds4.so
libprldap50.so
libsasl.so
libssl3.so
libssldap50.so

libibmldap.so

libldapsdk.so
libldapssl.so

(64 bit NA)

N/A

SunOS 5.9 and 5.10

libldap.so

(Native SunOS library)

libibmldap.so

libldapsdk.so
lilbldapssl.so

(64 bit NA)

N/A

Note:

Example: Making Sun LDAP Library Files Available

To make Sun LDAP library files available to the server at run time:

  1. Access the product download Web site for Sun ONE Directory Server Resource Kit 5.2.1:

    http://www.sun.com/download/products.xml?id=3f74a0db

    (Note that this URL is correct as of the date these Release Notes were published. Third-party URLs are subject to change.)

  2. Click the Download link at the bottom right of the Web page. (Do not click the Downloads menu option at the top of the page.)

    The login page opens. You will be prompted for a registered user login or to register.

  3. Enter your Sun username and password. If you do not have an account, click Register Now and follow the prompts to create an account and then log in. This is free.
  4. Accept the license agreement.
  5. Download the appropriate platform package. Select the optimized package, not the debug version.
  6. Once downloaded, unzip the file, and then unzip the second zip file contained within the first.
  7. Navigate to the directory in which you unzipped the downloaded file, and then cd to the lib subdirectory.
  8. FTP the files you need (as indicated in LDAP Vendor Library Prerequisites), in binary format, to their own directory on the server platform.
  9. Edit the library path to include the location of the library files you just FTPed.
Top of page
x
Configuring Custom Authentication

How to:

Reference:

CUSTOM security providers are used when the installation maintains non-standard repositories for users and groups, that is, when the standard methods like OPSYS and LDAP do not apply. An example of such a setup can be having RDBMS tables containing valid user IDs and their encrypted passwords, and also containing the mapping of users to groups. The customer may chose to access these tables using SQL SELECT statements, SQL Stored procedures, or Web Services. Typically these methods already exists and are used by other non-Information Builders components.

To enable the custom server security provider, the administrator needs to provide code that allows the server security module to perform these tasks:

The code for performing these tasks is written in the WebFOCUS language as TABLE FILE or SQL SELECT commands against the synonyms representing the SQL table, SQL Stored Procedure, or Web Service. The code can be debugged by running the server with security OFF and running the glue code from application folders. Once debugged, the code is deployed in EDACONF/catalog/xxx, and the CUSTOM provider made active.

A tutorial sample called WebFOCUS- Custom SQL Security Provider is available that creates examples of user and group storage and custom procedures that can be used as prototypes. To generate a tutorial, right--click an application on the Application page and select New then Tutorials from the context menu.
x
Procedure: How to Configure a Custom Security Provider
  1. On the Access Control page, right-click CUSTOM and select New from the context menu.

    The CUSTOM Security Provider Configuration page opens.

  2. Enter values for the following parameters:
    CUSTOM_PROVIDER

    Is a name to assign to the security provider.

    cust_authenticateuser

    Is the name of the procedure that authenticates users. For information about creating an authentication procedure, see Creating an Authentication Procedure for a Custom Provider.

    If you do not specify an authentication procedure, you must have a default server administrator user ID and password to use when connecting to the server. A default server administrator user ID was configured during server installation.

    cust_usersbygroup

    Is the name of the procedure that returns the list of all users or, if the group name is passed to the procedure, the list of all users in the group. For information about creating a procedure that returns users, see Creating a Procedure That Returns Users.

    cust_groupsbyuser

    Is the name of the procedure that returns the list of all groups or, if a user ID is passed to the procedure, the list of all groups for the user ID. For information about creating a procedure that returns groups, see Creating a Procedure That Returns Groups.

    cust_service

    Defines the data service to execute stored procedures specified in the custom security provider.

    trust_ext

    Specifies whether the server should accept trusted client connections using this provider.

    The procedures can be located under the server configuration directory (EDACONF/catalog), the installation directory (EDAHOME/catalog), or in an application that is on the application path of every user.

    We suggest that the synonyms used by custom provider procedures be copied to the directory EDACONF/catalog/custom. This will cause the server to protect adapter connections used by custom procedures. This means that only the Server Administrators and users with privilege WSCFG will have access to security data in those synonyms. All other users attempting to use this adapter connection will get an unauthorized message.

  3. To test your configuration, click Test.
  4. When you are satisfied with the test results, click Save.

    Your custom security provider is listed under the CUSTOM item on the Access Control tree.

  5. Select the appropriate primary security provider from the drop-down list and click Next.
    If you are changing primary providers, you may be asked to select or enter a Server Administrator user ID.
  6. Click Save and Restart Server.
x
Reference: Creating an Authentication Procedure for a Custom Provider

The authentication FOCEXEC for a custom provider must check the user ID and password passed to the Reporting Server against the custom provider data source and return a code that defines to the Reporting Server the status of those credentials.

The server calls your authentication FOCEXEC using the following syntax:

EX ptauth ID=user1, PASSWD=pass1 

where:

ptauth

Is the authentication procedure entered in the cust_authenticateuser field of the CUSTOM provider configuration page.

A simple example of an authentication procedure, ptauth.fex, is provided in the home/catalog directory.

user1

Is the user ID to be authenticated. It is stored in a variable named &USERID.

pass1

Is the corresponding password to be authenticated. It is stored in a variable named &PASSWD.

The authentication procedure must authenticate this user ID and password combination against the data source that contains the user credentials.

If the password is stored in encrypted form in the data source, the authentication procedure must encrypt the password using the same encryption process prior to authenticating it.

The authentication procedure must return a code to the Reporting Server based on the result of the authentication process. The syntax is:

-SET &a = SETAUTH(error_code, 'primary_group');

where:

a

Can be any valid variable name, for example &A.

error_code

Must be one of the following integers:

0

Indicates that the user ID and password are valid.

1

Indicates that the user ID is invalid.

2

Indicates that the password is invalid.

3

Indicates that the user ID has expired.

4

Indicates that the password has expired.

5

Indicates that another error occurred.

primary_group

Returns the primary group for the user. Enter the group ID enclosed in single quotation marks. If there is no primary group, enter two consecutive single quotation marks. For example:

-SET &A = SETAUTH(2, '');

You can provide messages in the authentication procedure using the -TYPE command. For example: 

-INVALIDPASS
-TYPE invalid password
-SET &A = SETAUTH(2, '');

The message will display when you click the Test button on the CUSTOM Security Configuration page.

When a user actually attempts to sign in to the server, the server will:
x
Reference: Creating a Procedure That Returns Users

The procedure entered in the cust_usersbygroup field on the CUSTOM Provider Configuration page has to return either all users or, if passed a group ID, all users for that group.

The procedure should retrieve the following fields (some are mandatory, some are optional) from the data source that stores all user IDs and their properties:

User ID

Mandatory

Contains alphanumeric user IDs with a maximum length of 99 (A99).

User Description

Optional

Contains alphanumeric descriptive information with a maximum length of 97 (A79).

User Email Address

Optional

Contains an alphanumeric email address with a maximum length of 127 (A127).

Group ID

Mandatory

Contains alphanumeric group IDs with a maximum length of 99 (A99).

After retrieving the fields, you must issue the PCHOLD FORMAT COMT FORMATTED command to place them in a comma-delimited file with each field value enclosed in double quotation marks. For example:

ON TABLE PCHOLD FORMAT COMT FORMATTED
ON TABLE SET PAGE-NUM OFF
ON TABLE SET HOLDATTR  OFF

The procedure should be able to retrieve the list of all users and the user list for one group.

The following procedure sets the variables &ID, &NAMEFILTER, and &DESCFILTER to _FOC_NULL by default.

It tests these variables to see if a specific group ID, a filter for the user ID, or a filter for the user description was passed to the FOCEXEC:

-DEFAULT &ID='_FOC_NULL',&NAMEFILTER='_FOC_NULL',&DESCFILTER='_FOC_NULL';
TABLE FILE USERINFO
PRINT DST.USERID DST.USERDESC DST.UEMAIL 
IF GROUPID EQ &ID
IF USERID CONTAINS &NAMEFILTER
IF USERDESC CONTAINS &DESCFILTER
ON TABLE PCHOLD FORMAT COMT FORMATTED
ON TABLE SET PAGE-NUM OFF
ON TABLE SET HOLDATTR  OFF
END

This procedure can be run as follows:

A simple example of a users procedure, ptusers.fex, is provided in the home/catalog directory.
x
Reference: Creating a Procedure That Returns Groups

The procedure entered in the cust_groupsbyuser field on the CUSTOM Provider Configuration page has to return either all groups or, if passed a user ID, all groups for that user.

The procedure should retrieve the following fields (some are mandatory, some are optional) from the data source that stores all user IDs and their properties:

Group ID

Mandatory

Contains alphanumeric group IDs with a maximum length of 99 (A99).

Group Description

Optional

Contains alphanumeric descriptive information with a maximum length of 97 (A79).

User ID

Mandatory

Contains alphanumeric user IDs with a maximum length of 99 (A99).

After retrieving the fields, you must issue the PCHOLD FORMAT COMT FORMATTED command to place them in a comma-delimited file with each field value enclosed in double quotation marks. For example:

ON TABLE PCHOLD FORMAT COMT FORMATTED
ON TABLE SET PAGE-NUM OFF
ON TABLE SET HOLDATTR  OFF

The procedure should be able to retrieve the list of all groups and group list for one user.

The following procedure sets the variables &ID, &NAMEFILTER, and &DESCFILTER to _FOC_NULL by default.

It tests these variables to see if a specific user ID, a filter for the group ID, or a filter for the group description was passed to the FOCEXEC:

-DEFAULT &ID='_FOC_NULL',&NAMEFILTER='_FOC_NULL',&DESCFILTER='_FOC_NULL'
TABLE FILE USERINFO
PRINT GROUPID  GROUPDESC
IF USERID EQ '&ID'
IF GROUPID CONTAINS &NAMEFILTER
IF GROUPDESC CONTAINS &DESCFILTER
BY GROUPID NOPRINT
ON TABLE SET PAGE-NUM OFF
ON TABLE SET HOLDATTR  OFF
ON TABLE PCHOLD FORMAT COMT FORMATTED
END

This procedure can be run as follows:

A simple example of a groups procedure, ptgroups.fex, is provided in the home/catalog directory.
Top of page
x
Authenticating Users Across Multiple Security Providers

How to:

Reference:

The Reporting Server can search across multiple LDAP sources, DBMS providers, an OPSYS provider, and a PTH server when authenticating users.

When authenticating or assigning privileges for a provider that is not the primary provider, the user ID is a two-part name consisting of the provider name and the user ID:

					provider\userid 

The authentication is done based on a two-part name.

The Server Administrator can add and remove security providers from the list at any time.

For instructions on configuring PTH and LDAP security providers, see Configuring PTH Authentication or Configuring LDAP Authentication.
x
Procedure: How to Change the Security Provider List

If you want to change the list of security providers:

  1. Logon to the server with Server Administrator credentials.
  2. Click Access Control, and the Manage Providers page appears in the right pane. You can also right-click the Access Control folder and select Manage Providers from the context menu.

    The Manage Providers page opens.

  3. You change the status of a provider by selecting a value from its drop-down list. If you make a provider Primary, the provider that previously had that status changes to Secondary.

Note:

x
Reference: Considerations for Changing the List of Security Providers From the Web Console

You can configure multiple security providers using the Web Console. A security provider can have the status Primary, Secondary, or Inactive. it is important that there be a valid server administrator ID for one of the active (Primary or Secondary) security providers so that you can use it to connect to the Web Console or Data Management Console as a Server Administrator after changing the active security providers list.

When you switch between security providers from the Web Console, you will be prompted to restart the server.

Environment variable EDAEXTSEC is only used to disable server security.
Top of page
x
Enabling Trusted Connections

You can enable trusted connections separately for each security provider.

You can configure a security provider to accept trusted connections by setting its trust_ext value to y.

  1. Right-click a security provider on the Access Control tree and select Properties on the context menu. This example shows a PTH security provider, but the same setting is available for all security providers.

    The Configuration page for that security provider opens.

  2. From the trust_ext drop-down list, select y.

    This setting is available for all types of security providers.

  3. Click Save and Restart Server.
Top of page
x
Identifying a Default Provider for Trusted Groups

When multiple security providers are configured, one must be identified as the default provider for trusted connections when WebFOCUS or other client software sends a trusted group ID without a security provider to the server.

To set the default provider for trusted groups:

  1. On the Access Control page, click Settings on the ribbon, or right-click the Access Control folder and select Settings from the context menu.

    The Access Control Settings page opens, as shown in the following image.

  2. You can select a security provider that accepts trusted connections from the trusted_group_default_provider drop-down list. You can also enter IP addresses to be mapped to a specific provider, if no provider name is supplied by the client.
Top of page
x
Setting an Anonymous User ID

How to:

An authorized server administrator can set an anonymous user ID that can access the Web Console when the user ID/password fields on the Web Console login screen are blank and the user clicks Log in.

This anonymous user ID provides the ID and, in turn, the user rights for the Web Console and the server. Further configuration for the anonymous user can be achieved by creating a user profile for the anonymous user ID. If an anonymous ID matches a user in the admin.cfg list, the applicable role and privileges are applied.

Note: On Windows, for security provider OPSYS only, you must turn IWA security off to use this feature. From the Workspace folder in the navigation pane, open the Special Services and Listeners folder, right-click TCP/HTTP, and select Properties. Click the Security IWA check box to deselect it.
x
Procedure: How to Set an Anonymous User ID
  1. Log on to the Web Console using a user ID that has server administration rights.
  2. Select Access Control from the Web Console menu bar.
  3. Right-click Access Control in the navigation pane, and select Settings.

    The Access Control Settings pane opens.

  4. Enter a user ID in the anonymous_id field.
  5. Enter a password in the anonymous_pass field and repeat it in the Confirm Password field.
  6. Click Apply and Restart Server.
Top of page
x
Configuring User Password Settings

In this section:

You can configure the following password settings for any security provider:
x
Viewing or Changing the Password Separator Character

When an application has the option to change a user password, the old and new passwords are sent to the server using a separator character (by default, a comma). For example: 

						old_password,new_password 

The separator character is defined by the password_change_delimiter field. The separator needs to be reset if the current separator character is contained in the password itself or if it is allowed by the server.

This feature is not supported when Security is OFF.

x
Procedure: How to View or Change the Password Separator Character
  1. From the Web Console menu bar, select Access Control.
  2. Right-click Access Control in the navigation pane, and select Settings.

    The Access Control Settings page opens.

  3. In the password_change_delimiter field, enter a single character to use as the delimiter between an old and new password. (The default character is a comma.)

    Note that you cannot use the designated password_change_delimiter character in a password.

  4. Click Apply and Restart Server.
x
Enabling Password Changes From the Web Console Sign-in Page

A Server Administrator can allow users to change their password from the Web Console sign-in page. By default, users cannot change their passwords from the Web Console sign-in page.

x
Procedure: How to Enable Password Changes From the Web Console Sign-in Page
  1. Sign in to the Web Console with Server Administrator privileges.
  2. From the Web Console menu bar, choose Access Control.
  3. Right-click Access Control in the navigation pane, and select Settings, or click Settings on the ribbon.

    The Access Control Settings page opens.

  4. Enter y in the password_change_wclogin field. The default is n.
  5. Click the Apply and Restart Server button.
x
Sign-in Password Expiration Warning

On Operating Systems that support password expiration, you can specify that a warning message be displayed a specified number of days prior to the expiration date. The message will appear after the initial login screen. You must then click the Continue button to open the Web Console. Users can employ standard tools to change their passwords before expiration occurs.

Note: The password expiration warning is supported only on operating systems where IDs are configured to expire and this extended security feature is active for the user ID. However, expiration warning is not currently supported on the Windows platforms.
x
Procedure: How to Initiate Notification of an Imminent Password Expiration
  1. From the menu bar, select Workspace.
  2. In the navigation pane, expand the Special Services and Listeners folder, then click TCP/HTTP and select Properties from the context menu. The Listener Configuration pane opens.
  3. Expand the Advanced group.
  4. In the PASS_EXPIRE_NOTIFICATION field, enter the number of days prior to expiration that you want the warning to begin to appear when a user whose password is about to expire logs in.
  5. Click the Save and Restart Server button.
iWay Software