Balabit 08 - Active Directory and access control

Balabit SCB Solution · Previous: Basic settings, logging and monitoring · Next: Certificates and keys

The appliance meets Active Directory twice. The administrators and operators of the appliance log in to its web interface with their AD accounts, and their AD groups decide what they may see and change. The users who pass through it to the jump servers are never logged in to the appliance at all, but their AD groups decide which channels they may open. Both rest on the same few objects in the directory and on one service account. This part covers those objects and how they nest, the AAA pages, the two local accounts that remain, the LDAP server policy that the connections use, the ldapsearch tests I ran while setting it up, and the test accounts per group.

Who is in the directory, and why there

The analysis asked where the users of the appliance should live: local users, POSIX LDAP or Active Directory. The answer was AD: "All users are here", and authorization "will not be handled on the level of the SCB but on the level of Active Directory", since all servers and network devices were already integrated with it. A RADIUS server existed but was not used. The design turned this into requirements FR7 (accounts and groups in AD) and FR8 (LDAPS).

The design document illustrates it with the vendor's figure, which shows more than was used here: the user's password can be checked by a RADIUS server, the group membership comes from LDAP, and the privileges follow from the groups. Here both the password check and the groups came from AD.

flowchart LR
  user["SCB web user"]
  scb["SCB"]
  radius["RADIUS Server"]
  ldap["LDAP Server"]
  priv["SCB user privilege based on group membership"]
  user --> scb
  scb -- "user authentication" --> radius
  scb -- "group membership" --> ldap
  scb --> priv

The objects

Chapter 4.4 of the design specifies a service account, an OU for user accounts and two layers of groups; chapter 4.7 adds the mail account and the mail group.

People go into the groups of RBAC_GROUPS; the appliance names only the groups of RBAC_ROLES. The design does not explain the two layers. As I read the OU names, it is the organisation's role-based scheme: a role is what a system refers to and stays stable, while the group of people behind it can be replaced or joined by another group without touching the appliance. The price is that the appliance must resolve nested groups, which is why "Enable nested groups" is on in both places where the directory is configured.

flowchart LR
  u["Account in OU=Users_STD"]
  g1["SCB_ADM_ORG"]
  g2["SCB_OPS_ORG"]
  g3["SCB_USR_PARTNER1"]
  g4["SCB_USR_ORG"]
  g5["SCB_USR_PARTNER2"]
  r1["SCB_ADM"]
  r2["SCB_OPS"]
  r3["SCB_USERS_PARTNER1"]
  r4["SCB_USERS_ORG"]
  r5["SCB_USERS_PARTNER2"]
  a1["AAA: All, read and write"]
  a2["AAA: All read, debug and troubleshooting write"]
  c1["Channel policies PARTNER1-*"]
  c2["Channel policies ORG-*"]
  c3["Channel policy PARTNER2-TERMINAL-ONLY"]
  u --> g1
  u --> g2
  u --> g3
  u --> g4
  u --> g5
  g1 --> r1
  g2 --> r2
  g3 --> r3
  g4 --> r4
  g5 --> r5
  r1 --> a1
  r2 --> a2
  r3 -- "remote groups" --> c1
  r4 -- "remote groups" --> c2
  r5 -- "remote groups" --> c3

SCB_USR_GUESTS and SCB_USERS_GUESTS are left out of the picture: no policy in the design names them. The IPMI modules of the two appliances do the opposite of the appliance: their AD role groups are the inner groups SCB_ADM_ORG and SCB_OPS_ORG, not the roles, and their LDAP switch is off; see IPMI out-of-band management. The later partners brought groups the design never lists: my test-account notes have SCB_USR_PARTNER3, SCB_USR_PARTNER4, SCB_USR_PARTNER5 and SCB_USR_CLOUD_PARTNER1 with SCB_USERS_* roles (for partner 4 the role column repeats SCB_USR_PARTNER4), and the site 2 configuration names SCB_USERS_PARTNER4 in a channel policy.

The listing is a Config document: AD objects for the SCB.

The web interface: AAA

The AAA settings authenticate web users against LDAP, type Active Directory, with the two domain controllers dc1-a-vcad001 and dc1-a-vcad002 on port 636, the whole domain as base DN, scb_svc as bind account, group membership read from memberOf, nested groups on. Users log in as account@ad.example.net. The connection is TLS on the LDAPS port, but the certificate check is "No certificate is required": the appliance does not verify that it talks to a domain controller. The mail servers of the Email Solution made the same choice against the same directory. "Require commit log" is on, so every change in site 1 needs a comment.

The access control list keeps the appliance's built-in groups as they are and adds two lines for the AD roles. SCB_ADM may read and change everything. SCB_OPS may read everything and change two things: system debug and the troubleshooting page, which is where a support bundle is collected; as I read the list, an operator can therefore help the vendor's support without being able to change the configuration.

The site 2 cluster, in its config.xml of September 2018, has the same backend and the same list. It authenticates against the same two site 1 domain controllers, with the encryption written as ssl and the certificate check never, and it has the commit log switched off.

The pages are Config documents: AAA (site 1).

The local accounts that remain

Once LDAP is the user database, the appliance disables its local users. The design keeps two exceptions: admin for the web interface "as last resort" when AD does not answer, and root for the console. The analysis had the same answer to "What if LDAP fails?" and left two other questions open with "TODO": what if the web interface itself does not work, and whether the passwords of the local accounts could be changed by a script. Neither was answered in my material.

The design is not consistent about the console. Chapter 4.3.3 says the console menu is accessible only to root, and chapter 8.1.2 says remote console access is "allowed only for local SCB user root", while the access table in the same chapter says "Only enabled account is admin". The SSH server has password authentication on and no keys. The operation how-to does not name the account it logs in with, the IPMI and debug how-to logs in as root, and the site 2 export lists admin as its only user (password set on 2018-01-08) and keeps root only as a removed password in the <management> element. My notes list passwords for both root and admin, replaced by placeholders here.

The connections: LDAP server policy and remote groups

Every RDP and SSH connection references the LDAP server policy AD.EXAMPLE.NET: the same domain controllers, base DN and bind account as the AAA page, nested groups on, the attributes sshPublicKey and userCertificate for keys and certificates, and again no certificate check. The channel policies do the rest. Each channel, for example the session shell of PARTNER1-ssh-only or the drawing channel of ORG-TERMINAL-ONLY, has its "remote groups" set to one role group and its "gateway groups" empty. As I understand the appliance, the remote groups are looked up in the connection's LDAP server for the user name the client gives for the target server, so a partner 1 user whose account is in SCB_USR_PARTNER1 gets the channels of PARTNER1-* and nothing else. As I understand it, the password is then checked by the jump server against AD (the analysis says all servers were integrated with it); for SSH, the authentication policy base relays password and keyboard-interactive logins to the server, and the appliance does not authenticate the user on its own. Gateway authentication, which would have made the user log in to the appliance first, was not used.

The site 2 configuration has the same policy, once more pointing to the site 1 domain controllers, and all eight of its connections reference it. The page is a Config document: LDAP server policy AD.EXAMPLE.NET (site 1); the connections and channel policies are in Connection and channel policies.

Testing with ldapsearch

Before trusting the appliance's nested-group lookup I tried to reproduce it from a Linux host with ldapsearch, as root, against the first domain controller. Active Directory resolves nested membership with a special matching rule, 1.2.840.113556.1.4.1941 ("in chain"), which follows the group chain on the server. The notes keep eight commands and two labels, OK1 and OK2, and no output. The first command has a typo in the bind DN (sbc_svc), the second a missing quote. The successful one, OK1, only reads the user OU after a bind with StartTLS:

$ ldapsearch -b OU=USERS_STD,DC=ad,DC=example,DC=net -D CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -W

The in-chain attempts got the direction wrong. OK2 and the two commands after it ask for objects that are, through nesting, members of the user admin01, which has no members; the question I meant, which role groups contain the user, needs member:1.2.840.113556.1.4.1941:= with the user's DN against OU=RBAC_ROLES, and the one line with member: put an OU, not the user, into the rule, and put the filter where the base DN belongs. The tests also ran on port 389, with StartTLS on some lines and in clear text with -x on others, while the appliance itself uses LDAPS on 636, so they proved less about the appliance's path than they seemed to. The whole set is a Config document: ldapsearch tests against Active Directory.

Test accounts

My notes keep two tables of test accounts, test_scb1 to test_scb6 plus test66 and test55, each in one AD group of the SCB (an SCB_USR_* group, or in the second table also SCB_ADM_ORG or SCB_OPS_ORG), so that every partner's path could be tried end to end; the in-band destination tests that used them are in End-user access. The two tables disagree. In one, test_scb1 is in SCB_USR_CLOUD_PARTNER1 and test_scb2 in SCB_USR_PARTNER4; in the other, test_scb1 is in SCB_ADM_ORG and test_scb2 in SCB_OPS_ORG, with partners 4 and 5 tested by test66 and test55. Neither table is dated.

Loose ends

• The mail integration table asks for the "Password for scb@ad.example.net"; the account is scb_mail.
• The service account's OU is Users_svc in chapter 4.4.1 and USERS_SVC on the AAA page; AD compares DNs without regard to case, so this is cosmetic.
• My notes have an LDAP setting with the base ou=users_partner1 and a bind account cn=balabit in that OU, which appears nowhere else.
• The domain membership of the appliance for RDP was disabled in the design; the site 2 support bundle shows its AD join test failing with "No logon servers".
• The design's own access table and its text disagree on whether admin or root opens the console.

What I would do differently

I would load the organisation's CA into the appliance and switch the certificate check on in both places, AAA and the LDAP server policy. My checklist for the Policies menu had "Trusted CA Lists, ALL settings" on it, but the as-built pages say "No certificate is required" and the site 2 export has an empty <pol_trustedca/>. I would run the ldapsearch tests the way the appliance connects, ldaps:// on 636 with the same CA, and keep their output. And I would date test-account tables, or better, keep them in the directory's own descriptions instead of in a notes file.