Hello,

I'm trying resolve common serious problem in my cluster environments (it
appear only in SQL cluster environment, no problem with standalone
installation).

I run two node cluster (A/A), sql server and cluster service work under
domain admin account. Whenever I try connect to other resource/server (for
example network share \\ from job) outside the cluster in the same domain ,
sql break security context and I receive "NT AUTHORITY\ANONYMOUS LOGON" on
destination server.

I started few months ago topic on SqlTeam forum, but unfortunately didn't
get explicitly answer

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=107269

Another example, two instances:

VIRTUAL1\SQL1 - SQLServer
VIRTUAL2\SQL2 - SQLServer, Analysis Services

When I created Linked Server on VIRTUAL1\SQL1 to VIRTUAL2\SQL2 (Analysis
Services) I got "NT AUTHORITY\ANONYMOUS LOGON" when try connect, when Linked
Server is on VIRTUAL2\SQL2 I'm able connect to VIRTUAL2\SQL2 (Analysis
Services).

I think it is the same problem as I experience with sql agent (described at
SqlTeam forum).

Could anybody help me find where is the problem, please. Active Directory,
Cluster Service, SQL ?

SQL 2005, Windows 2003

--
Regards,
anxcomp

What are the service accounts for the various instances/services?


--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP


"anxcomp" <anxcomp (AT) discussions (DOT) microsoft.com> wrote

We had a problem that seems to be like yours some. I opened a case at
Microsoft and they gave us a two-step workaround:
- set the DisableStrictNameChecking registry entry to 1
- set the DisableStrictNameChecking registry entry to 1
You may give it a try. Be careful, it worked for me, no warranty that it's
ok for you:
--------------------------------
1. 914060 A logon window appears in Windows Server 2003 Service Pack 1 NLB
when you try to browse the virtual NLB cluster name
http://support.microsoft.com/default...b;EN-US;914060

2. WORKAROUND
Warning This workaround may make your computer or your network more
vulnerable to attack by malicious users or by malicious software such as
viruses. We do not recommend this workaround but are providing this
information so that you can implement this workaround at your own
discretion. Use this workaround at your own risk.
Warning Serious problems might occur if you modify the registry incorrectly
by using Registry Editor or by using another method. These problems might
require that you reinstall the operating system. Microsoft cannot guarantee
that these problems can be solved. Modify the registry at your own risk.
To work around this problem, set the DisableStrictNameChecking registry
entry to 1. Then, use one of the following methods, as appropriate.
FROM:
http://support.microsoft.com/kb/281308/


Windows Server 2003
To resolve this problem in Windows Server 2003, complete the following
steps:
1. Create the CNAME record for the file server on the appropriate DNS
server, if the CNAME record is not already present.
2. Apply the following registry change to the file server. To do so, follow
these steps:
a. Start Registry Editor (Regedt32.exe).
b. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\LanmanServer\Parameters
c. On the Edit menu, click Add Value, and then add the following registry
value:
Value name:
Data type: REG_DWORD
Radix: Decimal
Value: 1
d. Quit Registry Editor.
1. Restart your computer.
---------------------------------------------------

Good luck
Pierrot



"anxcomp" <anxcomp (AT) discussions (DOT) microsoft.com> wrote

Hello,

Thanks for answers.

All instances and cluster service run under the same one account
(account (AT) domain (DOT) local), account (AT) domain (DOT) local is member of domain admin group.

I can't understand that situation, no problem with standalone installation
(without cluster service) run under the same account on the same active
directory domain. I can read remote files from another server using UNC (is
not possible in cluster), no problem with Linked Server.

Question is why it doesn't work with cluster? Off course I mean Failover
Cluster not NLB.

--
Regards,
anxcomp

check servicePrincipalName for sql server account in AD
--
Aleksandar Grbic
MCDBA, Senior Database Administrator


"anxcomp" wrote:

The answer I got from Microsoft refers to Windows Server 2003 and NLB, but
it also applies to Windows Server 2008 and Failover Cluster.

Pierrot


"anxcomp" <anxcomp (AT) discussions (DOT) microsoft.com> wrote

hello,

No problem with SPN, I didn't find any error in SQL Server log with spn,
setspn return:

setspn -L domain\account
Registered ServicePrincipalNames for CN=account,CN=Users,DC=domain,DC=local:
MSSQLSvc/VIRTUAL1.domain.local:2423
MSSQLSvc/VIRTUAL2.domain.local:2685

SQL working under domain admin account so I don't think it is problem with
SPN,

Do you have any idea what can I check more?

--
Regards,
anxcomp