First of all, it is the Cluster Service and the domain account used for this
service that manages the AD computer account objects for the cluster network
name resources. And, it does this regardless of whether or not the Enable
for Kerberos option is specified.
As far as the account slowly slipping away, I would check your cluster node
Window Time and see if they are sending any alerts to the event log stating
that they are getting out of sync. That and/or the node times may be out of
synch with the KDC, or with the clients.
Kerberos requires the entire domain infrastructure to remain synchronous in
time; otherwise the tickets will be denied for perceived expiration.
If not this, what does your system event logs say?
Sincerely,
Anthony Thomas
--
[quoted text, click to view] "Wilson U" <wilson_u@hotmail.com> wrote in message
news:458d88d1_3@newsfeed.slurp.net...
> Hello,
>
> We have SQL 2005 installed on Windows 2003 active/passive cluster. A
domain
> account is used in the cluster setup. The sql server name has the 'Enable
> kerberos authentication' checked to register and maintain its record in
AD.
> It can create the computer object in AD but about every 60 days, the
'Enable
> kerberos authentication' needs to be unchecked and rechecked to continue
to
> allow kerberos authentication.
> About 60 days after the registration, we begin to see failures in tasks we
> have to connect to the sql server name by unc using kerberos
authentication.
> The authentication shows up in the sql server as anonymous on the sql
> server side as it seems it could not negotiate kerberos authentication
with
> the calling server. One of the times this went its full course, the
> authentication issues spread to all servers using kerberos authentication
> and then the computer object is no longer seen in AD until a manual
uncheck
> and recheck of the 'Enable kerberos authentication' was made.
>
> Any one have any ideas on why this is happening?
>
> Thanks,
> Wilson
>
>
