Add login-methods and active-directory tasks to the authorization skill

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude/skills/authorization/SKILL.md

@@ -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.
+  Manual OS, No, SSO, Deny; no-login profile CI_NO_LOGIN), hide Engineering Module features
-  Sources IM 36K10C10-01EN §2; Active Directory and single sign-on follow in phase 13 (IM 36K10J40).
+  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 |

.claude/skills/authorization/tasks/active-directory.md

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

.claude/skills/authorization/tasks/login-methods.md

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