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, Unix, and macOS 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
Adds a user to the local authentication database.
Adds a group member to the local authentication database.
Deletes a user from the local authentication database.
Deletes a group from the local authentication database.
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.
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, Unix, or macOS 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:
For users and groups with an alias, the form of an entry is as follows:
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:
On a Mac OS X computer, you can add users to a local group with Apple's directory service command-line utility, dscl. In dscl, go to the /Local/Default/Groups directory and then add users to a group by using the append command.
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
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.
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).
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
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