|
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). This is also a problem with SMS 2003 in advanced security
mode connecting to a remote SQL Server configured to run its services as a
domain account. _______________________________________ Brian W.
Rogers, MCSE Consultant, Collective Technologies (904) 505-8484 (mobile) (800) 578-8577 (office) Managed Infrastructure
for the Real World™ ________________________________________ From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of 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 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 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. |
- [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error deji
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Brian Rogers
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Brian Rogers
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Brian Rogers
- RE: [ActiveDir] KRB_AP_ERR_MODIFIED error Rich Milburn
