SQL Server and SSPI handshake failed errorSQL Server 2012: Login failed for user. Reason: Failed to open the...
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
Confused about a passage in Harry Potter y la piedra filosofal
Where in the Bible does the greeting ("Dominus Vobiscum") used at Mass come from?
What to do with wrong results in talks?
Can I use my Chinese passport to enter China after I acquired another citizenship?
Are there any comparative studies done between Ashtavakra Gita and Buddhim?
Is HostGator storing my password in plaintext?
Bash method for viewing beginning and end of file
Why are on-board computers allowed to change controls without notifying the pilots?
Hostile work environment after whistle-blowing on coworker and our boss. What do I do?
How to be diplomatic in refusing to write code that breaches the privacy of our users
What are the ramifications of creating a homebrew world without an Astral Plane?
Do I need a multiple entry visa for a trip UK -> Sweden -> UK?
What is the opposite of 'gravitas'?
Modify casing of marked letters
Student evaluations of teaching assistants
Increase performance creating Mandelbrot set in python
Is there a problem with hiding "forgot password" until it's needed?
Teaching indefinite integrals that require special-casing
What will be the benefits of Brexit?
Time travel short story where a man arrives in the late 19th century in a time machine and then sends the machine back into the past
Efficiently merge handle parallel feature branches in SFDX
Products and sum of cubes in Fibonacci
Why is delta-v is the most useful quantity for planning space travel?
SQL Server and SSPI handshake failed error
SQL Server 2012: Login failed for user. Reason: Failed to open the database configured in the login objectPerform admin tasks (e.g. create database, add diagram support) in SQL Server when not connected to domainSQL Server mirroring causing issuessql server authentication login failedI am getting a failed login message in the SQL Server error logs however, nothing actually failed?SQL Server authentication failed after server promoteDatabase Mirroring login attempt failed with error: 'Connection handshake failed. The handshake verification failed. State 36.'SSPI handshake failed with error code 0x8009030c - only stops when SSMS is closedLinked SQL Server IssuePre-login handshake error connecting to SQL Server
Recently I faced an issue where users from one domain were unable to login to SQL Server and getting this error:
Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxxxxxx]
Error: 18452, Severity: 14, State: 1.
Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENT: xxxxxx]
We have two domains let's say A and B. My SQL Server is running in domain B. In a normal scenario, both domain users are able to connect. But few days ago, all the users from domain A were unable to connect to SQL Server running in domain B. However domain B users were able to connect it successfully. Users approached SQL Server DBA team to look into the issue.
When I checked, even I was unable to connect to SQL Server remotely using SSMS and using credentials of domain A. However when I tried to RDP the server using domain A's credential it was working fine and there after remote access to SQL server also started working fine. So it looked to me like when I RDPed the server something got refreshed and my login remotely started working fine. I was sure that the actual issue was something related to AD and kerberos authentication but unable to prove so.
I researched this issue on web and found two solutions to fix it. One was to fix malfunctioning DC and second was to restart the server where SQL Server was running. I went the 2nd way as windows admins were not accepting that it is an DC issue. I checked everything from SQL end nothing got changed recently. Also found that this issue started happening after below event was logged on server where SQL Server was running:
Log Name: System
Source: NETLOGON
Date: xxxxxxxx
Event ID: 5719 Task
Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxxxxxxxxx
Description: This computer was not able to set up a secure
session with a domain controller in domain xxxxxx due to the
following: There are currently no logon servers available to service
the logon request. This may lead to authentication problems. Make sure
that this computer is connected to the network. If the problem
persists, please contact your domain administrator.
ADDITIONAL INFO If this computer is a domain controller for the
specified domain, it sets up the secure session to the primary domain
controller emulator in the specified domain. Otherwise, this computer
sets up the secure session to any domain controller in the specified
domain.
My questions are:
- How to prove that this is a domain controller issue?
- How reboot of server fixes this issue?
Thanks for your help.
sql-server authentication windows-server
add a comment |
Recently I faced an issue where users from one domain were unable to login to SQL Server and getting this error:
Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxxxxxx]
Error: 18452, Severity: 14, State: 1.
Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENT: xxxxxx]
We have two domains let's say A and B. My SQL Server is running in domain B. In a normal scenario, both domain users are able to connect. But few days ago, all the users from domain A were unable to connect to SQL Server running in domain B. However domain B users were able to connect it successfully. Users approached SQL Server DBA team to look into the issue.
When I checked, even I was unable to connect to SQL Server remotely using SSMS and using credentials of domain A. However when I tried to RDP the server using domain A's credential it was working fine and there after remote access to SQL server also started working fine. So it looked to me like when I RDPed the server something got refreshed and my login remotely started working fine. I was sure that the actual issue was something related to AD and kerberos authentication but unable to prove so.
I researched this issue on web and found two solutions to fix it. One was to fix malfunctioning DC and second was to restart the server where SQL Server was running. I went the 2nd way as windows admins were not accepting that it is an DC issue. I checked everything from SQL end nothing got changed recently. Also found that this issue started happening after below event was logged on server where SQL Server was running:
Log Name: System
Source: NETLOGON
Date: xxxxxxxx
Event ID: 5719 Task
Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxxxxxxxxx
Description: This computer was not able to set up a secure
session with a domain controller in domain xxxxxx due to the
following: There are currently no logon servers available to service
the logon request. This may lead to authentication problems. Make sure
that this computer is connected to the network. If the problem
persists, please contact your domain administrator.
ADDITIONAL INFO If this computer is a domain controller for the
specified domain, it sets up the secure session to the primary domain
controller emulator in the specified domain. Otherwise, this computer
sets up the secure session to any domain controller in the specified
domain.
My questions are:
- How to prove that this is a domain controller issue?
- How reboot of server fixes this issue?
Thanks for your help.
sql-server authentication windows-server
1
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
1
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago
add a comment |
Recently I faced an issue where users from one domain were unable to login to SQL Server and getting this error:
Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxxxxxx]
Error: 18452, Severity: 14, State: 1.
Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENT: xxxxxx]
We have two domains let's say A and B. My SQL Server is running in domain B. In a normal scenario, both domain users are able to connect. But few days ago, all the users from domain A were unable to connect to SQL Server running in domain B. However domain B users were able to connect it successfully. Users approached SQL Server DBA team to look into the issue.
When I checked, even I was unable to connect to SQL Server remotely using SSMS and using credentials of domain A. However when I tried to RDP the server using domain A's credential it was working fine and there after remote access to SQL server also started working fine. So it looked to me like when I RDPed the server something got refreshed and my login remotely started working fine. I was sure that the actual issue was something related to AD and kerberos authentication but unable to prove so.
I researched this issue on web and found two solutions to fix it. One was to fix malfunctioning DC and second was to restart the server where SQL Server was running. I went the 2nd way as windows admins were not accepting that it is an DC issue. I checked everything from SQL end nothing got changed recently. Also found that this issue started happening after below event was logged on server where SQL Server was running:
Log Name: System
Source: NETLOGON
Date: xxxxxxxx
Event ID: 5719 Task
Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxxxxxxxxx
Description: This computer was not able to set up a secure
session with a domain controller in domain xxxxxx due to the
following: There are currently no logon servers available to service
the logon request. This may lead to authentication problems. Make sure
that this computer is connected to the network. If the problem
persists, please contact your domain administrator.
ADDITIONAL INFO If this computer is a domain controller for the
specified domain, it sets up the secure session to the primary domain
controller emulator in the specified domain. Otherwise, this computer
sets up the secure session to any domain controller in the specified
domain.
My questions are:
- How to prove that this is a domain controller issue?
- How reboot of server fixes this issue?
Thanks for your help.
sql-server authentication windows-server
Recently I faced an issue where users from one domain were unable to login to SQL Server and getting this error:
Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxxxxxx]
Error: 18452, Severity: 14, State: 1.
Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENT: xxxxxx]
We have two domains let's say A and B. My SQL Server is running in domain B. In a normal scenario, both domain users are able to connect. But few days ago, all the users from domain A were unable to connect to SQL Server running in domain B. However domain B users were able to connect it successfully. Users approached SQL Server DBA team to look into the issue.
When I checked, even I was unable to connect to SQL Server remotely using SSMS and using credentials of domain A. However when I tried to RDP the server using domain A's credential it was working fine and there after remote access to SQL server also started working fine. So it looked to me like when I RDPed the server something got refreshed and my login remotely started working fine. I was sure that the actual issue was something related to AD and kerberos authentication but unable to prove so.
I researched this issue on web and found two solutions to fix it. One was to fix malfunctioning DC and second was to restart the server where SQL Server was running. I went the 2nd way as windows admins were not accepting that it is an DC issue. I checked everything from SQL end nothing got changed recently. Also found that this issue started happening after below event was logged on server where SQL Server was running:
Log Name: System
Source: NETLOGON
Date: xxxxxxxx
Event ID: 5719 Task
Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: xxxxxxxxxx
Description: This computer was not able to set up a secure
session with a domain controller in domain xxxxxx due to the
following: There are currently no logon servers available to service
the logon request. This may lead to authentication problems. Make sure
that this computer is connected to the network. If the problem
persists, please contact your domain administrator.
ADDITIONAL INFO If this computer is a domain controller for the
specified domain, it sets up the secure session to the primary domain
controller emulator in the specified domain. Otherwise, this computer
sets up the secure session to any domain controller in the specified
domain.
My questions are:
- How to prove that this is a domain controller issue?
- How reboot of server fixes this issue?
Thanks for your help.
sql-server authentication windows-server
sql-server authentication windows-server
edited Oct 2 '15 at 5:59
marc_s
7,12053849
7,12053849
asked Oct 1 '15 at 9:15
SQLPRODDBASQLPRODDBA
1,10011430
1,10011430
1
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
1
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago
add a comment |
1
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
1
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago
1
1
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
1
1
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago
add a comment |
1 Answer
1
active
oldest
votes
Why does a reboot of the server sometimes fix this issue?
I think the OS has an issue talking with the DC (for whatever reason(s) you determine) and when this happens, it just gets out of sync somehow with DC, AD, etc. and a quick fix is to reboot the SQL Server OS when this occurs and there is no network communication with the DC at the time of the reboot, and all comes up fine with everything back in sync at that point. To accurately answer this, you probably need to find the reason first.
Proving that [the] Domain Controller(s) is/are or is/are not the issue
1. Troubleshoot & Consider
I'm not suggesting you make a bunch of changes before trying to find
and fix the specific problem beforehand but there are many factors to
consider I would think. It's just something you have to troubleshoot
one step at a time unless there's something obvious causing the issue.
2. Access Perspective
In my setup, I'm the domain admin as well as the DBA so I have access
to everything and all servers (two domains with two-way trusts) to
troubleshoot at all levels whereas you may be a bit more restricted
with what you can review, etc. on each server in the loop of the
issue.
3. No Simple Oversight
I usually start with the simple items first that don't require changes
and see if there are any obvious issues (e.g. event viewers on all
servers, DNS testing on all servers, review all server configurations,
etc.).
4. No Telling Logic
This could be an issue at the OS level of the SQL Server for the
Windows version it is on. This could also be an issue with the NIC of
the SQL Server or a mis-configuration of TCP/IP or DNS settings on the
SQL Server or any of your DCs.
5. Collect & Update
Gather information on or ensure the SQL Server is fully updated with
Windows Updates, and ensure server firmware is up-to-date if
applicable with BIOS version as well as any hardware device firmware
updates. The domain admins could also do the same on the DCs but use
caution with making a bunch of changes and do so one step at a time.
6. Best Practices
I'm not sure how your AD and DCs are configured topology wise, but
best practices should be followed as best as possible and a DC should
be close to the network where both domains are physically rather than
going across a slower network pipe or routers, etc. which adds another
level where there could be issues or configurations to review.
The DCs should have their TCP/IP settings configured so that their DNS
settings point to other DNS servers or follow best practices otherwise
as per Microsoft for the DCs configurations applicable in your
environment.
7. Request Access or Configuration Disclosure Assistance
You'll need to do basic troubleshooting to find the issues to resolve,
ask questions, see what all could be updated and patched or changed,
and get your domain admins to help you troubleshoot or disclose domain
configurations to you if you're not sure how to see if everything is
configured as best it could be for optimum performance and per best
practices.
Important: This not to say there couldn't be a very simple reason this suddenly happened but if nothing has changed anywhere (i.e. OS on DCs or SQL Server, network configurations, AD or forest functional levels, hardware upgrades, Windows Updates, etc.) then you just have to troubleshoot for the reason why one step at a time.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f116694%2fsql-server-and-sspi-handshake-failed-error%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Why does a reboot of the server sometimes fix this issue?
I think the OS has an issue talking with the DC (for whatever reason(s) you determine) and when this happens, it just gets out of sync somehow with DC, AD, etc. and a quick fix is to reboot the SQL Server OS when this occurs and there is no network communication with the DC at the time of the reboot, and all comes up fine with everything back in sync at that point. To accurately answer this, you probably need to find the reason first.
Proving that [the] Domain Controller(s) is/are or is/are not the issue
1. Troubleshoot & Consider
I'm not suggesting you make a bunch of changes before trying to find
and fix the specific problem beforehand but there are many factors to
consider I would think. It's just something you have to troubleshoot
one step at a time unless there's something obvious causing the issue.
2. Access Perspective
In my setup, I'm the domain admin as well as the DBA so I have access
to everything and all servers (two domains with two-way trusts) to
troubleshoot at all levels whereas you may be a bit more restricted
with what you can review, etc. on each server in the loop of the
issue.
3. No Simple Oversight
I usually start with the simple items first that don't require changes
and see if there are any obvious issues (e.g. event viewers on all
servers, DNS testing on all servers, review all server configurations,
etc.).
4. No Telling Logic
This could be an issue at the OS level of the SQL Server for the
Windows version it is on. This could also be an issue with the NIC of
the SQL Server or a mis-configuration of TCP/IP or DNS settings on the
SQL Server or any of your DCs.
5. Collect & Update
Gather information on or ensure the SQL Server is fully updated with
Windows Updates, and ensure server firmware is up-to-date if
applicable with BIOS version as well as any hardware device firmware
updates. The domain admins could also do the same on the DCs but use
caution with making a bunch of changes and do so one step at a time.
6. Best Practices
I'm not sure how your AD and DCs are configured topology wise, but
best practices should be followed as best as possible and a DC should
be close to the network where both domains are physically rather than
going across a slower network pipe or routers, etc. which adds another
level where there could be issues or configurations to review.
The DCs should have their TCP/IP settings configured so that their DNS
settings point to other DNS servers or follow best practices otherwise
as per Microsoft for the DCs configurations applicable in your
environment.
7. Request Access or Configuration Disclosure Assistance
You'll need to do basic troubleshooting to find the issues to resolve,
ask questions, see what all could be updated and patched or changed,
and get your domain admins to help you troubleshoot or disclose domain
configurations to you if you're not sure how to see if everything is
configured as best it could be for optimum performance and per best
practices.
Important: This not to say there couldn't be a very simple reason this suddenly happened but if nothing has changed anywhere (i.e. OS on DCs or SQL Server, network configurations, AD or forest functional levels, hardware upgrades, Windows Updates, etc.) then you just have to troubleshoot for the reason why one step at a time.
add a comment |
Why does a reboot of the server sometimes fix this issue?
I think the OS has an issue talking with the DC (for whatever reason(s) you determine) and when this happens, it just gets out of sync somehow with DC, AD, etc. and a quick fix is to reboot the SQL Server OS when this occurs and there is no network communication with the DC at the time of the reboot, and all comes up fine with everything back in sync at that point. To accurately answer this, you probably need to find the reason first.
Proving that [the] Domain Controller(s) is/are or is/are not the issue
1. Troubleshoot & Consider
I'm not suggesting you make a bunch of changes before trying to find
and fix the specific problem beforehand but there are many factors to
consider I would think. It's just something you have to troubleshoot
one step at a time unless there's something obvious causing the issue.
2. Access Perspective
In my setup, I'm the domain admin as well as the DBA so I have access
to everything and all servers (two domains with two-way trusts) to
troubleshoot at all levels whereas you may be a bit more restricted
with what you can review, etc. on each server in the loop of the
issue.
3. No Simple Oversight
I usually start with the simple items first that don't require changes
and see if there are any obvious issues (e.g. event viewers on all
servers, DNS testing on all servers, review all server configurations,
etc.).
4. No Telling Logic
This could be an issue at the OS level of the SQL Server for the
Windows version it is on. This could also be an issue with the NIC of
the SQL Server or a mis-configuration of TCP/IP or DNS settings on the
SQL Server or any of your DCs.
5. Collect & Update
Gather information on or ensure the SQL Server is fully updated with
Windows Updates, and ensure server firmware is up-to-date if
applicable with BIOS version as well as any hardware device firmware
updates. The domain admins could also do the same on the DCs but use
caution with making a bunch of changes and do so one step at a time.
6. Best Practices
I'm not sure how your AD and DCs are configured topology wise, but
best practices should be followed as best as possible and a DC should
be close to the network where both domains are physically rather than
going across a slower network pipe or routers, etc. which adds another
level where there could be issues or configurations to review.
The DCs should have their TCP/IP settings configured so that their DNS
settings point to other DNS servers or follow best practices otherwise
as per Microsoft for the DCs configurations applicable in your
environment.
7. Request Access or Configuration Disclosure Assistance
You'll need to do basic troubleshooting to find the issues to resolve,
ask questions, see what all could be updated and patched or changed,
and get your domain admins to help you troubleshoot or disclose domain
configurations to you if you're not sure how to see if everything is
configured as best it could be for optimum performance and per best
practices.
Important: This not to say there couldn't be a very simple reason this suddenly happened but if nothing has changed anywhere (i.e. OS on DCs or SQL Server, network configurations, AD or forest functional levels, hardware upgrades, Windows Updates, etc.) then you just have to troubleshoot for the reason why one step at a time.
add a comment |
Why does a reboot of the server sometimes fix this issue?
I think the OS has an issue talking with the DC (for whatever reason(s) you determine) and when this happens, it just gets out of sync somehow with DC, AD, etc. and a quick fix is to reboot the SQL Server OS when this occurs and there is no network communication with the DC at the time of the reboot, and all comes up fine with everything back in sync at that point. To accurately answer this, you probably need to find the reason first.
Proving that [the] Domain Controller(s) is/are or is/are not the issue
1. Troubleshoot & Consider
I'm not suggesting you make a bunch of changes before trying to find
and fix the specific problem beforehand but there are many factors to
consider I would think. It's just something you have to troubleshoot
one step at a time unless there's something obvious causing the issue.
2. Access Perspective
In my setup, I'm the domain admin as well as the DBA so I have access
to everything and all servers (two domains with two-way trusts) to
troubleshoot at all levels whereas you may be a bit more restricted
with what you can review, etc. on each server in the loop of the
issue.
3. No Simple Oversight
I usually start with the simple items first that don't require changes
and see if there are any obvious issues (e.g. event viewers on all
servers, DNS testing on all servers, review all server configurations,
etc.).
4. No Telling Logic
This could be an issue at the OS level of the SQL Server for the
Windows version it is on. This could also be an issue with the NIC of
the SQL Server or a mis-configuration of TCP/IP or DNS settings on the
SQL Server or any of your DCs.
5. Collect & Update
Gather information on or ensure the SQL Server is fully updated with
Windows Updates, and ensure server firmware is up-to-date if
applicable with BIOS version as well as any hardware device firmware
updates. The domain admins could also do the same on the DCs but use
caution with making a bunch of changes and do so one step at a time.
6. Best Practices
I'm not sure how your AD and DCs are configured topology wise, but
best practices should be followed as best as possible and a DC should
be close to the network where both domains are physically rather than
going across a slower network pipe or routers, etc. which adds another
level where there could be issues or configurations to review.
The DCs should have their TCP/IP settings configured so that their DNS
settings point to other DNS servers or follow best practices otherwise
as per Microsoft for the DCs configurations applicable in your
environment.
7. Request Access or Configuration Disclosure Assistance
You'll need to do basic troubleshooting to find the issues to resolve,
ask questions, see what all could be updated and patched or changed,
and get your domain admins to help you troubleshoot or disclose domain
configurations to you if you're not sure how to see if everything is
configured as best it could be for optimum performance and per best
practices.
Important: This not to say there couldn't be a very simple reason this suddenly happened but if nothing has changed anywhere (i.e. OS on DCs or SQL Server, network configurations, AD or forest functional levels, hardware upgrades, Windows Updates, etc.) then you just have to troubleshoot for the reason why one step at a time.
Why does a reboot of the server sometimes fix this issue?
I think the OS has an issue talking with the DC (for whatever reason(s) you determine) and when this happens, it just gets out of sync somehow with DC, AD, etc. and a quick fix is to reboot the SQL Server OS when this occurs and there is no network communication with the DC at the time of the reboot, and all comes up fine with everything back in sync at that point. To accurately answer this, you probably need to find the reason first.
Proving that [the] Domain Controller(s) is/are or is/are not the issue
1. Troubleshoot & Consider
I'm not suggesting you make a bunch of changes before trying to find
and fix the specific problem beforehand but there are many factors to
consider I would think. It's just something you have to troubleshoot
one step at a time unless there's something obvious causing the issue.
2. Access Perspective
In my setup, I'm the domain admin as well as the DBA so I have access
to everything and all servers (two domains with two-way trusts) to
troubleshoot at all levels whereas you may be a bit more restricted
with what you can review, etc. on each server in the loop of the
issue.
3. No Simple Oversight
I usually start with the simple items first that don't require changes
and see if there are any obvious issues (e.g. event viewers on all
servers, DNS testing on all servers, review all server configurations,
etc.).
4. No Telling Logic
This could be an issue at the OS level of the SQL Server for the
Windows version it is on. This could also be an issue with the NIC of
the SQL Server or a mis-configuration of TCP/IP or DNS settings on the
SQL Server or any of your DCs.
5. Collect & Update
Gather information on or ensure the SQL Server is fully updated with
Windows Updates, and ensure server firmware is up-to-date if
applicable with BIOS version as well as any hardware device firmware
updates. The domain admins could also do the same on the DCs but use
caution with making a bunch of changes and do so one step at a time.
6. Best Practices
I'm not sure how your AD and DCs are configured topology wise, but
best practices should be followed as best as possible and a DC should
be close to the network where both domains are physically rather than
going across a slower network pipe or routers, etc. which adds another
level where there could be issues or configurations to review.
The DCs should have their TCP/IP settings configured so that their DNS
settings point to other DNS servers or follow best practices otherwise
as per Microsoft for the DCs configurations applicable in your
environment.
7. Request Access or Configuration Disclosure Assistance
You'll need to do basic troubleshooting to find the issues to resolve,
ask questions, see what all could be updated and patched or changed,
and get your domain admins to help you troubleshoot or disclose domain
configurations to you if you're not sure how to see if everything is
configured as best it could be for optimum performance and per best
practices.
Important: This not to say there couldn't be a very simple reason this suddenly happened but if nothing has changed anywhere (i.e. OS on DCs or SQL Server, network configurations, AD or forest functional levels, hardware upgrades, Windows Updates, etc.) then you just have to troubleshoot for the reason why one step at a time.
edited 2 mins ago
answered Oct 6 '15 at 12:42
Pimp Juice ITPimp Juice IT
1,693614
1,693614
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f116694%2fsql-server-and-sspi-handshake-failed-error%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Can someone please help me understand this issue?
– SQLPRODDBA
Oct 2 '15 at 4:52
1
Reboot of entire server where SQL server lives fixes the issue. But I want to know below: 1. How to prove that this is a domain controller issue and not SQL server issue? 2. How reboot of server fixes this issue? It looks to me that trust works fine as I am able to RDP the server using domain A's credentials.
– SQLPRODDBA
Oct 6 '15 at 6:25
I went ahead and updated my post so see if maybe you think that may be more helpful. Curious what your status on the inquiry is but as you see, I tried, and now trying to improve and circle back around to it. Appreciate the question!!
– Pimp Juice IT
57 secs ago