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 logon multiple times or manage separate user ID/password combinations. If a user logs onto 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.
In this section:
How to: |
When security is set to OPSYS, 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.
The server will automatically run in security OPSYS mode if no other security mode has been configured and the server process has been granted sufficient privileges. If the server process does not have sufficient privileges for operating system authentication, and no other security mode has been configured, the server runs with security OFF.
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:
On Windows, the Server Administrator password is required for this security mode. If the password is not provided in the configuration, the server starts in safe mode and displays a message to that effect. Multiple administrators are allowed. For more information on creating server administrators and other roles, see Registering Users and Groups in a Role.
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.
When the Reporting Server runs on the Windows platform with OPSYS security mode 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.
The Access Control page opens.
The OPSYS Security Configuration page opens.
This procedure assumes that the server is already running in non-OPSYS security mode.
The Access Control page opens.
The server security mode is displayed on the Access Control page.
The Change Provider page opens.
Note: For more information about changing security providers, see Considerations for Changing the List of Security Providers From the Web Console.
The Change Provider page opens.
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.
The server will start in OPSYS security mode.
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.
If the environment variable EDAEXTSEC is explicitly set to OPSYS, and the server fails to start because it lacks system privileges to start in OPSYS mode, 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
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:
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:
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.
In a Linux or AIX environment, OPSYS security can be configured to use Pluggable Authentication Modules.
The Access Control Page opens.
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.
In this section: How to: |
PTH security mode only controls access to the Web Console. In this security mode, 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 in this security mode, 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.
PTH security mode 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.
The Change Provider page opens.
The Select an Option dialog box is displayed, as shown in the following image.
Once the server has restarted, the PTH security provider has icons for adding and viewing its users and groups.
The server will start in PTH security mode.
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 Create and Register Users 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) in OPSYS mode to clear the directory before switching.
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.
To assign an expiring password:
By default, the Password never expires box is checked.
The current date is saved in admin.cfg as admin_passdate for this user. This is the last password change date.
The Properties page for the user will show the number of days until password expiration.
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.
In this section: How to: Reference: |
In this security mode, 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.
DBMS security mode 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.
This procedure assumes that the server is already running.
Note that the Test button, which appears next to the Configure button, will not work until your restart the server with Security DBMS in step 5. Do not restart the server at this point.
The server security mode is displayed on the Access Control page.
This option identifies the database engine used to authenticate incoming requests.
This option identifies the database connection used to authenticate incoming requests.
The Change Provider page opens.
Note: For more information about changing security modes, see Considerations for Changing the List of Security Providers From the Web Console.
The server will start in DBMS security mode.
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) in EDAEXTSEC=OPSYS mode to clear the directory before switching.
Security DBMS (using password passthru) is supported for the following engines:
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:
Complete the following steps to ensure that prerequisites have been met:
Once prerequisites have been satisfied, complete the SSO verification procedure.
This generates an SSO cookie.
At this point, no logon screen should pop up since the user is logged in and SSO login has been successfully verified.
How to: Reference: |
In LDAP (Lightweight Directory Access Protocol) security mode, 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.
LDAP security mode is presently supported on Windows, UNIX, IBM i, and the Unified Server (HFS and PDS deployments).
LDAP security mode 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.
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.
The LDAP Security Provider Configuration page opens.
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.
Connection Properties
Specifies a name for this provider.
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
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).
Specifies whether the server uses a Secure Socket Layer (SSL) session with the LDAP server. Select No or Yes. The server default is No.
LDAP (Lightweight Directory Access Protocol) security mode 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:
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:
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:
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.
Determines the type of bind used. Can be one of the following.
The bind is performed using no credentials. This is the internal default value.
The reporting server authentication is performed against Active Directory utilizing a Windows-specific API.
The bind is done under the credentials supplied by the client in the authentication process.
The windows machine that hosts the reporting server should be in the same domain as Active Directory.
The internal parameter ldap_ad_only should be set to y and ldap_user_attribute should have the value sAMAccountName or userPrincipalName.
NEGOTIATE mode is mutually exclusive with Explicit mode where ldap_principal and ldap_credentials determine an account that performs the bind. For a trusted client, NEGOTIATE mode is not supported.
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.
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.
Contains the password of the service account defined in ldap_principal.
Specifies the timeout in seconds for ldap_search. The server default value is 60 seconds.
User properties
Specifies the DN of the entry that serves as the starting point for the search. Consists of attribute=value pairs, separated by commas.
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.
Specifies the object class used when searching for user entries. The server default is person.
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).
Specifies the LDAP attribute used to identify a group in a user object.
The Active Directory standard is Memberof.
Specifies the name of the attribute whose value contains description of an object (user, group). The server default is description.
Specifies the name of the attribute whose value contains the user email address. The server default is mail.
Group properties
Specifies the DN of the entry that serves as the starting point for the search. The server default is the ldap_user_base value.
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.
Specifies the object class used when searching for group entries. The server default is groupofuniquenames. The Active Directory standard is group.
Specifies the LDAP attribute used to identify the name of the group. The server default is cn.
Specifies the LDAP attribute used to identify users in a group. The server default is uniqueMember. The Active Directory standard is Member.
Disables or enables LDAP nested groups support. Select No or Yes. The server default is No, which disables nested group support.
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.
A Test LDAP Connection logon window opens.
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.
The Change Effective Security Provider(s) page opens.
Note: Each time you select an LDAP Security Provider, another Security Provider drop-down box is generated.
If the server is already running in LDAP security mode, the button at the bottom of the page says Apply and Restart Server. Click the button and wait for the server to restart.
Note: For more information about changing security modes, see Considerations for Changing the List of Security Providers From the Web Console.
The server will start in LDAP security mode.
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) in EDAEXTSEC=OPSYS mode to clear the directory before switching.
The Access Control page opens.
A dialog box opens asking you to confirm that you want to remove the provider.
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. LDAP Security mode requires the appropriate LDAP vendor library files to be available to the server at run time:
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:
To make Sun LDAP library files available to the server at run time:
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.)
The login page opens. You will be prompted for a registered user login or to register.
How to:
Reference: |
Security provider CUSTOM supports using non-standard security storage. You can create DBMS tables to store users, groups, and passwords. You must write procedures to read these tables to authenticate users.
When you a custom provider, you need to enter the name of a procedure for authentication that you created beforehand. If you do not enter a procedure name in the cust_authenticateuser field during custom provider configuration, and you make it the primary provider using the Change Provider page, the server will prompt for a default server administrator. You can use this user ID to connect to the server when it is restarted. If you change the primary provider to a custom provider with a cust_authenticateuser procedure entered, the procedure will be used for user authentication.
If your authentication procedure does not work correctly, you can make any corrections needed by starting the server with security OFF, connecting to the Web Console, and editing the cust_authenticateuser procedure.
The custom security mechanism has to be created prior to configuring the security provider and must be provided when the CUSTOM provider is added to the server provider configuration. It must perform the following standard security tasks:
The CUSTOM Security Provider Configuration page opens.
Is a name to assign to the security provider.
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 can identify a default server administrator user ID and password to use when connecting to the server. For information, see How to Specify a Default Server Administrator for a Custom Security Provider.
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.
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.
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 will have access to security data in those synonyms. All other users attempting to use this adapter connection will get an unauthorized message.
Your custom security provider is listed under the CUSTOM item on the Access Control tree.
When you configure a custom security provider, you are responsible for creating and identifying a procedure that will authenticate the credentials entered by the user attempting to connect to the server. If you configure a new custom provider as the primary provider, or change to the custom provider as the primary provider and have not entered the name of an authentication procedure, you can specify a default Server Administrator ID.
If you are changing to an existing Custom provider, continue with step 3. If you are creating a new provider, the CUSTOM Security Provider Configuration page opens:
The Testing CUSTOM Security page displays, prompting you for a user ID and a password:
Test the configuration with a valid user ID and an invalid user ID. In each case, check that the authentication procedure is returning the correct code to the server.
The Change Provider Page opens.
The Change Provider page displays fields for entering Server Administrator credentials:
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 USERID=user1, PASSWD=pass1
where:
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.
Is the user ID to be authenticated. It is stored in a variable named &USERID.
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:
Can be any valid variable name, for example &A.
Must be one of the following integers:
Indicates that the user ID and password are valid.
Indicates that the user ID is invalid.
Indicates that the password is invalid.
Indicates that the user ID has expired.
Indicates that the password has expired.
Indicates that another error occurred.
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 log onto the server, the server will:
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:
Mandatory
Contains alphanumeric user IDs with a maximum length of 99 (A99).
Optional
Contains alphanumeric descriptive information with a maximum length of 97 (A79).
Optional
Contains an alphanumeric email address with a maximum length of 127 (A127).
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 user list for one group.
The following procedure sets the variable &ID to all by default. It tests this variable to see if a specific user ID was passed to the FOCEXEC and branches accordingly:
-DEFAULT &ID=all; TABLE FILE USERINFO -IF &ID=all THEN GOTO L1 ELSE GOTO L2; -L1 PRINT DST.USERID DST.USERDESC DST.UEMAIL -GOTO END1 -L2 PRINT USERID USERDESC UEMAIL GROUPID NOPRINT IF GROUPID EQ &ID -END1 ON TABLE PCHOLD FORMAT COMT FORMATTED ON TABLE SET PAGE-NUM OFF ON TABLE SET HOLDATTR OFF END
A simple example of a users procedure, ptusers.fex, is provided in the home/catalog directory.
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:
Mandatory
Contains alphanumeric group IDs with a maximum length of 99 (A99).
Optional
Contains alphanumeric descriptive information with a maximum length of 97 (A79).
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 variable &ID to all by default. It tests this variable to see if a specific group ID was passed to the FOCEXEC and branches accordingly:
-DEFAULT &ID=all; TABLE FILE USERINFO -IF &ID=all THEN GOTO L1 ELSE GOTO L2; -L1 -L1 PRINT DST.GROUPID DST.GROUPDESC -GOTO END1 -L2 PRINT GROUPID GROUPDESC USERID NOPRINT IF USERID EQ &ID-END1 ON TABLE PCHOLD FORMAT COMT FORMATTED ON TABLE SET PAGE-NUM OFF ON TABLE SET HOLDATTR OFF END
A simple example of a group procedure, ptgroups.fex, is provided in the home/catalog directory.
How to: Reference: |
The Reporting Server can search across multiple LDAP sources, DBMS providers, and a PTH server when authenticating users.
The security provider selected on the Primary Security Provider drop-down list is the primary provider. Secondary providers are listed below with a check box you can use to activate them.
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 the primary provider for a one-part name and based on the provider specified for 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.
If you want to change the list of security providers:
The Change Provider page opens.
Note:
You can configure multiple security providers and change security modes using the Web Console. When changing security providers, it is important to make sure that there is a valid Server Administrator user ID for that provider.
Switching between security modes is done by changing the security provider from the Web Console, which will prompt you for server restart.
Environment variable EDAEXTSEC is only used to override the security provider setting that is stored in edaserve.cfg file.
Platform |
Start Method |
Actions |
---|---|---|
Windows |
Start Menu |
Under the main software folder for the server, select Start Security ON or Start Security OFF. |
As a Service under a local system account |
Set the system environment variable EDAEXTSEC, under My Computer, Properties, Advanced tab, to one of the following values: OPSYS or OFF. Restart Windows to initialize. | |
As a Service under the current account |
Set the system environment variable EDAEXTSEC, under My Computer, Properties, Advanced tab, to one of the following values: OPSYS or OFF. Restart Windows to initialize. | |
UNIX |
Command prompt or Script that calls edastart |
Export the variable setting in the edastart shell script, or before any calls to the shell script, as follows export EDAEXTSEC=security_mode where:
|
z/OS Unified Server |
JCL |
Place the variable in the EDAENV allocation of the IRUNJCL member of the configuration library EDAEXTSEC=security_mode where:
|
IBM i |
QSH command prompt or QSH script that calls edastart |
Export the variable in the edastart shell script, or before any calls to the shell script, as follows export EDAEXTSEC=security_mode where:
|
CALL {lib}/TSCOM300 or CL that calls TSCOM300 or CL that calls QSH, which, in turn, calls the edastart shell script |
Before the call to TSCOM300, add the following ADDENVVAR ENVVAR(EDAEXTSEC)
VALUE(security_mode) where:
| |
OpenVMS |
Command prompt or DCL script that calls edastart |
Before calling edastart.com or in edastart.com, add the following DEFINE EDAEXTSEC security_mode where:
You can also define the logical EDAEXTSEC in the EDAENV.COM file. |
Any |
Any |
Use the Web Console (Workspace, Configuration Files folder, Miscellaneous folder, Environment - edaenv.cfg) to edit the edaenv.cfg file and add the following: EDAEXTSEC=security_mode where:
Note: After a change, a hard restart of the server must be done. |
How to: |
You can configure the server to accept trusted connections.
The Access Control Settings page opens.
Note: For LDAP security mode, authentication must be configured with ldap_principal and ldap_credentials for trusted connections to work.
How to: |
An authorized server administration 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 mode 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 HTTP, and select Properties. Click the Security IWA check box to deselect it.
The Access Control Settings pane opens.
In this section: |
You can configure the following password settings for any security provider:
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 Mode is OFF.
The Access Control Settings page opens.
Note that you cannot use the designated password_change_delimiter character in a password.
A Server Administrator can allow users to change their password from the Web Console login page. By default, users cannot change their passwords from the Web Console login page.
The Access Control Settings page opens.
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.
The Web Console login screen has a check box for saving the current User ID and password so that the user does not have to enter them in subsequent logins.
To save your credentials, check the Remember me on this computer box and click Log in.
The credentials are stored in a browser cookie and are used for subsequent logins to the Web Console as long as the cookie is not deleted from the client computer.
iWay Software |