---
task: Active Directory integration and single sign-on (SPNEGO) for CI Server
version: R1.03
source: IM 36K10J40-01EN §1–§3, App. 1; dssana.sup AD/SSO keywords and auth\WEB-INF templates checked on the test system 2026-10-01
status: from docs (no domain on the test system)
---

# Active Directory and single sign-on

Needs a Windows domain, domain-joined CI Server machines and admin rights on the machines and
the domain controller. Not practiced; give the procedure and prepare the setup-file changes,
the user (and the domain administrator) applies them. Details: `knowledge/manuals/IM36K10J40-01EN.md`.

## 1. Decide the mapping mode

| | `Security_group` (recommended) | `Organizational_unit` (default in the file) |
|---|---|---|
| CI Server side | Each user profile gets a *Directory group* (Engineering Module user form, tab *Directory Services*; `USER_DF.DIRECTORY_GROUP`) and a *Profile priority* (`MERGE_PRIORITY`) | User profile names = OU names |
| AD side | One security group per profile, same name as the directory group; users in the groups | One OU per profile containing the users; all users also in the group named in `AD_SEC_GRP` (default: group named like the CI Server node) |

Profiles: reuse CI Server users as roles (e.g. `ADMIN`, `ENG`, `OPER`, `<Section>` operators);
they need no password for AD logins. A user in several groups gets the highest priority profile.

## 2. Enable AD integration (CI Core / CI Portal)

Prepared `dssana.sup` lines (tab *Active Directory*):

```
AD_INT_ON
AD_MAP_MODE = Security_group
AD_CHECK_THRESHOLD = 30
```

Optional (installed keywords, not in the manual): `AD_SERVER = "<dc host>[:port]"`,
`AD_SERVER_BACKUP`, `AD_SECURE` (LDAPS, port 636), `AD_ACCESS_USER`/`AD_ACCESS_PASSWORD` (blank =
the account that runs CI Server). For OU mode set `AD_MAP_MODE = Organizational_unit` and
`AD_SEC_GRP = "<group>"`.

Then: join the machine to the domain; run the CI Service as a domain account that is a local
administrator (*Services › CI Server Service › Log On*); restart CI Server. Users log in as
`<domain>\<user>` or `<user>@<domain>`; the Edit/Engineering Module login methods are then
ignored. If web access must not be open to every domain user, disable CI Portal (port 0 in
`jwuiisg.sup`, *Client communication*) — the manual's own warning.

## 3. Single sign-on for remote CI View (SPNEGO)

Checklist (order matters):
1. DNS forward and reverse records for CI Portal and CI View; CI Portal reached by host name;
   CI Portal with a valid SSL certificate (skill `portal-setup`).
2. DC: service user (e.g. `sso`), `setspn -S http/<portal FQDN> sso`, `ktpass … -out
   <file>.keytab -princ http/<portal FQDN>@<REALM> …` (realm upper case), delegation trust.
3. Keytab to `%TLS_ALLUSERS_PATH%\wap\webapps\auth\WEB-INF`; `kinit http/<portal
   FQDN>@<REALM>` succeeds on CI Portal (`tls\jre\bin`) and CI View (Remote Connect JRE).
4. `dssana.sup` tab *Single Sign On*: `SSO_INT_ON`, `WEBHMI_SERVER_FQDN = "<portal FQDN>"`,
   `DOMAIN_NAME = "<REALM>"`, `KRB5_FILE = "<path>\krb5.ini"` (set the realm mapping in that
   file), `KEYTAB_FILE = "<file>.keytab"`, `SSO_TOKEN_DURATION` (s); restart USER Service.
5. Browsers on CI View: Firefox `network.negotiate-auth.trusted-uris` and `…delegation-uris`
   = `https://<portal FQDN>`; Edge/IE: add the site to *Local intranet*, integrated Windows
   authentication on.
6. Test: temporarily enable the `test` servlet in `web.xml`, open
   `https://<portal FQDN>:8443/auth/test`, expect *Authorization scheme : SPNEGO*; restore
   `web.xml`.
7. Start applications from the *Remote Connect* folder on CI View; the login methods `SSO` in
   *Login control* (installed default for most UIs) then log the user in without a prompt.

Common failures (manual): "realm not found" → fix `krb5.ini`; access by IP address or from the
CI Portal machine itself → no SPNEGO; DNS reverse lookup missing → ticket errors.