| Author | Messages | |
edsibone
Posts:9
 | | 02/01/2012 5:44 PM |
| Hey all,
I've been starting to see some weird Kerb errors on some PCs and DCs in my
environment and its starting to stump me... These are not related but
naturally has got me worried. For the 1st event #4, I've been trying to
find a duplicate server named the same as the DC in question, but of course
there are none... For the event #27, I am not sure what that means.. Can
anyone shed some light on either of the issues? Thanks, Ed
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 10/20/2011
Time: 7:02:48 AM
User: N/A
Computer: PC1022
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server
hqdc1$. This indicates that the password used to encrypt the kerberos
service ticket is different than that on the target server. Commonly, this
is due to identically named machine accounts in the target realm (
CHILD.ROOT.ORG), and the client realm. Please contact your system
administrator.
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 27
Date: 10/17/2011
Time: 2:08:21 AM
User: N/A
Computer: HQDC3
Description:
While processing a TGS request for the target server krbtgt/CHILD.ROOT.ORG,
the account SRV1292$@CHILD.ROOT.ORG did not have a suitable key for
generating a Kerberos ticket (the missing key has an ID of 8). The requested
etypes were 18. The accounts available etypes were 23 -133 -128 3 1.
| | | |
| Parzival
Posts:122
| | 02/01/2012 5:46 PM |
| The other thing i can think of that i have seen once.. is if you are making snapshots of your virtual domain controllers. In some cases the disk cache is flushed during the snapshot which causes the Active Directory process to go bezerk..
_R
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Ed Sibone
Sent: Friday, October 21, 2011 4:51 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Kerberos Oddities
Thx for the info.. Believe it or not, the site that event 4 came from has a new DC... not sure why I'd have a duplicate anything, computer or SPN, but I will search.. I will also search for the SPNs of the client machines in question, but these have been there for some time and it seems to be happening on several in the site.. The issue that alerted me to this was users in the site were complaining it was taking longer than normal to retrieve files of the file server. This led to me finding the event 4 on the client PC that exhibited the problem.
As for event 27, its a 2K8R2 server, Exchange server no loess.. very odd.. Exchange functionality appears to be OK as far as we can tell.. We are in the middle of some 2003 DC migrations though, installing 2008R2 DCs, while decomming various 2003 ones.
As for replication, all seems well, no errors coming from any DC as per repadmin /replsum runs, even DCDIAGs from several DCs dont show any glaring problems..
Something definitely is afoot here.. not sure where though. might have to break out some wire capture if nothing on the surface comes out..
On Thu, Oct 20, 2011 at 2:13 PM, Roelf Zomerman <roelf.zomerman@xxxxxxxxxxxxxxxx<mailto:roelf.zomerman@xxxxxxxxxxxxxxxx>> wrote:
Hi,
So basically kerberos works with SPN's. These are the pointers on which kerberos works. Objects in the AD can have SPN's as an attribute. When you request a kerberos ticket.. the SPN is used to look for the object and then the domain controller uses the object secret key (actually a little more complicated.. but lets keep it simple).. in the ticket. Only the object itself can retract the ticket information as it shares the secret key with the domain controller.
The first one states that the secret key used for the kerberos ticket does not match the secret key on the machine that received the ticket. Thus the contents could not be retracted. As it states.. it could be that the password for the ticket was not replicated yet.. (meaning replication problems).. or that you have a duplicate SPN. To rule-out duplicate SPNs search for the SPN mentioned in the eventlog using the SPN find script: http://blogs.dirteam.com/blogs/carlos/archive/2006/04/21/812.aspx
if it is replication.. well .. eeuh then you have another problem.. but search for this one first..
Also.. it could also be that you have a custom SPN (for example for a website) that is not handled by the service account but the server.. (note that Windows 2008(R2) has kerberos Kernel mode for IIS that allows SPN's to be registered to the machine account hosting the website instead of the website application pool account.
For the second entry.. is that server a Windows server or Unix? If it is windows well there is something def. wrong.. or check replication.. if it is a non-windows machine, check if the right request type is sent.. it could be that the system is requesting AES encryption which is not supported by the Windows KDC. In order to test this.. try to logon to a windows machine, type klist on the command prompt and see the type of encryptions that are supported.
Roelf
From: activedir-owner@xxxxxxxxxxxxxxxx<mailto:activedir-owner@xxxxxxxxxxxxxxxx> [mailto:activedir-owner@xxxxxxxxxxxxxxxx<mailto:activedir-owner@xxxxxxxxxxxxxxxx>] On Behalf Of Ed Sibone
Sent: Thursday, October 20, 2011 8:59 PM
To: ActiveDir
Subject: [ActiveDir] Kerberos Oddities
Hey all,
I've been starting to see some weird Kerb errors on some PCs and DCs in my environment and its starting to stump me... These are not related but naturally has got me worried. For the 1st event #4, I've been trying to find a duplicate server named the same as the DC in question, but of course there are none... For the event #27, I am not sure what that means.. Can anyone shed some light on either of the issues? Thanks, Ed
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 10/20/2011
Time: 7:02:48 AM
User: N/A
Computer: PC1022
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server hqdc1$. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (CHILD.ROOT.ORG<http://CHILD.ROOT.ORG> , and the client realm. Please contact your system administrator.
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 27
Date: 10/17/2011
Time: 2:08:21 AM
User: N/A
Computer: HQDC3
Description:
While processing a TGS request for the target server krbtgt/CHILD.ROOT.ORG<http://CHILD.ROOT.ORG>, the account SRV1292$@CHILD.ROOT.ORG<http://CHILD.ROOT.ORG> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18. The accounts available etypes were 23 -133 -128 3 1<tel:23%C2%A0%20-133%C2%A0%20-128%C2%A0%203%C2%A0%201>.
| | | |
| Gil
Posts:316
| | 02/01/2012 5:46 PM |
| >> the disk cache is flushed during the snapshot which causes the Active Directory process to go bezerk..
I've never heard of that one before. Can you say more about it?
-gil
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Roelf Zomerman
Sent: Friday, October 21, 2011 11:37 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Kerberos Oddities
The other thing i can think of that i have seen once.. is if you are making snapshots of your virtual domain controllers. In some cases the disk cache is flushed during the snapshot which causes the Active Directory process to go bezerk..
_R
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Ed Sibone
Sent: Friday, October 21, 2011 4:51 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Kerberos Oddities
Thx for the info.. Believe it or not, the site that event 4 came from has a new DC... not sure why I'd have a duplicate anything, computer or SPN, but I will search.. I will also search for the SPNs of the client machines in question, but these have been there for some time and it seems to be happening on several in the site.. The issue that alerted me to this was users in the site were complaining it was taking longer than normal to retrieve files of the file server. This led to me finding the event 4 on the client PC that exhibited the problem.
As for event 27, its a 2K8R2 server, Exchange server no loess.. very odd.. Exchange functionality appears to be OK as far as we can tell.. We are in the middle of some 2003 DC migrations though, installing 2008R2 DCs, while decomming various 2003 ones.
As for replication, all seems well, no errors coming from any DC as per repadmin /replsum runs, even DCDIAGs from several DCs dont show any glaring problems..
Something definitely is afoot here.. not sure where though. might have to break out some wire capture if nothing on the surface comes out..
On Thu, Oct 20, 2011 at 2:13 PM, Roelf Zomerman <roelf.zomerman@xxxxxxxxxxxxxxxx<mailto:roelf.zomerman@xxxxxxxxxxxxxxxx>> wrote:
Hi,
So basically kerberos works with SPN's. These are the pointers on which kerberos works. Objects in the AD can have SPN's as an attribute. When you request a kerberos ticket.. the SPN is used to look for the object and then the domain controller uses the object secret key (actually a little more complicated.. but lets keep it simple).. in the ticket. Only the object itself can retract the ticket information as it shares the secret key with the domain controller.
The first one states that the secret key used for the kerberos ticket does not match the secret key on the machine that received the ticket. Thus the contents could not be retracted. As it states.. it could be that the password for the ticket was not replicated yet.. (meaning replication problems).. or that you have a duplicate SPN. To rule-out duplicate SPNs search for the SPN mentioned in the eventlog using the SPN find script: http://blogs.dirteam.com/blogs/carlos/archive/2006/04/21/812.aspx
if it is replication.. well .. eeuh then you have another problem.. but search for this one first..
Also.. it could also be that you have a custom SPN (for example for a website) that is not handled by the service account but the server.. (note that Windows 2008(R2) has kerberos Kernel mode for IIS that allows SPN's to be registered to the machine account hosting the website instead of the website application pool account.
For the second entry.. is that server a Windows server or Unix? If it is windows well there is something def. wrong.. or check replication.. if it is a non-windows machine, check if the right request type is sent.. it could be that the system is requesting AES encryption which is not supported by the Windows KDC. In order to test this.. try to logon to a windows machine, type klist on the command prompt and see the type of encryptions that are supported.
Roelf
From: activedir-owner@xxxxxxxxxxxxxxxx<mailto:activedir-owner@xxxxxxxxxxxxxxxx> [mailto:activedir-owner@xxxxxxxxxxxxxxxx<mailto:activedir-owner@xxxxxxxxxxxxxxxx>] On Behalf Of Ed Sibone
Sent: Thursday, October 20, 2011 8:59 PM
To: ActiveDir
Subject: [ActiveDir] Kerberos Oddities
Hey all,
I've been starting to see some weird Kerb errors on some PCs and DCs in my environment and its starting to stump me... These are not related but naturally has got me worried. For the 1st event #4, I've been trying to find a duplicate server named the same as the DC in question, but of course there are none... For the event #27, I am not sure what that means.. Can anyone shed some light on either of the issues? Thanks, Ed
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 10/20/2011
Time: 7:02:48 AM
User: N/A
Computer: PC1022
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server hqdc1$. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (CHILD.ROOT.ORG<http://CHILD.ROOT.ORG>, and the client realm. Please contact your system administrator.
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 27
Date: 10/17/2011
Time: 2:08:21 AM
User: N/A
Computer: HQDC3
Description:
While processing a TGS request for the target server krbtgt/CHILD.ROOT.ORG<http://CHILD.ROOT.ORG>, the account SRV1292$@CHILD.ROOT.ORG<http://CHILD.ROOT.ORG> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18. The accounts available etypes were 23 -133 -128 3 1<tel:23%C2%A0%20-133%C2%A0%20-128%C2%A0%203%C2%A0%201>.
| | | |
| adwulf
Posts:112
| | 02/01/2012 5:46 PM |
| On 21 October 2011 03:51, Ed Sibone <edsibone.rdy@xxxxxxxxxxxxxxxx> wrote:
> Thx for the info.. Believe it or not, the site that event 4 came from has a
> new DC... not sure why I'd have a duplicate anything, computer or SPN, but
> I will search.. I will also search for the SPNs of the client machines in
> question, but these have been there for some time and it seems to be
> happening on several in the site.. The issue that alerted me to this was
> users in the site were complaining it was taking longer than normal to
> retrieve files of the file server. This led to me finding the event 4 on
> the client PC that exhibited the problem.
>
I usually see this event when there's an alias pointing to a machine,
and the client attempts to use the alias instead of the actual
hostname (or there's no SPN configured for the alias).
Does hqdc1 actually exist as a machine? Or is it a stale DNS record
pointing to some other machine?
> As for event 27, its a 2K8R2 server, Exchange server no loess.. very
> odd.. Exchange functionality appears to be OK as far as we can tell.. We
> are in the middle of some 2003 DC migrations though, installing 2008R2 DCs,
> while decomming various 2003 ones.
>
I've seen this event ID 27 on some Win2K3 domain controllers, but
never on Win2K8.
When I looked into this, it seems that the customer had started
introducing Win7/Vista desktops to their estate, which were attempting
to use AES-256, which Win2K3 does not support. I thought I'd seen a
KB article about this, but currently can only find this:
https://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/29f55875-f3ee-476c-9d74-94f1b74edb31/
For a Win2008 DC - well, I thought that perhaps your Windows 2008 DCs
aren't capable of using AES-256 because of the domain functional level
- a bit of googling suggest that may well be the case:
http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx
--
AdamT
Karaoke: Japanese for 'avoid this pub'. As in "Karaoke, Saturday 7pm-11pm".
List info: http://www.activedir.org/List.aspx
| | | |
| barkills
Posts:303
| | 02/01/2012 5:48 PM |
| Sorry to jump in late, but I've been offline for a bit.
A couple things here:
etype 18 is AES256-CTS-HMAC-SHA1-96 which isn't supported by all Windows OSes. Your WS2003/WS2003R2 DCs do not support that requested etype.
There is a known error when you have a mix of DCs that are WS2003 and WS2008R2 that might fit with your KDC 27 log error. See KB978055.
In a nutshell, when a Kerberos token is issued it is issued with a specific encryption type. The chosen encryption type is supported by both the client and issuing KDC. But there's no guarantee that other Kerberized services or KDCs will also support that encryption type. And if the client passes that token (still encrypted) to something that doesn't support that encryption type, then you can have problems. The KB article I noted above is one such case. I've talked previously here about other examples involving cross-realm Kerberos. I can also imagine examples that involve Kerberos Delegation.
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Ed Sibone
Sent: Friday, October 21, 2011 8:01 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Kerberos Oddities
Yea, I tracked it down to a stale WINS server.. it had old records still for the defunct DC. My question is why is it even trying to resolve the old DC name.. its gone, demoted, removed from AD, DNS, and now WINS.. And is that whats causing the Kerb errs.
On Fri, Oct 21, 2011 at 9:10 AM, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx<mailto:adwulf@xxxxxxxxxxxxxxxx>> wrote:
On 21 October 2011 14:55, Ed Sibone <edsibone.rdy@xxxxxxxxxxxxxxxx<mailto:edsibone.rdy@xxxxxxxxxxxxxxxx>> wrote:
>
> BZTDC1 is the old DC... long gone, but the new DC (HQDC1) has the IP that
> BZT had..
>
Aha! So it is a case of a client using the wrong name for the IP address.
> The DNS records for BZT are gone... however in the capture I see the client
> asking for BZT via WINS which has some WINS servers giving the old IP of BZT
> which is now the IP for HQDC1. I am about to purge WINS of these old BZT
> records, but its odd that WINS would get in the picture... Or why is it
> doing a TGS to cifs of OLD DC.... Thats where the files USED to be, but
> not any more...
>
Something's giving the client machine that info. If not WINS or DNS,
check for hosts or lmhosts files - as these take precedence over
whatever your DNS/WINS servers say.
--
AdamT
Karaoke: Japanese for 'avoid this pub'. As in "Karaoke, Saturday 7pm-11pm".
List info: http://www.activedir.org/List.aspx
| | | |
| rmscheck
Posts:290
| | 06/16/2012 2:04 PM |
| Hmm, I've found this same problem occurring at my place.. I know this
is an old thread, and I understand it to be a case that 2003 DCs
cannot accept the kerb etypes that 2008R2 machines are using, as Brian
explained. However, many of the articles I've read say this is all
benign and to ignore the error. Is this true?
If so, what exactly happens when a 2008R2 box hits a 2003 DC for auth?
Are they not able to use their ticket and fails or does it bump down
its request to a level the 2003 DC will accept? I'm worried that it
may be causing authentication issues under the covers that I'm not
seeing. My SQL guy is claiming this is the cause for his SSPI errors
and my Exchange guy says its causing Exchange problems since a number
of the event 27s are coming from Exchange servers.
Thanks.
On Fri, Oct 21, 2011 at 12:26 PM, Brian Arkills <barkills@xxxxxxxxxxxxxxxx> wrote:
> Sorry to jump in late, but I've been offline for a bit.
>
>
>
> A couple things here:
>
>
>
> etype 18 is AES256-CTS-HMAC-SHA1-96 which isn't supported by all Windows
> OSes. Your WS2003/WS2003R2 DCs do not support that requested etype.
>
>
>
> There is a known error when you have a mix of DCs that are WS2003 and
> WS2008R2 that might fit with your KDC 27 log error. See KB978055.
>
>
>
> In a nutshell, when a Kerberos token is issued it is issued with a specific
> encryption type. The chosen encryption type is supported by both the client
> and issuing KDC. But there's no guarantee that other Kerberized services or
> KDCs will also support that encryption type. And if the client passes that
> token (still encrypted) to something that doesn't support that encryption
> type, then you can have problems. The KB article I noted above is one such
> case. I've talked previously here about other examples involving cross-realm
> Kerberos. I can also imagine examples that involve Kerberos Delegation.
>
>
>
> From: activedir-owner@xxxxxxxxxxxxxxxx
> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Ed Sibone
> Sent: Friday, October 21, 2011 8:01 AM
>
>
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] Kerberos Oddities
>
>
>
> Yea, I tracked it down to a stale WINS server.. it had old records still
> for the defunct DC. My question is why is it even trying to resolve the old
> DC name.. its gone, demoted, removed from AD, DNS, and now WINS.. And is
> that whats causing the Kerb errs.
>
> On Fri, Oct 21, 2011 at 9:10 AM, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx> wrote:
>
> On 21 October 2011 14:55, Ed Sibone <edsibone.rdy@xxxxxxxxxxxxxxxx> wrote:
>>
>> BZTDC1 is the old DC... long gone, but the new DC (HQDC1) has the IP
>> that
>> BZT had..
>>
>
> Aha! So it is a case of a client using the wrong name for the IP address.
>
>
>> The DNS records for BZT are gone... however in the capture I see the
>> client
>> asking for BZT via WINS which has some WINS servers giving the old IP of
>> BZT
>> which is now the IP for HQDC1. I am about to purge WINS of these old BZT
>> records, but its odd that WINS would get in the picture... Or why is it
>> doing a TGS to cifs of OLD DC.... Thats where the files USED to be, but
>> not any more...
>>
>
> Something's giving the client machine that info. If not WINS or DNS,
> check for hosts or lmhosts files - as these take precedence over
> whatever your DNS/WINS servers say.
>
>
> --
> AdamT
> Karaoke: Japanese for 'avoid this pub'. As in "Karaoke, Saturday 7pm-11pm".
>
> List info: http://www.activedir.org/List.aspx
>
>
List info: http://www.activedir.org/List.aspx
| | | |
| barkills
Posts:303
| | 06/18/2012 4:38 PM |
| It's only benign if the computer (the one which has received a ticket with an encryption type it doesn't support) doesn't need to do anything with the ticket other than pass it along. If it needs to do something with the ticket (for example, add local group SIDs), then it is definitely not benign.
And then there's the special case noted in KB978055, where the computer (which in this case received a ticket with an encryption type it does support) is a WS2008R2 domain controller. It turns out that there's a bug for that specific scenario related to the data structure used in the ticket for the two different encryption types--w/o that patch, a WS2008R2 DC uses the "old" data structure it finds in a WS2003 issued ticket when it goes to issue a fresh ticket with the newer encryption type. The resulting ticket is then interpreted as nonsense by any computer that actually does understand the newer encryption type. The patch presumably forces the WS2008R2 DC to rewrite the data structure in the "new" data structure when it gets a ticket in the "older" data structure, thus avoiding the nonsensical problem.
When a WS2008r2 member server gets a 2003 DC for login, there is an exchange to determine what encryption types the two have in common. If one is found (and it should be), then the "best" type both support is chosen. And then that's the encryption type of the logon token issued by that DC.
As to the claims your colleagues are making, it's hard to say whether they are valid or not without more info. It's possible that they are in the scenario described above for KB978055 although I'd expect eventid=14 instead of eventid=27 if that were the case. See http://technet.microsoft.com/en-us/library/cc733974(v=ws.10) for eventid=27. Given the description around that event, I'd suspect it's more likely that these computers go through the negotiation process to find an encryption type they share in common with a WS2008R2 DC, but are unable to find one. http://technet.microsoft.com/en-us/library/cc749438.aspx has a little background around which encryption type is supported (by default) by each platform. And http://support.microsoft.com/kb/977321 describes the scenario where a service only supports the DES encryption type, but the WS2008R2 DC doesn't have support for that encryption type enabled by default, and how you'd go about changing the configuration to fix that--note you can either use a registry key or a group policy setting to toggle the encryption types.
> -----Original Message-----
> From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-
> owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar
> Sent: Saturday, June 16, 2012 6:03 AM
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] Kerberos Oddities
>
> Hmm, I've found this same problem occurring at my place.. I know this
> is an old thread, and I understand it to be a case that 2003 DCs
> cannot accept the kerb etypes that 2008R2 machines are using, as Brian
> explained. However, many of the articles I've read say this is all
> benign and to ignore the error. Is this true?
>
> If so, what exactly happens when a 2008R2 box hits a 2003 DC for auth?
> Are they not able to use their ticket and fails or does it bump down
> its request to a level the 2003 DC will accept? I'm worried that it
> may be causing authentication issues under the covers that I'm not
> seeing. My SQL guy is claiming this is the cause for his SSPI errors
> and my Exchange guy says its causing Exchange problems since a number
> of the event 27s are coming from Exchange servers.
>
> Thanks.
>
>
>
> On Fri, Oct 21, 2011 at 12:26 PM, Brian Arkills <barkills@xxxxxxxxxxxxxxxx>
> wrote:
> > Sorry to jump in late, but I've been offline for a bit.
> >
> >
> >
> > A couple things here:
> >
> >
> >
> > etype 18 is AES256-CTS-HMAC-SHA1-96 which isn't supported by all
> Windows
> > OSes. Your WS2003/WS2003R2 DCs do not support that requested etype.
> >
> >
> >
> > There is a known error when you have a mix of DCs that are WS2003 and
> > WS2008R2 that might fit with your KDC 27 log error. See KB978055.
> >
> >
> >
> > In a nutshell, when a Kerberos token is issued it is issued with a specific
> > encryption type. The chosen encryption type is supported by both the
> client
> > and issuing KDC. But there's no guarantee that other Kerberized services or
> > KDCs will also support that encryption type. And if the client passes that
> > token (still encrypted) to something that doesn't support that encryption
> > type, then you can have problems. The KB article I noted above is one such
> > case. I've talked previously here about other examples involving cross-
> realm
> > Kerberos. I can also imagine examples that involve Kerberos Delegation.
> >
> >
> >
> > From: activedir-owner@xxxxxxxxxxxxxxxx
> > [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Ed Sibone
> > Sent: Friday, October 21, 2011 8:01 AM
> >
> >
> > To: activedir@xxxxxxxxxxxxxxxx
> > Subject: Re: [ActiveDir] Kerberos Oddities
> >
> >
> >
> > Yea, I tracked it down to a stale WINS server.. it had old records still
> > for the defunct DC. My question is why is it even trying to resolve the old
> > DC name.. its gone, demoted, removed from AD, DNS, and now
> WINS.. And is
> > that whats causing the Kerb errs.
> >
> > On Fri, Oct 21, 2011 at 9:10 AM, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx>
> wrote:
> >
> > On 21 October 2011 14:55, Ed Sibone <edsibone.rdy@xxxxxxxxxxxxxxxx> wrote:
> >>
> >> BZTDC1 is the old DC... long gone, but the new DC (HQDC1) has the IP
> >> that
> >> BZT had..
> >>
> >
> > Aha! So it is a case of a client using the wrong name for the IP address.
> >
> >
> >> The DNS records for BZT are gone... however in the capture I see the
> >> client
> >> asking for BZT via WINS which has some WINS servers giving the old IP of
> >> BZT
> >> which is now the IP for HQDC1. I am about to purge WINS of these old
> BZT
> >> records, but its odd that WINS would get in the picture... Or why is it
> >> doing a TGS to cifs of OLD DC.... Thats where the files USED to be, but
> >> not any more...
> >>
> >
> > Something's giving the client machine that info. If not WINS or DNS,
> > check for hosts or lmhosts files - as these take precedence over
> > whatever your DNS/WINS servers say.
> >
> >
> > --
> > AdamT
> > Karaoke: Japanese for 'avoid this pub'. As in "Karaoke, Saturday 7pm-
> 11pm".
> >
> > List info: http://www.activedir.org/List.aspx
> >
> >
>
> List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
|
|