domain\servername$ login

  • I inherited some instances where there are some logins of the format

    domain\servername$

    I'm not sure how ... that works. I've found some posts indicating that these are principals just like a user account, just at the server level. But when I search Active Directory for these accounts from SQL Server (I went to another instance in an attempt to add the account there), I come up with squat for the search.

    So, they definitely exist, as I see active connections using these logins, but I can't find the accounts in AD.

    Starting last night, I started receiving errors on one of our instances, and I'm hoping to use whatever information I can gather here to start troubleshooting why this server is attempting a login via a new (and non-existent) database login:

    Login failed for user 'our-domain\one-of-our-servers$'. Reason: Could not find a login matching the name provided. [CLIENT: xxx.xxx.x.xx]

    --Thanks,

    Chuck

  • Those would be the "logins" to the AD for the computer(s) in question.

    So if you have a server called "jimmyjoe" and you wanted to allow that server to access a network share, you would grant the login "MyAD\jimmyjoe$" access.

    Possibly the cause of the failing login is a server that was either renamed, or deleted from AD.

    (and yes, much as I'd wish otherwise I have a share on one of my servers to which a server name has access, rather than a "normal" account, long story.)

  • In this case the login is failing, because it's a new attempt to login with an account that was never setup in the SQL Server environment. Or maybe I'm reading your response incorrectly, about the server being removed from Active Directory? Actually, this probably just moreso explains my unfamiliarity with AD, as well as these ... umm ... SPN's?

    Is it the SPN (aka "domain\servername$") that you're saying might have been removed from AD, or the server itself? Because if it's the SPN, I can't even find that within AD.

    Thanks again for the help,

    --=Chuck

  • chuck.forbes (9/13/2016)


    In this case the login is failing, because it's a new attempt to login with an account that was never setup in the SQL Server environment. Or maybe I'm reading your response incorrectly, about the server being removed from Active Directory? Actually, this probably just moreso explains my unfamiliarity with AD, as well as these ... umm ... SPN's?

    Is it the SPN (aka "domain\servername$") that you're saying might have been removed from AD, or the server itself? Because if it's the SPN, I can't even find that within AD.

    Thanks again for the help,

    --=Chuck

    OK, based on your first sentence here, it sounds like somewhere a server has been added, with a task of some sort, that's trying to access your SQL Server.

    The servername$ account isn't an SPN (that's something else entirely.) If I recall, another instance where the servername$ login might show up is when a service / application is set to use the NT SERVICE\NETWORKSERVICE account.

    I found this topic on TechNet from 2013 that I think does a better job explaining what that account is, than what I'm doing...

    😉

    What I'd expect you're going to need to do is, track down whoever is responsible for the machine that's trying to log into your server, and find out what they're doing, then try to find a resolution.

  • It's a server that's been connecting to it's database via a SQL Server account, until this morning when it started also trying to use this AD machine account. The admin for that server hasn't changed anything recently, configuration-wise (meaning, the software running there has been used, but not configured). These machine accounts are a vaguely understood topic here in our shop, and so I'm looking around (which is fine, I like sleuthing, but I'm finding so little on this topic that it prompted a question here).

    I'll keep hunting, using "AD machine account" as my primary search term.

    --=Chuck

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply