Hello all!

Here's my issue:

I want to access my CRM app from the outside my Network, through a private
Internet connecion. I'm using an url like https://mydomain.com:5556, as I run
my CRM server on SLL, port 5556. I don't have any certificate error, I'm sure
of that. It works fine, I can access CRM, exept that I cannot view my reports
list, neither access this page: Parameters->Organisation Parameters->System
Parameters.

I get an error: "An error occured, contact your Administrator."

From the inside the network, everything works just fine, and my Windows user
(called rw) can generate reports, view all pages. He has, in CRM, an Admin
role.
He is also member of the fours AD groups created during the installation. So
he is full power user !

I guess my problem is that, from the outside, Kerberos auth could not be
used (even by adding https://mydomain.com to Local Intranet zone). So when I
first log, NTLM is used, and I get access to the classical pages (Accounts,
Activities, etc.).

Then, when I click on "Reports", the CRM server probably needs to
authenticate me again, but, because Kerberos fails, or is not even tried,
NTLM is probably used, and my local domain (the distant one) sees me (don(t
ask me why) as Anonymous User! In the Security Events log, I can see two
events (540 and 538) one after another, like: "success opening session for NT
AUTHORITY\ANONYMOUS USER", and just after "closing the session NT
AUTHORITY\ANONYMOUS USER".

Conclusion: an authentication issue leads to an Authorization issue, as CRM
Server does not accept (and that's normal) anonymous users.

I assume that I only have one server that runs CRM 3.0 + SQL 2005 + Rep.
Serv. 2005 + Exchange 2003, so I think it's not a classical double-hop
Kerberos authentication that would fail.

How can I use Kerberos auth or get NTLM work?

Sorry for the long long story.

Does anybody have a clue? A idea?

Thank you very much.

I'm going to agree with you and say that the problem is Kerberos, because the
Reports are probably making use of the filtered SQL views, which require the
user's credentials to determine whether you should have access to the info or
not, based on your MSCRM security role.

The portion starting with "How can my internal Web site use the client's
single sign-on credentials to access SQL Server?" in this article may help
you find an answer:
http://msdn.microsoft.com/msdnmag/is...ecurityBriefs/

Be warned, though, that if you have IIS and SQL on separate machines, it is
probably not going to be a walk in the park.

"whybe" wrote:

Thank for your response. The article was VERY interesting but did not solve
my problem. As a matter of fact, I already impersonate client with <identity
impersonate='true'/> in my CRM 3.0 web.config. I think the real problem is
I'm not loggued on the domain, so Kerberos won't be used. I fact I even don't
know if Kerberos can use with this topology (a computer not loggued on a
domain...).

I tried to activate Basic auth on the website (I use SSL as a security, of
course), but it did not work

Does anybody access his CRM app from outside his network, without a VPN?

Thanks...

"Chad Fulda" wrote:

Hope you don't mind if I chime in, but it is a Kerberos problem.
If you set IIS to anomynous access instead of integrated security you can
list the reports from outside the Kerberos realm.

Depending on the location of the reporting service and the SQL server, the
Kerberos hop and impersonation will not work with machines outside the realm,
because there is no token generated to speak to the SQL server on the back
end.

But when you log into the web server you are using NTLM.
So if you tell the web server to speak to the SQL serve with only NTLM then
outside clients will run the reports.

GO to HKLM\Software\Microsfot\MSCRM
Create the regkey NTLMForSQLRSServer Dword
Set it to a value of 1.

You will have to change the connection string in SRS from integrated
security to "Credential stored securly in the report server.

Use an domain account that also has access to the SQL server security. DBO
perhaps
Check both the following:
Use as Windows credentials when connecting to the data
source, and Impersonate the authenticated user after a connection has been
made to the data source.





"Venkatesh GP" wrote: