---
manual: IM 36K10J40-01EN
title: Active Directory Integration
edition: 3rd Edition, Sep. 2023
version: R1.03
status: installed dssana.sup (Active Directory, Single Sign On and Login control tabs), USER_DF fields and the auth WEB-INF templates checked read-only on the test system 2026-10-01; AD and SPNEGO set-up from docs only (no domain)
---

# Active Directory Integration (R1.03)

With AD integration CI Server takes users from a Windows domain (Kerberos/AD) instead of its own
user list; with single sign-on (SPNEGO) remote CI View users start CI Portal applications without
a login dialog. Windows only. Section numbers refer to the manual; "installed" means checked on
the R1.03.00 test system.

## 1. What it gives (§1)

Users and policies kept in one place (the domain), no second login after Windows, strong
password rules from Windows, still works when the domain controller is unreachable (cached
profiles), switchable per CI Server system. No *secondary login* (temporary elevation) with
AD/SSO. AD integration **overrides** the per-application login methods in `dssana.sup`.

Prerequisites (§2.1): CI Server machines in a valid AD domain, .NET 3.5+, domain users, and the
CI Service started by a domain user that is a local administrator (§2.12: add the AD user to
the local *Administrators* group, then *Services › CI Server Service › Log On* with that account).

## 2. Mapping AD users to CI Server user profiles (§2.4–§2.7)

The CI Server user records (`USER_DF`, Engineering Module user profile form) act as **profiles**;
AD users need no CI Server password. Two mapping modes (`AD_MAP_MODE`, one only):

| Mode | How a user gets a profile |
|---|---|
| `Organizational_unit` (default) | The user's AD **OU** name = CI Server user name; the user must also be in the AD security group named in `AD_SEC_GRP` (`"use_default_node_name"` = a group named like the CI Server node) |
| `Security_group` (**recommended**) | The CI Server user's *Directory group* (`USER_DF.DIRECTORY_GROUP`, tab *Directory Services*) = an AD security group name, e.g. `ADMIN` ↔ `FT-ADMIN-GR`, `ENG` ↔ `FT-ENG-GR`, `OPER` ↔ `FT-OPER-GR`. Several memberships: the highest *Profile priority* (`MERGE_PRIORITY`) wins; equal priority → first in alphabetical order. Nested groups count |

`ADMINE` is the enterprise profile (Enterprise Automation System only). When AD is enabled the
`ADMIN` profile is the default.

## 3. Setup steps (§2.8–§2.12)

1. IP addresses and DNS (AD server as preferred DNS) on the domain controller, CI Portal/Core
   and CI View machines.
2. Domain controller: AD DS role, promote to DC (new forest), DNS forward **and reverse**
   lookup zones with A and PTR records for CI Portal and CI View (`nslookup` to verify).
3. *Active Directory Users and Computers*: an OU for the CI Server objects (example
   `SCADAGROUP`), then OUs + one security group (OU mode) or security groups (group mode), the
   users, memberships.
4. `dssana.sup` tab *Active Directory* on CI Core/Portal: enable, mapping mode, security group
   (OU mode only), check threshold. Restart USER Service.
5. Join CI Portal/Core to the domain; users log in as `<domain>\<user>` or `<user>@<domain>`.
6. When AD is on, the login methods of the Edit and Engineering Modules are ignored and no login
   dialog appears; access depends on the mapped profile's rights. **Security note** in the
   manual: anyone with a domain account can then use CI Portal; set the CI Portal port to 0 in
   `jwuiisg.sup` (*Client communication*) if web access is not wanted.

## 4. Single sign-on for CI View (SPNEGO, §3)

Prerequisites: AD integration on, valid CI Server profile for the domain user, CI Portal with a
valid SSL certificate, CI View in the intranet zone, CI Portal addressed by host name with
forward and reverse DNS, browser integrated Windows authentication, CI View not on the CI
Portal machine.

1. DC: a dedicated AD user (e.g. `sso`, password never expires), `setspn -S
   http/<portal FQDN> <user>`, `ktpass -out <file>.keytab -princ http/<portal FQDN>@<REALM>
   -mapuser <user> -mapOp set -pass <password> -crypto All -ptype KRB5_NT_PRINCIPAL` (realm in
   upper case; one SPN per CI Portal), *Trust this user for delegation* (Kerberos only).
2. Copy the keytab to `%TLS_ALLUSERS_PATH%\wap\webapps\auth\WEB-INF`; check with `setspn -L`.
3. `kinit http/<portal FQDN>@<REALM>` from `tls\jre\bin` on CI Portal and from the Remote
   Connect JRE on CI View (must succeed).
4. `dssana.sup` tab *Single Sign On*: CI Portal FQDN, SPN domain, `krb5.ini` path (realm
   mapping; template in `auth\WEB-INF`), keytab file name, token duration. Restart USER Service
   (generates the `*.conf` files).
5. Browser: Firefox `network.negotiate-auth.trusted-uris`/`delegation-uris`; IE/Edge intranet
   sites + integrated Windows authentication.
6. Test page: uncomment the `test` servlet in `web.xml`, restart, open
   `https://<portal FQDN>:8443/auth/test` → *Authorization scheme : SPNEGO*; restore `web.xml`.
7. CI View: start applications from the *Remote Connect* start-menu folder; no login prompt,
   the loaded profile shows in the status bar.

## 5. Installed (R1.03.00 test system)

- `dssana.sup` *Active Directory* tab keywords: `AD_INT_ON` (installed `NO`), `AD_SECURE`
  (`NO`; help: "default is yes"), `AD_SERVER`, `AD_SERVER_BACKUP` (host or IP, optional
  `:port`; 389 plain, 636 secure), `AD_ACCESS_USER`/`AD_ACCESS_PASSWORD` (blank = the account
  that runs CI Server), `AD_MAP_MODE` (`Organizational_unit`), `AD_SEC_GRP`
  (`"use_default_node_name"`), `AD_CHECK_THRESHOLD` (30 s). The server, secure and access-user
  keywords are **not in the manual** (ISS-054).
- *Single Sign On* tab: `SSO_INT_ON` (`NO`), `SSO_TOKEN_DURATION` (20 s),
  `WEBHMI_SERVER_FQDN` (`'my-host.some.domain'`), `DOMAIN_NAME` (`SOME.DOMAIN`), `KRB5_FILE`,
  `KEYTAB_FILE` (`'keytab'`) — placeholders.
- `%TLS_WAP_PATH%\webapps\auth\WEB-INF` holds `krb5.ini`, `readme.txt` and the templates
  `spnego.conf.tpl`, `spnego.properties.tpl`, `web.xml.tpl`, `webstartauth.conf.tpl`.
- `USER_DF` has `DIRECTORY_GROUP` (68 characters) and `MERGE_PRIORITY` (the manual's *Profile
  priority*).
- *Login control*: the installed lines use **SSO** for local and remote Engineering Module, Edit
  Module, Operator Interface and other UIs; without SSO set up this falls back to *Manual CI
  Server* (help text). The *No* login profile is `CI_NO_LOGIN` (anonymous OPC UA:
  `CI_NO_LOGIN_OPCUAS`); help: if no user with that name exists, **full authorization** is used.
  Verified indirectly: `Quickload Utility` has *No* login with an empty profile and every
  `dssqld` run is recorded as user `FULL AUTHORIZATION` in the audit trail (ISS-018).

Task files: skill `authorization` (`login-methods.md`, `active-directory.md`).