I have a requirement, that the SharePoint portal of our company should be made accessible from internet, as in
once URL is entered in the browser, it should ask for credentials- once entered, should display the homepage of the portal.
Provided it should be accessible from the current intranet also.
It is in windows authentication mode currently.
Disclaimer: This question would be more appropriate in a forum like SuperUser or Sharepoint StackExchange. I am not a system administrator so my answer will lack detail and probably wont be optimal.
The only thing you need to provide is access from an external interface to your network. So something that routes requests from outside of your network to your sharepoint instance.
This is usually achieved through a reverse proxy and proper configuration of DNS. You can setup a reverse proxy by different means, if your organisation uses the Microsoft Stack then I suggest setting up IIS as a reverse proxy to your Sharepoint Instance. There are multiple tutorials on how to do this on the web.
http://sahelp.sharepointforall.com/FAQ/bconfigure_IIS.html
You then need to add an entry to your organisation DNS hosting something like sharepoint.organisation.com that points to your external interface (public IP) where the reverse proxy is sitting.
You will then need to add an Alternate Access Mapping to your Sharepoint WebApplication so Sharepoint can route the requests that the proxy sends to the appropriate Webapplication.
http://blog.blksthl.com/2012/12/03/a-guide-to-alternate-access-mappings-basics-in-sharepoint-2013/
If you are using basic authentication make sure you enable SSL. this can be done in several ways but a possible and easy (but not the most secure) is to enable SSL just externally and then use a normal unencrypted channel on the inside of your network, this is probably the easiest setup but again not very secure as people inside the newtork can snoop comms between the proxy and the sharepoint instance.
Related
I am currently building a custom cms system with the MEAN stack. I also want to have a backend web based admin panel for it, but I also want it to be as secure as possible. In the past, when I've build php-based scripts, I simply made a /admin route where the user would be presented with a login page and then allowed to proceed to use administration functions on the cms. However, by analysing my web server access logs, I've noticed a lot of requests to common admin routes such as /wp-admin or /administration and even my own /admin route from wannabe hackers, even when those websites did not have lots of traffic.
I've been thinking of using a different approach this time, specifically setting up a separate node app for administration purposes and putting it on a completely different port (i.e. 2123) and then setting up the server's firewall to only allow certain ip blocks to access that port. This way, even if the attacker does a portscan on my webserver, they would only be able to see the default ports 80 and 443. Would this be a good solution to secure my app or are there any better approaches?
Serving the admin interface from a different origin (origin being protocol+domain+port together) is indeed the best practice. One reason is what you mentioned, you can implement separate network level protection, for example you can restrict clients by their IP addresses.
Another reason is because this way, base app and the admin app will be separated in browsers by the same origin policy. Coming from different origins, they will not share cookies (session), broswer stores (localStorage, etc.) will be separate and so on. For example, if these two apps were on the same protocol, domain and port, one single XSS in the base app could be exploited to gain access to admin data or functionality - this is not the case with different origins.
Setup a VPN and make remote users connect with the VPN, and only allow local network access to the admin panel
Or put a WAF like modsecurity in front of your web server
Your IP restriction idea isn't a bad one though
I have a mobile application that communicates with a REST based web-service. The web-service lives behind the firewall and talks to other systems. Currently this web-service requires a firewall port to be opened and a SSL cert generated for each installation. Mobile apps sends login credentials so web-services can login to custom back-end systems.
Recently a customer approached us asking how could we deploy this to 50 offices. As we don't want to say modify every firewall in every office, we're looking for options.. This is a list of possible solutions and my thoughts on each one:
Open firewall port and expose https webservice - This is our current
solution but we dont want to have to contact 50 network admins and explain why we need to do this.
VPN - Too heavy weight, complex and expensive, we only need access
to one server. Does not solve problem as firewall needs to be
modified.
Microsoft Azure Hybrid Connection Manager - This provides a managed
service where the Azure cloud will expose an end point. Azure will
also expect connections from a easy to install application that
lives behind the firewall. When a REST call is made to the cloud
end-point, the request is forward down socket that was initiated by
the software behind the firewall. This does what we want but as its
a Microsoft Solution there might impose other requirements that our
customers might not want. Currently the simple Hybrid Connection Manager is free. But for how long?
Jscape MFT Gateway - Similar to Azure but you can host their server anywhere. Not that expensive but is not opensource.
Netty - A async java library/toolkit where this type of application could easily be build. Client and server apps would need to be build and deployed. Dont know what we dont know about Netty.
MDM, AirWatch, BlackBerry BES - A MDM based solution would work expect that MDM's are centrally managed and are not often in every office where the backend services are located. Airwatch has an AppTunnle but im not sure about the specifics.
At this point the Microsoft and Jscape systems are possible solutions.
But most likely these solutions will require us to modify the mobile software to work around issues such as:
How does the user know which server to login to? A locator service
needs to be built such that, an email address is used to lookup their
office, or they need to select their office location from a list.
While the connection is SSL many company might want some additional protection since network login information will be send down the pipe.
How is load balancing and fail-over managed?
So, at this point i'm looking for more options. The best option would be a commercial product that offers some level of customization. Second, would like a well used open-source product that could be installed in Aws and customized.
Thanks
The best approach we found was to use the PUTTY API and setup a reverse proxy.
I have Sharepoint on the cloud and I can access it from anywhere, except home. At home I have a ClearOS and I can´t go through to my Sharepoint Portal.
I guess that I may need to open some ports, right? Whic ports?
Port 80. SharePoint runs as a normal website, unless you're trying to access Central Admin or using SharePoint Designer.
You shouldn't need to explicitly open port 80, especially if you can access other websites.
You should post more info about any errors you are getting.
Likely you need to have your Sharepoint site bypassed in the proxy server settings section. Sharepoint can use proprietary bits (ikr? Microsoft doing something proprietary?) that get borked when passing through the proxy or content filter.
If you list the site(s) in the Web Proxy module (bypass section at the bottom) it will create appropriate firewall rules that will skip over using the proxy and content filter for that site.
Cheers.
We have been running WSS 3.0 for our intranet. We are going to be moving our internet site to WSS 3.0. The vast majority of people will access the new internet site anonymously. My question is in regards to the few people who will need to authenticate so that they can access intranet material from the internet.
We are going to host the intranet and internet sites on the same server. WSS 3.0 has already been installed, updated, and configured for our intranet. What would be the best way to set up the internet site collection so that it can be accessed anonymously but also so that when a user authenticates they can access intranet content as well? Currently the only way to access the intranet is to be on the companies domain with credentials that have access to it. What we would like to do, if possible, is use the login form that is built into WSS to make access to intranet content available opposed to setting up a sub domain.
You may use SharePoint alternte mapping feature as described in this article.
Configuring Multiple Authentication Mechanisms with Alternate Access Mappings in Windows SharePoint Services 3.0
I'm assuming that your Internet site collection and intranet site collection are not the same site collection with what I'm about to write. I am assuming, however, that they are housed in the same web application. If that's the case (and I understand enough of the specifics), here's how you'd carry out what you're trying to do:
Establish a Web application to house your site collections. You've already taken care of this (since you have your site collections available to you internally). In setting up a Web application, it (by default) is exposed at a URL (or server:port) through the Default zone mapping. For our purposes here, we'll assume that this is the URL through which you want to access the site internally (on your Intranet).
In order to expose your site collections via the Internet, you're going to want to extend the Web Application housing them. This is done through Central Admininstration > Application Management > Create or Extend Web Application. In extending the Web Application, you're creating another IIS site with (ideally) a publicly-accessible URL that can be exposed to the Internet. You'll be asked to pick a zone as part of the process; given your needs, I'd go with "Internet."
At this point, the Internet zone (you just extended) is still setup to use Windows authentication and Active Directory as it's membership provider. Though you probably want to keep AD as a membership provider (based on what you've stated), you'll probably want to look at enabling Forms-Based Authentication (FBA) on your Internet zone. Microsoft has a video on that here: http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd355701.aspx. Note: you won't want to use the SQL membership provider if you intend to continue using Active Directory accounts. Instead, you'll have to wire-in the Active Directory Membership Provider for FBA. Some info on that can be found here: http://blogs.msdn.com/solutions/archive/2007/08/27/forms-based-authentication-fba-in-wss-3-0-moss-2007.aspx.
At this point, your Default zone site should use NTLM and an intranet-available URL. Your Internet zone site should use FBA and have an Internet-available URL. You'll need to enable anonymous access on your public site collection for the Internet zone. This is done through a combination of Central Administration changes and changes from within the site collection itself (http://www.mindsharpblogs.com/ben/archive/2007/02/11/1557.aspx). Important point: when going into the site collection to enable anonymous access, be sure to go through the Internet URL; don't go through the default zone (i.e., the intranet zone).
With all of these things in-place and your site collections (or more specifically, the IIS site servicing the Internet zone Web application) wired-up to the outside world, you should be good to go.
I made a number of assumptions as I wrote this, so you may (obviously) need to adjust. Setting up anonymous access isn't overly hard, but there are a lot of steps to it. If you hit hiccups along the way, don't be afraid to search for answers. Many folks have done it successfully ... but more often than not, there are challenges along the way.
Good luck!
You can also create a web application for your intranet use, so user's who are in the domain get access through an internal URL authenticated, and then extend that web application for the extranet application for anonymous users....
I'm using IIS in Windows 2003 Server for a SharePoint intranet. External incoming requests will be using the host header portal.mycompany.com and be forced to use SSL.
I was wondering if there's a way to set up an alternate host header such as http://internalportal/ which only accepts requests from the internal network, but doesn't force the users to use SSL.
Any recommendations for how to set this up?
Daniel, keep in mind that just because something is possbile in IIS, and via any number of off box solutions (like hardware load balancers and SSL) doesn't mean that it is supported by SharePoint, or that it is implemented in the same way.
You can do what you are asking for, however you should do it via SharePoint Central Administration, and "Create or Extend a Web Application" and then "Extend and Existing Application".
In this way you can create a new web site (in IIS) for accessing your existing SharePoint Web Application, one that can be accessed via a different hostheader, port, using SSL, Authentication mechanism, etc.
As a general rule, if you can do something in IIS AND in SharePoint, you should do it only in SharePoint.
Assuming that http://internalportal/ wasn't accessible from outside the company, you could set up two websites in IIS. The first site, configured to use a host header value of 'portal.mycompany.com', would require SSL. The second site, configured to use a host header value of 'internalportal', would not require SSL. The host header value is configured under 'Web Site' -> 'Advanced'.
Having a hardware load balancer makes things much easier. The site on the load balancer is set up to require SSL, and your websites in IIS are setup not to require SSL.
You could just add a second host header and internal IP address to the site for internal non-ssl access
172.16.3.1:443:portal.mycompany.com
172.16.3.2:80:internalportal