|
Posted by Jorge Silva on September 25, 2007, 6:36 am
Please log in for more thread options If you're working in different subnets WINS is required.
for kereberos troubleshooting check:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
http://searchwindowssecurity.techtarget.com/originalContent/0,289142,sid45_gci1014048,00.html
--
I hope that the information above helps you.
Have a Nice day.
Jorge Silva
MCSE, MVP Directory Services
>> Hi
>> Specific to kerberos you can use
>> netdiag /test:kerberos
>>
>> to review all, run dcdiag and netdiag cmds in the DCs make sure that no
>> errors in output window
>
> Member server passes all tests with netdiag /test:kerberos except NetBT
> test, and that is correct result because NetBIOS over TCP is disabled on
> all of our computers.
>
> --
> Will
>
>>> We are in the process of migrating off W2K domain controllers to W2K3
>>> domain controllers. We had three DCs as follows:
>>>
>>> DC1: W2K
>>> DC2: W2K
>>> DC3: W2K3
>>>
>>> We brought up DC4 today running W2K3, with the intent to point users to
>>> those, migrate roles to them, and start to bring down the W2K DCs.
>>>
>>> On one of our W2K3 member servers, we get a very strange result. The
>>> following commands all work:
>>>
>>> net view \DC1
>>> net view \DC2
>>> net view \DC3
>>>
>>> However if you try this one it fails with an Access is Denied failure
>>> code 5:
>>>
>>> net view \DC4
>>>
>>> To get even stranger, these work:
>>>
>>> net view \DC4.our.domain.com // i.e., FQDN version of name works
>>> net view \<ip-of-DC4>
>>>
>>> So only the NetBIOS name version of the command fails.
>>>
>>> In the security eventviewer of the member server I see a failure on
>>> Error 529, and rather bizarre detail as follows:
>>>
>>> Logon Failure:
>>> Reason: Unknown user name or bad password
>>> User Name:
>>> Domain:
>>> Logon Type: 3
>>> Logon Process: Kerberos
>>> Authentication Package: Kerberos
>>> Workstation Name: -
>>> Caller User Name: -
>>> Caller Domain: -
>>> Caller Logon ID: -
>>> Caller Process ID: -
>>> Transited Services: -
>>> Source Network Address: 127.0.0.1
>>> Source Port: 0
>>>
>>>
>>> A sniffer trace on the member server shows that for the case of net view
>>> on DC1, DC2, and DC3, there is no attempt to use Kerberos. For the
>>> attempt to use DC4 using the FQDN or IP address, there is no attempt to
>>> use Kerberos. For the one case where things fail, sure enough there
>>> is a Kerberos ticket request from the member server, and one would
>>> assume the response back from the DC it contacts is a failure message.
>>>
>>> Looking at the text above, it looks like the ticket request is filled
>>> out incorrectly. I cannot make any sense of this.
>>>
>>> 1) Why is the user's name and domain left blank in the request?
>>>
>>> 2) Why is the request only needed for the NetBIOS version of the DC4
>>> hostname, but not for the FQDN or the IP?
>>>
>>> Any thoughts on how to go about debugging this?
>>>
>>> --
>>> Will
>
>
|