• State Not Answered
  • Replies 1 reply
  • Subscribers 61 subscribers
  • Views 681 views
  • Users 0 members are here
Options
Related

Lockdown web interface

Shawn.Ferrier
over 1 year ago

This question is a follow-up to this archived thread. In that thread, the only suggestion for addressing a desire to restrict access to specific AR web interfaces was an exploration of creating a new IIS Site. talked about editing Web.config to define roles, etc. While considering this idea as well, this struck me as unviable, since that Web.config file would be shared by all instances of the interface.

The thought that I've had was to create a symlink folder (e.g., C:\Program Files\One Identity\Active Roles\7.5\Web\RestrictedSite) that is a link to "C:\Program Files\One Identity\Active Roles\7.5\Web\Public". Even though the "RestrictedSite" link folder is just a redirect to the "Public" folder, it does allow separate NTFS permissions to be assigned, meaning that I can create multiple sites pointing to the same directory with different sets of permissions. Initial testing seems to suggest that this will work; I was just wondering if anyone else might have tried this and had any success or failure?

Thanks very much,

Shawn.

  • 0 over 1 year ago

    to set the NTFS permissions to limit access to an ARS site by AD group, we had to set NTFS permissions on the physical folder for the new site. 

    If you simply point the secure site back to the same folder, I don't get how you can permission the folder differently - but ready to learn.

    In our instance, we ended up copying the 'Public' Folder and it's content to a parallel folder named 'Private' and set the NTFS permissions on the Private folder.

    In order to redirect the web to the new physical path, we modified the IIS advanced settings for the sites 'Physical Path' to reflect the Server path to the Private folder.

    This had the unintended consequence of hiding the custom PRIVATE site in the ARS web configuration, since 'ARS' is unaware of the non-default path created.  It only knows 'Public'

    i.e. the secure site - just disappeared out of the Configuration Center\Web Interface tab.  Its still there - just ARS only knows 'Public' in the code.

    In order to backup, or edit configuration via ARS configuration center -  of the Secure site, we had to go into IIS and temporarily change the path back to the default PUBLIC path to get it to show up in Configuration Center under Web Interface tab.   after backups or maintenance, we set the physical path back to the secure location to affect the lock-down.  ( and poof - it disappears again in Configuration Center )

    So, we just have a process to follow now - where we hide/unhide the secure site by updating the physical path in IIS as needed.

    Ideally - ARS would recognize and respect the alternate folder to Public ... allowing custom permissions to be set and maintained easily.

    Once the custom secured site is setup, in IIS we configure Authorization Rules in IIS section of the site to allow the custom AD secure-group permission to access the site.

    If there is a simpler way, I'm game.