cluberti Posted April 27, 2006 Share Posted April 27, 2006 And you are correct, it's likely a permissions issue on logon by one of the svchost.exe processes (or a DCOM misconfiguration, as SP1 changes quite a few services to run as NETWORK SERVICE rather than LOCAL SYSTEM). Link to comment Share on other sites More sharing options...
fizban2 Posted April 28, 2006 Share Posted April 28, 2006 didn't know that, interesting bit of info. so from here memmnoch could check the svchost based on the PID and see what proccess is running and check permissions that are being used by the proccess to logon? Link to comment Share on other sites More sharing options...
cluberti Posted April 28, 2006 Share Posted April 28, 2006 (edited) Bingo. I'd guess it's an issue during SPNEGO, perhaps something that's requiring kerberos auth first, and when that fails (and logs the error), falls back to NTLM and works. Edited April 28, 2006 by cluberti Link to comment Share on other sites More sharing options...
fizban2 Posted April 28, 2006 Share Posted April 28, 2006 huzzaah for learning something new. wow i just read the articles as MS on SPNEGO, lol i know nothing.... Link to comment Share on other sites More sharing options...
nmX.Memnoch Posted April 29, 2006 Author Share Posted April 29, 2006 (edited) And you are correct, it's likely a permissions issue on logon by one of the svchost.exe processes (or a DCOM misconfiguration, as SP1 changes quite a few services to run as NETWORK SERVICE rather than LOCAL SYSTEM).This was happening prior to SP1.It also doesn't matter if one or all three of the programmers are connected. It does it even with just one. It also does it the entire time the DBA has Enterprise Manager opened...to the tune of about 3-5 events per second.The programmer that does most of the actual DBA stuff originally had a 2000 Pro machine but it was replaced with an XP Pro SP2 machine a few months ago...issue still there. They work in a different organization/building on base so I'm don't have any access to their workstations. I've gave them a list of settings to check a while back but I don't know how far that got.Oh...and the programmers are all admins on the server(s).I'll logon to the server later today and get the Security Options settings from gpedit.msc. Most of what we did was based on the DISA STIGs, NSA Guides, Microsoft Server 2003 Security Guide and what DISA refers to as their "Gold Disks". The Events appeared after we based our security configuration on those "guides" (they call 'em guides but they're more of a "policy" for us). Unfortunately the fix may be something that I "can't" undo.Some of the stuff regarding Kerberos and NTLM make since. One of the security settings on the servers is to "Send NTLMv2 response only\refuse LM and NTLM". We also have all three options (each) configured for the two "Minimum session security for NTLM SSP" options configured. There are other settings that may be contributing to this...Whatever the cause, it's not preventing anything from working...it just spams the Security Event Log repeatedly. Edited April 29, 2006 by nmX.Memnoch Link to comment Share on other sites More sharing options...
Zartach Posted May 3, 2006 Share Posted May 3, 2006 (edited) they have the same issue but silly event ID want you pay them to look and the anwser I have an eventid account, so if you still need some info i can get it for you, PM me if it is needed.Also i found this on the net: "I am running a W2K active directory domain in native mode. I have both W2K and NT clients and I noticed lots of event id 537 in the Security event log. I have followed the steps by MS that suggests in M262177 to enable Kerberos logging to pinpoint the errors. What I found is that these errors relate to the NTLM 2 security protocol. Basically the computer account tries to use NTLM 2, if not successfull that it uses NTLM then just LM. Mainly for downlevel clients. The error event ID 537, source Kerberos, is just basically indicating that the NTLM 2 failed, therefore creating the event in the log. Edited May 3, 2006 by Zartach Link to comment Share on other sites More sharing options...
cluberti Posted May 3, 2006 Share Posted May 3, 2006 The problem is that, in a native mode 2000 or 2003 domain, NTLM v2 should not fail - so the problem isn't the 537's, necessarily, but they are the visible indications of a bigger machine or user account auth problem on the domain. Link to comment Share on other sites More sharing options...
fizban2 Posted May 3, 2006 Share Posted May 3, 2006 zartach, that number in your post the M262177 is a KB article at EventID, if you have an accoutn you could look at it and see what the resolution was, i think memmnoch would appreciate it Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now