New AD user unable to access NAV using Citrix

Hi Guys,

There are 4 new AD users that can’t access NAV using Citrix. It prompts below error when they access NAV.

Error:

You do not have access to Microsoft Dynamics NAV. Verify that you have been set up as a valid user in Microsoft Dynamics NAV

Thank you.

Are there other users can access? Are you using office 365 logins?

Have you done ADFS

Yes, the old users can access. just the new users cannot. I have a feeling this is a user account issue. But don’t know where to check if it is in AD or in Microsoft Dynamic itself.

These old users are accessing nav in samw way as new ones?

Yes but the new users can’t,it prompts “You do not have access to Microsoft Dynamics NAV. Verify that you have been set up as a valid user in Microsoft Dynamics NAV”

Can you help me on how to fix this?

Check client settings config file for the new users on their PCs. what it says for ClientServicesCredentialType

Ok, will remote in one user’s computer. and will update you. Thank you.

Didn’t work and by the way Microsoft Dynamics NAV is on premise.

What has not worked? Its fine if nav is on premise

Sorry for missing info, I already tried changing the 3 keys in the config file as on the kb link below but didn’t work.

community.dynamics.com/…/you-do-not-have-access-to-microsoft-dynamics-nav

What is says for ClientCredentialType ?

compare the config file settings with the users that work for them and with new users. Thanks

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <!-- 
      Name of the machine hosting the Microsoft Dynamics Nav Server to 
      be connected to.
    -->
    <add key="Server" value="ServerName" />

    <!--
      The listening TCP port for the Microsoft Dynamics NAV Server.
      This is part of the server's URL.
      Valid range: 1-65535
    -->
    <add key="ClientServicesPort" value="7046"/>

    <!-- 
      Name of the Microsoft Dynamics NAV Server instance to connect
      to (for client).
    -->
    <add key="ServerInstance" value="InstanceName" />

    <!-- 
      Id of the tenant  to connect to (for client).
    -->
    <add key="TenantId" value="" />

    <!--
      The security services used to protect the client/server data stream.
      Valid options: EncryptAndSign, Sign, None
    -->
    <add key="ClientServicesProtectionLevel" value="EncryptAndSign"/>

    <!--
      Collection of past servers that have been connected to. This setting
      should not be edited by the user.
    -->
    <add key="UrlHistory" value=""/>

    <!--
      Threshold for when to start compressing data sets to avoid that they 
      consume prohibitive amounts of memory.
    -->
    <add key="ClientServicesCompressionThreshold" value="64"/>

    <!--
      Sets the default size of a chunk, in KB. Should be a value between 4 and 80.
    -->
    <add key="ClientServicesChunkSize" value="28" />

    <!--
      Sets the interval between reliable session keep alive messages in seconds.
      If the NAV Server sits behind a load balancer, set this value to approx. half of the load balancer's idle timeout.
    -->
    <add key="ClientServicesKeepAliveInterval" value="120" />

    <!-- 
      The amount rows that will be handled when sending a number of records through xml to Word or Excel.
    -->
    <add key="MaxNoOfXMLRecordsToSend" value="5000" />

    <!--
      Maximum image size (in bytes) allowed by validation.
    -->
    <add key="MaxImageSize" value="26214400" />

    <!--  
      The type of client credential used for authentication. 
        Possible values:
           Windows              - Windows authentication is used, and client will connect with "current user" 
                                  this user is expected to be the same and known to both server and client
                                  This is the default mode and is typically used on a LAN with Active Directory
                                  In this mode X.509 certificates are not used and options set below are ignored
           Username             - Windows authentication on the server. Client is expected to present username/password
                                  indentifying a windows user known (created) on the server.
                                  Typically the client will ask for these credentials and pass them to the server
                                  Certificates are used to protect the passing of credentials.
                                  This is typically used when only the server is part of an Active Directory, or
                                  when the client is not trusted, e.g. connection over a WAN/Internet 
           NavUserPassword      - Authentication is managed by the server but not based on windows users.
                                  Client is expected to present username/password matching a user known to the server.
                                  Typically the client will ask for these credentials and pass them to the server
                                  Certificates are used to protect the passing of credentials.
                                  This mode is used in hosted environments e.g. Azure where the list of allowed users 
                                  are maintained by NAV and not based on windows users.
           AccessControlService - Authentication for the Role-Tailored Client is handled by Windows Azure Access Control Service.
                                  An ACS namespace needs to be set up before. Also the Identity Providers need to be set up 
                                  as well as the Relying Party representing the NAV Role-Tailored Client. 
                                  To support ACS, you need to specify the ACS WS Federated authentication endpoint in the ACSUri.
    -->
    <add key="ClientServicesCredentialType" value="Windows" />

    <!-- 
      Specifies the sign-in page that Microsoft Dynamics NAV redirects to when configured for Single Sign-On.
      For Azure AD (Office 365) authentication, the ACSUri setting has the following format:
            https://login.windows.net/<AAD TENANT ID>/wsfed?wa=wsignin1.0%26wtrealm=<APP ID URI>%26wreply=<APP RETURN URL>
         Where
            "<AAD TENANT ID>" is the ID of the Azure AD tenant, for example "CRONUSInternationLtd.onmicrosoft.com". Use "common" if the application  is configured as a multitenant Azure AD application.
            "<APP ID URI>" is the ID that was assigned to the Microsoft Dynamics NAV application when it was registered in Azure AD, for example "https://localhost/".
            "<APP RETURN URL>" is the reply URL that was assigned to the Microsoft Dynamics NAV application when it was registered in Azure AD, for example "https://localhost/".
      For ACS authentication, the ACSUri setting is a top level partition of ACS that is used to create the ACS tokens, for example "https://CRONUSInternationalLtd.accesscontrol.windows.net/v2/wsfederation?wa=wsignin1.0%26wtrealm=https%3a%2f%2flocalhost%2f"
      Remarks:
        - Notice the difference between ACS "wsfederation" and Azure AD "wsfed" resource
        - The query string parameter needs to be URI-encoded (use "%26" instead of "&").        
    -->
    <add key="ACSUri" value="" />
    
    <!-- Settings for making sure we're connecting to an authenticated server, and that it's the server we want to connect to. -->

    <!--
      Specifies whether NTLM fallback is permitted when authentication of the server is not needed.
      Authentication of the server is only possible with kerberos.
      To require Kerberos authentication, set this value to false.
      This setting is only relevant if ClientServicesCredentialType is Windows.
    -->
    <add key="AllowNtlm" value="true" />

    <!--
      Specifies whether the service requires an SPN from Active Directory.
      If true, the connection will only be made to a service with an SPN <ServerInstance>/<Server>:<ClientServicesPort>
      If false, the connection will be attempted to a service with or without an SPN.
      This setting is only used together with Kerberos authentication and ClientServicesCredentialType is Windows.
    -->
    <add key="ServicePrincipalNameRequired" value="False" />

    <!--
      Indicate if you want to enforce validation of the certificate.  
      In a production environment this is strongly recommended.  (Default is true)

      When validation is enabled, the certificate needs to be trusted, not revoked and the CN name should
      match the URL of your service.

      When validation is disabled you can use a self-signed certificate with no revocation list and there
      are no constraint on the CN name
    -->
    <add key="ServicesCertificateValidationEnabled" value="true" />

    <!--
      One of the initial checks when a client authenticates a server is to compare the value of the Subject field 
      of the certificate to the Uniform Resource Identifier (URI) used to contact the service: the DNS of both must match. 
      For example, if the URI of the service is "net.tcp://NavServer.com:7046/DynamicsNav/Service." then the Subject field 
      of the certificate must also contain the value "NavServer.com". 
      Most commonly, the Subject is prefixed with "CN" (for common name), e.g., "CN = NavServer.com", but it can also just be "NavServer.com".
      It is also possible for the Subject field to be blank, in which case the validation rules will be applied to the Subject Alternative Name field of the certificate.
      The DnsIdentity configuration settings can be used to associate an endpoint with the specified Dns name.
    -->
    <add key="DnsIdentity" value="" />

    <!-- 
      Name of the Microsoft Dynamics NAV Help Server to connect
      to. The value of the "Server" setting is used as the default.
    -->
    <add key="HelpServer" value="" />

    <!-- 
      The listening TCP port for the Microsoft Dynamics NAV Help Server.
      Valid range: 1-65535
    -->
    <add key="HelpServerPort" value="49000" />

    <!-- 
      Alternative product name for the Microsoft Dynamics NAV client.
      Refer to the license terms before changing the product name.
    -->
    <add key="ProductName" value="" />

  </appSettings>
</configuration>

This is the config file

thanks for the file . you need to compare it with users that can access through citrix. also check event viewer if there is any clue there.

Will compare, I will contact the users again sorry, I am an overseas support based in Philippines and the users are in Singapore. I will update you once I get the config file. Thank you.

Thanks I am sure there is something missing around client settings. if the users are setup in NAV correctly , then it must the client for new users. comparing with similar users will help.

By the way, is this issue related to Citrix? Because the user are using citrix to access NAV. Or this is just plan account issue?

Right now, can’t hold any of the user.

it could be that yes. You need to check every thing to get to bottom of this. The best reference you have is the fact that this works for older user which means you can replicate what it has been done for older users. What you need to check

  1. Users are created in NAV and all look good

  2. Client settings match with other users.

  3. check event viewers in new users PCs as well and see you get a clue.

  4. New users have enough training to login in NAV and making sure that they are using right credentials.