--- title: "Database sign-in without a stored password (Windows integrated authentication)" description: "How portier Vision connects to Microsoft SQL Server without a stored password using the signed-in user's Windows identity, what the scheduled-task service account needs, and where the limits are." url: https://help.portiervision.com/en/articles/124-database-sign-in-without-a-stored-password-windows-integrated-authentication collection: "Integrations & IT Setup" updated: 2026-08-28 language: en alternates: [de, fr] --- # Database sign-in without a stored password (Windows integrated authentication) How portier Vision connects to Microsoft SQL Server without a stored password using the signed-in user's Windows identity, what the scheduled-task service account needs, and where the limits are. ## What this is 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)](https://help.portiervision.com/en/articles/108-single-sign-on-sso.md). ## Who it is for - 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 ## Prerequisites - 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`. ## Setup 1. Open the portier Vision Companion and go to **Database Configuration**. 2. Under **Database Type**, choose **Microsoft SQL Server - Windows Login**. The user name and password fields drop away. 3. 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](https://help.portiervision.com/en/articles/116-connecting-portier-companion-to-microsoft-sql-server-correct-host-configuration.md). 4. 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. ## Verify - 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. ## Scheduled background work runs under its own account 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. ## Recommended: a least-privilege login 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. ## What is not supported 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`. ## The security benefit 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](https://help.portiervision.com/en/articles/110-portier-vision-setup-and-installation-manual.md) and [Connecting to Microsoft SQL Server](https://help.portiervision.com/en/articles/116-connecting-portier-companion-to-microsoft-sql-server-correct-host-configuration.md).