Windows-Benutzer Berechtigungen

Iptor-User Berechtigungen

Dieses Dokument definiert das empfohlene Berechtigungsmodell für Iptor-Installationen bei Kunden. Es gilt für alle Umgebungen und kann direkt vom Support verwendet werden.

Grundprinzip: Least Privilege — jeder User bekommt nur die Rechte, die er tatsächlich braucht.

Zwei-User-Modell

Statt eines einzigen privilegierten Benutzers für alles werden zwei getrennte Windows-Accounts eingerichtet:

	Support-Admin-User	Service-User
Zweck	RDP-Zugriff, Multiflex-Installation	IIS App Pool, Scripts, Task Scheduler
Admin-Rechte	Lokaler Admin ✅	❌
RDP-Zugriff	✅	❌
IIS App Pool	❌	✅
Task Scheduler	❌	✅
Netzwerkpfade	—	✅ (via Windows Auth)
Netzwerkdrucker	—	✅

Support-Admin-User

Dieser User wird vom Iptor-Support für RDP-Zugriff und Softwareinstallation verwendet.

Benötigte Rechte:

Mitglied der lokalen Gruppe Administrators
RDP-Zugriff (Remote Desktop Users)

Warum lokaler Admin?
Multiflex-Installation und -Updates sind klassische Windows-Installer-Setups: sie schreiben in die Registry, legen IIS Application Pools und Websites an und registrieren Windows-Dienste. Dafür sind lokale Admin-Rechte zwingend erforderlich.

Service-User

Dieser Domain-User läuft im Hintergrund — als IIS App Pool Identity, für geplante Tasks und Skripte. Er hat keine Admin-Rechte und keinen RDP-Zugriff.

Windows-Rechte

Folgende lokale Sicherheitsrichtlinien müssen explizit zugewiesen werden (secpol.msc → Lokale Richtlinien → Zuweisen von Benutzerrechten):

Recht	Beschreibung
`SeServiceLogonRight`	Als Dienst anmelden — für IIS App Pool
`SeBatchLogonRight`	Als Stapelverarbeitungsauftrag anmelden — für Task Scheduler

Explizit nicht zuweisen:

SeInteractiveLogonRight / RDP-Zugriff → gehört zum Support-Admin-User

IIS Application Pool

Der App Pool muss so konfiguriert sein:

Identity: Service-User (Domain-Account)
Benutzerprofil laden: True

Wichtig: ApplicationPoolIdentity ist nicht ausreichend, weil:

Kein vollständiges Benutzerprofil → kein Zugriff auf Netzwerkdrucker

Kein Zugriff auf absolute Netzwerkpfade (UNC-Pfade für Dokumente)

PDF-Generierung und Druck schlagen fehl (kein Profil, kein Spooler-Zugriff)

Netzwerkzugriff

Da der Service-User ein Domain-Account ist, erfolgt der Zugriff auf Netzwerkressourcen automatisch über Windows Authentication — kein Passwort im Skript oder in der Konfiguration nötig.

Voraussetzung: Der Service-User hat auf den entsprechenden Netzwerkfreigaben die nötigen NTFS/Share-Berechtigungen.

Dateisystem-Berechtigungen

Pfad-Kategorie	Berechtigung
Multiflex-Installationspfad	Read (+ Write für Logs/Temp-Dateien falls nötig)
Daten- und Dokumentenpfade (absolut/UNC)	Read/Write
Temp-Verzeichnisse für PDF/Druck	Read/Write

Konkrete Pfade sind kundenspezifisch — die Kategorien gelten universell.

Task Scheduler

Alle geplanten Windows-Tasks (Datenexporte, Schnittstellenverarbeitung, automatische Jobs) laufen unter dem Service-User. Tasks dürfen nicht unter dem Support-Admin-User oder einem Domain-Admin laufen.

Sicherheitshinweis: Credentials in Scripts und Task Scheduler

⚠️ Bekanntes Sicherheitsrisiko

Iptor-Zusatzanwendungen (LC.WpfInterfaces, Interfaces, ScheduledTasks etc.) können aktuell mit Benutzername und Passwort als Kommandozeilenparameter gestartet werden. Diese Credentials sind dadurch im Klartext sichtbar:

In den Argumenten eines Windows-Tasks (Task Scheduler → Task-Eigenschaften → Aktionen)
In Batch-Scripts (.bat) oder PowerShell-Scripts (.ps1)

Empfohlene Übergangslösung bis zur Token-Implementierung:

Scripts, die Netzwerkpfade ansprechen: Credentials via Windows Authentication (Service-User ist Domain-Account → kein Passwort nötig)
SQL-Zugriff aus Scripts: Windows Authentication bevorzugen; wenn SQL Auth unvermeidbar → Windows Credential Manager (cmdkey) statt Klartext

Langfristige Lösung: Token-basierter Anwendungsstart mit eingeschränkten Berechtigungen im Token — in Entwicklung, siehe CRM 139721/14.