ci-server-engineer/.claude/skills/authorization/tasks/active-directory.md

task	version	source	status
Active Directory integration and single sign-on (SPNEGO) for CI Server	R1.03	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	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.