Discovering the Setup User Account - A SharePoint "Whodunit?"

It was a dark and stormy night. There were SharePoint problems in The City. Lots of them. And it was my job to track 'em all down. I'm a consultant. No problem is too big or too small. It's what I do.

This is the story of one of those problems...

I was hard at work at my desk when the phone rang. Even before he told me, I could tell from the sound of the caller's voice that he had a big problem. His name was Steve. Not the problem - the caller. Turns out Steve's SharePoint guy, Ben, was on the lamb. Ben ran into some Girl Trouble, you see, and he wasn't coming back. Now all Steve had was a SharePoint farm, a scrap of paper, and some half-linked wiki pages.

While I couldn't do anything about filling out his content, at least he used a SharePoint wiki, so his users could pick up the slack there.

I turned my attention to the only clue - that scrap of paper. Turns out, it had a hand full of account ID's written down. It didn't take a genius to figure out that these were the accounts he used when setting up his farm. There were more than three of them, and it was good. Unfortunately, these were all code-name accounts like s23365, and k45321. No way to tell which account was which. That was bad. For all we knew, Ben had used the same account for all three of the major functions (Setup User, Server Farm, and Content Access). Or maybe they were all individual service accounts, and he had been logged in with his own account when he set up SharePoint.

The Big Deal

Why is this so important, you ask? Well, if you've read "Taking Accounts into Account", you'll know that the Setup User has special status - essentially this ID has full control over the SharePoint installation, even if you take it out of the administrator groups. Generally, it is also a good idea to use this same ID when update time rolls around.

The problem is, there is no way to tell directly which account was the Setup User. Sure, you can tell what accounts are used for the services, and Default Content Access is particularly easy, just go to the Search Administration page. But although you can see the accounts in the Farm Administrators group, as noted above these can be changed, so that doesn't necessarily tell you who did the setup.

It was time for the thinking cap. Brainwaves are generated by caffeine and sugar, so I sent Steve for some coffee and donuts while I hashed things out. Since SharePoint wasn't going to help me here, I had to go outside the box. Or rather, straight to the box. I harkened back to my Windows admin days, and thought about what is actually happening when you install software. Registry changes, folders created, files copied, etc...

Chasing a Wild Goose

Half a cup of Columbian and a French cruller later, I thought had it. Files! Folders! When you install a program - especially one as big and powerful as SharePoint, you are creating files left and right. When you put a file into Windows, loads of information about it gets stored - its name, when it was created, and who has access to it. But more than that - Windows "knows" who created the folders and put the files in them.

I started looking in the same place you look for almost anything related to SharePoint configuration. An infamous little hangout called the 12 hive. So I started Exploring. I followed a sort of convoluted path - "C:\program files\common files\microsoft shared\web server extensions", but in the end, I found what I needed. And there was my witness - an unsuspecting little folder, called simply "12". Sure, she was cute, but I knew under that simple yellow exterior bubbled a mass of information.

I decided to be gentle at first. I gave the folder a little right-click and whispered "Properties" in her ear. She was compliant, and engaged in a simple dialog. I changed the subject to security:

I knew I was getting warm when she let slip that she knew the Creator/Owner. But she wouldn't tell who it was. I applied a bit of "Advanced" pressure, and finally got her to fess up. She showed me the owners, and there was... the Administrators group. A dead end. I had high hopes for this one.

You see, the creator of the file or folder automatically gets ownership-level rights. This means that they can do anything to it an administrator can. This is also one reason the Setup User in SharePoint gets so much power. Since they are the creators of the files that make up SharePoint, they can always access them, no matter what SharePoint's internal permissions say. Unfortunately, Windows Server automatically assigns Ownership to the Administrators.

The Light at the End of the Tunnel

Then I had another thought. The other thin the Setup User does is creates the Central Administration web site. Like I said before, you can't just check the Farm Administrators group. But there is another way to check for "special" users. The STSADM command has a way to list users who have been assigned direct permissions to a site collection. Central Administration needs someone to access it before all of the groups are built, so I thought, why not see if the Setup User was hiding there.

I opened up a command prompt. Central administration is configured on a random port at setup, so first thing I did was look up the port that was in use with the command:

stsadm -o getadminport

Once I had that, I used  the "enumusers" operation. Since the name of the server with Central Administration on it was "canon", the command (including the port found above) was:

stsadm -o enumusers -url http://canon:8585

And there it was - a user explicitly granted permissions. It even had a reasonable id: "SPAdmin".

I gave Steve the good news - the Setup User wasn't one of the accounts on the scrap, nor was it Ben's own account. Fortunately, Ben hadn't used it for any of the services. He had used an easy-to-remember name, SPAdmin. I suggested that Steve change the password, but otherwise he shouldn't have any trouble.

Elementary? Not Really, My Dear Watson...

While the story you have just read is fictional and somewhat tongue-in-cheek, all of the technical elements are true. The Setup User is a very powerful account. It should not be assigned to any of the SharePoint services, and shouldn't be anyone's "day to day" account. And, as you have seen here, there is no way to determine with certainty what account was used to set up SharePoint after the fact.

What we did here was look for ways to infer the account name. I have tested this method on several different SharePoint installations, and it has been accurate on the systems I had available. While there may be other ways beyond the one I used, none of them (even this one) are particularly robust. For example, although it is almost never done, you can explicitly assign rights on Central Administration to other users, or remove the Setup User's default explicit permissions grant (Note, as described in the story, this is NOT in the Farm Administrators group, and does not actually remove the Setup User's power). This will change what users are returned by the enumusers operation.

The moral of the story is that you need to keep a log of the accounts you use in your SharePoint configuration.