February 9, 2005 at 5:15 pm
Ok a while ago some Active Directory group policies changed so we comply with that junk Sarbanes. Now all my integrated security stuff fails and I can't get it to work for anything. If I set a SQL user/password then my program on the app server can access the SQL Server but if I use integrated security I get 'Logon failed for MYDOMAIN\MyMachineName". I replaced our actual domain name with MYDOMAIN and my actual machine name with MyMachineName. Here is where I am puzzled instead of using my actual username on the domain its saying the actual ID of my machine.
To solve this I had the network admins check to make sure that delagation was enabled for both my computer and the SQL Server. I also checked the accounts that I use on the domain and that the SQL Server box actually uses on the domain to make sure they DIDN'T have "this account is sensative to replication" or whatever that is checked. All that is set but still when I try to get my app to login to the SQL Server I get "Logon failed for MYDOMAIN\MyMachineName". I'm pretty much at the end of all solutions and really can't think of anything else to try for now. The only thing i'm not allowed to change is Delagation under the 'Group Policy'. The network guys said I would have to hold off on changing anything under the group policy. Since i've already tried all this does anyone have any idea what my problem with integrated security could be?
February 11, 2005 at 4:17 am
We have integrated security running under AD with no current issues.
You need to make sure SQL services are running under a domain account and that account has to have Windows local admin on the box it is running on. (You can try having the service account without local admin, but there are lots of things MS advertises as no longer working that we need to have.)
We did find one problem, the service account needs to have the 'Impersonate client after authentication' authority in W2003. This is not in BOL, but is in a KB article.
We also worked closely with our IT Infrastructure people to get SQL working, and suggest you do the same. One item that took a lot of working out is we wanted the DBAs to only have authority to start/stop SQL on the server boxes, and this needed command-line stuff to set up as the MS GUIs do not work at this level.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply