First, create the group if it doesn't exist:

$ groupadd -g 4200 sysadmin2

Next, create the user and add it to the group:

$ useradd sysadmin2 -u 4201 -g 4200 -m -s /bin/bash
$ useradd appadmin1 -u 4100 -g 4100 -m -s /bin/bash 

-m creates a home directory if it does not exist, and -s sets the user login shell path.

Don't forget to reset password for each user.

First - UIDs less than 1000 are usually system reserved, pick a higher UID.

Second - Why are you wanting it to not have a home directory. Keep in mind the --no-create-home doesn't mean the user doesn't have a home directory assigned, it just isn't created. An error will be logged every time that user logs in.

Third - Please remember to post errors your get, else we can only assume as to what the problem is. I'm assuming it has to do with the name format, in which case, you can bypass this using --force-badname, as the error message would say, or use all lower case characters.

*edit typo

Thanks to Tom Yan, I've ended up solving my issue by creating a group with the same name then added the user to that group. So I did the following:

sudo groupadd -r -g 1234567 nexus \
  && sudo useradd -r -u 1234567 -g 1234567 -m -c "nexus role account" -d /sonatype-work -s /bin/false nexus

Method 1 - If you just want to create a user with a given UID

1. Install Ubuntu normally
2. Log into Ubuntu
3. Open a Terminal
4. Create a new user with the ID 1200 sudo adduser -u 1200 <username>
5. Confirm that the user was created with the desired id awk -F: '/\/home/ {printf "%s:%s\n",$1,$3}' /etc/passwd
6. Add the newly created user to the sudoers group sudo adduser <username> sudo
7. Logout
8. Login with the newly created user
9. (optional) Delete the old user

Method 2 - Automated Ubuntu installation using preseeding

In order to be able to define a UID range at installation time, you need to automate the Ubuntu installation using preseeding, which is basically

a way to to set answers to questions asked during the installation process, without having to manually enter the answers while the installation is running. This makes it possible to fully automate most types of installation and even offers some features not available during normal installations.

Using this method, which is way to extensive to be posted as part of this post, you can (amongst many other things) setup the account which will created at installation time. Example:

# Skip creation of a root account (normal user account will be able to
# use sudo). The default is false; preseed this to true if you want to set
# a root password.
#d-i passwd/root-login boolean false
# Alternatively, to skip creation of a normal user account.
#d-i passwd/make-user boolean false

# Root password, either in clear text
#d-i passwd/root-password password r00tme
#d-i passwd/root-password-again password r00tme
# or encrypted using an MD5 hash.
#d-i passwd/root-password-crypted password [MD5 hash]

# To create a normal user account.
#d-i passwd/user-fullname string Ubuntu User
#d-i passwd/username string ubuntu
# Normal user's password, either in clear text
#d-i passwd/user-password password insecure
#d-i passwd/user-password-again password insecure
# or encrypted using an MD5 hash.
#d-i passwd/user-password-crypted password [MD5 hash]
# Create the first user with the specified UID instead of the default.
#d-i passwd/user-uid string 1010
# The installer will warn about weak passwords. If you are sure you know
# what you're doing and want to override it, uncomment this.
#d-i user-setup/allow-password-weak boolean true

# The user account will be added to some standard initial groups. To
# override that, use this.
#d-i passwd/user-default-groups string audio cdrom video

# Set to true if you want to encrypt the first user's home directory.
d-i user-setup/encrypt-home boolean false

Notice the line:

# Create the first user with the specified UID instead of the default.
d-i passwd/user-uid string 1010

If you want to learn more about automated installations there are several sources of useful information in the Internet. This is the official documentation currently:

https://help.ubuntu.com/lts/installation-guide/armhf/apbs01.html

There are actually valid reasons for this. For instance, I used to work in a lab where we each had our own computer but our $HOME was in a shared drive exported by a server. So, my $HOME was

/users/terdon

Since the /users folder was actually not on my local machine but exported over NFS, for any analysis that was heavy on I/O, I would use data stored on my local hard drives so as not to burden the lab's network. To that end I, and everybody else, had two users: one that was system-wide and one that was local to the machine in question. The local user's home was

/home/localuser

However, I needed to have full access to my files whether I was logged in as terdon or as localuser and the way our sysadmin had implemented that was by giving both localuser and terdon the same UID. That way, I could freely manipulate my local files irrespective of which user I was currently logged in as.

useradd only uses the same UID and GID when either:

• It won't cause a conflict; or

• You force it with the -u and -g flags

It will skip over already-in-use IDs. So, I would guess that you have added other users and/or groups since you created those that have matching UID/GID pairs.¹

To get the IDs back in lock-step, you could create the next one with -g and -u flags to give it IDs equal to one past the highest UID and GID yet assigned. Subsequent useradd calls won't fill the gaps back in. They'll just start numbering past the new high-water mark.

There's nothing wrong with having desynchronized UID and GID values. The system will work perfectly fine in that condition. Old-style Unixes generally didn't use a group-per-user scheme, so that the IDs were never synchronized from the start at all.

Footnotes:

1. You probably did not do this interactively. Many packages add groups, and sometimes users, in order to constrain access to files and other facilities owned by that package. Usually they do this with OS-reserved group IDs below 1000, but not always. When they add a group but not a user, it desynchronizes the two sets of ID values.