Proxy User Rights on MS Active Directory
  Download PDF

How To Set the Access Rights for Active Directory

There are two things to be considered in order to implement fine-grained LDAP permission for WebADM and its applications.

  1. WebADM Proxy user permissions: This system user is used by WebADM to access and manipulate the required LDAP resources without an administrator login, for example to increase the false authentication counter.

  2. Administrator users permissions: These accounts login to the Admin portal in order to manage LDAP resources and registered applications.

These users are defined in /opt/webadm/conf/webadm.conf with proxy_user and super_admins.

1. Proxy User

Proxy user needs to perform wide LDAP search and reads. It also requires read-only permissions to the WebADM LDAP configurations (ie. configured containers) and to the user Domains subtrees. Proxy user needs to do some write operations to a few LDAP attributes because it needs to store dynamic application user data into the users.

In some circumstances, the Proxy user will also need to write application setting on the users and groups. The following attributes are part of the WebADM LDAP schema and need Proxy user write permissions:

  • webadmData: is the attribute where the applications store the user data (ex. OpenOTP enrolled Token states).

  • webadmSettings: is the attribute where WebADM stores user-specific settings (ex. per-user OTP policy).

If you use WebADM Self-Services, and depending on what you allow users to do within the Self-Service applications, then WebADM Proxy user may need some additional permissions:

Example if you want users to reset their LDAP password, set their mobile numbers or email addresses, then the Proxy user will need to have write permissions to the corresponding LDAP attributes.

In general, it is recommended to implement Proxy user write access to the following attributes:

  • webadmData (dynamic and encrypted application data)

  • webadmSettings (only if Self-Services are used to configure account settings)

  • mail (only if Self-Services are used to set email addresses)

  • mobile (only if Self-Services are used to set mobile numbers)

  • preferredLanguage (only if Self-Services are used to set user language)

  • userPassword or unicodePwd for Windows AD (only if Self-Services are used to set user password)

1.1. With Graphical Interface

Note

With AdminSDHolder protection, a standard service account for WebADM proxy_user works for domain users but NOT for domain administrators. If you want to use WebADM/OpenOTP with domain administrator accounts, please refer to the setup with Powershell.

1.1.1. Rights for an Extended Schema

To set the good rights, go on your Active Directory interface, create a user (in our example the user is named proxyuser).

Complete the required information and click on Next:


Set the proxy user password and click on Next:


Click on finish:


My proxy user is created. Now, we will create a delegation of control for the proxy user. For this, select your user search base used by WebADM. In my example, my user search base is:

cn=Users,dc=ad,dc=rcdevs,dc=com

Right click on your user search base and Delegate Control:


Select your proxy user previously created:


On the next page, check the box Create a custom task to delegate:


Check the box Only the following objects in the folder and select webadmAccount objects at the end of the list. Click on Next:


On the next page, select every attributes you need. Look the screenshots below:


After that, click on Next and Finish:


To authorize the proxy user to change users password, you have to do another delegation of control for this permission.

As above, right click on your user search base and click on Delegate Control. Click on Next, select your proxy user and click on Next. Check the box Create a custom task to delegate and click on Next. On the next page, check the box Only the following objects in the folder : At the end of this list, you will find User objects, please check this box and click on Next:


In general permissions, you can find Change password, check this box, click on Next and Finish.

Proxy user rights are now settled.

1.1.2. Rights for a Not Extended Schema

Without schema extension, WebADM does not make any addition to the Active Directory schema. Instead the WebADM configuration is customised to re-use some existing object classes and attributes.

The following changes are applied to the configurations:

In conf/webadm.conf, the default configurations: webadm_account_oclasses “webadmAccount”.

webadm_group_oclasses "webadmGroup" 
webadm_config_oclasses "webadmConfig"
webadm_data_attrs "webadmData" 
webadm_settings_attrs "webadmSettings" 
webadm_type_attrs "webadmType"

Are changed to:

webadm_account_oclasses "bootabledevice"
webadm_group_oclasses "bootabledevice"
webadm_config_oclasses "device"
webadm_data_attrs "bootFile" 
webadm_settings_attrs "bootParameter" 
webadm_type_attrs "serialNumber"

WebADM will also use the AD object class bootabledevice as user/group activation class and the object class device for the LDAP configuration objects’ storage. It will also store user settings and metadata in the bootFile and bootParameter attributes in the bootabledevice class.

So, to configure these rights, right click on your User search base, Delegate Control.

Select your proxy user previously created :


On the next page, check the box Create a custom task to delegate :


Check the box Only the following objects in the folder and select bootableDevice objects. Click on Next.


On the next page, check the following permissions and press on Next and Finish:


For the other attributes, see above in the extended schema section.

1.2. With PowerShell

In this example, we work with the domain test.local:

PS C:\Users\administrator> (Get-ADRootDSE).rootDomainNamingContext
DC=test,DC=local
PS C:\Users\administrator> (Get-WmiObject Win32_NTDomain).DomainName
TEST

We create a proxy user:

PS C:\Users\administrator> New-ADUser -Name "proxy_user" -AccountPassword (Read-Host -AsSecureString "AccountPassword") -PassThru | Enable-ADAccount
AccountPassword: ***********

Once the proxy user is created, we can set minimal rights easily with Powershell for all groups and users in Users container:

dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;webadmData'
# replace webadmData with bootFile if the schema is not extended
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;webadmSettings'
# replace webadmSettings with bootParameter if the schema is not extended

We can also add access rights to others attributes in the same way:

dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;mail'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;mobile'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;preferredLanguage'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\proxy_user:WP;userPassword'

For writting on AD administrators, it’s not enough because AdminSDHolder overwrites these rights every hour. So we need also to apply thes rules on AdminSDHolder object and wait one hour that it’s applied on all admin users and groups of the domain:

dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;webadmData'
# replace webadmData with bootFile if the schema is not extended
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;webadmSettings'
# replace webadmSettings with bootParameter if the schema is not extended
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;mail'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;mobile'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;preferredLanguage'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\proxy_user:WP;userPassword'

2. WebADM Administrator

When an WebADM administrator logs in the WebADM Admin Portal, he always accesses and manages the LDAP resources under his own LDAP permissions. This means the user/group/configuration management permissions are enforced at the LDAP level. For example, a Windows AD Domain Administrator will be able to manage users and groups.

If the WebADM administrator is not an Active Directory administrator, we need to add permissions, depending on what the administrator is allowed to change in user’s attributes:

  • objectClass (only if admin portal is used to activate a user)

  • webadmData (only if admin portal is used to manage tokens)

  • webadmSettings (only if admin portal is used to configure account settings)

  • mail (only if admin portal is used to set email addresses)

  • mobile (only if admin portal is used to set mobile numbers)

  • preferredLanguage (only if admin portal is used to set user language)

  • userPassword or unicodePwd for Windows AD (only if admin portal is used to set user password)

The WebADM administrator needs also permissions for all Webadm containers.

2.1. With PowerShell

In this example, we work with the domain test.local:

PS C:\Users\administrator> (Get-ADRootDSE).rootDomainNamingContext
DC=test,DC=local
PS C:\Users\administrator> (Get-WmiObject Win32_NTDomain).DomainName
TEST

We create a WebADM administrator group and add the user john in it:

PS C:\Users\administrator> New-ADGroup -Name "webadm_admins" -GroupScope Global
PS C:\Users\administrator> Add-ADGroupMember -Identity "webadm_admins" -Member john

We set minimal rights easily with Powershell for all groups and users in Users container:

dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;objectClass'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;webadmData'
# replace webadmData with bootFile if the schema is not extended
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;webadmSettings'
# replace webadmSettings with bootParameter if the schema is not extended

We can also add access rights to others attributes in the same way:

dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;mail'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;mobile'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;preferredLanguage'
dsacls "CN=Users,DC=test,DC=local" /I:T /G 'TEST\webadm_admins:WP;userPassword'

For writting on AD administrators, it’s not enough because AdminSDHolder overwrites these rights every hour. So we need also to apply these rules on AdminSDHolder object and wait one hour that it’s applied on all admin users and groups of the domain:

dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;objectClass'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;webadmData'
# replace webadmData with bootFile if the schema is not extended
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;webadmSettings'
# replace webadmSettings with bootParameter if the schema is not extended
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;mail'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;mobile'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;preferredLanguage'
dsacls "CN=AdminSDHolder,CN=System,DC=test,DC=local" /G 'TEST\webadm_admins:WP;userPassword'

In this example, all WebADM configuration containers are under CN=webadm,DC=test,DC=local, we add full access to all descendants of this container:

dsacls "CN=webadm,DC=test,DC=local" /I:S /G 'TEST\webadm_admins:GA'