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

73 lines
4.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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