Aug 142012
 
If you want to find the system ID of the user type:
	id username

You can check what groups a user belongs to by using the "groups" command.
	groups <username>

To create a user with the default groups type:
	sudo adduser --add_extra_groups username
        Fedora: sudo adduser -m username

To delete a user and its primary group type:
	sudo deluser username

To delete user and files in the user's home directory along with the home 
directory itself and the user's mail spool (Fedora).
        sudo userdel -r username

To add an existing user to an existing group type:
	sudo usermod -a -G thegroupname theusername
	sudo usermod -a -G thegroupname theusername
	sudo useradd -G thegroupname theusername

Use gpasswd:
	sudo gpasswd -a theusername thegroupname

To remove user billybob from the group hillbilly.
	gpasswd -d billybob hillbilly

To give user billybob administrative rights to the group hillbilly.
	gpasswd -A billybob hillbilly

To Change a users primary group type:
	useradd -g www joebob

To show users that are in a group named joebob type:
	getent group joebob

To temporarily lock or unlock a user account, use the following syntax, respectively: 
	sudo passwd -l username 
	sudo passwd -u username 

If you want to use the GUI you will have to install the gnome-system-tools 
	sudo apt-get install gnome-system-tools 

Here are a few ways to run it once it is installed type: 
	sudo users-admin 
Press Alt+F2 
Type 
	sudo users-admin 
Press Enter. Press Ctrl+Alt+T. 
Type 
	sudo users-admin
Press Enter. 

If you want to add a group type: 
	sudo groupadd foo 
	sudo addgroup groupname 

If you want to delete a group type: 
	sudo delgroup groupname 

User Profile Security when a new user is created, the adduser utility creates a 
brand new home directory named /home/username, respectively. The default profile 
is modeled after the contents found in the directory of /etc/skel, which includes 
all profile basics. If your server will be home to multiple users, you should pay 
close attention to the user home directory permissions to ensure confidentiality. 
By default, user home directories in Ubuntu are created with world read/execute 
permissions. This means that all users can browse and access the contents of other 
users home directories. This may not be suitable for your environment. 

To verify your current users home directory permissions, use the following syntax: 
	ls -ld /home/username 

	The following output shows that the directory /home/username has world 
readable permissions: drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username 
You can remove the world readable permissions using the following syntax: 
	sudo chmod 0750 /home/username 

Some people tend to use the recursive option (-R) indiscriminately which modifies 
all child folders and files, but this is not necessary, and may yield other 
undesirable results. The parent directory alone is sufficient for preventing
unauthorized access to anything below the parent. A much more efficient approach 
to the matter would be to modify the adduser global default permissions when creating 
user home folders. Simply edit the file /etc/adduser.conf and modify the DIR_MODE 
variable to something appropriate, so that all new home directories will receive the 
correct permissions. 
	DIR_MODE=0750 

After correcting the directory permissions using any of the previously mentioned 
techniques, verify the results using the following syntax: 
	ls -ld /home/username 

The results below show that world readable permissions have been removed: 
drwxr-x--- 2 username username 4096 2007-10-02 20:03 username Password Policy A 
strong password policy is one of the most important aspects of your security posture. 
Many successful security breaches involve simple brute force and dictionary attacks 
against weak passwords. If you intend to offer any form of remote access involving 
your local password system, make sure you adequately address minimum password 
complexity requirements, maximum password lifetimes, and frequent audits of your 
authentication systems. Minimum Password Length By default, Ubuntu requires a minimum 
password length of 4 characters, as well as some basic entropy checks. These 
values are controlled in the file /etc/pam.d/common-password, which is outlined 
below. password required pam_unix.so nullok obscure min=4 max=8 md5 If you would 
like to adjust the minimum length to 6 characters, change the appropriate variable 
to min=6. The modification is outlined below. password required pam_unix.so nullok 
obscure min=6 max=8 md5 The max=8 variable does not represent the maximum length of 
a password. It only means that complexity requirements will not be checked on 
passwords over 8 characters. You may want to look at the libpam-cracklib package for 
additional password entropy assistance. Password Expiration When creating user 
accounts, you should make it a policy to have a minimum and maximum password age 
forcing users to change their passwords when they expire. 

To easily view the current status of a user account, use the following syntax: 
	sudo chage -l username 

The output below shows interesting facts about the user account, namely that there 
are no policies applied: Last password change : Jan 20, 2008 Password expires : 
never Password inactive : never Account expires : never Minimum number of days 
between password change : 0 Maximum number of days between password change : 99999 
Number of days of warning before password expires : 7 To set any of these values, 
simply use the following syntax, and follow the interactive prompts: 
	sudo chage username 

The following is also an example of how you can manually change the explicit 
expiration date (-E) to 01/31/2008, minimum password age (-m) of 5 days, maximum 
password age (-M) of 90 days, inactivity period (-I) of 5 days after password 
expiration, and a warning time period (-W) of 14 days before password expiration. 
sudo chage -E 01/31/2008 -m 5 -M 90 -I 30 -W 14 username To verify changes, use the 
same syntax as mentioned previously: 
	sudo chage -l username 

The output below shows the new policies that have been established for the account: 
	Last password change : Jan 20, 2008 
	Password expires : Apr 19, 2008 
	Password inactive : May 19, 2008 
	Account expires : Jan 31, 2008 
	Minimum number of days between password change : 5 
	Maximum number of days between password change : 90 
	Number of days of warning before password expires : 14 

Other Security Considerations Many applications use alternate authentication 
mechanisms that can be easily overlooked by even experienced system administrators. 
Therefore, it is important to understand and control how users authenticate and gain 
access to services and applications on your server. SSH Access by Disabled Users 
Simply disabling/locking a user account will not prevent a user from logging into 
your server remotely if they have previously set up RSA public key authentication. 
They will still be able to gain shell access to the server, without the need for any 
password. Remember to check the users home directory for files that will allow for 
this type of authenticated SSH access. e.g. /home/username/.ssh/authorized_keys. 
Remove or rename the directory .ssh/ in the user's home folder to prevent further 
SSH authentication capabilities. Be sure to check for any established SSH connections 
by the disabled user, as it is possible they may have existing inbound or outbound 
connections. Kill any that are found. Restrict SSH access to only user accounts that 
should have it. 

For example, you may create a group called "sshlogin" and add the group name as the 
value associated with the AllowGroups variable located in the 
file /etc/ssh/sshd_config. 
	AllowGroups sshlogin 

Then add your permitted SSH users to the group "sshlogin", and restart the SSH service. 
	sudo adduser username sshlogin 
	sudo /etc/init.d/ssh restart 

MakeUser Function for .bashrc file:

  makeuser () { 
  if [ $# -eq 0 ] 
  then 
  echo "Usage: makeuser username." 
  else 
  sudo adduser --add_extra_groups $1 
  fi 
  } 

Source for most of this document:

Jul 202012
 
To read the information about a group type:

dseditgroup -o read ladmins

Or the following has the same output:

dseditgroup read ladmins

In the case of a namespace collision between two ladmins in two directory services
then the one listed highest in the Search Policy would be displayed. The

dseditgroup create -n /Local/Default -r “Local Admins2″ ladmins2

Now read the group you just created and you’ll notice that it has a GeneratedUID
and a PrimaryGroupID even though one was not specified. Let’s say you wanted to
manually assign the PrimaryGroupID so you could hide a group; you could do so with
a -i parameter and not that many want to you could also use the -g option to
manually provide a GeneratedUID. Other parameters include -u and -P for placing the
username and password into the command (ie – if you’re creating groups in LDAP), -a
if you want to use the group name as a parameter rather than just trail the command
with it, -n to define the Directory Domain node (ie – /LDAPv3/MYDOMAIN vs.
/Local/Default vs. /var/Hidden), if you wanted to place keywords or comments then
use the -k or -c respectively and encase them in doublequotes (“).

Editing group memberships:

dseditgroup -o edit -n /Local/Default -a cedge -t user ladmins

In the above command we defined the node we were editing with the -n followed by the
user we were adding to the group with the -a and then the -t for the type of object
we’re adding into the group, which is listed last. The reason that you have to put
the -t with user in there is because we could just as easily have said:

dseditgroup -o edit -n /Local/Default -a staff -t group ladmins

Which would have put a group called staff into the ladmins group (noted by the
NestedGroups attribute).

To verify membership, use the checkmember verb (insert witty Beavis and Butthead
remark here;). If su’d the following command is likely to report back with the fact
that no, root has not been added to the group; otherwise it will look at your
currently logged in account:

dseditgroup -o checkmember ladmins

But you can check and see whether my account is a member of your ladmins group with
the -m parameter on the command:
dseditgroup -o checkmember -m cedge ladmins
Now finally, since no one likes a messy Marvin, to delete our test group:

dseditgroup -o delete -n /LDAPv3/ldap.company.com -u myusername -Pmypassword extragroupdseditgroup -o delete -n /Local/Default ladmins2