cliu/ci-server-engineer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Phase 13: High availability and Active Directory #15

Merged
cliu merged 4 commits from docs/phase-13-ha-ad into main 2026-10-01 19:52:27 +10:00
Conversation 0 Commits 4 Files changed 12 +123 -5
3 changed files with 123 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 5ae2de0d15 - Show all commits

14
.claude/skills/authorization/SKILL.md
View file

@ -5,14 +5,17 @@ description: >-
create, list or remove CI Server users or authorization groups, choose authorization actions
(ITEM_READ, ITEM_MODIFY_VALUE, …), set process areas, logoff timeout or initial display for
a user, change how users log in (dssana.sup login method: Automatic, Manual CI Server,
Manual OS, No, SSO, Deny), or hide Engineering Module features with a scheme.
Sources IM 36K10C10-01EN §2; Active Directory and single sign-on follow in phase 13 (IM 36K10J40).
Manual OS, No, SSO, Deny; no-login profile CI_NO_LOGIN), hide Engineering Module features
with a scheme, or connect CI Server to Active Directory (AD, domain users, security group or
OU mapping, directory group, profile priority, AD_INT_ON) and single sign-on for CI View
(SSO, SPNEGO, Kerberos, keytab, setspn, ktpass, kinit, krb5.ini). Sources IM 36K10C10-01EN §2,
IM 36K10J40-01EN.
---
# Authorization (R1.03)
Background: `knowledge/manuals/IM36K10C10-01EN.md` §2 (login methods, actions, user tabs,
schemes). Login settings are in `dssana.sup` on CI Core (skill `portal-setup` for reading
schemes), `IM36K10J40-01EN.md` (Active Directory, SSO). Login settings are in `dssana.sup` on CI Core (skill `portal-setup` for reading
and changing setup files).
Rules:
@ -24,6 +27,7 @@ Rules:
| Task | File | Status |
|---|---|---|
| Create, check and remove authorization groups and users (quick load) | `tasks/users-groups.md` | verified |
| Login methods per client and user interface (`dssana.sup`, tab *Login control*) | C10 summary §2 | from docs (installed values read) |
| Login methods per client and user interface (`dssana.sup`, tab *Login control*); *No* login = full authorization when the profile user is missing | `tasks/login-methods.md` | verified (read; changes from docs) |
| Schemes (hide Engineering Module features) | C10 summary §2 | from docs |
| Active Directory, single sign-on, password rules | phase 13 | not covered |
| Active Directory integration and single sign-on (SPNEGO) | `tasks/active-directory.md` | from docs (no domain) |
| Password rules (`dssana.sup` *Password rules*: length, digits, punctuation, mixed case) | L50 summary §3 | from docs |

67
.claude/skills/authorization/tasks/active-directory.md Normal file
View file

@ -0,0 +1,67 @@
---
task: Active Directory integration and single sign-on (SPNEGO) for CI Server
version: R1.03
source: IM 36K10J40-01EN §1–§3, App. 1; dssana.sup AD/SSO keywords and auth\WEB-INF templates checked on the test system 2026-10-01
status: from docs (no domain on the test system)
---
# 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`.
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.
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.

47
.claude/skills/authorization/tasks/login-methods.md Normal file
View file

@ -0,0 +1,47 @@
---
task: Read and change login methods per client and user interface (dssana.sup Login control)
version: R1.03
source: IM 36K10C10-01EN §2.2; IM 36K10J40-01EN §1.1, §2.10.3; dssana.sup help and installed values checked on the test system 2026-10-01
status: verified (reading and the No-login behaviour; changing the file from docs — admin)
---
# Login methods (`dssana.sup`, tab *Login control*)
## 1. Read the current methods
`findstr /b LOGIN_METHOD %TLS_ROOT_PATH%\tls\sup\dssana.sup` (or the Setup File Editor).
```
LOGIN_METHOD = <client>, "<user interface>", <method>, <no login when no users>, "<no-login profile>"
```
- `<client>`: host name or IP (wildcards allowed), `"<local>"` (this machine) or `"<remote>"`
(any other); lines are evaluated top-down, `<local>`/`<remote>` always last.
- `<user interface>`: the full name from the *User Interfaces* tab (`USER_INTERFACE = …`), e.g.
`"Engineering Module"`, `"Edit Module"`, `"Operator Interface"`, `"Quickload Utility"`.
- `<method>`: `Automatic` (Windows name = CI Server user, no password), `Manual CI Server`,
`Manual OS`, `No`, `SSO`, `Deny`.
Installed (R1.03.00): local and remote Engineering Module, Edit Module, Operator Interface, Item
Search, Mobile Operator, Excel Add-in → `SSO` (falls back to *Manual CI Server* while SSO is not
set up); local Quickload / Display and Symbol Utility → `No`; remote Playback Viewer, Quickload,
Display/Symbol utilities → `Deny`; OPC UA server, ODBC, `dnetapi` → `Manual CI Server`;
anonymous OPC UA (local) → `No` with profile `CI_NO_LOGIN_OPCUAS`.
## 2. *No* login — check the profile
With `No` the user interface runs with the no-login profile (5th field). **If no CI Server user
with that name exists, the session gets full authorization** (`dssana.sup` help; verified
indirectly: `Quickload Utility` uses `No` with an empty profile and every `dssqld` change is
recorded in the audit trail as user `FULL AUTHORIZATION`). The installed lines name
`CI_NO_LOGIN`, which does not exist by default (only `CI_NO_LOGIN_OPCUAS` does).
Before setting `No` for an operator UI: create user `CI_NO_LOGIN` with a restricted
authorization group (`users-groups.md`) and a password, then change the method.
## 3. Change a method
Admin rights; hand to the user (skill `portal-setup`, `change-setup-file.md`). Add a specific
line above the `<local>`/`<remote>` lines (e.g. one HMI PC by host name), save, restart USER
Service (or CI Server) for it to take effect. With **AD integration on** (`AD_INT_ON = YES`) the
methods of the Edit and Engineering Modules are ignored: see `active-directory.md`.