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.
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
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.
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 a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn
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.