Security Log Help

[Guest]

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

 

[Steven L Umbach]

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

 

[Guest]

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]

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;en-us;291382

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

 

[Guest]

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]

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

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

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;en-us;291382

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

 

[Guest]

The kerbos test passes on jusers workstation. Any other ideas. This is
driving me crazy.

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

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

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;en-us;291382

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

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?

:

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


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

 

[Steven L Umbach]

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.

The kerbos test passes on jusers workstation. Any other ideas. This is
driving me crazy.

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

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

:

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;en-us;291382

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

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?

:

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


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

 

[Guest]

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

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.

The kerbos test passes on jusers workstation. Any other ideas. This is
driving me crazy.

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


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

:

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;en-us;291382

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

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?

:

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


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

 

[Steven L Umbach]

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

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

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.

The kerbos test passes on jusers workstation. Any other ideas. This is
driving me crazy.

:

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


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

:

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;en-us;291382

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

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?

:

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


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