I deployed my MVC 4 application on Azure, installed own CA, create self-signed certificate and certificate for server (https working good). How can I activate require client certificates signed by my CA and working only with it?
The two viable options you have, you already described in your comments.
One is to use Azure VM and IIS (I don't like it) - there you know what to do.
The other one is to use a Web Role (Cloud Service) and do the things described in the link you refer to. I advise you to take the Web Role path.
Or third option, is to wait until (if ever) Windows Azure Web Sites to unlock the required property in application host config. Check this SO question and it's answer on what you need to do in your web.config in order to achieve your goal. The catch is that access section under system.webServer/security is locked at application host config level, and can only be unlocked when you have Azure Web Role.
Just fyi, here is a list of overridable sections in your web.config when you use Azure Web Sites.
Related
I have the following scenario:
(Client/Browser) => (Web Service/Web API) => (SharePoint REST-Api).
Basically what I want to achive is to have the middle application (WebService/Web API) to act as a facade infront of the SharePoint-REST-API to ease the development for anybody that needs to communicate with our SharePoint-application. (Basically we wrap a few SharePoint-request-calls into one single call in the Web API/Facade).
Now the problem is that I also want to be able to send the logged in Windows user (AD-user) from the Client to the Web Service, and then the web service should act on behalf of that Windows user and perform whatever actions needed in the SharePoint REST-API (this is to make sure that permissions to files and so on are actually set based on the authenticated user).
What we have tried so far is setting uo the Web Service on one server, and SharePoint on a different server.. and then we have tried to setup authentication using Kerberos and delegation, but we could not get this working.
Based on the information I have provided, do you guys think that a "double hop" like this would work if we manage to get Kerberos setup properly?
Another thought that hit me is that maybe we dont have to host the Web Service and the SharePoint applications in two different servers, but we could actually host them both on the same server within one single IIS-server with two sites.
Would this still require Kerberos to be setup with a double hop? Or does a "hop" only count once the ticket actually leaves one server to another.. cause in the case described here, the request from the Web Service to the SharePoint-REST-API would never leave the actual server, but it might cross domains (as in web-domains.. not AD-domains).
Could this work, instead of having to hassle with Kerberos double hop, SPNs and what not..?
when you use integrated authentication, anonymous is disabled at that time and impersonate is enabled.so security settings will not allow your site to access resources on any network servers.
When you authenticate to the IIS server using Integrated Authentication, that uses up your first 'hop'. When IIS tries to access a network device, that would be the double or second hop which is not allowed. iis will not pass those credential to the next network device.
if you use anonymous enable and impersonate off this issue will not occur.
to configure Kerberos Authentication in iis you could follow the below steps:
1)open iis manager and select site.
2)select the authentication feature from the middle pane.
3)enable windows authentication and disable anonymous.
4)With Windows Authentication, click on the Providers from the Action pane.
5)set the provider in below manner:
Negotiate
NTLM
save the changes.
6)go back and select the configuration editor.
from section dropdown select system.webServer/security/authentication/windowsAuthentication.
“useAppPoolCredentials” set to true.
"useKernelMode" to "True" and save the settings.
7)restart the iis.
8)Configure SPNs
open the command prompt as administrator and run below command to check the machine name:
hostname
When you have a custom hostname and you want to register it to a domain account, you need to create a SPN a below.
setspn -a HOST/${FQDN_HOST} ${MACHINE_NAME}
setspn -a http/${FQDN_HOST} ${MACHINE_NAME}
9)after doing that set application pool identity to the custom account and set the username and password.
You could refer this below article for more detailed information:
https://weblogs.asp.net/owscott/iis-windows-authentication-and-the-double-hop-issue
https://active-directory-wp.com/docs/Networking/Single_Sign_On/SSO_with_IIS_on_Windows.html
https://techcommunity.microsoft.com/t5/IIS-Support-Blog/Setting-up-Kerberos-Authentication-for-a-Website-in-IIS/ba-p/324644
We want to switch our ASP.NET MVC application from Azure Cloud Service to Azure App Service (web app). The application is currently using WIF as its identity framework, and as it is running in a farm configuration, we configured a custom SessionSecurityTokenHandler which encrypts the session cookie using a certificate (thus the cookie can be decrypted by all instances of the web farm).
We could provision this certificate in the Cloud Service scenario using the csdef/cscfg files and the built-in Azure certificate store associated with the Cloud Service, but there is no such thing with Azure App Services (unless I missed something).
Is there any way to configure a certificate in the App Service? Should we fall back to another mechanism to encrypt the session cookie, such as a shared machine key? The machine key is not an ideal solution as it forces us to leave some configuration out of source control to avoid leaking the key.
Using the Azure portal (https://portal.azure.com), open the web app blade for your web app and click on the Settings button in the toolbar.
In the Settings blade, click on Custom domains and SSL. In the Custom domains and SSL blade click on the Upload Certificate button in the toolbar. This will open a blade where you can upload the certificate.
In the web app settings blade, you will need to add an app settings using the key WEBSITE_LOAD_CERTIFICATES. You can set the value to * to load all certificates or if you want to specify a specific certificate you could do that.
From there, you can use the certificate like you would in your cloud service version of the application. Some additional information on this and how to use the certificate in code is available here if you need it.
Finally, to Michael B's point in the comments, using Azure Key Vault would be another approach you could take and would provide some additional security.
I have an existing VS2010 ASP.NET webforms site that I am trying to get running on Azure as a POC for a client.
I migrated the site to a VS2012 project, added an Azure Cloud Service Project, and have deployed the site as well as the back end DB to a 3 month trial account.
I've added the IP address of my dev machine to the firewall rules for the Azure db, and I can run the project locally and connect to the Azure db without incident.
On the firewall rules for the website, I have Windows Azure Services set to yes under Allowed services. I have no other rules in place other than the one for my dev machine.
When trying to access the site from the site deployed to Azure, I get the following exception:
Cannot open server requested by the login. Client with IP address '137.135.65.13' is not allowed to access the server.
To enable access, use the SQL Azure Portal or run sp_set_firewall_rule
on the master database to create a firewall rule for this IP address
or address range. It may take up to five minutes for this change to
take effect.
Login failed for user .
This session has been assigned a tracing ID of . Provide this tracing ID to customer support when you need assistance.
The site works normally if I add a firewall rule for the azure server IP address, but doesn't this defeat the whole purpose of Azure? Shouldn't allowing Azure services handle this? Is there an additional config item necessary or am I missing something basic in the design? I'm not sure if this is related but the site was deployed by VS2012 as a cloud service instead of a website, is this the issue? I also added the db as a linked resource in the cloud service but that didn't seem to have any effect.
Adding the DB as a linked resource for the WebSite will fix the problem w/out having to muck about with firewall settings.
Go to your website in m.anage.windowsazure.com.
Go to the LINKED RESOURCES tab.
Press the LINK button on the bottom of the page
Select your DB from the modal dialog
This is a bug in Azure. Newer IP ranges aren't included in their boiler plate "Azure Services" configuration, or something like that.
Been happening for a long time (at least ~3 years), unfortunately.
Happens with Web Roles, Worker Roles, and VMs as well - NOT specific to Web Sites. We regularly hit this with our Web and Worker Roles in US East but never saw it once in US North.
Our work-around is to add the range: 10.0.0.0-10.255.255.255. Probably not the most secure work-around but fortunately, this has so far only hit our Dev environments and not any of our Production environments.
I have an ASP.NET app. I plan to run several instances of this app on the same server.
Each instance has its own domain, like www.app1.com and www.app2.com.
Each app instance has its own Admin area, that should be SSL protected. You can't install multiple SSL certs on the same machine and port number, so using https://www.app1.com/admin and https://www.app2.com/admin is a no-go.
I would then like to do the following:
Use my appname domain: www.appname.com with an SSL cert, and add an Application to that website in IIS for each client domain I have:
https://www.appname.com/app1/admin & https://www.appname.com/app2/admin.
But that would isolate session state between www.app1.com and https://www.appname.com/app1/admin - even though, they use the same Application Pool in IIS 7.
Is there a way to work around this?
One way I've seen to share session state across different ASP.NET applications is to use one of the other options for storing session state information. Unfortunately I don't have access to IIS 7 at the moment, but assuming it is similar, here's how you configure it in IIS 6:
IIS Management Console
Bring up properties for the applicable virtual directory
ASP.NET tab -> Edit Configuration
State Management tab
The "Session state mode" defaults to InProc, but you can change it for your various application "instances" to use the same SQL Server database.
You can use multiple SSL certificates on the same machine, they just need dedicated IP addresses.
Just a heads up, you don't necessarily need multiple IPs on your server to install multiple domain SSL certificates on a Windows Server in IIS 7. You just need to add them from the command line.
I got a UCC Standard SSL Multiple Domain certificate from GoDaddy and then just added all the domain names I needed to it. You basically just install it to one of the domains that you want and then share it between the others via the command line. My guess is that this is not a best practice for all situations, but it does solve your problem without forcing you to share the secure parts of the app.
Check out this link for directions:
http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html
btw - the admin on each domain name will have to approve it. If the domain names on it ever change, it will invalidate the certificate in all your sites from IIS and all the admins will have to re-authorize the changes.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.