A very long standing feature request for Orion has been the ability to utilize Windows user accounts to connect to the SQL database backend. For years we've allowed you to use Windows accounts within the Configuration Wizard initially to create the database and the SQL user account that Orion utilizes thereafter for data storage and retrieval. What we haven't provided however, is the ability to leverage Windows credentials continuously for the Orion application itself. Below are just a few small examples of this outstanding feature request.
So why would anyone want to use Windows Authentication over SQL auth anyway? Well the answer sometimes comes down simply to better, easier, more uniform user management throughout the organization. More often though, it's a matter of security. One which can be mandated within an organization due to regulatory compliance or policy. SQL authentication by default is not encrypted, which means simply that both the username and password are sent across the wire in the clear (more on this later).
In a switched LAN environment on-prem, this might not be a huge concern. However, if you are running Additional Polling Engines in a distributed architecture across a WAN, or worse, the Internet, this is something that will undoubtedly raise more than just the eyebrow of your infosec officer. During the installation of this release, you will notice a few new options during the first steps of the Configuration Wizard if you chose the 'Advanced' installation option. As in previous releases you still have the ability to use passthrough authentication to the SQL server for the account you used to login to the machine you're installing Orion. That remains the first option "Authenticate as currently logged in user'. Below that option though, you may have eyed that you can now enter a separate username or password which will be auto-detected as either SQL or Windows credentials. This allows you to use Windows Authentication for initial setup, even if the Orion server isn't joined to a domain, or if the account you are using to install Orion does not have permissions to the SQL server. As expected, this same field can also be used to enter your traditional SQL credentials if you wish to continue using SQL authentication.
Additionally in this same step, you will notice a new option for enabling SSL for SQL communication. If SSL is already a forced setting in your SQL server's configuration, then this checkbox is not required. However, if SSL encryption is configured as optional, or if you are using a self-signed certificate on your SQL server to encrypt your SQL traffic, this new checkbox will allow you to enable SSL encryption for all Orion's communication to the SQL server. This new setting functions independent of SQL or Windows Authentication, providing full end-to-end encryption regardless of which authentication option you choose.
Two steps further into the Configuration Wizard is where you define the account Orion will use continuously for storing data it collects, and displaying information through the web interface. Here too you will find a new option available to you in this release. In addition to being able to leverage an existing SQL user account or create a new SQL user account, you are afforded the opportunity to enter a Windows username and password that the Orion application will use to access the database.
Again, this does not require the Orion server to be joined to the same domain as the SQL server to utilize Windows authentication, but all the same rules of Windows Authentication still apply to SQL as they would mounting a remote file share. This means any of the following must be true, but not all.
Please note: If you intend to use Windows authentication for the Orion application itself, remember to exempt that user account from any password change policies. Failure to do so will likely result in the Orion application ceasing to collect data, and users will be unable to access the Orion web interface, once the password has expired. SQL accounts can also have password change policies applied, so this is not anything new to be concerned about. However, Windows password policies are typically applied at the domain level via Group Policy and are often overlooked, whereas SQL password policies are front and center each and every time you create a new SQL user account.
Be sure to let us know in the comments below if you're using Windows authentication or SQL SSL encryption, and/or if you plan to migrate your Orion over to Windows auth or SQL SSL encryption once this new capability is officially released.
Not sure where to post this as I couldn't find another article.
I've installed the latest versions of NPM, NCM, IPAM, SAM, NTA, SRM, VMAN, and WPM on a server today. WPM does NOT work with Windows Authentication. I had to reconfigure the system to use a local SQL account in order to get WPM to work. Every other module was fine.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.