Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
John Marsland explains the methods of authentication in SQL Server databases, and shares some tips for keeping your data secure.
There are several methods for authentication to Microsoft SQL Server that can securely access the data that you need. Which method is best? Which is available on the platforms that you support? Let’s explore the options you might have.
There are essentially three methods used for authentication to SQL Server: SQL Server authentication, NTLM and Kerberos.
One advantage with Kerberos (and NTLM in a Windows-only environment) over SQL Server authentication is that you have the opportunity for a single sign-on. When you need to sign on to additional servers or applications, the Kerberos ticket can be used to authenticate you to additional resources.
Kerberos is now the default choice for most Windows environments. However, in cases where there is no Kerberos server, or when the network environment doesn’t allow for Kerberos authentication, NTLM can be used to securely access data.
Progress® DataDirect® provides the broadest range of authentication methods on the market. As the chart below shows, our driver supports SQL Server Authentication, NTLM and Kerberos with ODBC and JDBC, across a full array of platforms.
Microsoft also provides several options for authentication in their ODBC and JDBC drivers, but no longer supports NTLM in the drivers. Support outside of a pure Windows environment is limited.
Is your data secure?
Stovepipe data—data that is only available to one function in an enterprise—is increasingly becoming a liability. As we move into the world of Big Data, enterprises are finding that accessing data from anywhere in the company and often persisting that data in a Big Data store is very advantageous. Analytics across the entire enterprise is becoming the goal. Building an enterprise strategy where authenticated access to data is only possible from Windows machines or only some Unix platforms is often short-sighted.
For software vendors, a similar caution is in order. Having a Windows-only data access story is becoming a hard sell as the world evolves to more of an open-source mindset. A robust multi-platform authentication strategy significantly broadens the opportunity (and potential revenue) that a software vendor will see.
While Kerberos is a popular authentication method for many environments, there are configurations that do not need that level of security or cost. NTLM is sufficient in many environments, and an NTLM authentication capability across the broad set of operating systems is an appropriate direction for many software vendors.
DataDirect drivers provide a full range of database authentication methods. This is essential for both the modern enterprise moving toward Big Data and the open-source world, and for the ISV looking for broader opportunities.
What security features do you look for in your drivers? Let us know in the comments and check out our website for more information and a free trial.
John Marsland is Marketing Manager in the Data Connectivity and Integration business unit at Progress Software, covering the DataDirect and DataDirect Cloud products.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.