By default, portier Vision stores the database password, encrypted, in the portiervision.ini file on each machine. Some environments should hold no database password at all, for example Citrix and terminal servers, shared sessions, golden images, or security-reviewed environments.
For those cases, with Microsoft SQL Server, there is integrated authentication. portier Vision signs in to the database as the signed-in user's Windows identity. No password is stored and none is transmitted.
Not to be confused with signing in to portier Vision itself. For opening the program with your Windows account and no separate password, see Single Sign-On (SSO).
Citrix, terminal server, and golden-image environments that should carry no stored credentials in the profile
Security-reviewed IT environments that avoid stored service passwords
Organisations that control database access through their existing Windows (Active Directory) groups
The machine is joined to the Active Directory domain.
A login exists in Microsoft SQL Server for the Windows user or, better, for an AD group.
That login has db_datareader, db_datawriter, and db_ddladmin on the portier database. db_ddladmin lets portier Vision apply its schema updates when you upgrade. Not sysadmin, not db_owner.
Open the portier Vision Companion and go to Database Configuration.
Under Database Type, choose Microsoft SQL Server - Windows Login. The user name and password fields drop away.
Enter Host, Database Name, and Schema. A non-default port belongs on the host, appended with a comma, for example sqlhost, 1444. For the host format, see Connecting to Microsoft SQL Server.
Run Test Connection. On success, Save Config.
The Companion sets DBLOGIN=1 in the [Database] section of portiervision.ini. From then on portier Vision connects as the signed-in Windows user (a trusted connection over Kerberos or NTLM). No password is written to the file.
Open portiervision.ini. In the [Database] section, DBLOGIN=1 is set, DBPASSWORD is empty, and the DBPASSWORDENCRYPTED and DBSHAREDKEY entries are gone.
Start portier Vision. The database connects without prompting for a database password.
Access runs under the signed-in user's Windows identity.
The installation includes a third program with no user interface, companion-services.exe. It runs the scheduled background work, meaning reminder emails, Entra ID sync, scheduled personnel import, and data retention. It reads the same portiervision.ini.
A Windows scheduled task starts it, named PortierCompanionServices by default. The installer does not create that task. The Register-CompanionTask.ps1 script in the companion folder of the install directory does, and that is where you set the service account the task runs as.
For the database, that account is the one that counts. With DBLOGIN=1, companion-services.exe signs in as the service account, not as you. So the service account, or its AD group, needs the same SQL Server login and the same three roles as your users. Without it, Vision works fine on screen while every scheduled job fails to reach the database.
You can check this directly. Sign in to the machine as the service account and run companion-services.exe --once from the install directory. Exit code 0 means the start-up diagnostics reached the database. The Companion's task area also shows a banner once a scheduled task has missed its run time or failed.
With a stored password this point is more delicate. The password in portiervision.ini is by default tied to the Windows account that saved it, and the scheduled task runs only if that same account set up the connection. Integrated authentication removes that tie and asks for the SQL Server login on the service account instead.
Create the database login for portier Vision with the lowest rights that work: db_datareader and db_datawriter for normal operation, plus db_ddladmin so portier Vision can apply its schema updates during upgrades. sysadmin or db_owner are not needed and should not be granted. Without db_ddladmin the login passes Vision's start-up permission check but the next version upgrade stops at the first schema change. The simplest approach is to control access through a dedicated AD group and add the permitted users there.
On Citrix and terminal servers many users share one installation, but each connects under their own Windows identity. The AD group covers all of them without creating each login by hand. Add the scheduled-task service account to the same group.
Integrated authentication needs Microsoft SQL Server and a Windows domain identity. In two cases it is not available:
Firebird: The bundled Firebird database has no Windows integrated authentication. Here an encrypted password stays in portiervision.ini.
SQL Server on non-domain machines (workgroup): Without a domain identity there is nothing to authenticate against. An encrypted password stays stored here too.
For the SQL Server case, keep that stored login at least privilege: db_datareader, db_datawriter, and db_ddladmin.
With integrated authentication there is no recoverable database password, neither in portiervision.ini nor in the program's memory. Authentication is the user's own Windows identity.
See also: portier Vision Setup and Installation Manual and Connecting to Microsoft SQL Server.
