NAV Team: Transport Security in Microsoft Dynamics NAV 2009 R2

[Blog bot]

Microsoft Dynamics NAV 2009 R2 uses WCF (Windows Communication Framework) for the core of its transport of data between the RoleTailored client and Microsoft Dynamics NAV Server. This usage of WCF includes transport security. The default behavior for Microsoft Dynamics NAV 2009 R2 is to use the transport security setting Encrypt and Sign, encrypting all traffic between the RoleTailored client and Microsoft Dynamics NAV Server. This behavior is controlled by the ProtectionLevel parameter in both the RoleTailored client and the Microsoft Dynamics NAV Server configuration files. All clients and their associated server must have matching values for this parameter. Encrypt and Sign security utilizes TLS (Transport Layer Security), SSL (Single Sockets Layer), and Kerberos tickets.

See also the following topics on MSDN:

• Connecting the RoleTailored Client over a Wide Area Network
• What's New in Microsoft Dynamics NAV 2009 R2

Depending on how they are configured and where they are located, RoleTailored clients in an Encrypt and Sign implementation typically use one of the following security mechanisms in establishing a connection.

• If clients are physically connected to the organization's network and all in the same domain as Microsoft Dynamics NAV Server computers (or in a domain trusted by that domain), then clients will use standard Kerberos connection techniques to establish the initial connection to Microsoft Dynamics NAV Server. See "Trusted Connections - Kerberos," below, for details.
• If clients are outside the organization's network then it is recommended that you configure the clients and server to use SSL to secure the connection. See "Protecting Open Networks with SSL," below, for details.

Trusted Connections - Kerberos
When clients and server are all members of the same domain or mutually trusting domains, Kerberos is an appropriate security mechanism. The initial key exchange takes place as part of the Kerberos authentication with the server, and the channel is thereafter encrypted using the standard WCF implementation. If for any reason Kerberos authentication is not accomplished then clients and server fall back to NTLM authentication to negotiate encryption keys and start encrypting the channel. For more information on this see the standard Oasis document on Kerberos.


Protecting Open Networks with SSL
Microsoft Dynamics NAV 2009 R2 allows you to configure the connection between Microsoft Dynamics NAV Server and RoleTailored clients to use SSL. When the connection is created via the traditional SSL method, the client validates the server's identity in the same way that an https client does on the web. The SSL certificate on the Microsoft Dynamics NAV Server computer must be a server certificate issued by a trusted Certificate Authority. The certificate must be issued to the server, and the name on the certificate must match the name of the server. Clients authenticate that the certificate is valid by looking up the certificate revocation list (either locally or by calling the Certificate Authority). After the server has been authenticated the channel is converted to a TLS channel, and the server and clients negotiate the keys. The client is then authenticated using the NTLM authentication protocol.

You must edit the Microsoft Dynamics NAV Server and RoleTailored client configuration files to configure Microsoft Dynamics NAV 2009 R2 for SSL. Specifically, you choose settings that indicate that this channel will be using an SSL certificate and that allow for user name and password NTLM authentication.

In CustomSettings.config , the Microsoft Dynamics NAV Server configuration file, you configure the following parameters:

• Set ClientCredentialType to UserName. This specifies that client users will be prompted to provide a domain user name and password when logging on.
• Set CertificateThumbprint to the thumbprint for the server certificate's private key.

In ClientUserSettings.config, the RoleTailored client configuration file, you configure the following parameter:

• Set ClientCredentialType to UserName

If the client detects that the server has been configured to accept Windows credentials, then it fall backs to the negotiated protocol (Kerberos/NTLMl)

For more information on SSL and TLS, see What is TLS/SSL?


Self-Signed Certificate SSL
In addition to a certificate issued by a Certificate Authority, Microsoft Dynamics NAV 2009 R2 also utilizes a test certificate known as a self-signed certificate. For more information on creating and installing this certificate, see Walkthrough: Implementing Security Certificates in a Test Environment, part of the Microsoft Dynamics NAV 2009 R2 documentation on MSDN. Note that implementing the procedures in the walkthrough is recommended only for testing environments. This is because the procedures specify importing the certificate's public key and marking it as trusted, and importing an empty revocation list on each client. This is both prone to error and less secure than utilizing a certificate from a Certificate Authority. Further, if someone is able to obtain the full certificate (both public and private keys) you have no way to revoke the certificate on each of the clients except by going to each client and updating the information manually.

A further change is required in the RoleTailored client configuration file if the DNS name on the certificate used on the server does not match the DNS name entered on the client for the Microsoft Dynamics NAV Server computer. Service certificates have the primary task of authenticating the server to clients. One of the initial checks when a client authenticates a server is to compare the value of the Subject field 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 "ntp.tcp://www.DynamicsNAV.com/ServerInstance/", then the Subject field must also contain the value "www.DynamicsNAV.com".

Note that the field can contain several values, each prefixed with an initialization to indicate the value. Most commonly, the initialization is "CN" for common name, for example, "CN = www.DynamicsNAV.com". It is also possible for the Subject field to be blank, in which case the Subject Alternative Name field can contain the DNS Name value.

The RoleTailored client has a DNS name override setting (DnsIdentity) for when the names do not match. In this case the name on the certificate needs to match the name in the configuration file. The connection and encryption process is the same as with a certificate that was issued by a certificate authority.



Источник: http://feedproxy.google.com/~r/Micro...v-2009-r2.aspx