Getting Prompted for Login Repeatedly

If you encounter repeated login prompt even when the credential entered is correct, there are some common solutions that can help. If the issue persists after all these solutions are in place, systematic troubleshooting will be needed.

Here are the common areas to check, on the clients and the servers.

Client Side Solutions

Add the team Web site to the list of trusted intranet sites

To do this, complete the following steps:

  1. On the Internet Explorer toolbar, click Tools, and then click Internet Options.
  2. In the Internet Options dialog box, click the Security tab, and then select Local intranet.
  3. Click Sites, and then click Advanced.
  4. Type the URL of the team Web site in the Add this Web site to the zone box, click Add, and then click OK.

Bypass proxy server for local addresses

To bypass your Internet proxy for local addresses in Microsoft Internet Explorer 5 or later, complete the following steps:

  1. On the Internet Explorer toolbar, clickTools, and then click Internet Options.
  2. In theInternet Options dialog box, click the Connections tab, and then click LAN Settings.
  3. UnderProxy server, select the Bypass proxy server for local addresses check box, and then click OK.

Make sure Integrated Windows Authentication is enabled.

Make sure Integrated Windows authentication is enabled in IE. (Tools >> Internet Options >> Advanced >> under security, enable integrated authentication)

Add the entry to the Credentials Manager

  1. Go to Start > Run and type in control keymgr.dll to open the Windows key manager.
    Alternatevily: navigate to Contorl Panel > User Accounts > Manager Windows Credentials
  2. Select Add a generic credential
  3. Add yourSharePoint site URLlogin and password to the corresponding fields. If this entry already exists, edit it to have your login credentials.
  4. Reboot the computer.

If you are missing the Add button, you may want to modify Windows Registry to be able to save the password.

Note: for editing Windows Registry, administrator rights are required. Editing Windows Registry is not safe and users will perform it at their own risk.

  1. In Windows, go to Start > Run and enter regedit.
  2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\.
  3. Find the DisableDomainCreds A value of 1(enabled) will prevent you from saving new credentials.
    Change the value to 0 and reboot. Now you should have the Add button available. Note that 0 is the default value.
  4. Also check the LmCompatibilityLevel It should be set to 3, which is the default value. If you have another value, change it to 3. If it does not work with 3, then also try it with 2.
  5. Reboot the computer to apply changes.

If the client PCs are using Windows 7, some hotfixes may be needed:

The solutions below are specific to the “Open with Explorer” function. If you get prompted for login repeatedly when using “Open with Explorer” after trying the configurations above, you can try the solutions below.

Restart WebClient Service

  1. Click Start > Run
  2. Enter ‘services.msc’
  3. Find the WebCient service and select Restart

Check Internet Explorer Version

  • Windows 7: Internet Explorer 10 is not yet compatible with the You will need to revert to Internet Explorer 9.
  • Windows 8: Internet Explorer 10 is compatible, so you should not have an issue with this OS and browser version combination.

Server Side solutions

Specify Host Names on each SharePoint Web Front End. (Preferred method over disabling loopback check)

To do this, follow these steps for all the nodes on the client computer:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


  1. Right-click MSV1_0, point to New, and then click Multi-String Value.
  2. Type BackConnectionHostNames, and then press ENTER.
  3. Right-click BackConnectionHostNames, and then click Modify.
  4. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  5. Quit Registry Editor, and then restart the IISAdmin service.

Client and Server Coordination

Make sure the NTLM Level is the same among Domain Controllers, SharePoint Servers and Clients

This can be pushed down from a Domain Controller using GPO (Group Policy Object).

  1. Use Group Policy Editor (GPE) to open the Group Policy Object (GPO) you want to modify. You can create a policy that applies to the OUs that contains the DCs, SharePoint Servers, and user clients.
  2. Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.
  3. Double-click the “Network security: LAN Manager authentication level” policy.

You can choose a level that is acceptable to your internal security policy, Just make sure you use the same level across DCs, SharePoint Servers and clients.

  1. Select “Define this policy setting” and from the drop-down menu select the desired level.
  2. Click OK.
  3. Close the GPO.
  4. To make the modification effective immediately, run gpupdate /force on all the servers and clients.

Notes on ADFS for SharePoint

When deploying ADFS for SharePoint, there are a few considerations. Using ADFS for SharePoint is not just another authentication method, if will affect quite a few functionalists that we even take for granted. Here are some of the common situations that SharePoint customers will encounter when they implement ADFS for SharePoint.

Zoning for web applications.

Check out the dedicated
blog post for a detailed discussion about this topic.  Very likely, you will need to use ADFS in a non-default zone. The root cause is that search crawl does not work without Window Authentication.

People picker 

People picker is not working properly in the zone that uses ADFS.  It is accepting all the user claims.  Please refer to the attached screenshot for one example. Basically, anything users type in the People Picker will be accepted although there is no such user in Active Directory, just like in the picture below:

People picker

This is a known issue. As stated on TechNet (, “when you use SAML token-based authentication, all queries entered in the text box are automatically displayed as if they were resolved, regardless of whether they are valid users or groups”.  Therefore, we need to implement a custom claims provider in SharePoint, so SharePoint could query AD directly and the People Picker will work properly.  We could find from the internet a sample of such custom claims provider:

User Profile Sync

You will need to configure User Profile Service Application separately for ADFS.  Otherwise, users authenticated through ADFS will not be able to have their profiles synced from AD and consequently not populated to the site collections. They will not be able to use the functions dependent on user profiles, for example outgoing email service (simply because there is no email address in the user profile).

After the basic setup of ADFS for SharePoint, a User Profile Synchronization connection and a User Property mapping needs to be set up to make sure ADFS users’ properties are synced. Here are the steps to create a Profile synchronization connection to a directory service for ADFS users.

a.On the Add new synchronization connection page, type the synchronization connection name in the Connection Name box: User Profile Sync for ADFS.
b.From the Type list, select the type of directory service to which you want to connect.
c.Fill in the Connection Settings section according to the directory service to which you are creating a connection.
d.In the Forest name box, type the name of the forest.
e.Click Specify a domain controller and type the domain controller name in the Domain controller name box.
f.In the Authentication Provider Type box, select Trusted Claims Provider Authentication.
g.In the Authentication Provider instance box, make sure ADFS is selected.

h.In the Account name box, type the synchronization account domain\sp.profile.

i.In the Password box, type the password for the synchronization account.
j.In the Confirm Password box, type the password for the synchronization account again.
k.In the port box, enter the connection port 389.

l.In the Containers section, click Populate Containers, and then select the containers from the directory service that you want to synchronize.
m.Click OK.

Here are the steps for mapping User Properties for ADFS users.
a) On the Manage Profile Service page, in the People section, click Manage User Properties.
b) Click Claim Provider Identifier and choose Edit.
c) The mapping should have been configured automatically when the Synchronization connection was created. Make sure attributed ADFS is imported for the Connection User Profile Sync for ADFS.


d) Click OK.
e) On the Manage User Properties page, click claim User Identifier.
f) For the source User Profile Sync for ADFS, import email as the Claim User Identifier.


For the users authenticated through ADFS, Audience does not work even your have synchronized user profilers to SharePoint. You will need to create users manually or implement custom codes. If you would like to create users manually, create the profiles with their proper claims attributes—for example, i:05:t|AD FS with
roles| as the account name—and then populate the other fields with data that you want to use in your audiences. However, without implementing custom codes, you cannot use a user-based audience, such as membership in a group, for the audience.  You implement custom code in order to do that. It might be more efficient to use the property-based audience in this case.

This TechNet article mentioned this limitation:

Other known issues:

A few things don’t work, such as search alerts. Search Alerts does not work with SAML security tokens (generated by ADFS). On TechNet, there is an article that covers this topic for SharePoint 2010: There seems no improvement in this area in SharePoint 2013.

There are more issues if you are using an older version of SharePoint or ADFS. However, the good news is there are some updates if you are using SharePoint 2013 and ADFS 3.0.  For example, check out this blog for how to make SharePoint hosted apps work with ADFS 3.0:


If there have multiple zones, and the users subscribe to an alert from a non-default zone, in the email they receive about the alerts, the links are linked to the default zone.  This can only be resolved by custom codes. For a solution, you could check out this blog post:

Groups claims

For the LDAP attributes being passed to SharePoint as outgoing claims, you could pick up the one you need.  You could just use one sole attribute if you only would like to authenticate individual users.  You could for example only pass Email address, and all users will be able to get authenticated with their email addresses. However, if you could like to grant permissions to security groups in AD for ADFS users, you will need to pass group claims. The way to do it is to firstly in ADFS, make sure the LDAP attribute “Token-Groups – Unqualified Names” is mapped to the outgoing claim type “Role”. In this case, the sAMAccountName of the security groups will be passed to SharePoint as plain text.

BTW, if you forget to do this when the trusted token issuer (ADFS) was created, you could either recreated it including the “role” claim mapping or just update the existing one.  Here is the script to use:

$issuer = Get-SPTrustedIdentityTokenIssuer
$map=New-SPClaimTypeMapping "" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

For the URI of each type of claim, you could refer to this article:

Browser support

When implementing ADFS for SharePoint, you will encounter a few issues.  Some of the actually have been mentioned above.  I discovered one issue with Chrome in one the projects, and it has a solution.  You could check out this blog for details:

When Non-Windows Authentication is configured in SharePoint

Windows Authentication is quite popular but in real world, other authentication providers are needed. For example, some organizations require single sign-on (SSO) to provide end users with smooth experience across different platforms. Active Directory Federation Service (AD FS) meets the requirement, working as a shared trusted identity provider for the platforms involved. In SharePoint, it can be configured with Windows PowerShell after setting the SharePoint web applications as a relying party in AD FS. This sounds pretty straightforward. However, we could not get rid of Windows Authentications as crawling requires it.


It is possible to use two authentication providers in the same zone of the same web applications in SharePoint. However, this may not be ideal in the real world as users will be prompted the authentications provider picker before logging in if multiple authentication providers are enabled in the same zone.  For example:


IT managers usually would like to avoid this as end users very likely do not know which one to choose and may get lost, which is not helpful for user adoption. In order to have users authenticated through an authentication provider directly without picking an authentications provider, there can be only one authentication provider in the same zone. Therefore, we need to extend the web applications into a second zone, and use the second authentication provider such as AD FS in that zone and Windows Authentication in the default zone.

You may have a question. Can we put Windows Authentication in the second zone and use AD FS in the default zone? The answer is no. if you crawl a zone of a web application other than the default zone, the query processor does not map search-result URLs so that they are relative to the AAM zone from which queries are performed. Instead, search-result URLS will be relative to the non-default zone that was crawled. Because of this, users might not readily be able to view or open search results. Therefore, when AD FS or any other authentication provider is required in a web application in SharePoint, the zone and authentications provider design would be something like in the table below.


Zone Authentication Provider
Default Windows authentication
Intranet AD FS
Internet Forms-Based Authentication