Is it possible to use Active Directory Certificate Authentication per site basis?
If I enable Active Directory Certificate Authentication for whole server (is possible with IIS Manager) it works perfectly. But I cannot find how to do per site basis - Active Directory Certificate Authentication is not listed in Authentication section for concrete sites - and if I ry to do it directly from XML config, it doesn't work.
I quite need this, because I have multiple sites, some with iisClientAuthenticationMapping and some with Active Directory Certificate Authentication (ClientAuthenticationMapping).
I found out solution for this. It indeed is possible. You just have to enable clientCertificateMappingAuthentication for whole server and disable it on per site basis. The other way (enabling it just where I need it) doesn't work.
Related
Using Alfresco Community - 7.1.0, running on a Docker Swarm cluster with Portainer.
I have managed to set up an instance of Alfresco with SSO using Kerberos with an Active Directory server as KDC (with AD users synched through LDAP). All I did was follow the instructions in the Alfresco documentation, so I don't know enough about Kerberos to understand how and why it works.
Right now Alfresco is accessed through a single URL which has the same domain as the AD server (which is also the domain controller). For annoying reasons that I won't go into right now, I need to make this Alfresco accessible through 2 separate external URLs, both of which have
different domains from the AD server.
Do I need to have more than 1 Kerberos realm, or is there a 1 to 1 association between realms and KDCs?
Do I need to map from the internet domain names to the Kerberos realm?
For some reason I'm having a hard time getting my head around this Kerberos stuff...
Alfresco expects only one REALM.
You need to create for every expected url a separate SPN and put all of them into the one keytab for Alfresco.
At least Windows needs to be configured to trust the other domains for SSO/kerberos authentication by putting them into the intranet zone.
I’m building a web application where users can create their own websites. Users have the option to point their own domain names at these sites. A prototype for the application already exists; Apache accepts requests on all hostnames and the actual domain mapping and resolution happen at the application level (a simple database lookup grabs the site that matches the requested hostname).
Where I’m stuck is how users’ SSL certificates might fit into this equation. What steps would I need to take to allow a user to upload their SSL certificate such that the application could successfully handle secure HTTP requests to their hostname? Is this even something the application alone could handle?
I think you cannot handle this in your application alone.
It's a CA problem, except you are an intermediate CA company, or you cannot get the user's domain SSL certificate and sign for user's domain.
The typical user, and IMHO even more the user's who are going to create a web site of this system as opposed to setting up their own WordPress or other site on their own server (or their own paid shared server hosting account), will have absolutely no idea how to setup a proper SSL certificate, so getting it to your securely so that you can install it wouldn't even be an issue because they will never get that far.
However, you should be able to use Let's Encrypt to do exactly what you need. As part of the process of adding a domain, once the domain is pointing to your server (the users will have to figure out how to do that with their domain registrar), you can create a Let's Encrypt certificate and validate it. My favorite web hosting company (I won't name it as that is not relevant - anyone can do this with some effort) provides this capability as part of their Control Panel. They also provide paid certificates with a few of the big issuers, as they have for many years, but for most small sites Let's Encrypt works very well and is totally free. The setup literally takes only a minute. The key is that you have to give the user an IP address or CNAME first so that they can point the domain. Once the domain is resolving to your server, you can get the Let's Encrypt certificate.
Is there a (new) way to configure which fields should be logged by IIS in Azure (Web Role / Website)? For example, I don't want the server ip or the http referrer to be logged.
I only found an older post describing two approaches:
programmatically set site.LogFile.LogExtFileFlags in the web bole entry point (this requires the web role to be run in elevated mode);
running an appcmd-based script (did not work - infinite wait, sites were never ready :P, perhaps the set-up sequence had changed in the meantime).
You can also do this using your web.config file.
See: http://www.iis.net/configreference/system.webserver/httplogging
For Azure Websites (Web apps) you cannot configure IIS logging fields.
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.
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.