ci-server-engineer/.claude/skills/authorization/tasks/active-directory.md
cliu bf7d88a027 R1.05 re-check batch 3: alarms, audit, authorization, classes, HAC, reporting, pyTOOLS
Full manual diffs (L15, C20, E30, L25, J40, C10 §2, L10, P10, P11, J20,
C30, P20, R40, E10) and read-only checks on the shared R1.05 test server.
Skills and summaries moved to R1.05; new skill pytools (IM 36K10P40) from
docs (no Python on the test server). Issues ISS-132..181; corrections to
version-differences (E10, E30, P11, dss_ath_grp_u0104); C10 summary lists
the 3 new authorization actions; r105-verification V10-V17.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 10:21:36 +11:00

4.6 KiB
Raw Permalink Blame History


task: Active Directory integration and single sign-on (SPNEGO) for CI Server version: R1.05 (first written for R1.03) source: IM 36K10J40-01EN 4th ed. (Feb. 2026) §1–§3, App. 1 (unchanged from the 3rd ed. apart from contact information); dssana.sup AD/SSO keywords and auth\WEB-INF templates checked on R1.03 (2026-10-01) and on the R1.05 test server (2026-10-09) status: from docs; not tested (no Windows domain on either test system). R1.05: Active Directory and Single Sign On keywords, help texts and defaults identical to R1.03; auth\WEB-INF templates identical except web.xml.tpl (verified read-only 2026-10-09)

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. On R1.05 the template web.xml.tpl no longer has the old Servlet 2.3 DOCTYPE line (Servlet 3.1); the servlet entries are unchanged (ISS-153).
  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.

IM 36K10J40 does not mention the R1.04/R1.05 interfaces. Per IM 36K10J10 §2.9.1 the RESTful API accepts Manual CI Server or Manual OS (the latter for domain users), and pyTOOLS only Manual CI Server, so pyTOOLS scripts need a CI Server user with a password even when AD is on (from docs; login-methods.md).

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.