ZTNA application gateway with KDC to access shared drives
Fortinet technical support cannot troubleshoot third-party applications involved in this solution. |
Kerberos Key Distribution Center (KDC) proxy protocol can be used to remotely authenticate domain users and issue Kerberos tickets. A remote user can use the same Kerberos ticket to authenticate when remotely accessing shared drives through ZTNA application gateway.
The following options are available when setting up ZTNA application gateway on TCP 445 for remote access to mapped drives:
-
Create the mapped drive using the server’s IP address, which uses Windows NT LAN Manager (NTLM) to authenticate users.
-
Create the mapped drive using the server’s FQDN (or DNS name), which requires Kerberos authentication.
The preferred way to create mapped drives is using the server’s DNS name. KDC proxy protocol can be a reliable way to initiate Kerberos authentication for remote users to seamlessly access mapped drives and requires the following steps:
The KDC Proxy only works for domain-joined workstations. |
Setting up the KDC proxy service
The following steps are required to set up the KDC proxy service on a server:
-
Deploy a server that is joined to the domain and create a trusted certificate.
-
If client machines cannot retrieve group policy updates, configure registry keys on the clients.
Deploying a server and creating a certificate
Deploy a server that is joined to the domain. At a minimum, the server must have a public network interface with a domain name pointed to it. Clients will connect to the server over the internet. For networking, you can forward port 443 if necessary.
Create a trusted certificate for the public domain name of the proxy endpoint:
-
Domain: fortitest.net
-
KDC proxy: kdcproxy.fortitest.net
The KDC proxy service is present on the server, but not configured.
Configuring the KDC proxy service on the server
The KDC proxy service must be configured before it can be started.
To configure the server:
-
Start an elevated command prompt, and configure a URL ACL for the endpoint:
netsh http add urlacl url=https://+:443/KdcProxy user="NT authority\Network Service"
-
Associate the certificate created previously with the endpoint:
netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint of your certificate> appid={generated Guid}
This association instructs
HTTP.SYS
to use the certificate when connections occur over HTTPS.For example:
netsh http add sslcert ipport=0.0.0.0:443 certhash=aaaabbbbccccddddeeeeffff0000111122223333 appid={aaaaaaaa-bbbb-cccc-dddd-aaaabbbbcccc}
For
appid
you should generate a random GUID here. From PowerShell try[Guid]::NewGuid()
. Thecerthash
is the thumbprint of your certificate.If the certificate contains extensions for CRL or AIA, those URLs should be reachable from the remote client.
-
If not using smart card certificates (or Windows Hello) for authentication, disable the certificate authentication requirement:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings" /v HttpsClientAuth /t REG_DWORD /d 0x0 /f
-
Additionally if not using certificates, enable password authentication:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings" /v DisallowUnprotectedPasswordAuth /t REG_DWORD /d 0x0 /f
-
Configure the KDC Proxy Service (KPSSVC) to start automatically:
sc config kpssvc start=auto
-
Start the service:
net start kpssvc
Configuring clients to use a KDC proxy
Clients must be configured to use a KDC proxy. This can be done through GPO or through modifying the registry directly. The GPO path is:
Computer Configuration\Policies\Administrative Templates\System\Kerberos\Specify KDC proxy servers for Kerberos clients
Enabling this policy requires setting a realm-to-value mapping. The realm is your domain name, starting with a period (for example ".fortitest.net"
), or a "*"
to include all domains in a wildcard format. The value is specially crafted:
<https kdcproxy.fortitest.net:kdcproxy />
Deploy the policy, and reboot the client. Wait a while for caching to complete, and then log in. You should find users are now authenticating over the KDC proxy endpoint.
To verify from a logged in session, launch a command prompt and try the following command:
klist get krbtgt
Configuring registry keys on clients
If you are trying to deploy these settings on a client machine that cannot retrieve group policy updates, manually configure the registry keys for the client:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos] "KdcProxyServer_Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers]
"*"="<https kdcproxy.fortitest.net />" or ".fortitest.net"="<https kdcproxy.fortitest.net />"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters] "NoRevocationCheck"=dword:00000000
Setting up the ZTNA application gateway for mapped drives
The following steps are required to set up ZTNA application gateway for mapped drives on the FortiGate:
Configuring a ZTNA destination rule on FortiClient
The ZTNA destination rule can be configured by using FortiClient EMS or by manually configuring FortiClient. The destination host matches the server’s FQDN on port 445, and the proxy gateway should be the FortiGate WAN port on the chosen external port.
Another rule is required for the KDC proxy communication with the destination host defined as the FQDN of the KDC proxy server and port 443.
The map network drive configuration should be the last step after configuring the FortiGate. The following example shows the mapped drive:
The following example shows a ZTNA destination configured in FortiClient with the Proxy Gateway:
The following example shows the registry settings:
Configuring FortiGate
A ZTNA server and a proxy policy are required to verify and forward the incoming requests on port 10445 to the file server on port 445 as well as to the KDC proxy server on port 443.
The following example shows the ZTNA server:
The following example shows the proxy policy: