different feature sets depending on the user's group membership - how?

[orbs]

hi all,

i have a program (my compiled AutoIt script) that should allow or suppress different features, depending on the group membership of the user launching it. currently, what i'm doing is this:

 

in the Active Directory i have created a set of groups, one for each "feature set" of my program. the first two feature sets were "full functionality" and "only produce reports" (meanwhile few more were added, but let's stick to those two for the sake of simplicity). so i created the AD groups "AD_GROUP_MyProgram_Full" and "AD_GROUP_MyProgram_Reporting".

during the installation process on the local machine, i create an equivalent set of groups, and make each AD group a member of the equivalent local group. so i create the local groups "PC_GROUP_MyProgram_Full" and "PC_GROUP_MyProgram_Reporting", and i make the AD group "AD_GROUP_MyProgram_Full" member of the local group "PC_GROUP_MyProgram_Full", and the AD group "AD_GROUP_MyProgram_Reporting" member of the local group "PC_GROUP_MyProgram_Reporting".

in the local installation folder ("C:\Program Files\MyProgram") i create a subfolder for each local group, i.e. "C:\Program Files\MyProgram\FeatureSet_Full" and "C:\Program Files\MyProgram\FeatureSet_Reporting".

knowing that the default permissions for the installation folder is read-only for all users (none running elevated), i then use icacls.exe to break the inheritance of the subfolders and allow read+write permissions to each subfolder only to the equivalent group. so, the local group "PC_GROUP_MyProgram_Full" has read+write permissions to the folder "C:\Program Files\MyProgram\FeatureSet_Full", and the local group "PC_GROUP_MyProgram_Reporting" has read+write permissions to the folder "C:\Program Files\MyProgram\FeatureSet_Reporting". other than that, all groups have the default read-only permissions to the other subfolders.

when my program starts, i check for which of the subfolder i have read+write permissions. depending on that i decide which feature set is available to the user.

 

now, this works; but it is a cumbersome task, which is also difficult to maintain. it also poses a security risk, as the users - regardless of my program - now have write permissions to a subfolder of "C:\Program Files", which is typically used for... well... program files.

i'm looking for suggestions on a simpler way to achieve the goal of allowing different feature sets depending on the user's group membership.

any suggestions are most welcome!

 

[water]

Is there a reason why you create local groups and local directories in C:\program Files?
I would store all output your program generates in @AppDataDir.
I would check the user's permission with a query of his membership in AD_Group*

[argumentum]

Global $_g__MyProgram_Full = 1 ; 1 or 0
Global $_g__MyProgram_Reporting = 1 ; 1 or 0

Why do you need to stop users from access to the folders ? ( don't get me wrong, I like the idea and would love to see the code )
Users usually don't even know what a file structure is. ( usually )
I'd write to an ini in a read only share  ( PC\User=full:1 ;or what not ), the rights and carry on  

Edit: since the program needs the server for the DB, the program is useless without it anyway. Place a loader of sorts, that when not connected tells the user "not connected". ( these assumptions are based in that the program runs in a AD environment )

Edited June 21, 2020 by argumentum

[orbs]

@water, AD is not always present for my program.

although the program is typically installed on domain pc's, there was a need to install it also on a standalone pc, and there may be other such installations. hence the resolution to use local groups, which makes the installation procedure identical for all pc's. for the sysadmin managing the permissions, the AD-dependent installations rely on the AD group membership, and non-AD installations rely on local groups. from the program perspective, there is no difference - only local permissions are examined. this simplifies the programming - i don't need to write extra code to distinguish between AD and standalone installations.

the said folders have no use whatsoever except of checking the user permissions. the reports produced are sent to the user's documents folder (which is a show of bad taste on my part, i admit...).

@argumentum, users neither know nor care of these folders, nor should they. these folders are for internal use only bt my program, and only for checking permissions.

using a network share or other network resource (on which i can apply permissions) is not relevant for my case, because i must accommodate for standalone installations (without AD present).

 

i realize this is not a normal or a standard scenario, and i am trying to explain it the best i can. the method i'm using is a crude workaround (work very far around it seems...), so i'm pretty much stuck with local groups. hence, let me rephrase my question:

different feature sets depending on the user's local group membership - how?

 

 

[argumentum]

..so this way, any Admin can give and remove permissions ( to users ) without having to even touch a GUI to do so, or bother the coder(you) . (my guessing)

Is hard to work with an explanation when to really get down to it, it'd need an explication to be able to elucidate on the matter.  As we code, we have reasons for which we choose a path. Without the reasons, ..it'll be hard to come up with an alternative.
I would go "outside the box", and by "outside the box" I mean outside the impositions of the legacy code.

I know you are a more resourceful coder than I've ever being. So, ...that's all that come to mind at this moment. I really wish I could do more, something useful.

Edit:

34 minutes ago, orbs said:

different feature sets depending on the user's local group membership - how?

a group is a list of users and nothing more. (as far as I know)

Edited June 21, 2020 by argumentum

[BigDaddyO]

There is an app I used to support that used a registry key to store the users access.  it was a 16? character string that looked like binary 10101010101 but each character was Yes/No for if they had access to a specific group.

Only reason I knew about it was for support we had to flip them all to 1 for full admin access.