Jump to content

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

Recommended Posts

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!


Link to post
Share on other sites

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*

My UDFs and Tutorials:


Active Directory (NEW 2021-06-05 - Version - Download - General Help & Support - Example Scripts - Wiki
OutlookEX (2021-04-13 - Version - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version - Download
Outlook Tools (2019-07-22 - Version - Download - General Help & Support - Wiki
ExcelChart (2017-07-21 - Version - Download - General Help & Support - Example Scripts
PowerPoint (2017-06-06 - Version - Download - General Help & Support
Excel - Example Scripts - Wiki
Word - Wiki
Task Scheduler (2019-12-03 - Version - Download - General Help & Support - Wiki

ADO - Wiki, WebDriver - Wiki


Link to post
Share on other sites
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 by argumentum
Link to post
Share on other sites

@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?



Link to post
Share on other sites

..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.


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 by argumentum
Link to post
Share on other sites

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.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...