Kerberos back to NTLM

Someone did a sniffer trace bettween Windows 2000 servers and Windows 2000
domain controllers on our native-mode domain and found at that many of our
Windows 2000 servers are attempting to communicate using Kerberos to the
DCs, not negotiating for whatever reason, then falling back to NTLM. Does
anyone
know why this might be happening? Using

See if this help -
HOW TO: Troubleshoot Kerberos-Related Issues in IIS
http://support.microsoft.com/?id=326985

get the Kerbtray

--
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/



"Spin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Someone did a sniffer trace bettween Windows 2000 servers and Windows 2000
> domain controllers on our native-mode domain and found at that many of our
> Windows 2000 servers are attempting to communicate using Kerberos to the
> DCs, not negotiating for whatever reason, then falling back to NTLM. Does
> anyone
> know why this might be happening? Using
>
>

"Spin" <(E-Mail Removed)> wrote in message news:(E-Mail Removed):
> Someone did a sniffer trace bettween Windows 2000 servers and Windows
> 2000
> domain controllers on our native-mode domain and found at that many of
> our
> Windows 2000 servers are attempting to communicate using Kerberos to the
> DCs, not negotiating for whatever reason, then falling back to NTLM.
> Does
> anyone
> know why this might be happening? Using

Hello Spin,

Most likely port blocking - either a firewall or a router with specific
ports configured.

Windows 2000 higher is attempting to connect to the domain controller
via kerberous if it's Windows 2000 or higher. If it is not possible to
him to talk to the DC using kerberous it falls back to ntlm. This might
take up to 15 minutes.

If you know that you have a firewall, vpn, router or anything else
between the client (or memberserver) and the DC then you can switch the
domain to emulation mode until you have reconfigured your firewall. To
do this you'll have to set the nt4emulator key on the DCs:
http://support.microsoft.com?id=284937

Note that you'll have to rejoin computers to the domain which already
talked to the dc sucessfully since they've switched to "kerberous only
and never talk in NTLM with the domain again"-mode. In this interim
scenario you will have to set the neutralizeNT4Emulator key on
administrative clients and on future DCs. They have to be able to talk
to the DCs, so they need to be behind the port blocking device as well.

--
Gruesse - Sincerely,

Ulf B. Simon-Weidner

MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz
Weblog: http://msmvps.org/UlfBSimonWeidner
WebSite: http://www.windowsserverfaq.org

Are you sure they are authenticating to domain controllers not using
kerberos and not downlevel or external trust computers?? I would enable
auditing of account logon events in Domain Controller Security Policy and
then look in the security logs of the domain controllers for better info on
what is going on. If you find a problem with a particular computer run the
netdiag support tool on it to see if it reports any pertinent
errors/warnings/failed tests. Using the IP address of the target computer
[instead of name], being more than five minutes difference in time than the
domain controller, blocking of ports needed for AD, and dns misconfiguration
can cause kerberos authentication to fail. NtlmV2 can be a very secure
authentication protocol also and using complex passwords can be more
important in securing the network that the authentication protocol being
used if the choices are kerberos and ntlmv2 though kerberos should be used
by default for W2K/XP Pro/W2003 if the network is configured properly. ---
Steve


"Spin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Someone did a sniffer trace bettween Windows 2000 servers and Windows 2000
> domain controllers on our native-mode domain and found at that many of our
> Windows 2000 servers are attempting to communicate using Kerberos to the
> DCs, not negotiating for whatever reason, then falling back to NTLM. Does
> anyone
> know why this might be happening? Using
>
>