Archived from groups: microsoft.public.win2000.security (
More info?)
Running in mixed mode should not matter as kerberos would still be the
default authentication method for XP Pro/W2000 computers. As far as "It is
recommended to use NTLM authentication instead of LM" , while that is true
that should not be preventing your computers from using kerberos. There is a
security option called lan manager authentication level that can be used to
disable lm use in the domain to make sure it is not used and you can disable
storage of lm hashes. This is wise to do if there are no W9X computers that
are in the domain or need to access domain resources. The usual reasons for
situations why kerberos is not used by a kerberos capable domain computer is
if there is a time skew greater than five minutes compared to the domain
controller, that a resource is being referred to by an IP address instead of
a fully qualified domain name, or there is a problem with UDP for using
kerberos which is fairly unusual. --- Steve
"Johnse" <Johnse@discussions.microsoft.com> wrote in message
news:4A4D687B-9CC0-49E6-85AE-F5292DB1961C@microsoft.com...
> Could any of this be due to running in mixed mode? Should this be changed
> to
> native mode? We currently have 2 Windows 2000 servers, Windows XP Pro on
> the
> desktop & a few Windows 2000 Pro PC's.
>
> I have discovered something else. I ran a network security scanning
> program. It reported: "It is recommended to use NTLM authentication
> instead
> of LM". It then recommended: "Bugtraq ID/URL:
> http://support.microsoft.com/support/kb/articles/q147/7/06.asp" I have
> not
> made any changed regarding this. Does this have anything to do with my
> issue? This article appears to address NT4 not 2000 or XP. I don't find
> this type of entry in my registry. Under this are of my registry my
> authentication package is msv1_0. My security package is kerbos msv1_0
> schannel & notification package is scecli.
>
> I will try your suggestion to enable kerbos logging & let you know what I
> find.
>
> Thanks for your assistance.
>
> Brad
>
> "Steven L Umbach" wrote:
>
>> That is really weird if no problems are being reported anywhere for
>> netdiag
>> or dcdiag. Since user is not being denied access, fallback to NTLM
>> authentication must be how the user/computer is being authenticated. The
>> article on Kerberos troubleshooting may help. You can modify the registry
>> on
>> the domain controller being used for authentication to enable kerberos
>> logging which may generate information that may help pinpoint the
>> problem.
>> The other thing to try is to use netmon to capture authentication traffic
>> to
>> compare to authentication traffic that is successful for kerberos to
>> compare
>> the traces to see if anything stands out. You may also want to post in
>> the
>> server Active Directory newsgroup to see if anyone over there has seen
>> this
>> happen after a transfer of a pdc fsmo. --- Steve
>>
>> How to enable Kerberos event logging on a specific computer
>>
>> 1.
>> Start Registry Editor.
>>
>> Caution
>> Incorrectly editing the registry might severely damage your system.
>> Before making changes to the registry, you should back up any valued data
>> on
>> the computer.
>>
>> 2.
>> Add the following registry value:
>>
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
>>
>> Registry Value: LogLevel
>>
>> Value Type: REG_DWORD
>>
>> Value Data: 0x1
>>
>> 3.
>> If the Parameters subkey does not exist, create it.
>>
>> Note
>> Remove this registry value when it is no longer needed so that
>> performance is not degraded on the computer. Also, you can remove this
>> registry value to disable Kerberos event logging on a specific computer.
>>
>> 4.
>> Quit Registry Editor, and then restart the computer.
>>
>>
>>
>> "Johnse" <Johnse@discussions.microsoft.com> wrote in message
>> news:24C575C2-3E97-4BC2-A9B6-040A5A7079A1@microsoft.com...
>> > The kerbos test passes on jusers workstation. Any other ideas. This is
>> > driving me crazy.
>> >
>> > "Steven L Umbach" wrote:
>> >
>> >> I would not worry about those netdiag errors as I see them on occasion
>> >> and I
>> >> doubt would be related to what you are seeing in the security log. Try
>> >> running netdiag on the computer that juser is logging on from. Netdiag
>> >> includes a kerberos test. It could be that for some reason they are
>> >> not
>> >> being authenticated via kerberos and are falling back to NTLM to be
>> >> authenticated which may generate a successful account logon event
>> >> after
>> >> the
>> >> failed event for the user on the domain controller that authenticated
>> >> the
>> >> user. The first link below may be of interest but I doubt it is
>> >> related
>> >> to
>> >> your situation. The second link is on troubleshooting kerberos and
>> >> mostly
>> >> applies to Windows 2000 also. --- Steve
>> >>
>> >>
http://support.microsoft.com/?kbid=244474
>> >>
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
>> >>
>> >>
>> >> "Johnse" <Johnse@discussions.microsoft.com> wrote in message
>> >> news:6E6B6CDF-7A71-4621-82E0-88D0B4D835DC@microsoft.com...
>> >> > How could the password for juser be bad? They are able to logon on
>> >> > to
>> >> > the
>> >> > domain, access shared folders on the servers, access their e-mail on
>> >> > the
>> >> > exchange server and server based programs & databases. Most clients
>> >> > are
>> >> > XP
>> >> > Pro SP1. A few are at SP2 nad very few are 2000 SP4.
>> >> >
>> >> > I read the article on dns best practices. The only change I made to
>> >> > comply
>> >> > was to a second dc. I set it to point to the first dc as primary
>> >> > dns &
>> >> > itsself as secondary dns.
>> >> >
>> >> > These error messages are occurring for everyone. I have run netdiag
>> >> > on
>> >> > 10.0.0.127 & server2. No failures reported. Only a warning on
>> >> > 10.0.0.127.
>> >> > It passed the NetBT name test but had the following:
>> >> > [WANRING] At least one of the <00> 'Workstation Service', <03>
>> >> > 'Messenger
>> >> > service', <20> 'WINS' names is missing.
>> >> > Later in the netdiag report it listed:
>> >> > NetBT name test . . . passed
>> >> > [WANRING] You don't have a single interface with the <00>
>> >> > 'Workstation
>> >> > Service', <03> 'Messenger service', <20> 'WINS' names defined.
>> >> >
>> >> > No such errors on the server2
>> >> >
>> >> > "Steven L Umbach" wrote:
>> >> >
>> >> >> If netdiag and dcdiag results look good then it probably is not
>> >> >> related
>> >> >> to
>> >> >> dns configuration for the domain controller. The link below is a
>> >> >> good
>> >> >> read
>> >> >> on dns best practices.
>> >> >>
>> >> >>
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382
>> >> >>
>> >> >> If you have downlevel clients in the domain such as NT4.0 or
>> >> >> Windows
>> >> >> 98
>> >> >> you
>> >> >> may see failed account logon events for kerberos but I don't know
>> >> >> why
>> >> >> you
>> >> >> would have not seen that before if that is the case. I see user
>> >> >> juser,
>> >> >> Client address: 10.0.0.127, and SERVER2 failed referenced in the
>> >> >> logon/account logon failures. The error codes indicate bad
>> >> >> password.
>> >> >> You
>> >> >> might want to check to see what is going on with those objects. One
>> >> >> thing
>> >> >> to
>> >> >> try is running netdiag on Client address: 10.0.0.127, and SERVER2
>> >> >> to
>> >> >> see
>> >> >> what is reported and check with juser to see if there are any logon
>> >> >> problems. I don't know if you are seeing failures for just certain
>> >> >> users
>> >> >> or
>> >> >> most everyone. --- Steve
>> >> >>
>> >> >> "Johnse" <Johnse@discussions.microsoft.com> wrote in message
>> >> >> news:42FD7605-6D26-49ED-8E16-3D848F81AAC8@microsoft.com...
>> >> >> >I ran netdiag & dcdiag & no errors reported. IP addresses for DNS
>> >> >> >are
>> >> >> >all
>> >> >> > correct. Should the pdc point only to itself for DNS? Old
>> >> >> > server
>> >> >> > is
>> >> >> > out
>> >> >> > of
>> >> >> > DNS & new servers are listed. I'll set other DNS servers to
>> >> >> > point
>> >> >> > to
>> >> >> > pdc
>> >> >> > first & let you know if it fixes. Any other ideas if this
>> >> >> > doesn't
>> >> >> > fix
>> >> >> > the
>> >> >> > problem?
>> >> >> >
>> >> >> > "Steven L Umbach" wrote:
>> >> >> >
>> >> >> >> Try running the support tools netdiag and then dcdiag on your
>> >> >> >> domain
>> >> >> >> controller to see if it reports any pertinent problems that may
>> >> >> >> help
>> >> >> >> in a
>> >> >> >> solution and verify that your domain controllers have the
>> >> >> >> correct
>> >> >> >> IP
>> >> >> >> addresses for preferred dns servers in their tcp/ip properties
>> >> >> >> and
>> >> >> >> that
>> >> >> >> the
>> >> >> >> "old" domain controller IP address is not listed. Generally the
>> >> >> >> pdc
>> >> >> >> fsmo
>> >> >> >> should point to itself as it's preferred dns server and other
>> >> >> >> domain
>> >> >> >> controllers for the domain should point to the pdc fsmo first
>> >> >> >> and
>> >> >> >> then
>> >> >> >> themselves. The old domain controller's IP should also be
>> >> >> >> removed
>> >> >> >> from
>> >> >> >> DHCP
>> >> >> >> scopes and verified that the correct domain controllers IP
>> >> >> >> addresses
>> >> >> >> are
>> >> >> >> listed.--- Steve
>> >> >> >>
>> >> >> >>
>> >> >> >> "Johnse" <Johnse@discussions.microsoft.com> wrote in message
>> >> >> >> news:135F66D0-80B0-4070-B564-E2F334716710@microsoft.com...
>> >> >> >> > As soon as I retired my previous PDC I started getting errors
>> >> >> >> > in
>> >> >> >> > my
>> >> >> >> > security
>> >> >> >> > eventy log & I don't know why. Help!
>> >> >> >> > I followed KB255690 for transferring FSMO roles, KB295419 for
>> >> >> >> > transferring
>> >> >> >> > the Global Catalog. My other event logs are clean. It's just
>> >> >> >> > the
>> >> >> >> > security
>> >> >> >> > log that gets all the errors.
>> >> >> >> >
>> >> >> >> > Event ID: 537
>> >> >> >> > Source: Security
>> >> >> >> > Type: Failure
>> >> >> >> > User: NT AUTHORITY\SYSTEM
>> >> >> >> > Category: Logon/Logoff
>> >> >> >> > Reason: An unexpected error occurred during logon
>> >> >> >> > Username:
>> >> >> >> > Domain:
>> >> >> >> > Logon Type: 3
>> >> >> >> > Logon Process: Kerbos
>> >> >> >> > Authentication Package: Kerbos
>> >> >> >> > Workstation Name: -
>> >> >> >> >
>> >> >> >> > Event ID: 675
>> >> >> >> > Source: Security
>> >> >> >> > Type: Failure
>> >> >> >> > User: NT AUTHORITY\SYSTEM
>> >> >> >> > Category: Logon/Logoff
>> >> >> >> > Reason: An unexpected error occurred during logon
>> >> >> >> > Username:
>> >> >> >> > Domain:
>> >> >> >> > Logon Type: 3
>> >> >> >> > Logon Process: Kerbos
>> >> >> >> > Authentication Package: Kerbos
>> >> >> >> > Workstation Name: -
>> >> >> >> >
>> >> >> >> > Event ID: 675
>> >> >> >> > Source: Security
>> >> >> >> > Type: Failure
>> >> >> >> > User: NT AUTHORITY\SYSTEM
>> >> >> >> > Category: Account Logon
>> >> >> >> > Description: Pre-authentication failed
>> >> >> >> > Username: juser
>> >> >> >> > User ID: DOMAIN\juser
>> >> >> >> > Service Name: krbtgt/DOMAIN
>> >> >> >> > Pre-Authentication Type: 0x2
>> >> >> >> > Failure Code: 0x18
>> >> >> >> > Client address: 10.0.0.127
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Event ID: 681
>> >> >> >> > Source: Security
>> >> >> >> > Type: Failure
>> >> >> >> > User: NT AUTHORITY\SYSTEM
>> >> >> >> > Category: Account Logon
>> >> >> >> > Description: The logon to account: supervisor by
>> >> >> >> > MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from workstation:
>> >> >> >> > SERVER2
>> >> >> >> > failed.
>> >> >> >> > The
>> >> >> >> > error code was: 3221225578
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>
Facebook
Twitter
Instagram