103 lines
6.6 KiB
Markdown
103 lines
6.6 KiB
Markdown
---
|
||
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`).
|