Share via

SharePoint 2016 Troubleshooting: Authentication not accepted when connecting to any link in Central Admin

  • Article

Problem

Began reviewing a small legacy SharePoint 2016 instance dedicated to SharePoint developers for a new customer.  Remoted into the single SharePoint server (separate backend).  Launched IIS, expanded Sites node, selected SharePoint Central Administration v4, and then clicked on Browse link in the IIS Actions panel.  Default browser type appeared and connected to the Central Administration home page.  So far, so good.  When I then clicked on any hyperlink displayed on the home page, an authentication prompt was presented, which was expected for this environment.  However, after entering authentication details, and then clicking OK, the authentication prompt returned. Tried again but same result: authentication details were not being accepted.  Began troubleshooting.

Troubleshooting

01) Checked membership in server local Administrators group

  • Found that the appropriate AD group for SharePoint administrators had been added to this group

02) Checked membership in server local WSS_ADMIN_WPG group

  • Found that my admin account had been explicitly added to this group

03) Checked SQL Server roles and user mappings

  • Found that the appropriate AD group, to which my admin account had been added, had been granted the sysadmin role to the backend
  • Found that this AD group had not been explicitly mapped to any farm database
  • Found that my admin account was not listed in the Logins node or mapped to any farm database

04) Checked SharePoint Management Shell permissions

  • Found that the shell launched without any error

05) Checked administrator account SharePoint_Shell_Access role to farm configuration database

  • In elevated SharePoint Management Shell, executed Get-SPShellAdmin - found that my administrator's account was not listed among the results returned - nor was listed the AD group that all SharePoint admin accounts were added to

06) Tested adding administrator's account to SharePoint Shell Admin group

  • In same shell, executed Add-SPShellAdmin [DOMAIN]\MyAdminAcct - completed successfully.

07) Checked SharePoint_Shell_Admin role membership

  • In same shell, executed Get-SPShellAdmin: my administrator's account was now among the results returned.
  • In SQL Server Management Studio, checked my admin account user mapping and found that it was now listed under the Logins node and that it had been mapped to the farm configuration database with SharePoint_Shell_Access and SPDataAccess roles.

08) Tested clicking on a hyperlink in Central Administration home page

  • Initial authentication prompt appeared, as expected.  After entering authentication details, the prompt closed and the browser was navigated to the appropriate Central Administration page.
  • This outcome was repeatable: if I executed Remove-SPShellAdmin DOMAIN\MyAcct, I could re-create the earlier problem; and then if I executed Add-SPShellAdmin DOMAIN\MyAcct, the problem went away again.

Solution

  • If prompted to authenticate after clicking on a link on the Central Administration home page, and your authentication details are not accepted, ensure that your account has been explicitly granted the SharePoint_Shell_Access role to the farm's configuration database

References

Notes

  • This particular environment is configured so that authentication is required when connecting to Central Administration.
  • Using Get-SPShellAdmin without specifying the "-database" parameter returns a listing of accounts and groups that have been granted the SharePoint_Shell_Access role to the SharePoint the farm's configuration database.
  • What threw me off initially was that my administrator account was added to a privileged AD administrator group, and this group was a member of the local admin group for farm servers and was db_owner of the farm configuration database; and the SMS launched just fine without the usual error presented when you have insufficient config database permissions.Additionally, my admin account was found to have been added to the local WSS_ADMIN_WPG group. So, all the boxes where checked as far as I could tell.