Kick Logon issues to the Kerb(eros). How to get ‘smart’ with your DataNow authentication
*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.
Smart card authentication is becoming increasingly popular in the Enterprise. This is mainly due to the increased security and user convenience they offer. They do require special consideration for software packages that leverage single sign-on (SSO) technology.
AppSense DataNow is no exception to this. The good news is that we support Kerberos single sign-on for the Windows client. In this blog, I’ll run through the considerations and configuration required for Kerberos support, so by the end you’ll be an SSO pro.
The first step is to choose which scenario(s) match your organisation’s requirements
- NTLM SSO – Users log on to Windows with a Username and Password - In this mode, the DataNow Windows client will sign in silently at Windows logon from any internet enabled location. No additional appliance or infrastructure prerequisites required to support this mode. (note: this mode does not support smart-card logon) This is the recommended mode for most environments due to the lower complexity
- Kerberos SSO – Users log on to Windows with a Username and Password and / or a with a Smart card. In this mode, the DataNow Windows client will sign in silently at windows logon from endpoints with internal network connectivity (ie. On the internal network, or connected by a VPN tunnel so they can acquire their Kerberos ticket granting ticket from the domain controller)
- Mixed environment – Some smart-card enabled endpoints and some traditional password configured endpoints. DataNow supports logins from both types, but you need to specify the SSO type as part of the client configuration.
If you read my previous blog, you’ll have a good grasp of the requisite steps for the client side configuration from an SSO standpoint.
If you’re planning to use Kerberos SSO there are some additional steps required
- The creation of an Active Directory ‘Pre-authentication’ account. This facilitates the following:
- The acquisition of the Kerberos Keytab from a user account so that the server can trust the authorised user to access it
- Pre-authentication checks
- The determination of the ‘Service Principal’ used to access the DataNow appliance (As part of the ticket granting process)
- The re-use of service tickets sent to the platform so that the service can access data on the user’s behalf via Kerberos Constrained Delegation.
This user account should be a standard (non-administrative) account with minimal privileges. The account should be secured with a complex password, and we recommend that to avoid platform reconfiguration with new credentials, that the password be configured to not expire (this is not a strict requirement however)
- Ensure that DataNow has a valid DNS A record configured, and used by the connecting DataNow clients, eg datanow.mycompany.com
- Ensure a reverse DNS (PTR) record and corresponding A record are present for any File servers servicing map points (these should be defined in the DataNow admin console as FQDN as opposed to via IP address)
- Ensure that TCP/UDP 123 is open from the DataNow appliance to the Internet (this is used by Network Time protocol (NTP) to synchronise the appliance clock with an accurate time source which is an important Kerberos prerequisite. You should also check that your domain controller / file server and endpoint clocks are accurate. Chances are that if you’re already using smart cards, these should be fine.
- From a domain controller, with administrative credentials run the following command:
[code]setspn –S http/dn.mycompany.com dnpreauth[/code]
Where dn.mycompany.com is the FQDN of your DataNow appliance as used by your clients and ‘dnpreauth’ is the name of your AD pre-authentication account created above.
This allows the Kerberos Ticket Granting server within AD to locate the key information associated with the user account and allow a token to be returned to the Windows client on the endpoints which are then used to access the DataNow appliance(s).
Following this step, an extra tab called ‘delegation’ will appear in the properties dialogue of the pre-authentication user account in Active Directory.
- Navigate to this tab, and select ‘Trust this user for delegation to any service (Kerberos only)’
This ensures that the DataNow appliance has authorisation to utilise the Kerberos ticket forwarded to it by the DataNow client or web browser so that it can reuse the user identity to access file service resources.
- The next step is to move on to the configuration of the DataNow Appliance(s). To do this you firstly need to log on to a DataNow appliance admin console at https://dn.mycompany.com:8443/config/kerberos
- Enter the configuration details (This example is based on a single domain. In environments where users and network resources such as storage are in differing domains, these details will need to be added as required):
- Pre-auth user and password (created in step 1)
- The realm name - usually the DNS name of the domain in upper case e.g. MYCOMPANY.COM
- KDC - the FQDN of the Domain Key Distribution Centre (usually the same DNS name as the AD controller)(Note: if you are unsure of the KDC name try using
from a domain joined client to get the IP of the KDC, followed by
ping -a <ip address>
to get the canonical name of the KDC.)
- Default domain - the domain in lower case e.g. mycompany.com
- Click update, then save:
- To configure a domain-joined (and connected) Windows endpoint to use Kerberos SSO, use Environment Manager or Group Policy (with DataNow ADMX) to configure either:
Registry Key: HKLM\Software\AppSense\DataNow
Value Name: EnableSSO
Value Type: Reg DWORD
Value Data: 2
Registry Key: HKLM\Software\Policies\AppSense\DataNow
Value Name: EnableSSO
Value Type: Reg DWORD
Value Data: 2
Once the other pre-requisite settings have been applied you should be able to reboot the client endpoint and then see DataNow automatically log in with Kerberos SSO!
I hope this blog has been insightful – Please do not hesitate to comment below if you have any questions or feedback.