I've installed ADFS 2.0 on a Windows Server 2008R2, and after installation / configuration wizard I only see the error page when I access "https://myServer/adfs/ls/"
I see a reference number but no entry in the event Viewer. If I create a Wif demo application with the WIF SDK / FedUtil and enter the ADFS Server as existing STS I can find an error in the even Viewer (A token request was received for a relying party identified by the key 'https://localhost/wifdemo1', but the request could not be fulfilled because the key does not identify any known relying party trust).
I've added my demo app in ADFS as RP.
I've used a Self-Signed Certificate for the ADFS installation. I think something with the configuration of my ADFS is not Ok. Can someone please provide me some ideas what may be wrong?
Can you see the metadata at
https://yourserver/FederationMetadata/2007-06/FederationMetadata.xml?
Have you looked at the event log under "Application and Services Logs / AD FS 2.0 / Admin"?
To make sense of the reference number, look here: ADFS : There was a problem accessing the site - Reference number xxx
Double click the RP entry in ADFS and then look in the Identifier tab. That's the URL it expects. Is that how you configured the RP via FedUtil?
Related
I am able to get into SharePoint site using browser but not able to connect it using SSIS ODATA Connector. I have admin rights in that site. We have multiple imports successfully running using same SharePoint Server right now. Using SSDT2012. I tried another site successfully to confirm I don't have issue with SSDT. Any idea what I am missing.
Error msg:
TITLE: OData Connection Manager Editor
Test connection failed
ADDITIONAL INFORMATION:
The remote server returned an error: (401) Unauthorized. (System)
The logon attempt failed (System)
BUTTONS:
OK
What is the Service Document Location URL, you are giving in your case? Here is mine which works well.
Are you using basic authentication or Windows authentication?
If the former, double and triple-check that your userid and password are correct, and that the credentials have the proper access.
If the latter, check to see what user the package is running as. Also, I've found that when using Windows Authentication, you have to go back and double check what the Basic Authentication settings are, and zero them out before going back to Windows Authentication. It sounds crazy, but sometimes it works.
While accessing TFS Admin tool 2.1, it opens up the project but when i double click to provide access to users it give me error which says "An eeror occurred when connecting to reposting service for selected team project. To prevent any data corruption you will not be able to admistrate this project."
I check/restarted reporting service and analysis service, they running fine.
I am TFS admin.
I get same error for all the project.
What do i need to check?
I got the answer for this.. it was an IIS space related issue. my D: where my log sits were full. i deleted some old logs. viola! reports back on site. :)...
I am working on setting up my report server to use a web service as an XML datasource. I seem to be having authentication issues between the web service and the report with I choose to use Integrated security. Here's what I have:
1) I have a website w/ an exposed service. This website is configured to run ONLY on Integrated Security. This means that we have all other modes turned off AND Enabled anonymous access turned off under directory security.
2) Within the Web.config of the website, I have the authentication mode set to Windows.
3) I have the report datasource set to being an XML data source. I have the correct URL to the service and have it set to Windows Integrated Security. Since I am making a hop from the Browser to the Reporting Server to the Web Service, I wonder if I am having an issue w/ Kerberos, but I am not sure.
When I try to access the service, I get a 401 error.
Here are the IIS logs that I am generating:
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 0
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 5
Has anyone worked out this issue before? Thanks!
It does sound like you are experiencing the "double hop" issue. Is it possible to create an account on your web service that the reporting server uses explicitly instead of passing through the users credentials?
There's a simpler solution if you dont want to muck around with Kerberos... although the user experience is less desirable.
On the Data Source...If you check the "Credentials supplied by the user running the report" and the "Use as Windows credentials when connecting to the data source" then the user will be promoted to log in when they run the report. Since the credentials are being supplied to the SSRS server it's only a single hop from SSRS to the webservice... thus avoiding the double-hop NTLM authentication problem.
It's less user-friendly, though, since you have to log in to run the report.
I am building custom reports in Microsoft CRM and am using the CRM_URL parameter to created drill downs.
However, the URL coming in is ***http://**myserver.com/org/CRMReports...* but it should be **https://**myserver.com/org/CRMReports...
My understanding is that this value is dynamically passed in by MS CRM. How/where can I update this URL to use https?
you need to use the SRSS config tool. =>
Configuring a Report Server for Secure Sockets Layer (SSL) Connections (2005)
Configuring a Report Server for Secure Sockets Layer (SSL) Connections (2008)
"Edit UrlRoot in the RSReportServer.config File
If you are using the report server e-mail delivery extension, you can create subscriptions that included a report URL in the e-mail message. To construct the report URL, the report server uses the UrlRoot configuration setting in the RSReportServer.config file. If the report runs on a report server that is accessed through an SSL connection, you must manually edit the UrlRoot to use the https:// prefix.
If you are using a server certificate, the format of the URL is as follows:
<UrlRoot>https://certificatename/reportservervirtualdirectoryname</UrlRoot>
The answer to my issue was #4 & #5 from this link:
http://rc.crm.dynamics.com/rc/regcont/en_us/op/articles/secure_comm.aspx#ID0EFD
For deployments that will not be used
by external clients, which connect
over the Internet, follow these steps:
Obtain a certificate from a CA. To use certificates you will have set
up a public key infrastructure (PKI),
which consists of one or more CAs that
are linked in a hierarchy. These CAs
and the PKI are required to manage
certificate issuance, validation,
renewal, and revocation in one or more
organizations. You can use a
third-party PKI with Microsoft Windows
Server 2003, or you can establish your
own PKI, based on Windows Server 2003
Certificate Services.
Make sure that there are no users accessing Internet Information
Services (IIS) where the Microsoft
Dynamics CRM Web application is
installed. To do this, stop the
Microsoft Dynamics CRM Web site:
right-click the Web site, and then
click Stop.
Configure the Microsoft Dynamics CRM Web site to use SSL. To do this,
perform the following steps on the
server running IIS where the Microsoft
Dynamics CRM Web application is
installed:
1. Start Internet Information Services (IIS) Manager
2. Right-click the Microsoft Dynamics CRM Web site, and then click
Properties.
3. Click the Directory Security tab, click Server
Certificate, and then follow the
instructions in the Web Server
Certificate Wizard.
4. If you want clients to only use SSL when they connect to the
Microsoft Dynamics CRM application, on
the Directory Security tab in the
Secure communications area, click
Edit.
5. On the Secure Communications dialog box, click the
Require secure channel (SSL) check
box.
6. Close Internet Information Services (IIS) Manager.
Important: You can apply only a single certificate to the Microsoft
Dynamics CRM Web site. Therefore, you
if you have configured Microsoft
Dynamics CRM Server for both internal
and Internet-facing (external) access,
you cannot configure SSL for both
internal and external connections to
the Microsoft Dynamics CRM Web site.
You must manually modify the following values in the configuration
database.
Warning: Incorrectly modifying the configuration database
(MSCRM_CONFIG) can cause unexpected
behavior in the Microsoft Dynamics CRM
system or cause the system to stop
working. We recommend that you back up
the Microsoft Dynamics CRM system
before you complete these steps. For
information about how to back up the
Microsoft Dynamics CRM system, see the
Operating and Maintaining Guide that
is part of the Microsoft Dynamics CRM
4.0 Implementation Guide document set.
1. On the computer running Microsoft SQL Server, start SQL Server
Management Studio.
2. Expand Databases, expand MSCRM_CONFIG, expand Tables,
right-click dbo.DeploymentProperties,
and then click Open Table.
3. In the dbo.DeploymentProperties table under
the ColumnName column, in the
ADRootDomainScheme row, change the
NVarCharColumn column value from http
to https. Note that this value must be
in lower-case letters.
4. In the dbo.DeploymentProperties table, under
the ColumnName column, in the
ADSdkRootDomain row, change the
NVarCharColumn column value by using
the name of the certificate configured
for the Microsoft Dynamics CRM Web
site. The name of the certificate can
be found, in Internet Information
Services (IIS) Manager, on the
Directory Security tab of the
Microsoft Dynamics CRM Web site
properties page.
5. Click View Certificate.
6. On the Certificate dialog box, click Details.
7. Click the Friendly Name field to locate the certificate name.
If the certificate name is the same as
the computer name, you can use the
format ServerName:SSLPortNumber. By
default, the TCP port for SSL
connections is 443.
8. In the dbo.DeploymentProperties table, under
the ColumnName column, in the
ADWebApplicationRootDomain row, change
the NVarCharColumn column value by
using the name of the certificate
configured for the Microsoft Dynamics
CRM Web site. If the certificate name
is the same as the computer name, you
can use the format
ServerName:SSLPortNumber. By default,
the TCP port for SSL connections is
443.
9. Make sure your modifications are saved and then close
SQL Server Management Studio.
Modify the LocalSDKPort Windows registry subkey value. To do this,
complete the following steps.
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 and
Microsoft Dynamics CRM. We cannot
guarantee that these problems can be
solved. Modify the registry at your
own risk.
1. Start Registry Editor, and locate the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
subkey.
2. Right-click LocalSdkPort, click Modify, and then click OK.
3. In the Base area, click Decimal, and then type the TCP port.
4. Click OK.
5. Close Registry Editor.
Restart IIS. To do this, at the command line, run the iisreset
command.
Start the Microsoft Dynamics CRM Web site. To do this, right-click the
Microsoft Dynamics CRM Web site, and
then click Start.
Restart the Microsoft Dynamics CRM Asynchronous Processing Service.
To do this, click Start, point to
Administrative Tools, and then click
Services. In the list of services,
right-click Microsoft Dynamics CRM
Asynchronous Processing Service, and
then click Restart.
Verify that you can successfully connect to the Microsoft Dynamics CRM
Web site. To do this, you must use a
URL that begins with https. For
example, in Internet Explorer the URL
will appear similar to the following
address:
https://ServerName/OrganizationName/loader.aspx
If the Microsoft Dynamics CRM Web site is not configured to require
SSL connections, verify that you can
successfully connect to the site by
using an http connection, for example,
http://ServerName/OrganizationName/loader.aspx.
I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.