I am trying to install Master Data Service MSD on my local machine. Theorically there are 3 steps :
pre-installation tasks
Installation tasks
post-Installation tasks
During the pre-installation tasks we verify the installation requirements.
The Master Data Services web application needs some Windows Web Server roles and role services. Among these services we have the "Windows Authentication" (under Security).
The problem is that I did not find under security node Windows Authentication. Instead I find Basic Authentication.
My OS is Windows 10.
To install (add) the the desired roles I follow the theoritical instructions:
Control panel| Programs and features| turn Windows Featues on or off. I then expand Security under World Wide Web Services but there is no Windows authentication among the check boxes, there is only basic authentication.
Also when I open IIS and double click Authentication pane there are 4 Authentication (basic, anonymous,ASP.net impersonation and formular), so again, I don't find windows Authentication.
I read some suggestions on the internet telling that we can edit the applicationHost.config file. I find 2 file on different paths.
The location of the first one is: C:\Program Files (x86)\IIS Express\AppServer
and the second location is: C:\Windows\System32\inetsrv\config
In those files I replace <windowsAuthentication /> under
<security><authentication> node by :
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
and I also add <add name="WindowsAuthenticationModule" lockItem="true" /> under <system.webServer><modules>
I did this on the 2 files because I was not sure whether it should be done only on the latter one or not (iis and not iisexpess). But even with those changes it does not work and what surprise me is that when I open iis after editing file, I also don't find windows aythentication among the authentication list in Authentication pane. So I conclude that editing did not serve at all and make no change to IIS.
Of course because I failed to enable Windows Authentication when I open MDS (to do the installation step), I get a warning error telling that IIS is not configured correctly because windows authentication is not installed on this server.
You'll find here how to add it and after that you'll be able to use it:
https://weblogs.asp.net/zroiy/missing-windows-authentication-provider-for-iis-7-on-windows-server-2008
Related
So in order to use NuGet and other dev tools working inside my organisation we've had to set a system wide environment variable 'http_proxy' for each user in our user specific Environment variables.
Now, this works for everything we've tried so far, all package managers like NuGet, NPM, chocolatey, all work fine with external repositories.
Recently we've tried to set up an internal NuGet server on our build server to internally host common packages. Everyone can browse to the URL where the server is located: -ip-/nuget and we can see the XML feed. The issue comes when we try to use nuget.exe, or Visual Studio 2017 for connecting to this source, the requests to find packages all time-out after 100000ms which i guess is the default timeout.
We can also browse exactly to the URL that times out out in any browser with no issue. I'm assuming that this is something to do with our internal proxy trying to route traffic out of the network when it is actually internal, but i have no way of verifying that.
Is there anything we can try to see if we can get this resolved?
Is there anything we can try to see if we can get this resolved?
Since you can also browse exactly to the URL that times out out in any browser with no issue from your office system, there should be some internet limitations in your office environment. So I suggest you contact your office IT to confirm whether they add any limitations and whether used any proxy. If they are using some proxy, you need to set the proxy settings in NuGet.Config file which store in C:\Users\user name\AppData\Roaming\NuGet:
<configuration>
<config>
<add key="http_proxy" value="http://my.proxy.address:port" />
<add key="http_proxy.user" value="mydomain\myUserName" />
<add key="http_proxy.password" value="base64encodedHopefullyEncryptedPassword" />
</config>
</configuration>
Refer to this link for details: NuGet Behind Proxy
We have implemented the iT Hit server (v3.9) and Ajax library (v1.8.0.1342) and everything is fine with Word 2010 and 2013 and even Office for Mac:2011 but Word 2007 opens the document as read-only...we have tried using the information at http://www.webdavsystem.com/server/documentation/ms_office_read_only. We are using WebDAV.Client.DocManager.EditDocument(sFilename, "/ITHitMountOpenDocument.jar"); to open the document from a link on a web page. With 2007, there is not LOCK commands in the IIS log or in Fiddler...With 2010 and 2013, the LOCK command is in both...Also tried Webfldrs-KB907306-ENU.exe and updating the MSDAIPP.dll file. The client PC configuration is Windows 7 Professional SP1 (32bit), IE11 and Word 2007 (12.0.6715.5000) SP3 MSO (12.0.6683.5000).
The most typical cause of read-only issue with Microsoft Office 2007 is WebDAV server does not process requests on website root.
Microsoft Office 2007 and earlier may submit OPTIONS and PROPFIND
requests to site root (http://server/) and requires the server to
respond properly. If your WebDAV server is non-root (for example
http://server/dav/) Microsoft Office 2007 may open documents as
read-only.
If you are adding WebDAV to your project using 'Add WebDAV Server Implementation' wizard you will find the following code in your web.config file added by the wizard:
<system.webServer>
<handlers>
<add verb="OPTIONS,PROPFIND" path="*" type="WebApplication1.WebDAVServerImpl.DavHandler" name="My WebDAV Handler Root" preCondition="integratedMode" />
</handlers>
</system.webServer>
This enables WebDAV requests processing on site root in addition to your WebDAV folder (by default located in /DAV/ folder).
You can use Fiddler or any other HTTP debugging proxy to capture the request and see if there are any failed requests sent to site root.
EDIT: How to configure WebDAV server on root
As soon as WebDAV server is to large extent is a regular ASP.NET application, the configuration process is no different from configuring an ASP.NET web site on site root.
In short: Go to Sites node in IIS Manager and select Add Website in context menu. Fill-in the Site name in the Add Website dialog and select the application pool. In the Physical path field provide the path to the folder where your web.config file is located. Specify Binding options, such as hostname and port if necessary. Click OK.
You can find detailed instractions about how to configure WebDAV samples in WebDAV Server Examples section. The specifics of IIS configuration could be found in How to Configure Your WebDAV Server in IIS article.
Installation of Visual Studio local help (Books Online) fails with a 407 Proxy Authentication Required error.
The problem here is that if you are behind a not-terribly-friendly corporate firewall or proxy, you may have a hard time installing local help in Visual Studio 2013.
When I fired up the Help Viewer v2.1, I would initially see the list of help topics that might be installed. Instead I'd get a notification that errors had occurred. Drilling down into that, I'd see that our corporate proxy had handed back a 407 Proxy Authentication Required response asking for NTLM authentication. Apparently, the Help Viewer isn't smart enough to respond intelligently handle this ordinary HTTP response.
The question is: how to work around this problem, since getting the network gods to set up a more transparent proxy seems...unlikely.
The question, Visual Studio Error: (407: Proxy Authentication Required) (related, but not the same problem) helped lead me to the solution, as did this conversation:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/65c07e43-b652-496e-acbd-4d98861d527e/cannot-install-local-help-in-visual-studio-11?forum=vssetup
There are, apparently, 3 different processes involved in getting help installed for VS 2013:
The Microsoft Help Viewer (HlpViewer.exe)
The Microsoft Help Content Manager (HlpCtntMgr.exe)
The BITS service (Background Intelligent Transfer Service)
The above threads will lead you to monkeying with the config file for the help viewr, but that's insufficient to fix the problem. You will need to do the following:
Navigate to the help viewer's install directory (default location is C:\Program Files (x86)\Microsoft Help Viewer\v2.1).
Create or edit the file HlpViewer.exe.config so that it has a <system.net> element that looks like this:
<?xml version="1.0"?>
<configuration>
<system.net>
<settings>
<ipv6 enabled="true"/>
</settings>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
bypassonlocal="True"
proxyaddress="http://your-proxy-server:80/"
/>
</defaultProxy>
</system.net>
</configuration>
Depending on the vagaries of your proxy configuration, you might or might not need the <proxy> element.
Do the same for HlpCtntMgr.exe.config.
BITS (Background Intelligent Transfer Service) has a configuration value, UseLmCompat that tells it when to send NTLM authentication credentials. From the documentation,
The registry value is a DWORD. The following table lists the possible values for
UseLMCompat:
Value Description
----- -----------
0 BITS will send implicit credentials whenever the server prompts
for NTLM or Kerberos credentials.
1 BITS will send implicit credentials only if the client computer's
LMCompatibilityLevel registry value is greater than or equal to 2.
Prior to BITS 1.5: Not supported
2 BITS will send implicit credentials only if the application called
the SetCredentials method.
Prior to BITS 2.0: Not supported
The default cofiguration appears to be 2. You'll probably need to modify that in
the registry at
HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/BITS/UseLmCompat
where you'll want that value to be 0, so it will provide credentials on request.
NOTE: Since Microsoft, in its infinite wisdom, has blessed us with, not one, but two registries (32-bit and 64-bit), you'll need to make the above change twice, using the appropriate instances of regedit.exe located at
32-bit: C:\Windows\regedit.exe
64-bit: C:\Windows\SysWOW64\regedit.exe
Having done that, you'll need to bounce BITS. You can do that by rebooting your machine, or via the Services control panel (services.msc), where it's listed under the name Background Intelligent Transfer Service.
At this point, you should be good to go.
What are the pro's and con's of using the built in App Pool Identity in IIS as opposed to specifying a Windows account?
For SQL Server if you want to connect from a .Net application using Windows Authentication I presume that if I use an App Pool Identity, I must associate this with a user in SQL Server or give that App Pool Identity access to by db?
Are App Pool Identities just added as convenience so that you dont have to set up accounts for your App Pools?
The built in account used is specific to the computer. If applications inside the app pool need to connect to other resources on the network (database servers, file shares, etc) then using a (windows) domain account may be a better option. When you specify a domain account you must ensure they have the correct file permissions set on the physical folders that IIS is using. In later operating systems - you can add this account to the IIS_IUSRS group to achieve the default permissions.
We have several application running on our intranet that use windows authentication. The way we handle this in our web.config is to specify our SQL connection string as follows:
<connectionStrings>
<add name="ConnectionStringName" connectionString="Data Source=ServerName;Initial Catalog=DatabaseName;Trusted_Connection=true" providerName="System.Data.SqlClient"/>
</connectionStrings>
Also in the web.config is the following:
<system.web>
<authentication mode="Windows"/>
<identity impersonate="true" username="Domain\Username" password="password"/>
</system.web>
Using a domain account allows you to manage the account in the same way you manage other users accounts. Down side here is that the username and password are included in plain text in the web config.
Hope this helps.
What I am doing
I am building an MVC2 website with Windows Authentication using Visual Studio 2010. I want to debug the website using IIS7 and access it from a browser in a virtual machine (in order to sign in using different users with different privileges).
Problem
When I try to access my website from my virtual machine, I get the following error:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Environment
I have visual Studio 2010 set to debug using IIS and to "Don't open a page. Wait for a request from an external application." I have created www.myWebsite.com in IIS7 on my host machine and have only Windows Authentication enabled.
I have made appropriate entries in the hosts file on both the virtual machine and my host machine so that when I type www.mywebsite.com into the browser on my virtual machine, it targets my website I set up on IIS7.
I tested my IIS7 setup process by using the same settings to set up an html website (with the same web.config security settings) and I could access that from my virtual machine. For this reason I think the problem has something to do with my application. IIS7 is set up to use .net 4.0 and Integrated Pipeline Mode.
Code
Here is my web.config file:
connectionString="metadata=res:///Models.ReportDB.csdl|res:///Models.ReportDB.ssdl|
res://*/Models.ReportDB.msl;provider=System.Data.SqlClient;provider connection string="Data Source=JDOE-
PC;Initial Catalog=ADVENTUREWORKSDB;Integrated Security=True;MultipleActiveResultSets=True""
providerName="System.Data.EntityClient" />
res:///Models.WDB.ssdl|res:///Models.WDB.msl;provider=System.Data.SqlClient;provider connection
string="Data Source=JDOE-PC;Initial Catalog=WarehouseDB;Integrated
Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
PublicKeyToken=31BF3856AD364E35" />
PublicKeyToken=31BF3856AD364E35" />
PublicKeyToken=31BF3856AD364E35" />
PublicKeyToken=b77a5c561934e089" />
type="System.Web.Security.WindowsTokenRoleProvider"/>
type="System.Web.Security.WindowsTokenRoleProvider"/>
type="System.Web.Security.WindowsTokenRoleProvider" />
I started over and everything has been working fine. I'm curious what the problem is, but with all the settings I was messing with (was doing a lot of experimenting as this was my first MVC project) I probably hosed something.
I don't think I have enough information to really solve the problem, so I will close this question.