Balabit - AAA (site 1)
Balabit SCB Solution · Config document · referenced from Active Directory and access control
note
password_for_scb_svc was a placeholder already in my design document; the real bind password was never written into it. "No certificate is required" means the certificates of the domain controllers were not verified.Who may log in to the web interface of the appliance and what each user may see and change: the web users are authenticated against Active Directory over LDAPS with the service account scb_svc, their AD group memberships (nested ones included) decide their rights, and every configuration change needs a commit message.
| Item | Value |
|---|---|
| Where | SCB web interface, AAA > Settings and AAA > Access Control |
| 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), chapters 7.3.1 to 7.3.3 |
| Directory | ad.example.net, domain controllers dc1-a-vcad001 (10.11.16.209) and dc1-a-vcad002 (10.11.16.210), LDAPS on TCP 636 |
| Groups in AD | AD objects for the SCB |
The answers
# Page / Field = value, as configured on dc1-s-xblb001, from the design document v0.5, chapters 7.3.1 to 7.3.3 AAA > Settings > Authentication settings / AUTHENTICATION METHOD = Password provided by database AAA > Settings > Authentication settings / USER DATABASE = LDAP AAA > Settings > Authentication settings / SERVER ADDRESS = Address: dc1-a-vcad001.adm.example.net / Port: 636 / Address: dc1-a-vcad002.adm.example.net / Port: 636 AAA > Settings > Authentication settings / TYPE = Active Directory AAA > Settings > Authentication settings / BASE DN = DC=ad,DC=example,DC=net AAA > Settings > Authentication settings / BIND DN = CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net AAA > Settings > Authentication settings / BIND PASSWORD = password_for_scb_svc AAA > Settings > Authentication settings / USE ATTR. OF GROUP DNS = memberOf AAA > Settings > Authentication settings / ENABLE NESTED GROUPS = Yes AAA > Settings > Authentication settings / ENCRYPTION / SERVER CERTIFICATE CHECK / AUTHENTICATE CLIENT = TLS / No certificate is required / No AAA > Settings > Accounting settings / REQUIRE COMMIT LOG = Yes AAA > Access Control > basic-view / Object = Basic Settings AAA > Access Control > basic-view / Type = read AAA > Access Control > basic-write / Object = Basic Settings AAA > Access Control > basic-write / Type = read and write/perform AAA > Access Control > auth-view / Object = AAA AAA > Access Control > auth-view / Type = read AAA > Access Control > auth-write / Object = AAA AAA > Access Control > auth-write / Type = read and write/perform AAA > Access Control > search / Object = Search AAA > Access Control > search / Type = read AAA > Access Control > changelog / Object = AAA/Accounting AAA > Access Control > changelog / Type = read AAA > Access Control > policies-view / Object = Policies AAA > Access Control > policies-view / Type = read AAA > Access Control > policies-write / Object = Policies AAA > Access Control > policies-write / Type = read and write/perform AAA > Access Control > ssh-view / Object = SSH Control AAA > Access Control > ssh-view / Type = read AAA > Access Control > ssh-write / Object = SSH Control AAA > Access Control > ssh-write / Type = read and write/perform AAA > Access Control > rdp-view / Object = RDP Control AAA > Access Control > rdp-view / Type = read AAA > Access Control > rdp-write / Object = RDP Control AAA > Access Control > rdp-write / Type = read and write/perform AAA > Access Control > telnet-view / Object = TELNET Control AAA > Access Control > telnet-view / Type = read AAA > Access Control > telnet-write / Object = TELNET Control AAA > Access Control > telnet-write / Type = read and write/perform AAA > Access Control > vnc-view / Object = VNC Control AAA > Access Control > vnc-view / Type = read AAA > Access Control > vnc-write / Object = VNC Control AAA > Access Control > vnc-write / Type = read and write/perform AAA > Access Control > indexing / Object = Search/Search / Indexer/Audit Player communication AAA > Access Control > indexing / Type = read and write/perform AAA > Access Control > ica-view / Object = ICA Control AAA > Access Control > ica-view / Type = read AAA > Access Control > ica-write / Object = ICA Control AAA > Access Control > ica-write / Type = read and write/perform AAA > Access Control > api / Object = Access RPC API AAA > Access Control > api / Type = read and write/perform AAA > Access Control > http-view / Object = HTTP Control AAA > Access Control > http-view / Type = read AAA > Access Control > http-write / Object = HTTP Control AAA > Access Control > http-write / Type = read and write/perform AAA > Access Control > indexer-view / Object = Indexer AAA > Access Control > indexer-view / Type = read AAA > Access Control > indexer-write / Object = Indexer AAA > Access Control > indexer-write / Type = read and write/perform AAA > Access Control > admin-write / Object = All AAA > Access Control > admin-write / Type = read and write/perform AAA > Access Control > admin-read / Object = All AAA > Access Control > admin-read / Type = read AAA > Access Control > SCB_ADM / Object = All AAA > Access Control > SCB_ADM / Type = read and write/perform AAA > Access Control > SCB_OPS / Object = All AAA > Access Control > SCB_OPS / Type = read AAA > Access Control > SCB_OPS / Object = System debug / Basic Settings/Troubleshooting AAA > Access Control > SCB_OPS / Type = read and write/perform
| Setting | What it means here |
|---|---|
| Password provided by database, LDAP, Active Directory | A web user types the AD password, the appliance checks it against AD. When LDAP is the user database, the local users are switched off except admin, which stays as the way in when AD does not answer |
| Two servers on 636 | If the first domain controller does not answer, the second is tried |
Bind DN scb_svc | The service account that searches the directory. The design's chapter 4.4.1 writes its OU as OU=Users_svc; here it is OU=USERS_SVC. AD does not care about the case of DNs, so both name the same object |
memberOf, nested groups Yes | The groups are read from the user's memberOf attribute, and groups inside groups count, which is what lets SCB_ADM_ORG inside SCB_ADM work |
| TLS, "No certificate is required", authenticate client No | The connection is encrypted (LDAPS), but the domain controller's certificate is accepted without any check, and the appliance shows no client certificate |
| Require commit log Yes | Every change in the web interface asks for a comment, which the changelog page shows later |
basic-view to admin-read | The groups the appliance creates by itself, with their default rights; they were left as they are |
SCB_ADM: All, read and write | The AD role group of the administrators gets everything |
SCB_OPS: All read, plus System debug and Troubleshooting write | The operators see everything and change nothing, except that they can switch on debug mode and use the troubleshooting page, for example to collect a support bundle |
The exported config.xml of the site 2 cluster (2018-09-17, element <aaa>) has the same backend and the same access control list, with one difference, the commit log. It authenticates against the site 1 domain controllers dc1-a-vcad001 and dc1-a-vcad002, as here; the XML writes TLS and "No certificate is required" as <encryption choice="ssl"> and <server_cert_check choice="never"/>. But it has <require_commitlog enabled="no"/>, so in site 2 changes needed no comment. Its only local user is admin, whose password was set on 2018-01-08 (pwcreated), and the built-in groups have no members.
Checked against One Identity Safeguard for Privileged Sessions 9.0
| As built | Today |
|---|---|
| AAA > Settings, LDAP, Active Directory | Configured under Users & Access Control > Login options: first an AD/LDAP server, then a login method; "Enable nested groups" is still there, with the warning that nested groups can slow the query; the group attribute is still for example memberOf |
| TLS on 636, "No certificate is required" | 636 for TLS, 389 for STARTTLS. The server certificate is verified against a trust store, and the address must then be a name or address present in the certificate. Since 6.0.4 and 6.5.0 certificates with SHA-1 signatures are not trusted for AD or LDAP authentication. Whether "no check" can still be selected the 9.0 guide does not say |
Local admin as last resort | Unchanged: local users including admin exist by default, admin cannot be deleted and is subject to the brute-force protection |
| Require commit log; built-in groups | Both remain |
The structure of this page survived. Its weak setting, no verification of the domain controllers, now has a documented replacement in the trust store, and SHA-1 signed domain-controller certificates would no longer be trusted after an upgrade.