In the past, SQL Server on Linux has required SSSD to be configured for AD Authentication to work. SSSD is a very powerful service which provides support AD authentication and integration. However, there are some third-party AD providers (such as Centrify, PBIS, and VAS) which provide additional value-added services (such as auditing) on top of basic AD authentication. These third-party AD providers do not configure SSSD when joining the AD domain.
There are many customers which depend on these third-party AD providers to provide single “trusted zone” for all users to access resources regardless of the host OS of said resources. In today’s hybrid environments which uses Windows server, Linux servers and Windows AD to provide authentication, ease of configuration and audit capability among others, are often highly preferred. Listening to the demand from such customers, SQL Server now supports AD authentication without SSSD.
To support these third-party AD providers which do not configure SSSD, SQL Server performs its own LDAP queries when looking up AD accounts. For this to work successfully, several extra configuration checks must be done, and these can be found here: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-third-party-providers?view=sql-server-2017. This functionality was made available in SQL Server 2017 CU10 first. But it is highly recommended to use it with SQL Server 2017 CU12 onwards.
Additionally, if your domain controller supports LDAPS, you can force all connections from SQL Server to the domain controllers to be over LDAPS. To check your client can contact the domain controller over ldaps, run the following bash command, “ldapsearch -H ldaps://contoso.com:3269”. To set SQL Server to only use LDAPS, run the following:
- sudo mssql-conf set network.disablesssd true
- sudo mssql-conf set network.forceldaps true
- systemctl restart mssql-server
Tejas Shah - Senior Program Manager
Dylan Gray - Senior Software Engineer