What Would Happen

If you configure your system so that no users are administrators, then no one will be able to perform administrative tasks as root with sudo (or its graphical frontends, such as gksu, gksudo, and kdesudo) or PolicyKit. Assuming the root account remains disabled, you will not be able to log in as root (even from a virtual console) or su-to-root either. Barring possible security vulnerabilities, this would prevent anyone from performing administrative tasks in the running system.

Fixing the Problem

However, if you did this, the problem would still be easily fixed, assuming you have physical access to the machine. Fixing this problem is similar to resetting a forgotten password, except you add the user to the sudo and/or admin groups with usermod, rather than resetting their password with passwd.

Here's one method:

1. Boot into recovery mode by holding Shift while booting and selecting it. Select the option for a root shell. You'll get a shell with a # prompt (rather than the usual $). This means it's a root shell. Any command you run here is run as root.

2. If you know your username, skip this step. To find out your username, run ls /home. This is a pretty reliable way to list the usernames of the human users of your system (while omitting user accounts like www-data and nobody which are used internally but don't represent real people).

3. Run these commands to add username to the necessary group(s) to be an administrator. (Replace username with the actual username.)

   usermod -a -G sudo username
   usermod -a -G admin username

   This separately attempts to add the user to the sudo and admin groups. In Ubuntu releases up to Ubuntu 11.10, administrators were in the admin group. In Ubuntu 12.04 (and in future releases), administrators are in the sudo group; if a 12.04 system was upgraded from a previous release, both groups will exist.

   So you can put the user in just one, if you know which one, or you can just run those two commands and put them in whichever exists. I advise doing this with two commands so that if one group doesn't exist, the error doesn't stop usermod from attempting to add the user to the other group.

Recovery mode is usually accessible. But occasionally it may be broken, disabled, or require a password, in which case you can boot from a live CD, chroot into the installed system, and run the usermod commands. Here's a procedure for doing that, adapted from my considerably more general answer here:

1. If you don't already have one, burn an Ubuntu live CD/DVD (on Ubuntu, Windows, or Mac OS X) or write an Ubuntu live USB flash drive (on Ubuntu, Windows, or Mac OS X).

2. In your Ubuntu system (not the live CD/DVD/USB system), run the following command in the Terminal (Ctrl+Alt+T). You do not need to be an administrator to do this.

   mount | grep ' on / '
   

   You should include the spaces before on and after /.

3. That command produces something like /dev/sda1 on / type ext4 (rw,errors=remount-ro,commit=0) as the output. The text before on (not including the space) is the device name of the partition that contains your Ubuntu system's root filesystem. Remember it (or write it down).

4. Boot the computer from the live CD/DVD/USB and select Try Ubuntu without installing (not Install Ubuntu).

5. Run these commands, replacing /dev/sda1 with the device name of the partition containing your Ubuntu system's root filesystem, if different (and username with the name of the user account you wish to give administrative abilities).

   sudo mount /dev/sda1 /mnt
   sudo chroot /mnt
   usermod -a -G sudo username
   usermod -a -G admin username
   exit
   sudo umount /mnt

   As with the other method, you can use ls /home (run this after the chroot command) to see a list of users on the machine, if you don't know the username.

Alternatives to Eliminating Administrators

On Ubuntu, when you're an administrator, you still need to authenticate with sudo or PolicyKit to perform actions as root. This is considered to be at least as secure as using su to perform actions as root, since anyone who can compromise your account in such a way to read your own password (for sudo) can also read root's password (for su). Furthermore, there are some substantial advantages (explained here) of sudo over su, and enabling the root account, while quite possible, is neither recommended nor officially supported in Ubuntu.

If you decide that even though sudo and PolicyKit require your password to perform actions as root, you still want yourself and all other human users on your machine to run as a standard user (and not as an administrator who can run commands as root), you have two easy options:

1. You can enable the root account, but this is discouraged as explained above. Also, by default you will not be able to log in to a graphical session as root, and you should not configure your system to allow this, as it's particularly dangerous to run an entire graphical desktop environment as root (a security bug in any part of it could compromise your system). Also, most GUI programs are not tested as root so there may be substantial usability bugs. If you do enable root, you should only ever log on as root from a virtual console (or use su).

2. The better option is to just create another user account for administrative purposes. Make this account an administrator. Having a non-root account that can perform administrative tasks with sudo and PolicyKit does not force you to use that account for day-to-day, non-administrative tasks.

However, most users are best off with the default--where at least one user account is an administrator and can perform administrative tasks, but must (re)enter their password to do so.