I see posts come up every 6 - 9 months on SQL Serv...
# lucee
a
I see posts come up every 6 - 9 months on SQL Server data sources and windows authentication. Since windows auth is more secure, it would be my first choice - but TBH the only way I can get integrated auth to work is using the deprecated (in lucee admin) 'other JDBC' driver. Even though my 'other JDBC' driver connection string references SQL Server JDBC 8.4.1 {JRE8] under the covers when you look at the connection string in lucee-server.xml. Despite my preference to use windows auth, I also really don't want to implement a data source that is either deprecated for a good reason (might be no longer supported soon) or has material performance issues that will show up under heavy prod load. this thread - https://dev.lucee.org/t/using-a-windows-domain-account-in-a-lucee-ms-sql-datasource/4459 talks about hooking up a supported driver by editing the lucee-server.xml, but i could not get that to work under 8.4.1, on the latest release of lucee 5. Lastly - I think Zac said in March in a thread that windows auth is not supported...Not sure if he meant setting up via admin, or just meant.. 'stop using it at all, people' so bottom line - is anyone using window auth to SQL server in production reliably and are there valid reasons not to?
a
I would imagine not supported meant we don't provide specific support for it in the admin.
One question I do have though is why windows auth is more secure? In the user context it makes total sense but the only time I've experienced it it was for enterprise it “reasons” wanting to rotate password every 30 days and us needing to work out how to achieve that. Whenever we've used used sql in prod it's been with sql auth but I'd like to understand outside of centralised controls whether it offers other benefits ?
a
Thanks Alex. the section - Authentication methods supported - in the link below discusses a reason - related to storing in the master database. I suspect that it's also that you end up connection strings with passwords and, whilst usually encrypted - it only takes someone not paying attention to expose it. for example - exporting configs with cfconfig to json files and leaving them lying around. Maybe password policies are better managed at the AD level too, and sys admins spend less time enforcing SQL password rules. As a casual observation, I'd say that most SQL passwords I see are pretty bad :) MS has been pushing people to install SQL server NOT in mixed mode for 15 years to get folks off of SQL Auth. - https://www.red-gate.com/simple-talk/databases/sql-server/learn/sql-server-authentication-methods/
j
In theory you should be able to use windows auth if you run commandbox as a service under your desired user account. https://commandbox-service-manager.ortusbooks.com/ Having said that, as long as you're doing proper firewalling and using strong passwords, I think SQL users are fine, and provide another layer of isolation.