ci-server-engineer/knowledge/manuals/IM36K10J40-01EN.md

manual	title	edition	version	status
IM 36K10J40-01EN	Active Directory Integration	4th Edition, Feb. 2026 (first written from the 3rd Edition, Sep. 2023)	R1.05 (first written for R1.03)	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 R1.03 (2026-10-01) and compared with the R1.05 test server (2026-10-09); AD and SPNEGO set-up from docs only, not tested (no domain)

Active Directory Integration (R1.05)

R1.05 edition (Feb. 2026): the revision table lists only contact information, and the full text diff against the 3rd edition (2026-10-09) found nothing else (spacing and the cover only). No R1.04 edition change. Section numbers below are unchanged. The manual does not mention the login methods of the R1.04/R1.05 interfaces (RESTful API, pyTOOLS, Password Check; see §5).

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; R1.05.00 compared 2026-10-09)

R1.05.00 (verified read-only on the R1.05 test server, 2026-10-09): the Active Directory and Single Sign On keywords, their help texts and the installed values are identical to R1.03; USER_DF is unchanged (DIRECTORY_GROUP, MERGE_PRIORITY); the auth\WEB-INF files are the same six, and only web.xml.tpl changed (old Servlet 2.3 DOCTYPE removed, ISS-153). Login control gains three user interfaces with Manual CI Server lines: RESTful API Server, Python Interface (pyTOOLS), Password Check Function; the .NET API line is now named Application Interface (R1.03: dnetapi, ISS-148). IM 36K10J10 5th ed. §2.9.1 allows Manual CI Server or Manual OS for the RESTful API and only Manual CI Server for pyTOOLS, so pyTOOLS cannot use AD/SSO logins.

R1.03.00:

• 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).