In an otherwise good article Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out, the author tells us that all we have to do to regain control of our SQL Server is to
"Start the instance of SQL Server in single-user mode by using either the -m or -f options. Any member of the computer's local Administrators group can then connect to the instance of SQL Server as a member of the sysadmin fixed server role."
Unfortunately, what it means to start in single-user mode is not an intuitive matter. Also, at least in my experience, membership in my computer's local Administrator's group did not grant sysadmin status to my "user" account.
This story had begun when to address a problem of membership in my domain by a non-DC server (a consequence of changing ISP), I rebuilt the DC into Windows Server 2008 R2 from 2008. This solved a couple minor problems but did not address the question of membership by the errant server. It took a fix suggested in ServerFault to accomplish that (in my case, it was a matter of resetting winsock and tcpip).
SQL Server 2008 resides on that second server, now a member of the domain. Here's the problem. As someone points out on ServerFault, it is common to push the "let the current user become as sysadmin," when installing Server 2008. Common also to not consider anyone else. Because that single user identity was a domain member of a domain that no longer existed, no one had permission to administer Sql Server.
I logged on as the local server administrator that had been around when Sql Server was installed, but although this allowed me access to the Management Studio, I quickly discovered that BUILTIN\Administrators had only the "public" server role.
After much research and experimentation, I happened upon an article giving the specifics of single-user logon http://technet.microsoft.com/en-us/library/ms180965.aspx:
C:\>cd \Program Files\Microsoft SQL Server\MSSQL10_50.1\MSSQL\Binn
To prepare to take this step, you must shut down Sql Server (which runs by default in most cases). Use SQL Configuration Manager to stop "Sql Server."
Then, in a command prompt, navigate to that program file location (or equivalent on your machine), and issue the "sqlservr.exe -m" command. If you see a stream of activity logged in your command prompt, you're being successful. If it fails to start, then you probably have SQL Server running already. Shut it down.
Allow the single-user instance to attach its databases. When log activity has ceased, open Management Studio. You will be automatically in single-user mode, and therefore whatever account you represent will be a sysadmin. Use that power to adjust Security logins and server roles.
In my case, I had to recreate the domain accounts in the new domain, then delete their namesakes in SQL Server, and reconstruct them (due to the SID/GUID situation), reassigning permissions to particular databases as necessary.