Sudo Manager Client Settings

This section provides settings and configuration options specific to the Sudo Manager plugin client.

For a comprehensive listing of settings available, see Settings in the Endpoint Privilege Management for Unix and Linux Administration Guide.

enforcehighsecurity

This enforces the use of more secure configuration, including using SSL for communications, FIPS 140-2 compliant symmetric encryption algorithms, an enhanced Pseudo Random Number Generator, and the use of the enhanced pb.key format.

Only encryption algorithms that are accredited by FIPS 140-2 can be used for network and file encryption (for example, AES- 128, AES-192, AES-256 and tripledes). All others are deprecated.

Once this has been enabled the following pb.settings need to be configured:

  • ssloptions requiressl sslfirst sslverbose
  • sslengine
  • sslservercertfile /etc/pbssl.pem
  • sslcountrycode US
  • sslprovince AZ
  • ssllocality Phoenix
  • sslorgunit Security
  • sslorganization BeyondTrust

You also need to generate a new key using pbkey -F.

enforcehighsecurity yes

Default

enforcehighsecurity yes
  • Sudo Manager policy server
  • Sudo Manager client

For more information, see the following:

logport

The port numbers for Endpoint Privilege Management daemons must use the non-reserved system ports. The allowed port numbers are 1024 to 65535 (inclusive).

logport 12345
logport pblogd

Default

logport 24347

Used on

  • Sudo Manager policy server
  • Sudo Manager client

logservers

The logservers setting provides a list of outgoing connection information for EPM-LSudo Manager programs that use log servers.

The list can contain:

  • Host names
  • A single asterisk (*) denoting a Registry Name Service lookup
  • Netgroups in the form:
    +@name
  • Hosts to exclude in the form:
    -name
  • Netgroups to exclude in the form:
    -@name
  • Absolute path names of a local pblogd. If spaces are required, the string must be quoted.
  • DNS SRV lookups, in the form:
    _<pbul service name>._tcp.<domain name>.[:port=<port>[:interface=<IP or hostname>]]
  • External Programs, in the form:
    `/path/to/external/program`

The following are tried in sequence to determine the port value:

  1. The non-zero port value from a DNS SRV lookup
  2. The value specified within the logservers setting
  3. The value of the logport setting
  4. The pblogd entry in services 5.
  5. Port 24347
logservers mylogserver.mydomain
logservers sparky spot
logservers loghost1 loghost2
logservers +@logservers -@badlogservers -badlogserver
logservers sparky spot "/usr/sbin/pblogd"
logservers _auto
logservers _pbmasters
logservers _pbmasters._tcp.mydomain.
logservers _pbmasters._tcp. mydomain.:port=12345
logservers `/bin/get_first_submitmaster`

Default

No default value

Used on

  • Sudo Manager policy server
  • Sudo Manager client

logserverdelay

When a log request is processed, the log servers that are listed in the logservers line are tried in the order they appear, from left to right. The logserverdelay setting enables the administrator to adjust the amount of time between failover attempts.

Without a specified time-out, the logging program (for example, pbrun, pbmasterd, pblocald, etc.) tries the first log server on the logservers line. If it does not receive a response within 500 milliseconds, then it adds the second log host. If neither responds in the next 500 milliseconds, then it adds the third log host, and so on. By specifying a logserverdelay, you can change the 500 millisecond waiting period before the logging program goes on to the next log server.

With a logserverdelay of 0 milliseconds, you get the fastest possible connection, but the log server that you connect to may not be predictable. You might also increase network traffic, depending on the number of connections that are opened.

With a larger logserverdelay you can increase the predictability, but you might also increase the time needed to form a failover connection. The longer the delay, the more predictable the sequence is.

logserverdelay 2500
Default
logserverdelay 500
Used on
  • Sudo Manager policy server
  • Sudo Manager client

logserverprotocoltimeout

After a connection is established, the programs perform some protocol checks to verify a proper and working connection. Some types of protocol failures can take a very long time to determine. For example, the wrong service running on the log server port, or mismatched encryption types/keys.

The logserverprotocoltimeout setting enables the administrator to control the maximum time to wait for protocol completion. If a protocol step does not complete within the specified number of milliseconds, then the logging program continues to try the next log server in sequence. A value of -1 indicates no protocol timeout.

If the iologack setting is used, then the logserverprotocoltimeout setting also controls how long a submit host should wait for an acknowledgment from the log host.

logserverprotocoltimeout 2000
Default
logserverprotocoltimeout 500
Used on
  • Sudo Manager policy server
  • Sudo Manager client

minoutgoingport and maxoutgoingport

When an Endpoint Privilege Management program needs to contact another program, the program opens an outgoing port in the range between minoutgoingingport and maxoutgoingport. This range is used for connections to a well-known service port and for dynamic connection.

If you want to use unreserved ports, then make sure that allownonreservedconnections is set to yes for the host that receives the connection.

minoutgoingport 20000
maxoutgoingport 20200
Default
minoutgoingport 600
maxoutgoingport 1023
Used on
  • Sudo Manager policy server
  • Sudo Manager client

networkencryption

The networkencryption setting specifies one or more encryption settings for encrypting network traffic between hosts. The networkencryption setting uses the following syntax:

networkencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
    [:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
    <algorithm-2>:<keyfile=/fullpath/data-file-2>
[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

For successful communications between Endpoint Privilege Management hosts, each host must use the same encryption algorithm and data file, from which the encryption key is generated. To prevent service interruptions, you can specify multiple algorithms and keys on each host. The hosts resolve discrepancies as follows:

When one Endpoint Privilege Management program attempts to communicate with another, it uses the first valid algorithm/key pair (encryption algorithm type and encryption key derived from the data file) in the networkencryption setting. The receiving host then attempts to find the correct algorithm/key pair from its networkencryption setting.

Servers attempt to connect the first valid algorithm/data-file pair and, if that fails, the servers then attempt to use other valid algorithm/data-file pairs that are defined in the networkencryption entry in the settings file. We strongly recommend placing the best and newest algorithm/data-file pair as the first entry in the settings file in all servers. Also, the algorithm/data-file pairs must be listed in the same order for all servers.

A client that is not upgraded to the newest algorithm/data-file pair continues to be supported by the policy server host as long as the client’s algorithm/data-file pair is listed as a valid entry in the networkencryption setting. These clients continue to use the settings that are defined by the encryption keyword in the settings file, and the same initial algorithm/data-file pair is used during the initial connection between the two hosts.

If an algorithm/data-file pair is deprecated in the policy server host and it is the first item in the clients’ list of supported algorithm/data-file pairs, then the new clients recognize this change and respond by automatically updating their setting files and backing up the previous settings files. Then the new clients reconnect to the policy server host using an algorithm/data-file pair that is common to both the policy server host and the client. However, if an algorithm/data-file pair is deprecated in the policy server host and the encryption that is used by the policy server host is not supported by the client, then the client’s list must be manually upgraded or the initial connection will fail.

The starting date and ending dates are optional and are applied as follows:

  • If the optional dates are used, then the algorithm/data-file pair is valid only during the specified time period.
  • If a starting date is specified, then the algorithm/data-file pair takes effect at the start of that day; otherwise, the algorithm/data-file pair is active immediately.
  • If an ending date is specified, the algorithm/data-file pair becomes inactive at the end of that date; otherwise, the algorithm/data-file pair never expires. The starting and ending dates are determined using Universal Coordinated Time (UTC) to eliminate ambiguity when the machines involved are in different time zones.

 

If the start and/or end date option is used, administrators must ensure that all hosts use the same validity period. Failure to do so will result in the hosts being unable to communicate with each other, or the hosts using other less desirable algorithm/data-file pairs that are common to both hosts, and the hosts must be synchronized. If all listed algorithms have expired (they have an end date and the end date has expired), then the default network algorithm (DES) is used unless one of the network encryptions is listed or the keyword none is specified with no end date.

networkencryption des:keyfile=/etc/pb.key:enddate=2008/05/31 aes-256:keyfile=/etc/pb.key.aes

This example setting directs the new client to use the DES encryption algorithm with the data file /etc/pb.key until May 31, 2008 (UTC). After that date, the new client is to use the AES-256 encryption algorithm with the data file /etc/pb.key.aes.

Default

The default encryption algorithm type is AES-256 and the default data file is typically /etc/pb.key.

Used on

  • Sudo Manager policy server
  • Sudo Manager client

pbrestport

The pbrestport setting details the TCP/IP port that REST services use to communicate to remote hosts. This should be consistent across the enterprise installation.

pbrestport 3000

Default

pbrestport 24351

Used On

All hosts

pbsudofailover

  • Version 22.2.0 and earlier: pbsudofailover setting not available.
  • Version 22.2.0 and later: pbsudofailover setting available.

When set to yes, allows sudo to run the secured task when the policy or log server cannot be contacted. The transparentfailover keyword is ignored so that connection errors are always displayed.

When set to no, an error message displays indicating sudo cannot contact the policy server or log server regardless of the value on transparentfailover.

pbsudofailover yes

 

Use the keyword pbsudofailover to enable and disable using the cached policy. By default, this keyword is set to no. If you want to allow the Sudo Manager client to fail over to the cached policy when connection to all Sudo Manager policy servers, or logservers fails, set pbsudofailover to yes in /etc/pbsudo.settings.

You can set it to yes in pbsudo.settings.default, so any new Sudo Manager client installation will have it set to yes in its pbsudo.settings file.

Default

pbsudofailover no

Used On

Sudo Manager client hosts

pbsudofailovertimeout

  • Version 9.3.0 and earlier: pbsudofailovertimeout setting not available.
  • Version 9.4.0 and later: pbsudofailovertimeout setting available.

When multiple Sudo Manager policy servers are configured in /etc/pbsudo.settings on sudo clients, they automatically try to retrieve their policy from each server in turn, providing failover. The pbsudofailovertimeout setting specifies how long it will take to timeout and try the next host in the list.

pbsudofailovertimeout     60

Default

pbsudofailovertimeout    30

Used On

Sudo Manager client hosts

pbsudorefresh

  • Version 9.3.0 and earlier: pbsudorefresh setting not available.
  • Version 9.4.0 and later: pbsudorefresh setting available.

Sudo Manager maintains a cached copy of the sudoers file on the target host which it updates periodically. The pbsudorefresh setting is the time in seconds that a client’s sudoers cache is valid. After that time, it contacts the policy server to refresh the cache.

pbsudorefresh    120

Default

pbsudorefresh    30

Used On

pbsudo client (stored in profile on policy server)

randomizelogservers

The randomizelogservers setting forces the policy server/submit host/run host to choose a log server host at random, rather than choosing the first available log server host that is specified in the logservers setting. This feature balances the load among multiple log server hosts.

The use of randomizelogservers can cause accept and finish events to be located on different log servers if the log servers are configured with eventdestinations set to a flat file (authevt=<file>) or an SQLite Database (authevt=db). However, if eventdestinations is set to authevt=<DSN> (same ODBC Oracle or MySQL database on all the log servers), then the accept and finish events are stored on the same Oracle or MySQL server. The default randomizelogservers setting is no.

The randomizelogservers keyword should not be used with the use of DNS SRV lookups. The randomizelogservers keyword can result in accept and finish events logged on different logservers, causing the need to merge iologs.

randomizelogservers yes
Default
randomizelogservers no
Used on
  • Sudo Manager policy server
  • Sudo Manager client

registrynameservice

  • Version 9.3.0 and earlier: registrynameservice setting not available.
  • Version 9.4.0 and later: registrynameservice setting available.

The registrynameservice option provides a global switch on each host to turn Registry Name Services on or off. Once it is turned on, individual settings such as submitmaster, acceptmaster, and logservers must be configured with a single asterisk to enable each setting to look up information in the Registry Name Service.

registrynameservice yes

Default

registrynameservice no

Used On

All hosts

restkeyencryption

  • Version 8.0 and earlier: restkeyencryption setting not available
  • Version 8.1.0 and later: restkeyencryption setting available

This is similar to other encryption keywords but only takes one value at a time.

restkeyencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
restkeyencryption aes-256:keyfile=/etc/pb.key

Default

restkeyencryption aes-256

Used on

  • Sudo Manager client

For more information, see networkencryption.

ssl

The ssl setting is always set to yes, and enables the use of EPM-L SSL features. 

ssl yes

Default

ssl yes

Used on

  • Sudo Manager policy server
  • Sudo Manager client

sslcountrycode

Country code to use when creating x509 SSL client certificates. Used by Client Registration.

sslcountrycode US

Default

sslcountrycode US

Used on

All hosts

For more information, see the following:

sslengine

The sslengine setting specifies the SSL engine ID to be used with the HSM. The value is case-sensitive.

The following is an example pb.settings configuration when using the SafeNet Luna SA Hardware Security Module:
sharedlibkrb5dependencies none
    sharedlibldapdependencies none
    sharedlibssldependencies /usr/local/lunassl/lib/libcrypto.so.0.9.8
    /usr/local/lunassl/lib/libssl.so.0.9.8
    /usr/local/lunassl/lib/engines/liblunaca3.so
            
    ssl yes
    sslservercertfile /etc/pb/CERTS/safenet.crt
    sslserverkeyfile /etc/pb/CERTS/safenet.key

sslengine LunaCA3

New SSL libraries with engine support are built and installed in the /usr/local/lunassl directory. Kerberos and LDAP are not in use. The engine ID is LunaCA3. The key file value is a name that is interpreted by the engine to access the private key on the HSM.

Default

No default value

Used on
  • Sudo Manager policy server

ssllocality

Locality to use when creating x509 SSL client certificates. Used by Client Registration.

ssllocality Phoenix

Default

ssllocality Phoenix

Used on

All hosts

For more information, see the following:

ssloptions

The ssloptions setting controls the following system-wide options:

Option Description
ClientCertificates To require certificates on the client side, add ClientCertificates to the ssloptions line.
AllowCachedNonSSL To allow a cached client to not use SSL when interacting with other components (for example: pbcached, pblocald) on the cached client machine.
AllowNonSSL

To communicate with older, non-SSL versions of EPM-L, add AllowNonSSL to your ssloptions line. Doing so allows SSL-enabled versions to communicate with non-SSL versions.

If an EPM-L client is SSL-enabled and the policy server host specifies AllowNonSSL, but not ClientCertificates, then the communications do not use SSL.
TLSMinV1.0, TLSMinV1.1, TLSMinV1.2, TLSMinV1.3 When SSL is enabled, this option allows you to set the minimum SSL/TLS value to use in the protocol.
TLSMaxV1.0, TLSMaxV1.1, TLSMaxV1.2, TLSMaxV1.3 When SSL is enabled, this option allows you to set the maximum SSL/TLS value to use in the protocol.
RequireSSL

To require SSL communications between Endpoint Privilege Management components without requiring EPM-L client certificates, then add RequireSSL to your ssloptions line.

This option is not compatible with the AllowNonSSL option. If you specify both AllowNonSSL and RequireSSL, then the last one that is specified takes precedence.
SSLFirst

If the SSLFirst option is selected, this option forces the SSL handshake to happen before the EPM-L handshake.

The SSLFirst option must be set on every EPM-L host including clients and servers.

The SSLFirst option is turned on by default in version 10.3.2 and later.
sslverbose If the sslverbose option is selected, server components log informational messages that are sent to error logs, detailing connections, SSL/TLS protocols, and the encryption ciphers used to communicate. This is a debugging and diagnostic option
validateClient

The option validateClient enables EPM-L servers (pbmasterd, pblocald, pblogd) to use SSL verifypeer and verifyhost features to validate the connected client host. Note that pbmasterd is also a client to pblocald, and both pbmasterd and pblocald are clients to pblogd.

This can be used when the client hosts have certificates installed, and the servers’ ssloptions includes the ClientCertificates option (validateClient forces ClientCertificates).

Enabling the validateClient ssloption on the server requires that pb.settings on the server includes the sslservercafile keyword, specifying the CA that signed the client’s certificate. The pb.settings file on the client must include the sslpbruncertfile and sslpbrunkeyfile keywords, specifying the client’s certificate and key. This feature alternatively uses the sslpbruncertdir, sslpbrunkeydir, and sslservercadir keywords.

The pb.settings file on pbmasterd and pblocald must include sslservercertfile and sslserverkeyfile keywords, specifying the servers' certificate and key. This feature alternatively uses the sslservercertdir and sslserverkeydir keywords.

Enabling the AllowNonSSL with validateClient results in an error. Non-SSL connections are not allowed with validateClient.

The client host’s hostname should be listed in the Subject Alternative Name (SAN) field of the certificate.
validateServer

The option validateServer enables EPM-L SSL clients to verify the server with the SSL verifypeer and verifyhost features. Note that pbmasterd is a client to pblocald, and both pbmasterd and pblocald are clients to pblogd.

Enabling the validateServer on the client requires that pb.settings on the client includes the sslpbruncafile keyword (sslpbservercafile keyword on pbmasterd and pblocald), specifying the CA that signed the server’s certificate. The pb.settings file on the server must include the sslservercertfile and sslserverkeyfile keywords, specifying the server’s certificate and key. This feature alternatively uses the sslservercertdir, sslserverkeydir, and sslpbruncadir keywords.

Enabling the AllowNonSSL with validateServer results in an error. Non-SSL connections are not allowed with validateServer.

The hostname should be listed in the Subject Alternative Name (SAN) field of the certificate.

The program terminates if invalid values are provided for ssloptions.

ssloptions AllowNonSSL
ssloptions requiressl sslfirst
ssloptions ClientCertificates
ssloptions AllowNonSSL ClientCertificates

Default

requiressl

Used on

  • Sudo Manager policy server
  • Sudo Manager client

sslorganization

Organization to use when creating x509 SSL client certificates. Used by Client Registration.

sslorgunit BeyondTrust

Default

sslorgunit BeyondTrust

Used on

All hosts

For more information, see the following:

sslorgunit

Organization unit to use when creating x509 SSL client certificates. Used by Client Registration.

sslorgunit Security

Default

sslorgunit Security

Used on

All hosts

For more information, see the following:

sslprovince

Province to use when creating x509 SSL client certificates. Used by Client Registration.

sslprovince AZ

Default

sslprovince AZ

Used on

All hosts

For more information, see the following:

sslpbruncipherlist

OpenSSL provides a variety of algorithms that can be used for encryption. The sslpbruncipherlist setting enables the administrator to restrict or promote the set of encryption algorithms that are used by Endpoint Privilege Management clients to communicate with SSL enabled server services.

The keyword sslpbruncipherlist accepts "cipherlist=" and "tlsv1.3=" cipher groups.

The cipher groups cipherlist= and tlsv1.3= are case-sensitive and space is not allowed before =.

When using the sslpbruncipherlist keyword, the order of cipher lists is not relevant.

This format: sslpbruncipherlist cipherlist= TLSv1.2:!SSLv2:@STRENGTH tlsv1.3= TLS_AES_256_GCM_SHA384

is the same as this format:

sslpbruncipherlist tlsv1.3= TLS_AES_256_GCM_SHA384 cipherlist= TLSv1.2:!SSLv2:@STRENGTH

These ciphers are limited to the set of ciphers available in the given version of OpenSSL used by the Endpoint Privilege Management installation.

Valid Values

Refer to the following table for the valid values for the sslpbruncipherlist. To use more than one cipher set, separate the values with colons.

cipherlist Values
OpenSSL Cipher Set Setting Value
SSL_RSA_WITH_NULL_MD5 NULL-MD5
SSL_RSA_WITH_NULL_SHA NULL-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
SSL_RSA_WITH_RC4_128_MD5 RC4-MD5
SSL_RSA_WITH_RC4_128_SHA RC4-SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
SSL_RSA_WITH_DES_CBC_SHA DES-CBC3-SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA
tlsv1.3 Values
OpenSSL Cipher Set Setting Value
TLS13-AES-256-GCM-SHA384 TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256 TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256 TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256 TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256 TLS13-AES-128-CCM-SHA256
Examples

In the following code snippet, EPM-L uses the cipher lists:

  • TLSv1.2:!SSLv2:@STRENGTH for TLS v1.2 (and earlier) connections
  • TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 for TLS v1.3 connections
sslpbruncipherlist cipherlist=TLSv1.2:!SSLv2:@STRENGTH tlsv1.3=TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

In the following code snippet, EPM-L uses the cipher lists:

  • TLSv1.2:!SSLv2:!3DES:!eNULL:@STRENGTH for TLS v1.2 (and earlier) connections.
  • tlsv1.3= cipher group for TLSv1.3 connections. This is the default value.
sslpbruncipherlist cipherlist=TLSv1.2:!SSLv2:!3DES:!eNULL:@STRENGTH
Default
cipherlist=TLSv1.2:!SSLv2:!3DES:!MD5:!ADH:!AECDH:!DHE:!eNULL:@STRENGTH
tlsv1.3=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
Used on

Submit hosts

submitmasters

Submitmasters is the hostname for the Sudo Manager Policy Server, where the sudoers policy files are stored. These hosts act as central repositories of the sudoers policy files obtained from sudo client hosts. It is highly recommended that hosts designated as sudo policy servers be isolated from regular user activity, to shield policies from users that can elevate their privileges.

The submitmasters setting provides a list of outgoing connection information for submitting task requests to EPM-L policy server daemons.

The list can contain:

  • Host names
  • A single asterisk (*) denoting a Registry Name Service lookup
  • Netgroups in the form:
    +@name
  • Hosts to exclude in the form:
    -name
  • Netgroups to exclude in the form:
    -@name
  • Absolute path names of a local pbmasterd. If spaces are required, then the string must be enclosed in quotation marks.
  • DNS SRV lookups, in the form:
    _<pbul service name>._tcp.<domain name>.[:port=<port>[:interface=<IP or hostname>]]
  • External programs, in the form:
    `/path/to/external/program`

The following are tried in sequence to determine the port value:

  1. The non-zero port value from a DNS SRV lookup
  2. The value specified within the submitmasters setting
  3. The value of the masterport setting
  4. The pbmasterd entry in services
  5. Port 24345
  6. The non-zero port value from a DNS SRV lookup
  7. The value specified within the submitmasters setting
  8. The value of the masterport setting
  9. The pbmasterd entry in services
  10. Port 24345
submitmasters myhost.mydomain
submitmasters sparky spot submitmasters host1 host2
submitmasters +@submitmasters -@badmasters -badhost
submitmasters sparky spot "/usr/sbin/pbmasterd -ar"
submitmasters _auto
submitmasters _pbmasters
submitmasters _pbmasters._tcp.mydomain.
submitmasters _pbmasters._tcp. mydomain.:port=12345
submitmasters `/bin/get_first_submitmaster`
Default

No default value

Used on

Submit hosts

transparentfailover

A transparentfailover occurs when an initial connection to a policy server or logserver host has failed and the program performs a failover to another available policy server or logserver host in the list. To acknowledge that a user failover has occurred, error messages from the failed connection are displayed to the user.

The transparentfailover setting enables you to suppress the following failover error messages:

  • Any Kerberos initialization error
  • 3084 initMangle failure during startup
  • 3089 Could not send initial protocol header to Policy Server
  • 3090 Did not receive initial protocol header from Policy Server
  • 8534 Policy Server on %s is not SSL enabled
  • 1913 Invalid Policy Server daemon on Policy Server host %s

When transparentfailover is set to yes, failover error messages listed above are suppressed. To display failover error messages, set transparentfailover to no in the pb.settings file.

This keyword is ignored if pbsudofailover is set to no. When pbsudofailover is set to no, sudo fails if it cannot connect to policy or logserver, and displays an error regardless of the value of transparentfailover.

transparentfailover yes
Default
transparentfailover yes
Used on

Sudo Manager client