Secure the PeopleUpdate Administration Console

  1. Home
  2. Knowledge Base
  3. PeopleUpdate
  4. Secure the PeopleUpdate Administration Console
  1. Home
  2. Knowledge Base
  3. PeopleSearch
  4. Secure the PeopleUpdate Administration Console

Securing the Administration Console
You can secure the PeopleUpdate Administration Console to restrict access to a set of authorized users in your environment. PeopleUpdate leverages ASP.NET security to check user credentials and authorize access to the Administration Console and this security works by using Windows authentication to examine the current user accessing PeopleUpdate.

By default, PeopleUpdate ships with an Administration Console security configuration that allows everyone to access it. You can set Windows groups or individual users to access PeopleUpdate and Web Active Directory recommends that you only use groups as a best practice to control access to the Administration Console.

To restrict access to the Administration Console:

Navigate to the PeopleUpdate installation directory on the web server where you installed PeopleUpdate. This directory is by default located at C:\inetpub\wwwroot\PeopleUpdate but may be in a different location depending on your environment. You can look up the location using Internet Services Manager and examining the PeopleUpdate application’s home directory.

Open the Web.config file–located in the PeopleUpdate installation directory’s root–with a text editor like Notepad.

Find the two elements near the end of the Web.config file, one with a path=”AdminPage.aspx” attribute and the other with a path=”UserControls/Admin” attribute. These location elements and their child nodes control access to the Administration Console by restricting access to the page and directory that contain the Administration Console files. The excerpt below shows the configuration for the elements and includes the %domain% and %group% placeholders you can use to restrict access to the Administration Console.

Important Note: Make sure you move the closing XHMTL comments (<!– and –>) so the location elements get processed by the security system. You need to ensure the closing element (–>) is above the location elements and not below.


< location path="AdminPage.aspx">
<system.web>
<authorization>
<allow roles="%domain%\%group%" />
<deny users="*" />
</authorization>
</system.web>
< /location>
< location path="UserControls/Admin">
<system.web>
<authorization>
<allow roles="%domain%\%group%" />
<deny users="*" />
</authorization>
</system.web>
< /location>

Modify the <allow /> and <deny /> elements to allow access to the select group or groups of Windows users who need access to the Administration Console while denying access to everyone else. Add roles and users attributes to the elements to determine which groups (roles) and users are allowed and denied access. Ensure you include the domain name followed by the group or user name in the appropriate roles or users attribute values and separate multiple roles or users using commas. You may also employ the asterisk character (*) as a wildcard meaning all users or roles (depending on the attribute) and the question mark character (?) to mean anonymous access.

 

The following examples help you understand how to implement this security.

  • Allow access to IT and HR groups and deny access to everyone else

    <allow roles="MYDOMAIN\IT, MYDOMAIN\HR" />
    <deny users="*" />
  • Allow access to IT group and HR user and deny access to everyone else

    <allow roles="MYDOMAIN\IT" users="MYDOMAIN\HR User" />
    <deny users="*" />
  • Allow access to IT group and deny HR user explicitly

    <allow roles="MYDOMAIN\IT" />
    <deny users="MYDOMAIN\HR User" />

Save your changes and test the Administration Console with user accounts in different groups to ensure you have properly configured the security to allow and deny access.

Was this article helpful?

Related Articles

Sign in
classic
Forgot password?
×
Sign up

(*) Required fields

I agree with OptimaSales Terms & Privacy Policy

×