2

I'm stuck unable to access a newly created sharepoint 2013 server web application (at portal.spdev.mycompany.com, with host header of same name) unless I have an entry for that web application in the hosts file.

I have the DNS name set up on our network: portal.spdev.mycompany.com points to 12.3.4.567
From a command window on the server hosting the web app or from a different machine on the network I can 'ping portal.spdev.mycompany.com' and have it resolve correctly to 12.3.4.567. When I enter the URL in IE (on the hosting server and other machines) I am asked to present my username and password, and then it asks again for username and password... and again until it is just a white screen.

In IIS 7 Manager, site bindings for this web application are: http/portal.spdev.mycompany.com/80/*/(blank)

We are on windows server 2008 R2 Standard.

When I have the server hosts file entry for that URL pointing to 127.0.0.1, pinging the site on the server resolves to 127.0.0.1 and in IE going to that URL I am prompted for a password and now am taken to the portal (it would be nice if I didn't have to log in…)

The portal web app was just created in CA using default claims based authentication settings, in the default zone. In the 'Edit Authentication' screen 'Claims Authentication Types' we have 'Enable Windows Authentication' selected, also selected is 'Integrated Windows authentication' [Negotiate(Kerberos)].

In IIS Manager -> portal… webapp -> Authentication I have enabled Anonymous Impersonation Forms Windows

Under 'Windows authentication' -> advanced options I have both options off.

On the host server, with the server’s host file entry set to point to the servers IP of 12.3.4.567 I am asked to log in, I provide my username and password and I can get in…

With that entry removed, again I get the repeated login prompts.

In IIS Manager -> portal… webapp -> Authentication I disable forms authentication as warning messages on the right tell me I can’t use challenge and redirect together. I restart the webapp.

I clear IE cache. I enter the portal URL. Again, continual prompting to login and blanks screen.

With the host file entry back and pointing to 12.3.4.567 and forms authentication disabled, after providing my username and password I see “Sorry, this site hasn’t been shared with you.”

I am attempting to log in using the account that created the web application, which is a farm admin account.

My questions – 1) why do I need to have the entry in the hosts file? I can ping the URL and it resolves to the correct IP. If that IP is in the hosts file it works… but without the host file entry it just repeats the login prompts. 2) How can I fix this so I can just go to the site?

3) What are the necessary IIS authentication settings to work with the default CA installed claims based authentication web applications? I think I have deduced from this that forms authentication must be enabled as I get a “Sorry, this site hasn’t been shared with you.” message if it is off, but IIS 7 tells me I can’t have challenged-based and login redirect-based authentication simultaneously. Do I have to ignore the warning messages from IIS to have sharepoint work? I haven’t found any helpful information on technet that tells me what exact IIS authentication settings to use for what I assume is the standard AD enabled intranet sharepoint scenario.

------------------

UPDATES:

I found the http://support.microsoft.com/kb/896861/en-us loop back checking windows 2008 rc2 ‘feature’. Set the DisableStrictNameChecking to 1 and DisableLoopbackCheck to 1 and restarted the server. I am still getting the same repeat prompt for credentials with no host file entry.

In the ULS logs, with no entry in hosts file and authentications of anon, impers, forms, windows, I see the following messages:

SPFederationAuthenticationModule.OnAuthenticateRequest: Start
SPTokenCache.ReadTokenXml: Successfully read token XML '{0}'.
SPTokenCache.ReadTokenXml: Successfully read token XML '{0}'.
No windows identity for request url '{0}' so no action taken.
SPApplicationAuthenticationModule: There is no Authorization header, can't try to perform application authentication.
Non-OAuth request. IsAuthenticated={0}, UserIdentityName={1}, ClaimsCount={2}
Sending HTTP response {0} - {1}:{2}.
SPRequestModule.PreSendRequestHeaders
Not sign in operation.
SPFederationAuthenticationModule.OnEndRequest: User was being redirected to authenticate.
Claims Windows Sign-In: Sending 401 for request '{0}' because the user is not authenticated and resource requires authentication.
SPFederationAuthenticationModule.OnEndRequest: Start

Disabling forms authentication. Clearing cache. Iisreset. Same behavior. Same ULS messages...

Improve this question
3
  • Did you configure Alternate Access Mappings?
    – RJ Cuthbertson
    Jul 30, 2013 at 19:41
  • No, I haven't. Am I doing something that would require one?
    – Robbie
    Jul 30, 2013 at 19:58
  • Do you need forms authentication are your users not in AD?
    – Simon Doy
    Jul 31, 2013 at 7:01

4 Answers 4

Reset to default
1

After reading that IE automatically puts a URL into the internet zone when it includes a period (.), which forces the browser to ask for credentials, I created a new DNS record - a Host (A host this time), with name 'portaldev' pointing to my IP 12.3.4.567. I added the new binding to IIS and in Alternate Access Mappings added an internal URL pointing to the 'portaldev', then edited the public URL to point to portaldev, which removed the earlier link to portal.spdev.mycompany.com.

[Note: make sure to include the http:// otherwise sharepoint will say "sorry, there was an error" and you must dig through the ULS logs to see that the url was invalid. Would it be too much to ask for form validation or even a helpful error message?]

I think I stumbled on the fix (changing to an A Host as Simon mentioned) by changing the name to remove the periods (to stop IE from asking for username and password). I am not sure why this was a problem though.

Improve this answer
1
  • IE will not by default automatically send your username and password if the site is in anyother zone apart from Local Intranet. Also proxy server can get in the way of requests too.
    – Simon Doy
    Jul 31, 2013 at 20:31
0

Check the windows eventlog on the server. There should be an entry that the alternate access mapping is missing. Add the entry and you should be fine.

Improve this answer
2
  • Max, No eventlog messages regarding aam. I'm wondering if this may have to do with periods in the URL (even though microsoft's example is portal.contoso.com). I have 'h\ttp://portal.spdev.mycompany.com' for both internal and public url in default zone. Have you worked with similar URL structures and not needed to log in or add the site to IE's 'trusted site'?
    – Robbie
    Jul 30, 2013 at 23:58
  • Can you check the IIS log? Check if the http code is 401.1
    – Max Melcher
    Jul 31, 2013 at 5:23
0

I see that you have enabled Kerberos. You need further setup to configure Kerberos correctly. As a first step, change the authentication type to NTLM and test to see if you can access the site.

Have you have setup SPNs and configured delegation for the SharePoint servers in AD?

Also is your DNS record pointing to the SharePoint farm a A record rather than CNAME?

Improve this answer
3
  • Simon, I think the need for the host file might have been resolved by switching the portal.spdev.mycompany.com site to an A host named portaldev which pointed to the IP. What confuses me is why would CNAME create an issue if DNS can resolve it to the correct IP?
    – Robbie
    Jul 31, 2013 at 17:58
  • Sounds like a fair assumption. The issue isn't down to ip resolution its down to the way that Kerberos works when trying to establish the Kerberos protocol. The fact that you have changes urls will mean that IE will see your site as part of the Local Intranet zone and automatically log on. Plus if you have proxy servers then they should be being bypassed.
    – Simon Doy
    Jul 31, 2013 at 20:22
  • so have we fixed your issue?
    – Simon Doy
    Jul 31, 2013 at 20:30
0
  1. Open IE
  2. Go to Internet Options
  3. Go to Security Tab
  4. Go to Custom Level
  5. Scroll down to last under 'User Authentication' and check 'Automatic logon with current user name and password

Let me know if this helped.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.