0

This is crazy, so please bear with me. This is NOT incorrect password.

I have a SQL Service Account that will NOT authenticate. I am an experienced server guy and have tried all the basics with a couple of knowledgeable colleagues (even if they are Cisco orientated).

Scenario:

  1. Active Directory on 3 sites each with 2 DC's and 1 root DC on Server 2008 R2
  2. No DNS issues and site replication is spot on. Any account changes happens within seconds.
  3. Newly built SQL 2016 R2 deployed to 2 x Server 2012 R2 servers on the domain that reside in an OU that SQL 2005 on Server 2008 R2 also resides.
  4. ALL SQL servers are on its own vlan, DC's on another. No firewall issues between though hand on heart, we cannot see any logs as they are 3rd party hosted on ESX clusters with Cisco contracts between vlans.
  5. SQL 2005 server has no issues authenticating with DC's on the other vlan.

Setting an established AD SQL Service account on the new SQL servers fails due to Error 1069: The service did not start due to a logon failure.

The event in the event logs on the DC's (whichever of the 2 are authenticating the account) state the following:

Kerberos pre-authentication failed. Account Information: Security ID: DOMAIN\sqlsvcaccount$ Account Name: sqlsvcaccount$ (not the real account name) Service Information: Service Name: krbtgt/DOMAIN (not our domain name of course) Network Information: Client Address: ::ffff:10.30.x.x (our IPv4 address) Client Port: 49464 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x18 Pre-Authentication Type: 2

Certificate Information: Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:

Now 0x18 is normally a bad password but as mentioned, the accounts are fine and when they get disable I re-enable them, reset the password yadda yadda. I can do a RunAs on an application on the new SQL server and that works fine.

I have set a Computer group policy to allow the service account rights for services etc and ran a gpresult to confirm that the GPO is applied.

Back up files and directories DOMAIN\sqlsvcaccount$ Log on as a batch job DOMAIN\sqlsvcaccount$ Log on as a service DOMAIN\sqlsvcaccount$

Even had a restricted Computer GPO and put the domain account as local admin (which would have negated the need for the services GPO).

Created a new User OU for the Service Account with inheritance blocked and moved the service account there, again gpupdate /force and ran gpresult again to html and all looks OK.

Also rebooting a few times in between things, the usual stuff.

We have ran Wireshark which never showed anything wrong, moved the SQL server onto the same vlan as the DC's, and as mentioned earlier, SQL 2005 server on DB vlan has no issues authenticating.

Finally, created a new Computer OU, blocked policy inheritance and tried all of this again but still no joy trying to start SQL Server or Agent service.

I have tried the SQL Management tool for editing services as should be and even just Windows Services.msc.

The last thing we started looking at was cyphers and if the Server 2012 is trying to authenticate using RC4 and disabling cyphers. But not done too much with this yet.

Soooooooo Does anyone have any idea what could be going on? Appreciate ANY feedback or another avenue I could try.

There's a virtual crate of beer to anyone that has the answer?

1 Answer 1

1

Managed Service Accounts (MSA) resolved this. Server 2012 AD uses gMSA so that kind of threw me:

In AD (with Advanced options) under Novacroft there is an OU called Managed Service Accounts. You find your created MSA's there once created with Powershell.

So, to install a service account:

  1. You create the account (without $) using Powershell.
  2. Then associate the account to a server - again using Powershell.
  3. On the destination server, install Powershell and AD module under features and AD tools. Also install .NET 3.5
  4. On the destination server within Powershell, import the account onto the host.
  5. Then setup the services (you need to add $ at the end now), and leave the password blank.

Nice and easy eh (if you know how) ? Credit to NedPyle [MSFT] Full Article HERE I hope this helps someone :-)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .