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>
73 lines
4.6 KiB
Markdown
73 lines
4.6 KiB
Markdown
---
|
||
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.
|