for some reason if your sharepoint server or any other application server is creating an authentication issue (especially with credentials pop-up) please consider reading the below article which is already puplished at the microsoft site. re-registering will do no harm with the FQDN. I have highlighted the commands which you need to look at. let me know in case of any doubts which I would be happy to explain.
Kerberos Authentication and Delegation.. one of the areas which needs to be looked at
The Kerberos authentication protocol is a technology for single sign-on to network resources. This enables web parts to access remote resources i.e. it makes it possible for web part to access cube information from Analysis Services running on another machine then your SharePoint machine with logged on/page user identity.
Requirements
- All accounts (including machine accounts) must belong to the same Windows 2000/2003/2008 based Active Directory domain (or to trusted domains in the same forest).
- User account (s) must allow delegation (default). The user account (s) you want to be delegated must have the Account Is Sensitive And Cannot Be Delegated option cleared (i.e. not checked). You'll find this property in Active Directory Users, under the Account property tab.
- If running Analysis Services 2000 you must have SP3 or higher. SP3 or higher version of PTS needs to be installed both on the server and on the client. In this case the client is the SharePoint Server.
- SPN (Service Principal Names) configuration utility. To configure SPN's you need the tool setspn.exe that can be downloaded from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp.
- For more in detail requirements please read following articles:
Configuration
1. Enable Kerberos in the IIS Metabase on your SharePoint machine
To configure a virtual server that is extended with Windows SharePoint Services to use Kerberos authentication, you must first enable Kerberos in IIS. To enable Kerberos on the virtual server, first you need to shutdown IIS (iisreset /stop in the command window) and then follow these steps:
a. On your SharePoint server, start Notepad, and then open the \system32\inetsrv\Metabase.xml file located on the hard disk.
b. In the <IIsWebServer> section, locate the following line:
NTAuthenticationProviders="NTLM"
Modify the line so that it reads exactly as follows:
NTAuthenticationProviders="Negotiate,NTLM"
c. Save changes and then quit Notepad.
d. Start IIS (Run iisreset /start in the command window).
2. Configure SharePoint machine to be Trusted for Delegation
To configure your SharePoint server to be trusted for delegation, follow these steps:
a. On the domain controller, start Active Directory Users and Computers.
b. In the left pane, click Computers.
c. In the right pane, right-click the name of your SharePoint server, and then click Properties.
d. Click the Delegation tab (or General for WinSrv2000), click to select the Trust computer for delegation check box.
e. Quit Active Directory Users and Computers.
3. Configure the domain account to be trusted for delegation
This is only necessary if the application pool for your SharePoint service is running under a domain account. To configure the domain account to be trusted for delegation, follow these steps:
a. On the domain controller, start Active Directory Users and Computers.
b. In the left pane, click Users.
c. In the right pane, right-click the name of the account that runs the SharePoint application pool, and then click Properties.
d. Click the Delegation tab (or for WinSrv2000 Account tab) click to select the Account is trusted for delegation check box, and then click OK.
e. Quit Active Directory Users and Computers.
4. Configure Service Principal Names
You only have to configure SPN's if SharePoint Service and/or Analysis Services is running under a domain account (I.e. you do not have to perform this step if your services is running under a built-in security principal such as NT Authority\Network.
a. Perform this step if SharePoint Services runs in a application pool under a domain account. Type the following line at the command prompt on your SharePoint machine, and then press Enter, where ServerName is the NETBIOS or DNS name of your SharePoint server machine, Domain is the name of your domain, and UserName is the name of the domain user account running your SharePoint Services application pool:
setspn -A HTTP/ServerName Domain\UserName
b. Perform this step if Analysis Services runs under a domain account. Type the following line at the command prompt on your Analysis Services machine and then press Enter, where ServerName is the NETBIOS or DNS name of your Analysis Server machine, Domain is the name of your domain, and UserName is the name of the domain user account running your MSSQLServerOLAPService:
Analysis Services 2000: setspn -A MSOLAPSvc/ServerName Domain\UserName
Analysis Services 2000: setspn -A MSOLAPSvc.3/ServerName Domain\UserName
5. Configure connection string for the data sources
Each data source definition must have the SSPI property set to Kerberos to enable Kerberos Authentication. Add ;SSPI=Kerberos; to the connection string on all defined data sources. See how to configure a data source. Note: To verify that Kerberos Authentication works for your OLAP server you can run the MDX sample application locally on the OLAP server. In the Connect dialog add the string ;SSPI=Kerberos after the server name and try to connect.
Example to register a Server Principal Name
Say your MSOLAPServices runs on a machine called IM-PROD and you've decided to run the service under a domain account named F.Lastname. In this case, you add a SPN (Service Principal Name) on your IM-PROD machine for MSOLAPSvc with F.Lastname as the service account:
setspn -A MSOLAPSvc/IM_PROD.Mydomain.com MyDomain\F.Lastname
setspn -A MSOLAPSvc/IM_PROD MyDomain\F.Lastname
this way you register with the AD
Register NETBIOS or/and DNS name
It can be convenient to use both NETBIOS and DNS name because it allows the client to specify either name, but bear in mind that NETBIOS names might not be unique across the directory and, if a duplicate SPN is found in the directory, authentication will fail. If you're worried about this, use only DNS names when registering SPNs, and make sure your clients always use the fully qualified DNS name when making authenticated connections to a server using Kerberos.