Kerberos for RDP sessions from 8.0 LTS

Hi Dario,

At this time the RDP Kerberos support feature in 8.0 LTS cannot be used with Connection policy that is using AA plugin or Credential store plugins such as SPP related plugins for example.

Another feature # 466766 is still pending for adding (Support plugins with Kerberos authentication) in a future release of SPS subject to PM approval and successful QA (no ETA at this time)

Thanks!

ok thank you! So, if I need to access windows servers that only use kerberos authentication I have to make a new dedicated connection policy without setting up the AA plugin and selecting the kerberos authentication method, so, i think that the configurations in the new connection policy would be:

Enable NTLM Authentication unchecked

Enable Kerberos Authentication checked

Require domain membership checked

Also i have to put in the "To" field of the Connection Policy the IP Address of that server or in the Targets field if i have more than one windows server.

and nothing else?

Is it everything right?

thanks

To avoid conflicts with existing connection policies, you may have to use a different port number for this new connection policy.

Adding the target to the TO field is not required, just use a different port number (example: 3388) instead to separate the traffic from other connection policies using 3389.

In the RDP client, when connecting to SPS use the new port number in the Computer field (sps_ip_address:port) example x.x.x.x:3388 so that the RDP client will use that Kerberos connection policy then in the username you can add the username@domain.local%targetserverIP

the rest is correct.

Thanks!

ok, clear! GREAT! and last thing, for the creation of the new connection policy are the flags on the attributes indicated correct and without selecting the AA plugin?

Yes these flags are correct

Hello Tawfiq, last thing: if the AA Plugin is not specified in the connection policy, can I put the flag on both kerberos and NTLM authentication methods in the connection policy --> settings (default_nla)? Does it work correctly?

In addition I wonder: if I don't specify the AA Plugin (by default is not selected), how is authentication handled by default in general, even if i have only activated NTLM by default?

And, in addition, the SPS nodes must be members of the domain. This is a prerequisite without which the configuration is not correct. right?

Thank you very much for your help and....best wishes for happy holidays and happy New Year

Hi Dario,

Please find my answers inline:

if the AA Plugin is not specified in the connection policy, can I put the flag on both Kerberos and NTLM authentication methods in the connection policy --> settings (default_nla)? Does it work correctly?

>>> No, you cannot mix NTLM and Kerberos in single RDP Settings policy

In addition I wonder: if I don't specify the AA Plugin (by default is not selected), how is authentication handled by default in general, even if i have only activated NTLM by default?

>>> This would use NLA authentication (using Credssp protocol) and require NTLM authentication on target.

And, in addition, the SPS nodes must be members of the domain. This is a prerequisite without which the configuration is not correct. right?

>>> Correct for Kerberos to work, SPS must be joined to Domain.

Kerberos Example:
----------------------------------------------------------------

- In RDP settings > Create new RDP Settings policy:

- Server logon screen - Disabled
- NTLM Authentication - Disabled
- Kerberos Authentication - Enabled
- Require domain membership - Enabled

- In the Connection policy > Create a new Connection policy (could use a different RDP port here to avoid conflict with existing connection policies)

- Use Inband target selection
- Cannot use Act as RDP gateway
- Cannot use AA plugin
- Cannot use Credential Store plugin

In RDP client:
Computer: SPS_FQDN_Address:Port 
Username: RemoteUserName@domain.local%Target_FQDN_Address
or 
You can also use interactive RDP where you provide only Username RemoteUserName@domain.local and then get the blue screen with target server address input separately.

User will be prompted for Windows Security login prompt and enter credentials then will be authenticated using Kerberos.

----------------------------------------------------------------

Hello Tawfiq,

we have discussed this with the customer and have a specific doubt. I will try to explain the example:
We have the default connection policy.
I create the new connection policy where I select RDP settings (with the flags on ‘Kerberos Authenticaion’ and 'Require Domain Membership').
I put the new connection policy at the top to execute it first.
All servers using NTLM authentication will skip the new connection policy and trigger the second one (the new one with the settings for kerberos authentication) and if a server uses only kerberos authentication it will trigger the first one.
Is this correct?
In this way, any server can be managed for both authentications.
Does it work like that, or if, e.g., a server with NTLM authentication fails to skip the first connection policy in order to trigger the second one (which handles this type of authentication), does it fail without triggering the right connection policy?

If the two different connection policy, each with its specific authentication method, work correctly, we can handle both cases.

The connection policy list does not have a failover mechanism, it basically works based on (first policy that matches will be used) and therefore it would stop matching with other policies if first one is a match.

Each policy can have its own unique port and that way if you wish to use Kerberos, you would connect via SPS using the connection policy with Kerberos settings enabled by pointing to that unique port.

ok clear!

After discussing it with the customer we have a couple of other doubts:

- they have different domains (perhaps more than 10 domains) not in trust with each other. Can this scenario be managed? In which way? in SPS in the section where you configure the membership, you cannot configure it for several different domains, right? If this is correct, is there a way to manage a scenario where there are some different domains?
- Also, when configuring this section, is it mandatory to also configure LDAP Server under Policies?

thank you very much!