<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Identifying the source of SQL Server login failures (18456 errors)</title>
	<atom:link href="http://www.eraofdata.com/blog/sql-18456-login-failures/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.eraofdata.com/blog/sql-18456-login-failures/</link>
	<description>SQL Server posts that DBAs will (hopefully) find useful.</description>
	<lastBuildDate>Fri, 04 May 2012 18:56:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Ajmer Dhariwal</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-5331</link>
		<dc:creator>Ajmer Dhariwal</dc:creator>
		<pubDate>Fri, 04 May 2012 18:56:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-5331</guid>
		<description>SPN&#039;s for SQL Server can be a nightmare to configure, especially on a cluster. I guess you&#039;ve already stepped through this doc: http://msdn.microsoft.com/en-us/library/ms189585(v=sql.90).aspx but it&#039;s worth double-checking and listing out the SPNs (via SetSpn -L SQLServiceAccount).

I would also check via management studio:
     - the account is not disabled
     - the database user account associated with that login is not orphaned or somehow disabled in the default database associated with that login (displayed on the login&#039;s properties)

Worth also ensuring that that these accounts haven&#039;t become locked in AD.

Let me know if that helps at all.</description>
		<content:encoded><![CDATA[<p>SPN&#8217;s for SQL Server can be a nightmare to configure, especially on a cluster. I guess you&#8217;ve already stepped through this doc: <a href="http://msdn.microsoft.com/en-us/library/ms189585(v=sql.90).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms189585(v=sql.90).aspx</a> but it&#8217;s worth double-checking and listing out the SPNs (via SetSpn -L SQLServiceAccount).</p>
<p>I would also check via management studio:<br />
     &#8211; the account is not disabled<br />
     &#8211; the database user account associated with that login is not orphaned or somehow disabled in the default database associated with that login (displayed on the login&#8217;s properties)</p>
<p>Worth also ensuring that that these accounts haven&#8217;t become locked in AD.</p>
<p>Let me know if that helps at all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DetRich</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-5330</link>
		<dc:creator>DetRich</dc:creator>
		<pubDate>Fri, 04 May 2012 17:30:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-5330</guid>
		<description>Hello,

When attempting to implement kerberos authentication between BizTalk 2006 servers and SQL 2005 servers, SQL will not restart after SPN&#039;s are created.  SQL is clustered over 2 nodes.  SQL runs under one service account and BizTalk is running under a different account.  After restarting SQL, we get failed logins, Severity 14, State 11.

We changed the password on the account that is running SQL, changed the password entry for SQL in the Services console and in the Cluster Admin console, but continued getting same errors.  Eventually, after resetting password several times, it finally started successfully.  The only errors seen between SQL Agent, Server and Event logs are the 18456, 14,11.

The error state indicates &quot;Login valid but server access failed&quot;.  What exactly does this mean?  Access to what has failed?  How do I troubleshoot this?</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>When attempting to implement kerberos authentication between BizTalk 2006 servers and SQL 2005 servers, SQL will not restart after SPN&#8217;s are created.  SQL is clustered over 2 nodes.  SQL runs under one service account and BizTalk is running under a different account.  After restarting SQL, we get failed logins, Severity 14, State 11.</p>
<p>We changed the password on the account that is running SQL, changed the password entry for SQL in the Services console and in the Cluster Admin console, but continued getting same errors.  Eventually, after resetting password several times, it finally started successfully.  The only errors seen between SQL Agent, Server and Event logs are the 18456, 14,11.</p>
<p>The error state indicates &#8220;Login valid but server access failed&#8221;.  What exactly does this mean?  Access to what has failed?  How do I troubleshoot this?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-4144</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 27 Dec 2011 20:49:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-4144</guid>
		<description>Searched for hours until coming across this entry --- great article! Thank you for sharing!</description>
		<content:encoded><![CDATA[<p>Searched for hours until coming across this entry &#8212; great article! Thank you for sharing!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ajmer Dhariwal</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-4094</link>
		<dc:creator>Ajmer Dhariwal</dc:creator>
		<pubDate>Sat, 10 Dec 2011 17:56:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-4094</guid>
		<description>This is the sql server agent account and it sounds like the account is locked out or disabled in some way.
From a dos prompt run &quot;net user &lt;service account&gt; /domain&quot;  where &lt;service account&gt; is the full service account name (including domain name) and check the Account Active status and there is no password expiry for the account.
If that doesn&#039;t help then send me the full fragment from the error log showing the login failure.</description>
		<content:encoded><![CDATA[<p>This is the sql server agent account and it sounds like the account is locked out or disabled in some way.<br />
From a dos prompt run &#8220;net user <service account> /domain&#8221;  where </service><service account> is the full service account name (including domain name) and check the Account Active status and there is no password expiry for the account.<br />
If that doesn&#8217;t help then send me the full fragment from the error log showing the login failure.</service></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: philip</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-4077</link>
		<dc:creator>philip</dc:creator>
		<pubDate>Fri, 09 Dec 2011 15:55:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-4077</guid>
		<description>awsome article, it allowed me to find the process and the service but i&#039;m still getting the lock outs. they are happening on the master database of our sql1/sql1 instance. the process is sqlagent90.exe and the service is SQL Server(sql1) i have verified that the account running the service is correct, i have verified that the service account is in the security folder of the master database. 

our sql enviorment is in a MS cluster. this failure aduit is only happening on this node of the cluster. i&#039;m lost as to what to do now.</description>
		<content:encoded><![CDATA[<p>awsome article, it allowed me to find the process and the service but i&#8217;m still getting the lock outs. they are happening on the master database of our sql1/sql1 instance. the process is sqlagent90.exe and the service is SQL Server(sql1) i have verified that the account running the service is correct, i have verified that the service account is in the security folder of the master database. </p>
<p>our sql enviorment is in a MS cluster. this failure aduit is only happening on this node of the cluster. i&#8217;m lost as to what to do now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ashish Jain</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-3877</link>
		<dc:creator>Ashish Jain</dc:creator>
		<pubDate>Fri, 25 Nov 2011 08:49:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-3877</guid>
		<description>Very important and nicely written post</description>
		<content:encoded><![CDATA[<p>Very important and nicely written post</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ajmer Dhariwal</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-3778</link>
		<dc:creator>Ajmer Dhariwal</dc:creator>
		<pubDate>Thu, 03 Nov 2011 17:43:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-3778</guid>
		<description>The trace can be stopped or paused and saved so you can go back over it in your own time.
You can capture a similar trace of the processes and their PIDs by running an e.g. perfmon trace, or you can just open a DOS prompt (command window) on the host sending the invalid logins and typing &quot;tasklist&quot; and hitting return.
This will list all the processes running on that host along with their PIDs which you can then reconcile with the trace output. You can also redirect the tasklist output to file via &quot;tasklist &gt; c:\temp\tasks.txt&quot;. If you use the following syntax with  &quot;tasklist &gt;&gt; c:\temp\tasks.txt&quot; you can append the output to a text file, which means you can repeatedly run the tasklist command on a scheduled basis, for example, and this will allow you to capture all the processes and their PIDs over the time interval you schedule it for. With the trace and tasklist data saved you can go over it at your lesiure to reconcile the logins with their PIDs.</description>
		<content:encoded><![CDATA[<p>The trace can be stopped or paused and saved so you can go back over it in your own time.<br />
You can capture a similar trace of the processes and their PIDs by running an e.g. perfmon trace, or you can just open a DOS prompt (command window) on the host sending the invalid logins and typing &#8220;tasklist&#8221; and hitting return.<br />
This will list all the processes running on that host along with their PIDs which you can then reconcile with the trace output. You can also redirect the tasklist output to file via &#8220;tasklist &gt; c:\temp\tasks.txt&#8221;. If you use the following syntax with  &#8220;tasklist &gt;&gt; c:\temp\tasks.txt&#8221; you can append the output to a text file, which means you can repeatedly run the tasklist command on a scheduled basis, for example, and this will allow you to capture all the processes and their PIDs over the time interval you schedule it for. With the trace and tasklist data saved you can go over it at your lesiure to reconcile the logins with their PIDs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Diane</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-3776</link>
		<dc:creator>Diane</dc:creator>
		<pubDate>Wed, 02 Nov 2011 16:06:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-3776</guid>
		<description>Thank you for the information.  This has been somewhat helpful, at least more so than other articles I have found.  I am having one issue though.  The trace is capturing the information but it goes by so fast I can&#039;t catch the PID on task manager when it&#039;s caught in profiler.  Is there anything I can do to see this?  I don&#039;t know what process is running to cause failure and that is what I am trying to catch.  Please advise.

Much thanks!!!</description>
		<content:encoded><![CDATA[<p>Thank you for the information.  This has been somewhat helpful, at least more so than other articles I have found.  I am having one issue though.  The trace is capturing the information but it goes by so fast I can&#8217;t catch the PID on task manager when it&#8217;s caught in profiler.  Is there anything I can do to see this?  I don&#8217;t know what process is running to cause failure and that is what I am trying to catch.  Please advise.</p>
<p>Much thanks!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crystal Reports Generating SQL Server Error 18456 Severity 8 Error Logs &#171; Justin Cooney &#8211; Senior Programmer / Analyst</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-3668</link>
		<dc:creator>Crystal Reports Generating SQL Server Error 18456 Severity 8 Error Logs &#171; Justin Cooney &#8211; Senior Programmer / Analyst</dc:creator>
		<pubDate>Mon, 03 Oct 2011 17:42:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-3668</guid>
		<description>[...] Identifying the source of SQL Server login failures (18456 errors)  Share this:TwitterLike this:LikeBe the first to like this post. [...]</description>
		<content:encoded><![CDATA[<p>[...] Identifying the source of SQL Server login failures (18456 errors)  Share this:TwitterLike this:LikeBe the first to like this post. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Deb</title>
		<link>http://www.eraofdata.com/blog/sql-18456-login-failures/#comment-3378</link>
		<dc:creator>Deb</dc:creator>
		<pubDate>Fri, 12 Aug 2011 20:34:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.eraofdata.com/blog/?p=114#comment-3378</guid>
		<description>I was getting those mysterious Error: 18456, Severity: 14, State: 38. messages every three minutes on one of my test servers, and this helped me pinpoint the db name and the client process that was trying to access it. I had suspected it was a database we recently migrated to a production server, and the application support person was arguing it couldn&#039;t be, he had changed all the pointers. This solved the argument quickly and finally.

Thanks very much for posting this info.</description>
		<content:encoded><![CDATA[<p>I was getting those mysterious Error: 18456, Severity: 14, State: 38. messages every three minutes on one of my test servers, and this helped me pinpoint the db name and the client process that was trying to access it. I had suspected it was a database we recently migrated to a production server, and the application support person was arguing it couldn&#8217;t be, he had changed all the pointers. This solved the argument quickly and finally.</p>
<p>Thanks very much for posting this info.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

