LsaSrv - No authentication protocol was available ...

  • 11K Views
  • Last Post 26 March 2009
DeLF posted this 24 March 2009

Hi all,

I am trying to solve an AD client issue (XP). I am seeing lots of errors in the
client's system event log with respect to EventID "40961" Source LSASRV. E.G

"The Security System could not establish a secured connection with the server
ldap/ad-server.dsto.defence.gov.au/dsto.defence.gov.au@dsto.defence.gov.au. No
authentication protocol was available."

Interesting i can still log on using AD credentials. As well as this I was able
to successfully do a "gpupdate.exe /force" + reboot. However, system event logs
are still being polluted with this error.

I have turned on DEBUG logging for Userenv.log, but I'm not sure exactly what to
look for. There is a tonne of output and its hard to distinguise what is relevant.

Can anyone suggest how to determine the root cause of this issue ?

Thanks!

-aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

show

Order By: Standard | Newest | Votes
DeLF posted this 26 March 2009

Anyone ?

-aW

0n Wed, Mar 25, 2009 at 11:24:29AM +0900, Wilkinson, Alex wrote:

>Hi all,
>
>I am trying to solve an AD client issue (XP). I am seeing lots of errors in the
>client's system event log with respect to EventID "40961" Source LSASRV. E.G
>
> "The Security System could not establish a secured connection with the server
> ldap/ad-server.dsto.defence.gov.au/dsto.defence.gov.au@dsto.defence.gov.au. No
> authentication protocol was available."
>
>Interesting i can still log on using AD credentials. As well as this I was able
>to successfully do a "gpupdate.exe /force" + reboot. However, system event logs
>are still being polluted with this error.
>
>I have turned on DEBUG logging for Userenv.log, but I'm not sure exactly what to
>look for. There is a tonne of output and its hard to distinguise what is relevant.
>
>Can anyone suggest how to determine the root cause of this issue ?

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

show

johnbmoranyahoocom posted this 26 March 2009



show

Tspring posted this 26 March 2009

Alex, I think Netlogon logging would be the thing to do on that client. This may be a transient network thing, but should show up in that log along with a status code if so.

I did a blog post on this recently http://blogs.technet.com/ad/archive/2009/03/20/downgrade-attack-a-little-more-info.aspx that might help.

The MVPs may have other suggestions that can help too...


Tim

show

DeLF posted this 26 March 2009


0n Thu, Mar 26, 2009 at 06:16:57AM -0700, John Moran wrote:

>Can you remove one of them from the domain and re-add it back
>in to test?  It sounds like a kerberos ticket problem maybe.

I could try this, but what i dont like, is if it works I wont know
what the the actual problem was :(

-aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

show

johnbmoranyahoocom posted this 26 March 2009



show

johnbmoranyahoocom posted this 26 March 2009



show

iainmccall posted this 26 March 2009

Is the XP machine behind the Firewall?

Try forcing the machine to use TCP over UDP. UDP fragmentation is common when going through firewalls.

http://support.microsoft.com/kb/244474

show

kbatlive posted this 26 March 2009

You may try a couple of other things, first (before unjoin/rejoin). Looking back in my own knowledge base of stuff we've run across, we've seen this error a couple of times (on XP machines).

The kerberos packet may be getting fragmented. There is a reg-hack to force kerberos to use TCP packets for all packets over 1 byte in size (basically, all kerberos packets). We have in our automated build/patching process that all DC's get the reghack on all DC's (we had a domain trust failure issue because of this - ten's of thousands of users affected).

See Microsoft's article Q244474, "How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000".




We had an issue where the local machines Anti virus software, when disabled, stopped having the problem. When enabling the AV software, the problem returned. I don't remember the outcome of that - either an AV patch or re-install of the AV software.


Good luck!


Oh...is the time accurate on the workstation when it is booting up?

show

ermitanyo posted this 26 March 2009

Alex,

If your clients are running on Windows XP SP2, you should try this hotfix:
http://support.microsoft.com/kb/885887. This resolved the issue for our
environment where we were getting this error. The reason we had to chase
this down was because we had apps that were configured to use AD for
kerberos authentitcation and those SSO would fail when a users has been
logged on for longer than the ticket expiration time (10 hours by default).
This is a common occurrence in our environment since users leave their
machines locked.
Without the hotfix, users actually had to reboot their machines, not just
logoff and login, to have SSO working again.

I believe this hotfix is in SP3, btw.

Regards,

Arden

show

Close