WEB-MON
Introduction Copied
Geneos WEB-MON Plug-In checks a WEB Server’s ability to supply pages/files by requesting a series of pre-set pages/files on a regular basis.
Page/file availability, response time, data size and any HTTP headers are displayed and rules can be set to alert when a page/file becomes unavailable or when the response times are unacceptable.
This is particularly useful when WEB Servers are managed by an Application Service Provider (ASP) or Internet Service Provider (ISP), where this could be the only facility to ensure the quality of the service. Additionally, you can use this plugin to:
-
Check if a website is up and validate its content.
-
Get QoS information for logging or SLA purposes.
-
Check website security.
-
Validate responses from different users.
-
Pass content to the extractor plugin for further content processing.
All HTTP Web Server types are supported. Where servers publish their type, this information is displayed for reference.
Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.
Note
The cURLÂ library used by WEB-MONÂ plug-in cannot utilise JavaScript. Refer to ITRS Synthetic Monitoring User Guide for more information.
Intended Audience Copied
This user guide is intended for experienced Geneos users who want to monitor web pages. As a user, you should be familiar with the HTTP protocol, cURL library, proxy connection, and protocols like NTLM and Kerberos if authentication will be used.
Scenarios and Stages Copied
The configuration of the WEB-MON plug-in is broken down into a number of scenarios. Each scenario allows a series of stages (web pages or files) to be requested in sequence, in the same way that a user would do. Scenarios themselves are run in parallel.
Stages have a set of success criteria associated with them, such as a response code or time to complete. If the criteria are not met then the stage and the overall scenario will fail.
If the website is simple then a number of scenarios may exist, each of which may be composed of a single stage. These could then check that a number of key pages are available.
If the website is more complex then more stages may be needed in the scenarios. An example scenario might be to log in with a username and password, and then request a page that is unavailable without a login. Another scenario may be to deliberately enter an incorrect username and password, and verify that the request for the protected page fails.
The Examples section of this document describes possible uses in more detail.
Views Copied
The WEB-MON plugin produces one view which can be displayed in Summary
or Summary and Details
mode.
WEB-MONÂ plugin in Summary
mode:
WEB-MONÂ plugin in Summary and Details
mode:
The samplingStatus
will show OK
if the sampling takes longer than the initial sample period to complete a scenario, or FAILED
if the setup is incorrect.
Headline Legend
The headlines are shown above the main table and provide an overview of the state of the server.
Name | Description |
---|---|
serverName | The name of the server, as specified in the setup. This is what is sent as the Host header in the request. |
ipAddress | The IP address that has been resolved from the server name or proxy name. |
serverURL | If present, the ipAddress, serverType and serverState fields are populated as a result of making a request for this URL (relative to serverName). Otherwise, the mentioned fields are populated as a result of making a request for "/" (which is typically the default server webpage). |
portNumber | The port being used. This will typically be 80. |
serverType | If the server publishes a type (Server header) then this will be displayed here. If a proxy server has responded with an error then this will be the proxy server type. |
serverState |
This will be one of:
If a proxy server is used this will show the state of the proxy server, not the destination server. |
scenariosFailed | A count of the number of scenarios that have failed. |
scenariosInError | A count of the number of scenarios that have errors. |
scenariosTimedOut | A count of the number of scenarios that have taken too long to run. |
protocol | Whether http or https is being used. |
proxy | Server name and port of proxy server being used, if any. |
The ipAddress, serverType and serverState columns are populated as a result of making a request for the default server webpage (/).
Table Legend
The columns in the table are broken up into two parts:
The first set of columns show status information about the stages and scenarios;
The second set of columns show more details about the requests and responses. For scenarios, the second set of columns will show the details of the last stage to run. For successful scenarios, this will be the last stage. For unsuccessful scenarios this will be the stage that failed.
Name | Description |
---|---|
name |
Scenario Name
or
Scenario Name # Stage No. # Stage Name
|
status |
For scenarios, the status can be:
For stages, the status can be:
|
detail | If the status is not OK then this column provides more information about what went wrong. |
duration |
For stages this will be the time taken to resolve the hostname, make the request and get the page back. For scenarios this will be the time taken to run each stage, check the success criteria, and set up the next stage. The time will therefore sometimes be fractionally greater than the sum of the stage times. |
Name | Description |
---|---|
url | The URL of the request |
responseCode | The HTTP response code. This will be, for example, 200 for OK or 404 for Not Found. The full set of possible response codes can be found in RFC2616 References. |
responseText | A textual description of the response code, as sent by the server. |
downloaded | The number of bytes downloaded as the body of the page. If a Transfer-Encoding is used by the server then this will not necessarily be the same as the length of the content. |
(additional headers) | Additional response headers may be configured, and these will be shown as extra columns in the view. |
Plug-In Configuration Copied
Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.
Scenarios are configured with a number of stages in each. Stages can have additional data sent as part of the request, such as query variables and headers. They also specify a set of success criteria that, if breached, will cause a FAILED state to occur. In addition to the configurable success criteria, if the server sends a Content-Length header and the amount of data downloaded does not match this then the stage will fail.
It is possible to configure connection details at the scenario or stage level in addition to the top level. This allows connections to other servers if, for example, authentication is required from a central location. It also allows monitoring of multiple domains that are served from the same physical web server, or checking both secure and non secure versions of a site.
Although setting different connection details would also allow multiple physical servers to be monitored from the same WEB-MON instance, this is not recommended, and the headline variables will only show the status of the main server being monitored.
The configuration parameters are listed below:
host Copied
The full name of the server to monitor.
This should be entered as it is entered in a web browser, and might not be the same as the physical hostname of the server if virtual hosting is being used. For example, a server serv1 might be hosting <www.example.com> and <www.example.net>. The host should be set to <www.example.com> or <www.example.net> rather than serv1.
Mandatory: Yes
port Copied
The port of the server to monitor.
Mandatory: No
Default: 80 (http) or 443 (https)
serverURL Copied
If specified, the ipAddress, serverType and serverState headline fields are populated as a result of making a request for this URL (relative to host). Otherwise, the mentioned fields are populated as a result of making a request for “/” (which is typically the default server webpage).
For example: if host is set to <www.example.com> and serverUrl is set to sample1, the request would be made for <www.example.com/sample1>. If this field is not set, request would be sent for for <www.example.com> instead.
Mandatory: No
Default: 80 (http) or 443 (https)
protocol Copied
Whether to use http (unencrypted) or https (SSL encrypted). When using SSL connections, the server certificate can also be verified.
Mandatory: No
Default: http
protocol > https > certificate Copied
Certificate to use for the SSLÂ authentication.
Setting | Description |
---|---|
Verify | Whether to check the server certificate. |
Client Certificate | Certificate that will be sent to a web server that requires SSL client authentication. Must be in PEM format. Required for client authentication. |
Client Key | Private key corresponding to the client certificate. Must be in PEM format. Required for client authentication. |
Client Key Passphrase | Passphrase used to encrypt the private key. Needs to be specified only if private key is passphrase-protected. |
Mandatory: No
Default: No
protocol > https > certificate > verify Copied
What to check within the certificate.
Setting | Description |
---|---|
None | Will succeed as long as any certificate is present. |
Against authority | Checks the certificate to ensure it has been signed by a Certificate Authority (CA) that is trusted, but doesn't check that the hostname matches. |
Against authority and hostname | Checks that the certificate has been signed by a trusted CA and that the hostname matches |
When checking the certificate against a Certificate Authority then a CA Bundle in PEM format must be used. This file specifies the CAs that are to be trusted. If the operating system has not come with a CA or it is out of date then a CA Bundle should be specified.
This can either be constructed (if, for example, you wish to add your own trusted authorities when self-signing) or downloaded. If you wish to generate your own then please search online for ‘Creating a PEM CA bundle’. If you just wish to download an existing one then you can do so from the cURL page describing how to extract CA certificates from Mozilla: http://curl.haxx.se/docs/caextract.html
Mandatory: No
Default: none
protocol > https > tlsVersions >Â minTLSVersion Copied
Minimum TLSÂ Protocol version to be used.
Mandatory: No
Default:Â none
protocol > https > tlsVersions > maxTLSVersion Copied
Maximum TLSÂ Protocol version to be used.
Mandatory: No
Default:Â none
proxy Copied
Settings for making connections via proxy servers.
Note
If a proxy is specified at the top level then this changes the behaviour of some headline variables.
Name | Description |
---|---|
serverName | Unchanged |
serverURL | Unchanged |
ipAddress | This will be the IP address of the proxy. |
portNumber | Unchanged |
serverType | In the event that the proxy server responds with an error then this will be the proxy server type, otherwise it will be unchanged. |
serverState |
The state of the proxy server. The state of the destination server is invisible to the netprobe. If the destination server is unavailable the proxy will likely respond with an http error code, however this could equally have come from the destination server. There is no way to tell. The server type should give a clue as to whether the request reached the destination or got no further than the proxy. |
scenariosFailed | Unchanged. |
scenariosInError | Unchanged. |
scenariosTimedOut | Unchanged. |
protocol | Unchanged. |
proxy | Configured proxy connection settings. |
Mandatory: No
Default: none
proxy > none Copied
Explicitly disable proxy.
proxy > proxyServer > host Copied
Hostname of proxy server.
Mandatory: Yes
proxy > proxyServer > port Copied
Port number of proxy server.
Mandatory: Yes
proxy > proxyServer > type Copied
The type of proxy to use. Six types are currently supported.
Mandatory: Yes
HTTP | Http 1.1. |
HTTP 1.0 | Http 1.0. |
SOCKS 4 | Socks 4. |
SOCKS 4A | Socks 4a. |
SOCKS 5 | Socks 5 but resolve the hostname locally. |
SOCKS 5 Hostname | Socks 5 and let the proxy resolve the hostname. |
proxy > proxyServer > authentication Copied
Authentication settings for proxy.
Mandatory: No
Default: None
proxy > proxyServer > authentication > password Copied
Allows username/password combinations to be sent to proxy servers.
proxy > proxyServer > authentication > password > loginCredentials Copied
Contains details of the username and optional password. The password may be encoded in the setup file so that it is not easily visible if required. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.
proxy > proxyServer > authentication > password > method Copied
Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended.
For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication.
Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.
Mandatory: No
Default: All methods are enabled
authentication Copied
Allows authentication information to be sent along with requests using various methods. When usernames and passwords are entered into webpage forms then query vars should be used instead. See the Checking Secured Pages example for more details.
Mandatory: No
authentication > httpAuthentication Copied
Allows HTTP level authentication to be set
authentication > httpAuthentication > password Copied
Allows username/password combinations to be sent to servers. When using a web browser, this authentication method is typically seen by a pop-up dialog box.
authentication > httpAuthentication > password > loginCredentials Copied
Contains details of the username and optional password. To set an encrypted password, click on the “Set Password” button, then enter and confirm the password to be used. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.
authentication > httpAuthentication > password > method Copied
Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended.
For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication.
Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.
Mandatory: No
Default: All methods are enabled
display Copied
Contains a number of settings to control how the information is displayed.
display > displayMode Copied
The display mode will be one of:
Mandatory: No
Default: SUMMARY
Setting | Description |
---|---|
SUMMARY | Just display the Scenarios |
SUMMARY+DETAILS | Display the Scenarios, and also display each of the Stages under each Scenario. |
display > displayURL Copied
You can display URLs in one of the following ways:
You may not wish the query part of the URL to be shown in the view if it contains sensitive information, however if you use the ’encoded’ query variables option then it will be shown as name=[encoded] so that it is not visible in Geneos. Even with all these measures in place, this will not prevent the information showing up in any server logs.
Mandatory: No
Default: PATH
Setting | Example Result |
---|---|
PATH | /path/to/file.html |
PATH+QUERY | /path/to/file.html?name=value&name=value |
FULL | http://www.example.com/path/to/file.html |
FULL+QUERY | http://www.example.com/path/to/file.html?name=value&name=value |
display > displayHeaders Copied
If you wish to see additional HTTP headers then they can be specified here. Each one will appear as a new column in the view. This is particularly useful if your web application writes out custom headers.
A full list of standard headers can be found in RFC2616 References. Examples of potentially useful headers are: Content-Length, Last-Modified, X-Powered-By.
Mandatory: No
Default: No additional headers
maxInitialSample Copied
When each sample starts it will check the status of the downloads every 0.1 seconds for an initial period. If it hasn’t finished after that time then it will leave the downloads in the background and relinquish control to other samplers. It will then check the status again while other samplers aren’t sampling, until all the scenarios are complete. The minimum time between these additional checks is 1 second.
Mandatory: No
Units: Seconds
Default: 5
maxServerDuration Copied
This setting allows the maximum amount of time to wait for the main server status - the settings which allow the headline variables to be populated.
Mandatory: No
Units: Seconds
Default: 60
GSS-Negotiate Copied
Note
Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms.
Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal.
Option | Description |
---|---|
Principal | Unique identity to which Kerberos can assign tickets. |
Keytab | File path to the keytab for the specified principal. |
Once the principal and keytab are defined, the sampler will generate the Kerberos ticket inside the current working directory.
scenarios Copied
Contains the list of scenarios. If no scenarios are configured then only the default server webpage (/), or the serverUrl(if provided), will be monitored and the results shown in the headline variables.
scenarios > scenario Copied
A scenario is a named object that consists of a number of requests to the same web server (scenarios > scenario > stages). Cookies are maintained within a scenario but not between scenarios.
scenarios > scenario > name Copied
Specifies the name of a scenario. Each scenario should have a unique name within this sampler. The scenario mode will be displayed as the row name in the dataview, and will also form the first part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.
scenarios > scenario > connection Copied
This allows the connection details to be overridden. See the following sections for more details:
scenarios > scenario > successCriteria Copied
Allows success criteria to be specified for the whole scenario. Each stage also has its own, more extensive, success criteria.
scenarios > scenario > successCriteria > maxDuration Copied
This specifies the maximum amount of time the scenario is allowed to run for. If this time is exceeded then the scenario will be marked as TIMEDOUT, the current stage will be CANCELLED and any remaining stages will be SKIPPED.
Mandatory: No
Units: Seconds
Default: 60
scenarios > scenario > stages Copied
Contains the list of stages. A stage is a single request to a web server. Requests in a scenario are made in the order they are declared in the setup.
scenarios > scenario > stages > stage Copied
A stage is a named step inside a scenario. A stage is a single request to a web server.
scenarios > scenario > stages > stage name Copied
Specifies the name of the stage. This should be unique within the scenario. It will be seen in the scenario line if this particular stage fails. It will also form the second part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.
scenarios > scenario > stages > stage > connection Copied
This allows the connection details to be overridden. See the following sections for more details:
scenarios > scenario > stages > stage > url Copied
Specifies the URL (relative to the server root) of the page to request. Example:
/path/to/file.html
It is possible to specify the query string as part of the URL, but it must be properly encoded. This may be used in addition or as an alternative to the queryVars table. The queryVars table is preferred as any name/value pairs in this table will be encoded by the plugin, and hiding of sensitive information is also supported. Example:
/path/to/file.html?name=value&name=value
Mandatory: Yes
scenarios > scenario > stages > stage > requestData Copied
This configuration allows the request to be altered
scenarios > scenario > stages > stage > requestData > method Copied
Sets the request method to GET or POST.
GET is the normal option for standard page requests, and POST is the normal option when submitting information to forms, particularly if a lot of data is to be sent, or if sensitive information needs to be transferred so that it won’t show up in server logs and proxies as part of the request URL.
Although it is possible that either method can be used in either case, sometimes when forms are involved the server will insist on one method or another so it is worth checking the page source to see which is used. See the Checking Secured Pages example for more details.
Mandatory: No
Default: GET
scenarios > scenario > stages > stage > requestData > method > get > queryVars Copied
The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.
It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example:
/login.php?username=myname&password=[encoded]
Mandatory: No
Default: No additional variables
scenarios > scenario > stages > stage > requestData > method > post > body > queryVars Copied
The query variables to be sent as the body of the POST request. Each name value pair is url encoded and then passed to the server with the Content-Type: x-www-form-urlencoded unless overridden in the requestHeaders configuration.
For example:
- Geneos: Netprobe
- Gateway: Webmon
would be encoded as:
geneos=netprobe&gateway=webmon
Mandatory: No
Default: Empty Post Request
scenarios > scenario > stages > stage > requestData > method > post > body > rawData Copied
The body of the post request to be sent to the server, as a string. This allows Webmon to post any type of string data to the server, for example SOAP requests.
Note
You should also add the Content-Type to the requestHeaders configuration to indicate to the server the mime-type of the raw data that Webmon will send. For example a SOAP request would have a Content-Type ofapplication/soap+xml
. If this header is not specified the type will default tox-www-form-urlencoded
.
Mandatory: No
Default: Empty Post Request
scenarios > scenario > stages > stage > requestData > queryVars Copied
Deprecated: use queryVars under the GET or POST elements
The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.
It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example:
/login.php?username=myname&password=[encoded]
Mandatory: No
Default: No additional variables
scenarios > scenario > stages > stage > requestData > requestHeaders Copied
The request headers allow additional headers to be sent to the server as part of the request. An example of use might be to change the User-Agent header for applications that serve different pages depending on the web browser being used.
A full list of standard headers can be found in RFC2616 *[1]*.
An example of use may be seen in the Changing Request Headers example.
Mandatory: No
Default: No additional headers
scenarios > scenario > stages > stage > successCriteria Copied
This configuration section allows the response to be checked against a set of criteria. This will determine whether the scenario and stage show as OK or FAILED in the dataview.
scenarios > scenario > stages > stage > successCriteria > responseCodes Copied
The response codes specify the acceptable responses given by the server. These are all three digit codes. The first digit specifies the type of response, and the other two digits provide more detail. 4xx codes are problems with the request, such as specifying a URL for a file that doesn’t exist. 5xx codes are server errors, when a problem occurred trying to fulfil the request.
A full list of the response codes and their meanings can be found in RFC2616 References.
Mandatory: No
Default: All codes in the 100 to 399 range
scenarios > scenario > stages > stage > successCriteria > maxDuration Copied
This specifies the maximum amount of time the stage is allowed to run for. If this time is exceeded then the stage will be TIMEDOUT and any remaining stages in the scenario will be SKIPPED. The scenario will then show FAILED.
Mandatory: No
Units: Seconds
Default: Unlimited
scenarios > scenario > stages > stage > successCriteria > response Copied
Can check the response from the server for various different conditions
scenarios > scenario > stages > stage > successCriteria > response > expression Copied
The expression defines, using Boolean and/or/not logic, which of the conditions need to be met in order for the server response to be valid. For example, you may define a page content condition called ‘failed’ which matches against the text ’login failed please try again’ and then the expression would be:
not “failed”
Right clicking on the expression editor will bring up a menu that gives access to the available operators, and also provides some common templates for expressions that may be used.
scenarios > scenario > stages > stage > > successCriteria > response > conditions Copied
Allows the various different conditions to be specified. These can then be used in the expression above to define the criteria under which the response matches.
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent Copied
The page content checks look at the actual page - the text that would be seen in a browser’s ‘Show Page Content’ or ‘View Page Source’ options.
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string Copied
Checks the page content against an exact piece of text.
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string > text Copied
The actual text to match against
Mandatory: Yes
scenarios > scenario > stages > stage successCriteria > response > conditions > condition > type > pageContent > match > string > caseSensitive Copied
Whether to perform a case sensitive comparison. Case sensitive comparisons will be slightly quicker, so if the case of the text you are looking for is not going to change then this is the best option.
Mandatory: No
Default: true
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex Copied
Checks the page content against a regular expression.
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > regex Copied
The perl-compatible regular expression to use. Example:
a.\*b
Mandatory: Yes
scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > flags Copied
This a set of zero or more regex flags which can affect how the regex is applied to the contents of the web page. For example if ‘i’ is specified then the web page contents is considered in a case-insensitive manner when the regex is being applied to it.
Any of the following flags may be specified:
Setting | Description |
---|---|
i | Case insensitive |
s | A dot should match all characters when applying the regex. This is required if the expression will span several rows since a dot will not match newline characters by default. |
Mandatory: No
Default: All flags are false
scenarios > scenario > stages > stage > dataTransfer Copied
If a page downloads correctly and passes all the success criteria then the content may be exported for other samplers to read, such as EXTRACTOR. The purpose of the web-mon plugin itself is to allow the server/app to be checked to ensure that it is returning pages. In contrast, the data transfer may be used, for example, to display the page content in a separate dataview so that the figures displayed can be monitored by Geneos.
The name selected does not have to match anything else in the web-mon plugin, however:
- The name must match the name used in the sampler reading the data.
- It must be unique on any particular Netprobe - if multiple instances of the same web-mon sampler are used on the same Netprobe (through use of different Managed Entities or Types) then variables must be used to make it unique.
If web-mon is only present to provide other samplers with information and you do not wish to see the status of the pages being retrieved, then once it has been set up you can prevent it being shown by setting the ‘Publish’ option to false in the Visibility tab of the Sampler configuration section.
Mandatory: No
Default: The page content is not exported.
Additional Configuration Information Copied
This section provides additional configuration information needed to use certain features of this plug-in.
Authenticating with Kerberos Copied
Note
Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms.
Before setting the plugin to use Kerberos authentication to connect to a web server, the client machine must first acquire a Kerberos ticket-granting ticket from that web server. The following guidelines describe how to acquire the Kerberos ticket:
Verify the Kerberos realm Copied
Verify that the Kerberos realm of the web server is defined in the Kerberos configuration of the client. The configuration file is located in /etc/krb5.conf
. Below is an example of the realms section of the configuration file:
Example realms definition in krb5.conf
[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com:88
admin_server = kerberos.example.com:749
default_domain = example.com
}
Check that the realm of the web server is defined with the corresponding names of the kdc
, admin_server
, and default_domain
.
After verifying the Kerberos realm, you can follow any of the options below to set up the Kerberos ticket generation:
- Generate the Kerberos ticket-granting ticket for an authorized user
- Set up the Kerberos principal and keytab on the sampler
Generate the Kerberos ticket-granting ticket for an authorized user Copied
-
Generate the Kerberos ticket-granting ticket for an authorized user and store it in the default location. This can be done by running
kinit <user@realm>
on the command line. Enter the password when prompted:# kinit user@example.com
-
Run
klist
on the command line to view the generated ticket. Verify that ticket is stored in the default location,/tmp/krb5cc_0
:# klist
When using this method, consider the following limitations:
- The ticket has a finite lifetime and the client machine will need to regenerate it once it expires. The lifetime of a ticket is controlled by the Kerberos Key Distribution Center (KDC) of the web server, which issues the tickets. The default expiration is typically set to 8 or 10 hours, but can be configured to a longer duration in the KDC. Ticket renewal polices can also be set between the web server and client. Consult your web server administrator on how to configure ticket lifetime and renewal.
- The plugin requires that the client machine generate the Kerberos ticket-granting ticket from the corresponding web server and store it using the default file setting. The plugin does not generate the ticket on its own and only looks for it in the default location when performing the authentication.
Set up the Kerberos principal and keytab on the sampler Copied
Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal.
If you have a Kerberos principal, you can set it up on the sampler for Kerberos authentication. The Kerberos options can be found in the Advanced tab > GSS-Negotiate. For more information, see GSS-Negotiate.
Examples Copied
This section provides more detailed examples possible uses of this plug-in.
Simple Server Status Monitoring Copied
If the requirement is just to check that a particular server is up, then no scenarios need to be configured. The plug-in will make requests for the default server page ( / ), or the serverUrl (if provided), and use this to decide on the server status.
Checking Simple Pages Copied
If there are pages that need to be available on the server, these may be configured as single stage scenarios. One scenario would be written for each page, as the requests do not have to happen in any particular order. The plug-in would try and access all these pages simultaneously to minimise the time taken to perform a sample. Since each scenario only has one stage, the display should probably be set to SUMMARY.
Checking Secured Pages Copied
If a login is required to view pages, scenarios may be configured with the login page as the first stage, and the page to check as the second stage. Query variables can then be used to pass the username and password to the login page.
To find out the query variables that need to be used, it is necessary to look at the source of the login page. This would look something like this:
...
<form action="/site/login.php">
...
<input type="text" name="username">
...
<input type="password" name="passwd">
...
</form>
...
In this case, the URL should be set to /site/login.php, and the query variables needed are username and passwd.
Depending on how the login was written, it may require other name/value pairs to be set. It may require hidden variables, like this:
<input type="hidden" name="action" value="login">
or the submit button, like this:
<input type="submit" name="submit" value="Log Me In">
It is also worth checking the request method, which will also be part of the form definition:
<form action="/site/login.php" method="POST">
The method (either GET or POST) can be set as part of the request data for the stage.
Checking Security of Pages Copied
It is also possible to ensure that it is not possible to access pages that have been secured behind a login. In this case, a single stage is needed that accesses the secured page. The acceptable responseCode should then be set to 403 (Forbidden). The scenario will then be successful if it is not possible to view the page.
Another similar test would be to visit the login page first, but deliberately enter in an invalid username/password.
Changing Request Headers Copied
It is possible to change the headers that get sent as part of the request. One possible use would be to change the User-Agent if the same URL is used to serve pages for different browsers, or for a browser and a PDA.
In this case scenarios could be set up with a User-Agent requestHeader of:
Mozilla/4.0 (compatible; MSIE 6.0; Win32)
and another with
Nokia6630/1.0 (2.39.129) Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1
That would allow the responses to be compared for Internet Explorer 6 and a Nokia 6630 mobile phone. User-Agent strings for common browsers and wireless devices can be found on the Internet.
References Copied
RFC2616 - Hypertext Transfer Protocol - HTTP/1.1
RFCs are “Request For Comments” documents and each system used on the Internet has one that describes exactly how to use it. The documents are all numbered and are hosted many places on the Internet. RFC2616 can be found by performing a search for “RFC2616” in any search engine.
Known Issues Copied
IPv6 with NTLM
In a few cases timeout issues have been seen when using NTLM authentication with some types of IPv6 environments.
If you experience any issues, contact ITRS Support .