Giving Active Directory Group Access to File/Directory own by Local User

Latest response

Using RHEL 7.5 and AD integration is complete.
We have an application running on RHEL that uses a local account.
[root@test ~]# ls -ltr /opt/APP
total 38176
drwxrwx---+ 2 app app 4096 Jul 9 17:20 bin
drwxrwx---+ 12 app app 8192 Aug 2 04:20 run

This is the AD user:
[root@test ~]# id testuser
uid=21313(testuser) gid=10097(jumpboxaccess) groups=10097(jumpboxaccess),10420(app-admin)

How to give testuser permission to access and execute commands inside the /opt/APP/bin/ and /opt/APP/run/ without changing the permissions from 770 to 777?


Hello Ahmed Aziz,

Thanks for posting your issue in the Red Hat discussion area. I'll give this a go and hopefully help. If my post doesn't help, or you need clarification, please post back and either I or another ought to post back to assist further.

ADDED: I put in an example for an active directory group using %nameofactivedirectorygroup below. I think sudoers directives would be a most likely candidate. The bottom paragraph explains what I did in my own environment, and I have an example in the middle of this long (sorry for the length) post.

There are a couple of methods you could use to allow access for "testuser" to access & execute commands within `/opt/APP/{bin,run} directories.

One immediate method you could do is to put a sudo rule for the user in /etc/sudoers. If you look in the man page for sudoers, (it is one of the very best written manual pages that exist) and search for the example for "fred" *(no kidding, and scroll up 3 pages) in the man page for sudoers, you'll find immediate examples on how to set up a sudoer directive.

Here's an example:

You will have to make a list of the items under those two directories for each command under each of the subdirectories

### this would be an excerpt for sudoers file
User_Alias   TESTUSER = testuser
## "test" is the name of the hostname, or enter the ip address instead in the next line where you see "test"
Host_Alias  THISSERVER = testvictim1
# you probably do not need "Runas_Alias since it is just "app" user
## This next line will take some work.

I do not know what executables are within your system below. So this is one possibility to figure out what ought to go into the Cmnd_Alias above.

I can't guarantee this next line will harvest all the commands necessary... If those 2 directories contain subdirectories, you'll have to remove those distractors from this glob I made.

echo `for i in /opt/APP/{run,bin}/*; do echo ${i},;done` |  sed 's/,$//'
/opt/APP/run/runcmd1, /opt/APP/run/runcmd2, /opt/APP/run/runcmd3, /opt/APP/bin/prog1, /opt/APP/bin/prog2
# the ending thing in the line above is an approximation, you'll have to run your own command to get correct output
# remember to remove subdirectories to /opt/app/{bin,run}/ directories to avoid issues with sudoer rules
# important, remember not to have a trailing comma "," at the end of the Cmnd_Alias !!!!
  • Alternative, using this find method below with the "-f" forces only files to be returned!
echo `find /opt/APP/{bin,run} -type f` | sed 's/\ /,\ /g'
/opt/APP/run/runcmd1, /opt/APP/run/runcmd2, /opt/APP/run/runcmd3, /opt/APP/bin/prog1, /opt/APP/bin/prog2

So I made and populated on my RHEL system just now directories /opt/APP/{bin,run}/ with some files posing as commands. I made a user called "testuser" and "app" local to my system, along with corresponding groups. I ran the glob above, and populated my /etc/sudoers (use visudo so that it will complain if there are issues when you exit visudo. Always user visudo to edit the /etc/sudoers file!). And for my system I tested it as this:

(all accounts, files were made on my system prior to this test, I made passwords so I could test sudoer rules)

# excerpt from /etc/sudoers
User_Alias   TESTUSER = testuser
Host_Alias  THISSERVER = testvictim1
Cmnd_Alias = APPCOMMANDS = /opt/APP/run/runcmd1, /opt/APP/run/runcmd2, /opt/APP/run/runcmd3, /opt/APP/bin/prog1, /opt/APP/bin/prog2
# You could also just do this since it is just one user:
# there are other examples for an active directory group below, and the last paragraphs.

For an Active-Directory user here, let's say you had an AD group named "app_commands_allow_sudoer". You could then do something such as this: (see further down for an active-directory group).

#use the previous like directives of User_Alias, Host_Alias, Cmnd_Alias listed in principle in previous examples in this post.
# this would follow those directives in /etc/sudoers
%app_commands_allow_sudoer THISSERVER = (app) APPCOMMANDS

Then I switched to the account "testuser" (I assume it is not a nologin account).

[root@mysystem] # su - testuser
[testuser@mysystem] # sudo -l             # this "-l" here is the letter "l" not the number one 
<output truncated>
User testuser may run the following commands  on testvictim1:
        (app) /opt/APP/run/runcmd1, /opt/APP/run/runcmd2, /opt/APP/run/runcmd3, /opt/APP/bin/prog1, /opt/APP/bin/prog2

I provided the idea of sudo here since the ownership seems to be for an account named as "app". If you do not have to run this as the account "app" then you could perhaps consider adding "testuser" to (hopefully the local) group of "app" on the local system. If the "app" group is not a local group, and the programs do not have to be ran as "app" you could use an acl such as the following:

# back tick character follows after the colon in quotes: "`"

Note the use of "back tick" characters (see block below, identified in quotes above, used in the block below in the find command that is chained to the setfacl. So the setfacl command uses a "back ticked" find command below)

## note, consider this ---if-and-only-if--- it doesn't matter if the user "testuser" has to run this as "app" user with sudo
[root@yoursystem] # setfacl -m u:testuser:rx `find /opt/APP/{run,bin} -type f`

The last example will set acls against all files (not directories) under both of those subdirectories only. Make sure in /etc/fstab that "noexec" is not set for /opt in the options!!!!

  • Allowing sudoer directive for an Active Directory group

However, something I did with one customer that had a never-ending river of changes of developer admins who needed sudoer access. I didn't want to keep maintaining user changes on sudoer directives spread over dozens of computers. I made active directory groups named "allow_sudoer_development_servers" (name the group something sensible for your environment) group in active directory (these were for servers joined directly to active directory). Then in the sudoers file, instead of a user, I used "%allow_sudoer_development_servers" which would point back to the group in active directory. I had the same for production named as such, for the river of developers allowed to touch production. Then the river of changes went to the help desk who had authority to add/change/delete memberships in groups in active directory and made the whole thing tremendously easier. Three years later, I've found they still use this method I established (same as next paragraph)

We also had a directive in /etc/ssh/sshd_config for AllowedGroups (see man page for sshd_config) which was named akin to the group above, such as "dev_admins_allowed_ssh_to_dev_servers" and only then they could log into that group of servers. I had another group for production named as such. We also had a lot of the service accounts in active directory where applicable, where it made sense.

Let us know how this goes, or if you need further assistance,