Click here to get back home

Problems With Kerberos Authentication

 HomeNewsGroups | Search | About
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Problems With Kerberos Authentication Will 09-25-2007
Posted by Will on September 25, 2007, 2:33 am
Please log in for more thread options
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



Posted by Jorge Silva on September 25, 2007, 3:45 am
Please log in for more thread options
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

--
I hope that the information above helps you.
Have a Nice day.

Jorge Silva
MCSE, MVP Directory Services
> 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
>



Posted by Will on September 25, 2007, 4:06 am
Please log in for more thread options
> 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



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
>
>



Posted by Will on September 25, 2007, 3:13 pm
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

The message was Access is DENIED. Not Host not Found.....

And all of those DCs that work are on different subnets. DNS seems to
solve different subnet problems just fine and we have NetBIOS over TCP
turned off in any case.

--
Will



Similar ThreadsPosted
Kerberos machine authentication - apparent authentication failures May 30, 2005, 10:35 am
Problems with authentication and using alias to the local machine April 27, 2006, 10:22 am
How to set up Kerberos authentication? (some code :) August 18, 2005, 2:55 pm
Kerberos and Integrated Windows authentication July 24, 2005, 8:26 am
Kerberos V5 Authentication for a Telnet Session October 27, 2005, 3:21 am
Kerberos authentication failed across forest March 23, 2006, 8:58 am
Kerberos authentication failed across forest March 23, 2006, 9:08 am
Intermittent Kerberos authentication failure June 14, 2007, 2:26 pm
EFS problems January 4, 2007, 2:15 pm
Ca problems February 2, 2007, 3:59 am

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap