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
Get Chitika Premium
Posted by Will on September 25, 2007, 3:28 pm
Please log in for more thread options
> Do you point your dc to a WINS server on its NIC configuration? It needs
to
> be on the same subnet as where you are attempting this test or be
registered
> with a WINS server.

We haven't used WINs in seven years, and nearly every machine we have is on
a different subnet. We turn off NetBIOS over TCP, and ports 137, 138, and
139 are dirty words in our office. :)

In any case, I don't see any attempt by client to locate the server by any
method other than DNS. The problem is the client is sending out a Kerberos
request just for this one DC using some malformed Kerberos request and
getting back a rejection. All of that activity takes place between client
and another DC on port 88 (from memory).

Note that from my example, DC1, DC2, DC3, and DC4 are all on different
subnets than the client. Net View works to all DCs except DC4. So
subnetting is not the unique variable associated with the failure case.

--
Will



Posted by Jorge Silva on September 25, 2007, 3:41 pm
Please log in for more thread options
Network browsing is NetBIOS resolution dependent, that's by design, in
different subnets you need WINS.

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

Jorge Silva
MCSE, MVP Directory Services
>> Do you point your dc to a WINS server on its NIC configuration? It needs
> to
>> be on the same subnet as where you are attempting this test or be
> registered
>> with a WINS server.
>
> We haven't used WINs in seven years, and nearly every machine we have is
> on
> a different subnet. We turn off NetBIOS over TCP, and ports 137, 138,
> and
> 139 are dirty words in our office. :)
>
> In any case, I don't see any attempt by client to locate the server by any
> method other than DNS. The problem is the client is sending out a
> Kerberos
> request just for this one DC using some malformed Kerberos request and
> getting back a rejection. All of that activity takes place between
> client
> and another DC on port 88 (from memory).
>
> Note that from my example, DC1, DC2, DC3, and DC4 are all on different
> subnets than the client. Net View works to all DCs except DC4. So
> subnetting is not the unique variable associated with the failure case.
>
> --
> Will
>
>



Posted by Will on September 25, 2007, 6:50 pm
Please log in for more thread options
> Network browsing is NetBIOS resolution dependent, that's by design, in
> different subnets you need WINS.

We are not using Network Browsing, if by that you mean the use of Network
Neighborhood. When you turn off NetBIOS over TCP you lose that capability
entirely.

We were issuing command line net view \DC4 which is a specific command
directed at specific hostname, resolvable through DNS.

--
Will

>>> Do you point your dc to a WINS server on its NIC configuration? It
>>> needs
>> to
>>> be on the same subnet as where you are attempting this test or be
>> registered
>>> with a WINS server.
>>
>> We haven't used WINs in seven years, and nearly every machine we have is
>> on
>> a different subnet. We turn off NetBIOS over TCP, and ports 137, 138,
>> and
>> 139 are dirty words in our office. :)
>>
>> In any case, I don't see any attempt by client to locate the server by
>> any
>> method other than DNS. The problem is the client is sending out a
>> Kerberos
>> request just for this one DC using some malformed Kerberos request and
>> getting back a rejection. All of that activity takes place between
>> client
>> and another DC on port 88 (from memory).
>>
>> Note that from my example, DC1, DC2, DC3, and DC4 are all on different
>> subnets than the client. Net View works to all DCs except DC4. So
>> subnetting is not the unique variable associated with the failure case.
>>
>> --
>> Will



Posted by Jorge Silva on September 25, 2007, 7:12 pm
Please log in for more thread options
That's correct, I was just re-stating previous posts regardind to that
resolution mechanism.

Regarding to the Access is DENIED error, did you tried the KB that I
provided you?

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

Jorge Silva
MCSE, MVP Directory Services
>> Network browsing is NetBIOS resolution dependent, that's by design, in
>> different subnets you need WINS.
>
> We are not using Network Browsing, if by that you mean the use of Network
> Neighborhood. When you turn off NetBIOS over TCP you lose that
> capability entirely.
>
> We were issuing command line net view \DC4 which is a specific command
> directed at specific hostname, resolvable through DNS.
>
> --
> Will
>
>>>> Do you point your dc to a WINS server on its NIC configuration? It
>>>> needs
>>> to
>>>> be on the same subnet as where you are attempting this test or be
>>> registered
>>>> with a WINS server.
>>>
>>> We haven't used WINs in seven years, and nearly every machine we have is
>>> on
>>> a different subnet. We turn off NetBIOS over TCP, and ports 137, 138,
>>> and
>>> 139 are dirty words in our office. :)
>>>
>>> In any case, I don't see any attempt by client to locate the server by
>>> any
>>> method other than DNS. The problem is the client is sending out a
>>> Kerberos
>>> request just for this one DC using some malformed Kerberos request and
>>> getting back a rejection. All of that activity takes place between
>>> client
>>> and another DC on port 88 (from memory).
>>>
>>> Note that from my example, DC1, DC2, DC3, and DC4 are all on different
>>> subnets than the client. Net View works to all DCs except DC4. So
>>> subnetting is not the unique variable associated with the failure case.
>>>
>>> --
>>> Will
>
>



Posted by Will on September 25, 2007, 7:41 pm
Please log in for more thread options
> That's correct, I was just re-stating previous posts regardind to that
> resolution mechanism.
>
> Regarding to the Access is DENIED error, did you tried the KB that I
> provided you?

Maybe I'm thinking of the wrong one, but the KB you sent was for resetting
the password of a domain controller?

That sounds like a serious thing to do, potentially destabilizing, and why
would it be an appropriate step to take when it is the client that is
malforming a Kerberos request to use the DC? I'm willing to try it if
there is a reason to try it, but it seemed a bit random.

--
Will


>>> Network browsing is NetBIOS resolution dependent, that's by design, in
>>> different subnets you need WINS.
>>
>> We are not using Network Browsing, if by that you mean the use of Network
>> Neighborhood. When you turn off NetBIOS over TCP you lose that
>> capability entirely.
>>
>> We were issuing command line net view \DC4 which is a specific command
>> directed at specific hostname, resolvable through DNS.
>>
>> --
>> Will
>>
>>>>> Do you point your dc to a WINS server on its NIC configuration? It
>>>>> needs
>>>> to
>>>>> be on the same subnet as where you are attempting this test or be
>>>> registered
>>>>> with a WINS server.
>>>>
>>>> We haven't used WINs in seven years, and nearly every machine we have
>>>> is on
>>>> a different subnet. We turn off NetBIOS over TCP, and ports 137,
>>>> 138, and
>>>> 139 are dirty words in our office. :)
>>>>
>>>> In any case, I don't see any attempt by client to locate the server by
>>>> any
>>>> method other than DNS. The problem is the client is sending out a
>>>> Kerberos
>>>> request just for this one DC using some malformed Kerberos request and
>>>> getting back a rejection. All of that activity takes place between
>>>> client
>>>> and another DC on port 88 (from memory).
>>>>
>>>> Note that from my example, DC1, DC2, DC3, and DC4 are all on different
>>>> subnets than the client. Net View works to all DCs except DC4. So
>>>> subnetting is not the unique variable associated with the failure 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