We are having some issues getting SharePoint to work as we want it to.
We have an enterprise MOSS configuration on our domain and have the entry http://intranet pointing to it on port 80.
We also have another site collection and have pointed an internet domain name http:/nww.oursector.nhs.uk at it. We have done this to allow those outside our domain but on the same physical network to view it. Our network admin hasd configured the firewall to redirect any requests to this url to our sharepoint server.
The problem with this is that we have had to turn on anonymous access otherwise SharePoint sees this url as external and blocks authenticated access to the site. This means that all users need to manually sign in to the site, which is making working with SharePoint quite problematic.
Is there a way to configure SharePoint to allow the url http:/nww.oursector.nhs.uk to access the site collection without having anonymous access turned on for the site? I want users to be able to browse to the site and if authenticated then fine, if not then prompt them to login.
Can anyone suggest a way to achieve this?
I would say you need to use SharePoint's alternate access mapping to use the correct authentication type depending on the method users are using to access the website.
Basically i think this would work as follows for your situation:
For internal users, use the default zone, using NTLM with SSO configured.
Thus users should be signed in transparently without requiring to login.
For external users, extend the web application, using the extranet zone, using anonymous access.
This will allow external users, to browse the website without signing on.
See:
http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx
Related
I have an IIS website on a server internal to my domain that is also published via azure application proxy, which is secured using windows authentication. Our AD structure is hosted locally and published to Azure AD via AD connect.
Users visiting from outside the domain are authenticated first via the login.microsoftonline.com page.
My problem is that users external to the domain are on shared devices and need to change users occasionally, and I can't figure out how to do that.
I have read that navigating to an url like https://login.microsoftonline.com/{tenant id}/oauth2/logout?client_id={client id}&post_logout_redirect_uri={???} is supposed to achieve this, but after arriving at the login page and logging in as a different user, when we return to the site the user turns out not to be the user that authenticated, but remains the same user as before the attempt to change the user.
I have also read that deleting the cookies named like AzureAppProxyUserSessionCookie, AzureAppProxyAnalyticCookie and AzureAppProxyAccessCookie can help, but doing so does not seem to make any difference.
I thought that perhaps the browser was auto-authenticating or pre filling in forms etc, but turning those features off does not affect anything.
My questions are:
Are any log-off / log-on via Azure AD event logs kept that I can view, and if so, where?
How are you meant to log-off for my scenario?
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).
A developer posts their code from a staging site (which requires authentication) to the live public site (which should not) and suddenly the live site is requiring authentication (which is not good).
They don't have permissions to change any settings on the server(s) and there is no call from the code on the live site to anything on the staging site, that I can locate. (No forgotten calls to an image on the staging site or anything)
Can the group think of some file that might have been removed/changed that could cause this to happen? I checked this question as well - [HTTP Authentication in ASP Classic via IIS] - but none of those methods are being used.
App is Classic ASP, IIS6.0 server.
Security Settings - Anonymous Access permitted on the live site. Account for anonymous internet users allowed read access to the directory where the site is located - user is unable to change directory or site permissions on the server.
Thanks!
Did the files retain their security permissions from the folder they were copied from? Reset the permissions on the files.
Are you using a four-part URL to get to the site (http://www.somesite.com/)? That will default to the Internet zone and not intranet, prompting for authentication.
User will get challenged when Anonymous Access is turned off in IIS. What are the security settings? Without that information, we will not be able to help much.
Is it possible to access a sharepoint web service without authenication? If you can't do it directley can you think of any ways to get round it such as haveing an open service inbetween that does authenicate for you using a public account.
John,
The security model of the web application through which you're trying to access the web service in question is going to drive whether or not you can access the service anonymously. If you're attempting to access the web service through a web application on which anonymous access is enabled, then you'll be able to hit the web service. Go ahead and try this on an anonymous site (if you have one): http://yoursitehere/_vti_bin/lists.asmx. You'll get the friendly service page back, no auth required.
Here's the catch: once you traverse the web service layer, you've got another layer of security to deal with. SharePoint itself is going to want to check permissions for access via the web services just as it normally would, so unless you are attempting an operation or trying to access data that is allowed for anonymous users, you're going to get blocked.
You have a handful of options:
Simply ensure that everything you're trying to do is permitted anonymously. This may sound easy, but it can actually be pretty difficult for anything but the simplest and straightforward of operations. Most organizations, too, don't care for opening things up to this extent.
If you control the code that's calling the web service, then you have the ability to attach credentials to the web service request. I recommend starting here, as it is going to make things a lot easier than trying to throw everything wide open. Plenty of examples exist on attaching credentials to a web service proxy (e.g., http://msdn.microsoft.com/en-us/security/cc178918.aspx)
Finally, you could write your own web service that wraps the SharePoint web service (or services) of interest. You could permit anonymous access to your web service and then adopt an appropriate security context within your own service to access SharePoint with the required permissions level.
I hope this helps!
Sean
I don't think you can, most actions the webservices perform need an explicit user with the correct permissions set. If both sites are internal, your options might include
Using automatic NTLM authentication, give the complete Authenticated Users group the necessary acecss. Using IE or the proper extensions to FireFox credentials will be automatically passed without user prompting. Your mileage may vary.
Passing the proper credentials to a default user explicitly in the call to the webservice
from that other website.
If you feel creative, here is a blog from Reza Alirezaei where he walks through the steps of mapping the anonymous user onto a specific account. If you manage to give that acount the proper permissions, you are there. Not for the faint of heart, though.