Lockdown web interface

Hey David,

There is no way to currently lock down access to the sites from within ARS, there may be something that can be done via IIS but I am unaware.

By default, no one has access to anything in ARS unless delegated, so if user's do manage to stumble upon the site it should just be a blank slate essentially.

What a timely topic David.

We're investigating the same.

Interested to see how others approached the issue.  We're currently taking baby steps.

We created a new site under IIS Server\Sites node to keep impact away from the interfaces that are live under a sister site node in IIS Manager.

We've set a custom port, and gave a custom name to differentiate between the production site and the test secure site.

In looking through IIS documentation, they do have a method to specify which AD groups are allowed to access a particular site  ...

in web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        ...
        <security>
            <authorization>
                <remove users="*" roles="" verbs="" />
                <add accessType="Allow" roles="myDomain\myGroup01" />
                <add accessType="Allow" roles="myDomain\myGroup02" />
            </authorization>
        </security>
    </system.webServer>
</configuration>

Like I said, we're at the beginning, taking baby steps here ... so any shared experience from those that have gone through the exercise is appreciated!

my suggestion.

In general. There is no need to luck down AR WI. AR WI is just a client and AR Delegation Roles is supposed to lock the security for any client (AR MMC, WI, scripts) anyway.

AR WI is Itranet only and *not* exposed to Internet.

IIS security. AR WI ApplPool runs under IIS server default local IIS account account with limited local rights.

You may additionally ACL IIS folder with AR WI files allowing Read for dedicated AD\ARS_Users_Group - the standard way to lock any IIS website.

Not sure of Davids specific use-case here, but you've worked with us before Aidar ... we like to shoot ourselves in the foot and then come to  you for better fitting shoes.

In my case, We have delegated everyone view all across all interfaces.  Only change-rights are delegated to groups.

Now, for one specific site, we're asked to lock-down that site so only people with privileged access can connect.  That's where this comes in to play for me.

Which specific folder Aidar?
This?
\Program Files\One Identity\Active Roles\7.3\Web\public\Interfaces\<lockeMEdownsite>

I've started seeing if I could lockdown my policy more.  I created an MU with only Exchange enabled objects in it.  I set my policy to that MU to use the builtin Active Roles groups "Primary Owner" and "Secondary Owner.

In the web interface I can still see all the AD structure.  In the MMC I can't.  Is this supposed to be like that?

I started looking at this also and ran up against the same thing.  I couldn't seem to find the right place to modify the web.config.

Ooooo

C:\Program Files\One Identity\Active Roles\7.2\Web\public\Interfaces\ARWebAdmin
C:\Program Files\One Identity\Active Roles\7.2\Web\public\Interfaces\….

If you really want to restrict the sites, isn't it safer to configure the site permissions in IIS Manager?  There's an option in there that effectively locks down the NTFS permissions on the site.

Messing with web config seems fraught with peril - i.e. user error messing up XML code.

Just sayin',

Configuring in IIS mgr is modifying the web.config.  Well sometimes at least.  It's all about hierarchy I believe. 

Preference being users can't see the AD Structure in the web interface.