RE: [ActiveDir] KRB_AP_ERR_MODIFIED error

[joe]

Hey Rich, I am by far not a kerberos expert but I will try to help with what I know...   First off, Kerberos doesn't do anything with IP addresses. In fact if you need to test authentication on DC's like by hitting the netlogon share in a monitor loop you use IP addresses so you don't get a kerb ticket from you local DC and send a kerb ticket to the remote machine instead of credentials...   Now the duplicate computer names (say the same machine name in multiple domains in the same forest) could produce duplicate SPNs. This would require using a disjoint namespace for the FQDN HOST record but could easily happen with the short host name record (HOST/FASTMOFO) but I am not entirely sure that one is ever used. I generally recommend people use a unique naming system for machines in an entire enterprise anyway as kerberos is not the only thing that can choke on that, WINS, Broadcast traffic, etc can all have issues with duplicate short host names.   Generally when you have these duplicates you will see duplicate SPN record errors on your DCs when the DC is trying to chase down the security principal tied to a specific SPN  - like HOST/fastmofo.joehome.com. If in fastmofo example I was using a disjoint DNS namespace and the DNS FQDN for fastmofo was fastmofo.fastpcs.com (and in the AD domain joehome.com) and then I removed the machine from joehome and put it in fastpcs.joehome.com but didn't remove the computer object with the SPN I would now have two instances of HOST/fastmofo.fastpcs.com in the forest and would not be able to uniquely identify the security principal.   Now the CIFS registrations are not listed in AD for Windows machines. All Windows machines are assumed to have them from what I recall reading in some MS documentation I saw previously so I could see having duplicate entries for that, but if you say you don't have duplicate machine names this could be (and probably is) a red herring.   I don't use SMS and haven't used it so I am not sure what it could be doing, but it could possibly be an issue that just wasn't flagged previously because nothing was using the kerberos functionality in question or you guys were dismissing something like say slow performance while whatever fell back to some other form of authentication or SMS is screwed up.   Hope that clears it up to the point of mud.   One other thing comes to mind. Is SMS running as a localsystem type of account or is it running as a userid? Either way, does it have permission to register SPN's for itself? If running as an ID it would need to be able to register an SPN on the userid, if running as a local system type of account it would need to register on the computer object. Note me typing this surprised me as well but I just went through a go around with PSS concerning SQL Server SPNs and the fact that if you run SQL Server in a user context instead of localsystem it has to register the SQL SPN on the user object instead of the computer object and in many implementations of AD (read Secure implimentations) this probably wouldn't be able to happen and it could cause SQL Server kerberos issues specifically from what I understand in the area of ticket delegation (doing work on behalf of someone else on another machine).   Like I said, I am NOT a kerberos expert. MS did a great job of burying the details of kerberos so we don't have to worry about it. I didn't know this but know this now after seeing all of the issues our UNIX Kerberos folks have been going through trying to kerberize their machines. Right now they are trying to figure out how to handle expiring tickets for jobs that run on UNIX machines that take 2-3 weeks to run... MS doesn't have a problem with that one at all.     joe     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn Sent: Friday, February 20, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] KRB_AP_ERR_MODIFIED error I think I’m making a little progress… we have not yet enabled scavenging on DNS and there seems to be a pattern with duplicate registrations in DNS.  For example, in the one below, there are two A records with the same IP address – REM4649XP and REM4724.  These two clients happen to be remote, coming in through the VPN or RAS.  But not all clients with duplicates are remote – some are local.  So… you ping REM4649XP and you get 192.168.20.20, and you ping REM4724 and you get 192.168.20.20.  “So what?” someone asked.  We have had a problem with remote users over the VPN having really slow response on Exchange – it asks Retry, Work offline, or Cancel the first time Outlook 2000 tries to contact the Exchange server, click Retry and it comes up, minutes later.    What am I getting at?  Two things:   1)       What are the ramifications of having duplicates in DNS for workstations? 2)       Is Kerberos doing a DNS lookup on the SMS server, or is the client itself confused, and do I care?  Seems to me this situation could have strange and sometimes serious implications to the clients involved.  ??   Thanks – I imagine Kerberos is very few people’s favorite subject, but maybe it’s good for me to have to learn more about it! J   Rich   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn Sent: Tuesday, February 17, 2004 11:12 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] KRB_AP_ERR_MODIFIED error   AD 2003, 2003 domain mode, 2000 forest mode I just installed SMS 2003 and started seeing the following on the SMS server (running W2K3).  I am trying to chase this down but the stuff I’m finding online is not helpful.  I have a large (over 50) number of errors like the following on the SMS server in the System log: Event Type:   Error Event Source:          Kerberos Event Category:       None Event ID:       4 Date:            2/17/2004 Time:            8:22:12 AM User:            N/A Computer:     AIISMS Description: The kerberos client received a KRB_AP_ERR_MODIFIED error from the server REM4649XP$.  The target name used was cifs/REM4724.CORPORATE.DOMAIN. 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 (CORPORATE.DOMAIN), and the client realm.   Please contact your system administrator.  (that’s me, thanks a lot)   Well, there would have to be an awful lot of “identically named computers” on our network if that is the case, and they were fine before SMS… but it seems strange they are showing a different FQDN than the server name shown – which is not a server but a workstation (not that it cares here I think).  I don’t know enough about Kerberos to know if that is important, but I have printed out the RFC.  Fun.  Anyone know anything about this error?  Hint – I’m pretty certain the answer is not to re-add all those workstations to the domain….   Thanks   Rich     Rich Milburn MS MVP – Directory Services MCSE NT4/2000         -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. This information is strictly confidential and may be subject to attorney-client privilege. This message is intended only for the use of the named addressee. If you are not the intended recipient of this message, unauthorized forwarding, printing, copying, distribution, or using such information is strictly prohibited and may be unlawful. If you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. Unauthorized interception of this e-mail is a violation of federal criminal law. Applebee's International, Inc. reserves the right to monitor and review the content of all messages sent to and from this e-mail address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. e-mail system. -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. This information is strictly confidential and may be subject to attorney-client privilege. This message is intended only for the use of the named addressee. If you are not the intended recipient of this message, unauthorized forwarding, printing, copying, distribution, or using such information is strictly prohibited and may be unlawful. If you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. Unauthorized interception of this e-mail is a violation of federal criminal law. Applebee's International, Inc. reserves the right to monitor and review the content of all messages sent to and from this e-mail address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. e-mail system.