Skip to main content
networkm
networkm
Explorer
June 15, 2026
Question

FortiPAM Failed login via SSMS

  • June 15, 2026
  • 5 replies
  • 86 views

Hi,

 

We have FortiPAM. We have our users who use SqlServer Mgmt Studio for connecting to database and they using windows integrated authentication. External users have also account and they connect the same while they are logged on some domain PCs. But sometimes external users need to connect from their own laptops which doesnt belong to domains. We created secret with sql template and ssms launcher and when they launch we see that SSMS is not run with user who can log choosing option windows integrated authentication and also login is failed because natively it using sql server authentication.

Is there anyway to say fortipam agent when launch secret to run as different user ssms (using defined credential in secreet)? I see that is option With FortiPam 1.9 and FortiClient 8.0. I have PAM with 1.9 version but i dont see 8.0 version of PAM agent? 

Can someone help or give some idea how to enable users to connect to db?

5 replies

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
June 19, 2026

Hello networkm, 

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

 

Regards,

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
June 23, 2026

Hello,

 

We are still looking for an answer to your question.

 

We will come back to you ASAP.

 

Regards,

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
June 24, 2026

Hello again networkm,

 

I found this answer, can you tell us if it helps, please?

 

You are experiencing issues with FortiPAM when external users attempt to connect to a SQL Server using SQL Server Management Studio (SSMS) with Windows Integrated Authentication. The problem arises because these users are trying to connect from non-domain laptops, and the SSMS launcher defaults to SQL Server Authentication instead of using the credentials stored in FortiPAM.

 

Potential Solutions

  1. Run SSMS as a Different User: FortiPAM does not natively support running SSMS as a different user directly through the launcher. However, you can manually run SSMS as a different user by right-clicking the SSMS shortcut and selecting "Run as different user." This requires the user to manually enter the credentials.

  2. Use FortiPAM 1.9 and FortiClient 8.0: You mentioned that FortiPAM 1.9 and FortiClient 8.0 might have the capability to run applications as a different user. Ensure that you have the correct versions installed and configured. If FortiClient 8.0 is not available, check with Fortinet support for the latest version that supports this feature.

  3. Alternative Authentication Methods: Consider using SQL Server Authentication for these external users if Windows Integrated Authentication is not feasible. This would require setting up SQL Server accounts for these users.

  4. Network Configuration: Ensure that the network configuration allows for the necessary authentication methods and that there are no restrictions preventing the use of Windows Integrated Authentication from non-domain machines.
     

Follow-ups and Clarification Questions

  • FortiClient Version: Can you confirm the version of FortiClient you are using? If FortiClient 8.0 is not available, you may need to check for updates or contact Fortinet support.

  • Authentication Method: Are there any specific reasons why SQL Server Authentication cannot be used for these external users?

  • Network Policies: Are there any network policies or restrictions that might be affecting the authentication process?

  • FortiPAM Configuration: Have you verified that the FortiPAM configuration is set up correctly to handle the authentication method you are trying to use?

If these suggestions do not resolve the issue, I recommend reaching out to Fortinet Support for further assistance.

Jean-Philippe - Fortinet Community Team
    networkm
    networkmAuthor
    Explorer
    July 7, 2026

    Hi ​@Jean-Philippe_P 

    You understand problem good. Just to mention to you i can run SSMS as different user from non-domain laptop and successfully log with windows integrated auth, but during lunch secret through FortiPam, launcher run SSMS as system user.

    I read in documentation that FortiPam agent 8.0 during launch can run application with different user but during download available version is 7.4.7.

    I tried and recreate user as sql server auth type, and that works pretty good, but on some clients i face error regarding trusting certificate. Do you have any idea how to solve this?

     

     

    Jean-Philippe_P
    Staff & Editor
    Jean-Philippe_P
    Staff & Editor
    July 8, 2026

    Hey networkm,

     

    Here is what I found as an answer:

     

    Thank you for the detailed follow-up. Let's address your two main points:

     

    1. SSMS Launcher Runs as SYSTEM User

    You are correct:

    • When launching SSMS via FortiPAM from a non-domain laptop, the application runs as the SYSTEM user, not as the user defined in the secret.
    • This prevents Windows Integrated Authentication from working as expected, since the SYSTEM account does not have the necessary domain credentials.

     

    Current Limitation:

    • As of now, the FortiPAM agent version 7.4.7 is the latest available for download.
    • The feature to launch applications as a different user (as described in documentation for agent 8.0) is not available in 7.4.7.
    • Until agent 8.0 is released, this limitation will persist.

     

    Workaround: Using SQL Server Authentication (as you have tested) is a valid workaround for non-domain devices.

     

    1. SQL Server Authentication – Certificate Trust Error

    You mentioned that when using SQL Server Authentication, some clients encounter a certificate trust error. This is a common issue when SQL Server is configured to use SSL/TLS encryption and the client does not trust the server's certificate.

     

    How to Resolve the Certificate Trust Error

    1. Install the SQL Server's CA Certificate on the Client

    1. Obtain the CA Certificate

      • Get the root or intermediate CA certificate that signed the SQL Server's SSL certificate.

    2. Install the Certificate

      • Double-click the certificate file on the client machine.
      • Follow the wizard and install it into the Trusted Root Certification Authorities store (if it is a root CA), or Intermediate Certification Authorities (if it is an intermediate CA).
      • Reference:
        • If Issued to and Issued by are the same, use Trusted Root.
        • If different, use Intermediate.

    3. Restart SSMS

      • After installation, restart SSMS and try connecting again.
         
    1. (Optional) Trust Server Certificate Setting in SSMS
    • In the SSMS connection dialog, click Options > Connection Properties.
    • Check the box for Trust server certificate.
    • This bypasses certificate validation, but is less secure and not recommended for production.
       
    1. FortiPAM Web Proxy CA Certificate
    • If you are using FortiPAM's web proxy feature, you may also need to install the FortiPAM CA certificate on the client to avoid browser warnings.
    • Download the CA certificate from FortiPAM (as described in the documentation) and install it as above.
       
    1. Reference: Certificate Installation Steps

    When downloading the certificate file, double-click it and follow the wizard to install it.

    • If the CA certificate is root, install it in the trusted root store.
    • If intermediate, install it in the intermediate store.

     

    Follow-up and Clarification Questions

    1. Are you using FortiPAM's web proxy feature for SSMS, or is this a direct SQL connection?
    2. Can you confirm the exact error message you see in SSMS? (A screenshot or text would help.)
    3. Do you have access to the SQL Server's CA certificate?
    4. Are you planning to use Windows Integrated Authentication only, or is SQL Server Authentication acceptable for your use case?
    5. Would you like to be notified when FortiPAM agent 8.0 becomes available?

     

    If you provide more details on the error or your environment, I can give more targeted guidance.

    Jean-Philippe - Fortinet Community Team
    networkm
    networkmAuthor
    Explorer
    July 15, 2026
    1. HI ​@Jean-Philippe_P 

      Sorry for delayed answers.

      Ok i will use sql server auth as workaround. The second thing which is related Certificate error.

      A. It seems sql is sending some self signed certificate.
      B. When i launch ssms, i get error regarding certificate.i click ok, and i must check box and again enter password. That is ok, but i dont want to always get error and always enter credentials.
      C. what do you think about this? i mean everything is going through PAM?
       

       

      Jean-Philippe_P
      Staff & Editor
      Jean-Philippe_P
      Staff & Editor
      July 15, 2026

      Here is some answers that I found:

       

      Certificate Error with SSMS Through FortiPAM
      What you are seeing is consistent with a certificate trust problem, not necessarily a FortiPAM problem.

       

      Why the warning appears
      If SQL Server presents a self-signed certificate, the client does not trust it by default. Fortinet documentation explains that when a certificate is self-signed or signed by an untrusted CA, the client shows a security warning until that CA/root certificate is trusted locally. More generally, Fortinet states that devices trust a certificate only if the relevant CA root certificate is installed on the endpoint.

       

      This matches your SSMS behavior:

      SSMS connects:

      • You get a certificate warning.
      • You must acknowledge it.
      • Then you re-enter credentials / continue manually.

       

      Is everything going through PAM?
      FortiPAM can launch SSMS and broker access, but the retrieved FortiPAM SSMS article does not indicate that FortiPAM replaces SQL Server’s TLS certificate validation or suppresses SSMS trust prompts.

       

      So the most likely interpretation is:

       

      FortiPAM is handling the secret launch / access workflow
      SSMS is still validating the certificate presented for the SQL connection
      if that certificate is self-signed or untrusted, SSMS will warn
      Nothing in the provided documents verifies that FortiPAM “terminates” or “rewrites” the SQL certificate path for SSMS connections. That part could not be confirmed from the retrieved sources.

       

      How to stop the repeated certificate warning
      Recommended option: trust the issuing CA on the client
      Fortinet guidance for similar trust errors is to import the CA certificate into the client’s Trusted Root Certification Authorities store. This is also consistent with Fortinet certificate management guidance: endpoints must have the CA root installed to trust certificates signed by that CA.

       

      If SQL Server is using:

      • A self-signed certificate: import that certificate to the trusted root store on the client, if your security policy allows it.
      • A certificate from an internal/private CA: import that internal CA root to the client.
      • A certificate from a public CA: clients usually already trust it, so warnings should stop once the server certificate is correctly deployed.

       

      Better long-term option: replace the self-signed certificate
      Fortinet guidance on certificate warnings consistently recommends using a certificate signed by a trusted CA instead of a self-signed one, because self-signed certificates trigger trust warnings and identity validation issues.

       

      This is the cleanest fix if you do not want users to:

      • click through warnings
      • re-enter credentials
      • accept exceptions repeatedly

       

      What the warning likely means in your case
      From the Fortinet certificate docs, there are two common causes for this kind of warning:

      • The certificate is self-signed / untrusted
      • The certificate name does not match the server name you used (CN/SAN mismatch)

      So besides trusting the CA, also verify that the SQL Server certificate matches the hostname/FQDN you use in SSMS.

       

      About the repeated credential prompt
      The retrieved documents do not explicitly document why SSMS asks you to enter the password again after the certificate dialog in this exact FortiPAM + SSMS flow.

       

      What can be verified is:

      FortiPAM supports SSMS launch only with the standard launcher, and SSMS 19/20 are the supported versions.
      launch issues can also be affected by SSMS local settings, credential delegation, and secret settings.
      So if the certificate warning is resolved and you still get a second credential prompt, check:

       

      SSMS version is 19 or 20.
      standard SSMS launcher is used, not a custom launcher
      FortiPAM secret has credential delegation enabled if applicable
      The provided documents do not confirm that the repeated password prompt is entirely caused by the certificate warning, so that part cannot be fully verified.

       

      Practical recommendation
      Confirm what certificate SQL Server is presenting
      self-signed, internal CA, or public CA
      If self-signed or internal CA
      import the root/self-signed cert into the client machine’s Trusted Root Certification Authorities store.
      Prefer replacing the SQL certificate
      use a certificate signed by a trusted CA to avoid ongoing warnings.

      Verify the hostname used in SSMS
      ensure it matches the certificate CN/SAN to avoid name mismatch warnings.

      Validate FortiPAM SSMS prerequisites
      SSMS 19 or 20 only
      use the standard SSMS launcher
      review credential delegation and user settings if prompts continue

      Bottom line
      Yes, your access workflow may be going through FortiPAM, but the certificate warning is still most likely coming from SSMS validating the SQL Server certificate. If SQL is presenting a self-signed or otherwise untrusted certificate, that warning will continue until the client trusts the issuing CA/root or the server uses a trusted certificate.

      Jean-Philippe - Fortinet Community Team
      Terms & ConditionsAccessibility statement