When a new Replica is brought online, users are unable to log in to the Server Agents that bind to that Replica. The audit logs show messages with "No Terminal Authorization". The rules assigned to the user appear normal and as if they should permit access. When the new Replica is taken offline, access returns to normal.

Resolution / Workaround

This can happen when a customized setting in the $BOKS_etc/method.conf file is set differently on the new Replica to the Master and other Replicas.

In the $BOKS_etc/method.conf file, verify that the DEFAULTHOSTTYPE variable is set the same on the Master and all Replicas.

The default setting is KNOWN. This means that hosts listed as a source in Access Routes must be defined in the BoKS database. It also sets how network/subnets should be defined when used as sources. With the default configuration, the source must be defined in the BoKS database unless prefixed by ANY/.

If this value is changed, it can affect how rules are written and how they are interpreted. If rules are written with a certain setting expected and the setting is different on a Replica, the rules could be interpreted in an unintended way and as a result, access could be denied.

One example might be where the Master and Replicas have a customized definition of "DEFAULTHOSTTYPE ANY" set in the method.conf file. A new Replica is brought online, but this customization was not made and it has the default setting of "DEFAULTHOSTTYPE KNOWN". When Server Agents start communicating with the new Replica, the rule sets would be interpreted differently and could result in access denials.

As a general rule, we would recommend against changing the default value of DEFAULTHOSTTYPE.


This example discusses DEFAULTHOSTTYPE, but that isn't the only variable that could cause similar symptoms. The real take-away here is that the method.conf file must be the same on all Replicas as it is on the Master.

Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: June 28, 2019