by lunarg on December 17th 2009, at 22:40

If you ever happen to get locked out of a SBS 2008 system, with no way to get back in as Administrator (it's easier than you might think), use the instructions in this blog should get you back up and running.
Note that you will have to have physical access to the server, or else it will be very challenging to solve the problem.
The content of this has been tested for real on an SBS 2008 which had this problem. Check out the bottom of the page for the sources I used to compile this post.

For a background story, read this post.

Step 1 : getting in

In order to get in the server, we need some way of an account and password. As the SBS is a domain controller, you can't simply use the local Administrator account...
Well, actually, you can. Upon installation of the SBS, the promotion to a domain controller is the same as on any other server, accept for the fact that the process of dcpromo (= the application that creates DCs out of a regular server) runs in the background. On a regular server, in one of the steps, a Directory Services Restore password is being asked. The SBS skips this step, because it fills this one in for you: it's in fact the same as the Admin password you entered in the wizard. And even when the Admin password changes, this one remains always the same.

So if you still remember the very first password of the Admin account, you can skip right to step 2, as you will already be able to log in when running in Directory Services Restore mode.

Resetting the password

So, when you're reading this, you probably forgot about the password. In that case, you'll be needing a tool to reset the DSRM password.

The DSRM account is in fact a fancy word for a sort of local Administrator account. Therefore, you can use whatever tool you want to reset a local NT account.
A few examples are:

How to use these tools is beyond the scope of this document, although most them are pretty straight-forward.
In a nutshell, you have to reset the Administrator account.

Changing the DSRM password

If you can get in the server (but then you wouldn't be reading this blog), you can change the DSRM password. See here on how to do this.

Step 2 : circumventing the account lock-out

When you've got the DSRM password (either because you know it, or because you've resetted it), you can boot into Directory Services Restore Mode. For this, you need to hammer F8 when booting the server, just like you would when you want to boot in Safe Mode. Aside of this, there's an option allowing you to boot the server normally, but without Active Directory starting up. As a result, you can log in using the local Administrator account (and the DSRM password).

  • Login: machinename\Administrator
  • Password: the DSRM password you have set

This will allow you to log into the system. You're not out of the woods yet, though: you still can't get into the AD portion of the server, and it's not possible to change the contents of the AD when you're in DSRM. Luckily, there's a nifty workaround which allows you to fiddle with the AD: changing the stuff through a service!

Step 3 : fiddling with Active Directory

We will be using a service to execute the necessary commands to unlock the Admin account. For this, we will be using the commandline tools dsquery and dsmod; these are basically the CLI counterparts of the MMC snap-ins, and they are just as powerful (you can do the same things with them, and perhaps even more).
Additionally, we will use the Windows 2003 Resource Kit to install a custom service which will allow us to run these CLI tools.
The service will run as local system user, which is the highest privilege in Windows (higher than Administrator). We can only run through a service because we can't alter or query things in the AD while in DSRM, and in normal mode, we can't get into the system at all. Using this method, we can circumvent these limitations. The only drawback is that we would have to reboot each time into normal mode to actually get the things we require, executed.

You will need another Windows computer, and preferably an USB stick.

In our sample the domain we're playing will be:

  • NetBIOS domain: EXAMPLE
  • FQDN: example.lcl
  • Domain Admin: EXAMPLE\Admin

All right, here we go.

Installing Resource Kit and getting the right files

Okay, so first we need the necessary resource kit things. In particular, we need SRVANY which is the cool service that will launch our CLI tools, and INSTSRV, which will install the service. Both are present in the resource kit.

To get to them, download the resource kit, then either install it on another computer (it doesn't have to be a Windows Server, any Windows will do), or extract the contents of it to an USB stick. When you've installed it, copy the folder Tools from the installation folder to an USB stick.
Alternatively, you can copy the contents to a network share. Just get the resource kit files to the SBS 2008.

Place the resource kit files in a folder on the SBS 2008. In the examples here, I've placed my resource kit in C:\Tools.
Fire up a command prompt to install SRVANY:

cd \Tools
instsrv MyService C:\Tools\SRVANY.exe

This installs SRVANY as a service with name MyService.

Now that we have the service, we still need to tweak it so it starts the right things.
For this, fire up regedit.

  1. Navigate to our newly created service: HKLM\SYSTEM\CurrentControlSet\Services\MyService
  2. Create a key called Parameters
  3. Inside the new key, create a REG_SZ (string) value with name Application. The value of the string can be whatever you want, but for the sake of this post, let's set it to C:\fiddle.cmd.

That's it for the configuration of the service.

Creating our fiddling batch file

The cool thing about SRVANY is that it can run anything, even batch files. And that's exactly what we need, because now we can do a bit of scripting.

As we named the parameter C:\fiddle.cmd, you need to save the batch file we create in the next step with the same name. Else, it won't work (which is logic).
Querying the AD

Unless you exactly know which user (in LDAP search query syntax) is the right one, you will have to query the AD first. This is done with the dsquery tool. We will create a list of all users in the system, and pipe it to a file (as we can't see the output because it's running as a service).
Therefore, create a batch file which says something like:

dsquery user -name * DC=example,DC=lcl >> C:\out.txt

This will query the AD for all users and pipe them to out.txt. Note that we're using 2 brackets as to avoid the output file being overwritten when executed more than once.

Now reboot the server into normal mode, and wait until it's completely started (you should see the CTRL+ALT+DEL message) on screen.
After that, you can power-down again and reboot back to DSRM. Check out the results in our output file. You should get a list like:

"CN=Standard User,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl"
"CN=Network Administrator,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl"
"CN=Standard User with administration links,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl"
"CN=SBS ADMIN,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl"

Note that you see a regular Administrator account. This is the real Administrator account, but was disabled by the SBS wizard during installation. In our example, there's also a user called SBS ADMIN. This is the one we want to unlock.

On your server, the name of the domain admin account can be something entirely different. This is normal as the account name can be chosen during installation of SBS.
Make sure to select the right account before proceeding.

When you've determined the right account, copy its complete DN, as you will need it later on.

Setting the account properties in AD

Now that we have the right DN, we move on to actually changing the account properties. For this, we use the same method (and batch file), and the CLI tool dsmod; this tool allows us to change properties of an AD object (and that includes user accounts).
You would want to unlock the account, perhaps change the password, and maybe even set the "never expires" property.
Edit the batch file we created earlier and change it like so:

Unlock the account

dsmod user "CN=SBS ADMIN,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl" -disabled no

Set a new password

dsmod user "CN=SBS ADMIN,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl" -pwd your-password-here

Password never expires

dsmod user "CN=SBS ADMIN,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=example,DC=lcl" -pwdneverexpires yes

Choose the options you want, save the file, then reboot back in normal mode. Again, wait until the server is completely booted.
If all is well, you should now be able to get in the server using the domain admin account. If it doesn't work, you either haven't waited long enough, or have changed the wrong account. In that case, boot back to DSRM and recheck the batch file.

Normally not needed, but on the server were I was performing this operation, I had to reboot twice before it would take effect. Although, it may be quite possible I did not wait long enough.
Clean up

If you're able to get back in, clean up by disabling or removing SRVANY from the registry, and delete the batch file and output file in C:\.


« June 2017»
« Most people tend to avoid true conflict. Ironically this breeds more conflict. »