Local Accounts Commands in AD Bridge

The AD Bridge Enterprise local authentication provider for local users and groups includes a full local authentication database. With functionality similar to the local SAM authentication database on every Windows computer, the local authentication provider lets you create, modify, and delete local users and groups on Linux and Unix computers by using the following commands.

To execute the commands that modify local accounts, you must use either the root account or an account that has membership in the local administrators group. The account can be an Active Directory account if you manually add it to the local administrators group. For example, you can add the Domain Administrators security group from Active Directory to the local administrators group, and then use an account with membership in the Domain Administrators security group to execute the commands.

To authenticate a local provider user before the machine is joined to a domain, you must run the following commands to enable pam and nsswitch:

domainjoin-cli configure --enable nsswitch
domainjoin-cli configure --enable pam

Command

Description

add-user

Adds a user to the local authentication database.

add-group

Adds a group member to the local authentication database.

del-user

Deletes a user from the local authentication database.

del-group

Deletes a group from the local authentication database.

mod-user

Modifies a user's account settings in the local authentication database, including an account's expiration date and password. You can also enable a user, disable a user, unlock an account, or remove a user from a group.

mod-group

Adds members to or removes members from a group in the local authentication database.

/opt/pbis/bin/mod-group --add- members DOMAIN\\Administrator BUILTIN\\Administrators

Add Domain Accounts to Local Groups

You can add domain users to your local groups on a Linux or Unix computer by placing an entry for the user or group in the /etc/group file. Adding an entry for an Active Directory user to your local groups can give the user local administrative rights. The entries must adhere to the following rules:

  • Use the correct case; entries are case sensitive.
  • Use a user or group's alias if the user or group has one in Active Directory.
  • If the user or group does not have an alias, set the user or group in the AD Bridge Enterprise canonical name format of NetBIOSdomainName\sAMAccountName.

For users or groups with an alias, the AD Bridge Enterprise canonical name format is the alias, which you must use; you cannot use the format of NetBIOS domain name\SAM account name.

For users and groups without an alias, the form of an entry is as follows:

root:x:0:EXAMPLE\kristeva

For users and groups with an alias, the form of an entry is as follows:

root:x:0:kris

In /etc/group, the slash character separating the domain name from the account name does not typically need to be escaped.

On Ubuntu, you can give a domain user administrative privileges by adding the user to the admin group as follows:

admin:x:119:EXAMPLE\bakhtin

Check a User's Canonical Name on Linux

To determine the canonical name of an AD Bridge user on Linux, execute the following command, replacing the domain and user in the example with your domain and user:

getent passwd example.com\\hab
EXAMPLE\hab:x:593495196:593494529: Jurgen Habermas:/home/local/ EXAMPLE/ hab:/bin/ sh

In the results, the user's AD Bridge Enterprise canonical name is the first field.

Extend File Mode Permissions with POSIX ACLs

When you have to grant multiple users or groups access to a file, directory, or Samba share on a Linux server, you can use POSIX access control lists to extend the standard file mode permissions.

Linux and Unix file mode permissions control access only for a single user, a single group, and then everyone else. Thus, the only means of granting access to more than one group with the standard file modes is either to nest the groups together or to give everyone access, approaches that are often unacceptable. Nested groups can be a maintenance burden, and granting access to everyone can undermine security. As for Samba shares, it is insufficient to add multiple users and groups to the valid users parameter in smb.conf if the underlying file system does not allow them access.

Prerequisites:

You must have the acl package installed. You can determine this as follows:

# rpm – qa | grep acl
libacl-2.2.23-5
acl-2.2.23-5

The file system must be mounted with acl in the option list.  You can determine this using the mount command:

# mount
/dev/sda1 on / type ext3 (rw,acl)

As shown above, the root file system has been mounted with read-write (rw) and acl options.  If you do not see acl in the options for the file system you are working with, modify /etc/fstab to include this option, and then remount the file system. In the case of the root file system, you may need to restart the system.

All users and groups must be created before adding them to the ACL. In the case of Active Directory users, they must be preceded by the domain unless user aliases have to be configured (for example, DOMAIN\username).

Example:

This example uses a directory called testdir. The process is the same for files.

Here are the standard file mode permissions of the testdir directory.  

[aciarochi@rhel4-devel tmp]$ ls -ld testdir
drwxrwx---  2 root root 4096 Dec 14 13:28 testdir

You can view the extended ACL using the getfacl utility. In this case, it shows the same information, in a different format:

[aciarochi@rhel4-devel tmp]$ getfacl testdir
# file: testdir
# owner: root
# group: root
user::rwx
group::rwx
other::---

With these permissions, only the root user and members of the root group are allowed to open the directory.  Since the aciarochi user is not in the root group, they are denied access:

[aciarochi@rhel4-devel tmp]$ cd testdir
-bash: cd: testdir: Permission denied

However, we can grant access to aciarochi by using the setfacl utility to add them to the ACL. We must switch to the root user, since that is the directory owner. Once the ACL is set, aciarochi can open the directory:

[root@rhel4-devel ~]# setfacl -m u:aciarochi:rwx /tmp/testdir/
[root@rhel4-devel ~]# exit
logout
[aciarochi@rhel4-devel tmp]$ cd testdir
[aciarochi@rhel4-devel testdir]$ pwd
/tmp/testdir

Notice that the standard file mode permissions have not changed, except for the addition of a plus (+) at the end, indicating that extended file permissions are in effect:

[aciarochi@rhel4-devel tmp]$ ls -ld /tmp/testdir/
drwxrwx---+ 2 root root 4096 Dec 14 13:28 /tmp/testdir/

Additional groups can be added in the same manner, using a g: instead of a u: to indicate a group.  In the following example, we grant read and execute (open) access to the ftp group:

[root@rhel4-devel ~]# setfacl -m g:ftp:r-x /tmp/testdir
[root@rhel4-devel ~]# getfacl testdir
# file: testdir
# owner: root
# group: root
user::rwx
user:aciarochi:rwx
group::rwx
group:ftp:r-x
mask::rwx
other::---

Using POSIX ACLs to Grant AD Accounts Access to Subversion

With AD Bridge, you can use AD accounts with Subversion. Use POSIX ACLs to give a domain group write access to the SVN repository.

Use only one forward slash (/) in /etc/group. The entry is case-sensitive. The domain name must be uppercase and the username lowercase.

Here is an example:

$ svnadmin create /data/foo 

## Add domain admins to the default directory ace 
$ find /data/foo -type d | xargs setfacl -d -m “g:AD\domain^admins:rwx” 

## Add domain admins to the directory ace 
$ find /data/foo -type d | xargs setfacl -m “g:AD\domain^admins:rwx” 

## Add domain admins to the ace for files 
$ find /data/foo -type f | xargs setfacl -m “g:AD\domain^admins:rw” 

$ getfacl /data/foo 
# file: foo 
# owner: AD\134gjones 
# group: AD\134unixusers 
user::rwx 
group::r-x 
group:AD\134domain^admins:rwx 
mask::rwx 
other::r-x 
default:user::rwx 
default:group::r-x 
default:group:AD\134domain^admins:rwx 
default:mask::rwx 
default:other::r-x