Balabit - LDAP server policy AD.EXAMPLE.NET (site 1)

category: solutionz · date: 2018-12-31 · updated: 2026-10-03 · author: LALA

Balabit SCB Solution · Config document · referenced from Active Directory and access control and Connection and channel policies

notepassword_for_scb_svc was a placeholder already in my design document. The certificate of the domain controllers is not verified here either.

The LDAP server policy that every RDP and SSH connection of the cluster references. It is a second, separate definition of the same directory that the AAA page uses for the web interface: the AAA page decides who may administer the appliance, this policy is what the connections use to look up the groups of the users who pass through it.

Item	Value
Where	SCB web interface, Policies > LDAP Servers > `AD.EXAMPLE.NET`
Cluster	`dc1-s-xblb001`, site 1
Firmware at the time	5 LTS (5.0.3)
Source	My design document, version 0.5 of 2017-12-01 (draft), chapter 7.4.5
Used by	All three RDP connections and all four SSH connections of the design (field LDAP SERVER); all eight connections of the site 2 `config.xml`
Web interface	The AAA settings with the same servers and account: AAA (site 1)

The answers

ini

# Page / Field = value, as configured on dc1-s-xblb001, from the design document v0.5, chapter 7.4.5

Policies > LDAP Servers > AD.EXAMPLE.NET / NAME = AD.EXAMPLE.NET
Policies > LDAP Servers > AD.EXAMPLE.NET / SERVER ADDRESS = Address: dc1-a-vcad001.adm.example.net / Port: 636 / Address: dc1-a-vcad002.adm.example.net / Port: 636
Policies > LDAP Servers > AD.EXAMPLE.NET / TYPE = Active Directory
Policies > LDAP Servers > AD.EXAMPLE.NET / BASE DN = DC=ad,DC=example,DC=net
Policies > LDAP Servers > AD.EXAMPLE.NET / BIND DN = CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net
Policies > LDAP Servers > AD.EXAMPLE.NET / BIND PASSWORD = password_for_scb_svc
Policies > LDAP Servers > AD.EXAMPLE.NET / CERTIFICATE RELATED ATTRIBUTES: / PUBLICKEY ATTRIBUTE NAME / GENERATED PUBLICKEY ATTRIBUTE NAME / CERTIFICATE ATTRIBUTE NAME / GENERATED CERTIFICATE ATTRIBUTE NAME = sshPublicKey / userCertificate
Policies > LDAP Servers > AD.EXAMPLE.NET / ENABLE NESTED GROUPS = Yes
Policies > LDAP Servers > AD.EXAMPLE.NET / ENCRYPTION / SERVER CERTIFICATE CHECK / AUTHENTICATE CLIENT = TLS / No certificate is required / No

Setting	What it means here
Name `AD.EXAMPLE.NET`	The domain name in capitals, as the policy is named after the directory, not after a server
Servers, base DN, bind DN	The same two domain controllers on LDAPS 636, the whole domain as search base, the same service account `scb_svc` as on the AAA page
`sshPublicKey / userCertificate`	The design joins four field names into one row and gives two values. The site 2 `config.xml` shows where they belong: `<publickey_attr>sshPublicKey</publickey_attr>` and `<x509_attr>userCertificate</x509_attr>`, the attributes for a user's SSH public key and X.509 certificate; it has no element for the two "generated" fields. As built, the authentication policy relayed only password and keyboard-interactive logins, so, as I read it, neither attribute was used
Nested groups Yes	A user who is in `SCB_USR_PARTNER1` counts as a member of `SCB_USERS_PARTNER1`, the group the channel policies name
TLS, no certificate check	As on the AAA page: encrypted, not verified

How the policy is used is in the channel policies: every channel of the documented RDP and SSH channel policies has its REMOTE GROUPS set to one of SCB_USERS_PARTNER1, SCB_USERS_ORG or SCB_USERS_PARTNER2, and the GATEWAY GROUPS empty. As I understand the appliance, "remote groups" are looked up in the LDAP server of the connection for the user name the client gives for the target server, so the policy is what turns an AD group membership into the right to open a channel. Gateway authentication, the alternative that asks the user to log in to the appliance first, was not used.

The site 2 config.xml (2018-09-17, element <pol_ldaps>, id id057) has this policy with the same name and the same values, including the two site 1 domain controllers, and writes the encryption as <encryption choice="ssl"> with <server_cert_check choice="never"/>.

Checked against One Identity Safeguard for Privileged Sessions 9.0

As built	Today
Policies > LDAP Servers, `sshPublicKey`, `userCertificate`	Same menu; "Publickey attribute name" and "Certificate attribute name" remain
"No certificate is required"	"Only accept certificates authenticated by the Trust Store" with a selected trust store
Relayed password and keyboard-interactive, no gateway authentication	Relayed authentication methods remain. The vendor's security checklist, in SCB 5 as in SPS 9.0: "Always use gateway authentication to authenticate clients. Do not trust the source IP address of a connection, or the result of server authentication."

The as-built design did exactly what the checklist warns against, then and now: it relied on the jump server's authentication and on the AD group looked up for the name the user typed.