Do you have access to the SharePoint 2010 Management Shell?
Because the SharePoint Farm Account got deleted and then recreated, the SID will probably be different. Because the SID in Central Admin and the Configuration Database don't match, they are considered different users.
You might regain access by making sure the SID in Central Admin is the same as the SID of the account that has access to the Configuration Database
In the SharePoint 2010 Management Shell try the following to compare the SID's:
$CentralAdmin = Get-SPWeb -Identity http://url_of_your_central_admin:1862
$CentralAdmin.groups['Farm Administrators'].Users['Farm Account Name'].Sid
Now you have the SID of Farm Account in Central Admin. Next we are going to compare this SID with the SID of the newly created account.
$user = New-Object System.Security.Principal.NTAccount("domain name", "Farm Account name")
$sid = $user.Translate([System.Security.Principal.SecurityIdentifier])
$sid.Value
Do these two SID's match?
If the SID's do not match, i suggest reading this article: http://support.microsoft.com/kb/2809787. The article deals with Active Directory groups that had their SID's changed. But I think a similar solution is applicable for user accounts.
Extract from http://support.microsoft.com/kb/2809787:
Consider the following scenario:
You have created a SharePoint 2010 Web Application using NTLM authentication and decided to manage the SharePoint Security using Active Directory Groups.
The AD users are added as members into Security Groups and the groups are granted permissions in SharePoint.
You delete one of the groups in Active Directory and re-create it using the exact same name and members.
In this scenario, you may receive the following message when you check a group member’s permissions from 'Check Permissions' control in SharePoint
Permission levels given to USER (DOMAIN\USER)
None
Cause:
SharePoint will not be able identify the group being used due to a change in the security identifier (SID) when you recreate the group. This is an expected behavior, as SharePoint relies on the security identifier (SID) as the unique identity of users and groups, and subsequently a GUID, which is internal to SharePoint.
Resolution:
The "Stsadm -o migrateuser" command will not work for the Active Directory group migration and will fail with "The user does not exist or is not unique" error. You need to use the "Stsadm -o migrategroup" command to change the group SID. Here's the command syntax
Stsadm.exe -o migrategroup
-oldlogin
-newlogin
Ex: Stsadm -o migrategroup -oldlogin Domain\Group –newlogin Domain\Group
After this you should be able to check permissions correctly, and the users who belong to the affected AD groups should have the permissions set correctly.
I think, in this case we will need to use Stsadm -o migrateuser to update the SID of the user (since it is not a group, and the article is about a group) in Central Administration. If the SID in Central Admin is the same as the SID as in the Configuration Database, i think you will regain access.
Try updating the SID in Central Admin by using
Stsadm.exe -o migrateuser
-oldlogin <DOMAIN\name>
-newlogin <DOMAIN\name>
