Having an issue with users of one domain from viewing a website being hosting on another domain. Both domains are internal, domain1.local & domain2.local.
The website hostname is webapp.domain1.local. It is being hosted on a server webserver.domain2.local. When i view the site off the "Default Web Site" as a sub-webapp, it renders correctly when a user, domain2\user, is accessing the "Default Web Site" it renders correctly. But if the same user were to access the webapp web site, with hostname webapp.domain.local, there is an access denied.
Default Web Site:
Hostname: localhost default for IIS 7.
webapp Web Site:
Hostname: webapp.domain1.local
Both IIS 7 websites having a webapplication named webapp.
According to our Network Administrator, there is an existing passthrough communication handle but seems to be quirky on what gets passed through.
Background
Over the last 5-7 years the company has been absorbing other smaller companies and during this time absorbed a company as big as them and hence the two domains. We are currently in the process of migrating to domain1.local but its taking time cause of the sheer size of domain2.local.
Its hard to say without Event Viewer and/or IIS logs from the troublesome server (in either direction) however it looks to me like passthrough is probably doing what it should and denying access because the users are not allowed to authenticate.
I would say your looking at setting up cross domain authentication in its entity e.g. file shares from one domain to another how does that work? If the problem is more wide spread then really your looking at setting up a domain trust relationship between Domain1 and Domain2 (http://technet.microsoft.com/en-gb/library/cc739693(v=ws.10).aspx) either this or allow anonymous access to the website but its not exactly secure :)
Any questions let me know.
Charles
Related
i have a live web app on azure with settings
with several host-names assigned to the site as below
As a change of requirements , i want the domain.net to be the parent domain where the root directory of my app points to, and not domian.co.uk
basically as shown below
As this is a live website, i want to achieve this with minimum downtime.
As you have added more than one custom domains to your web app, all the domains can be used to access your website, even only one is shown in the overview page.
If you want to use only one custom domain, you can remove the others. Or you can set a redirect rule for other domains at the DNS.
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.
I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.
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