Overview

This documentation provides information regarding Active Directory ACLs for the administrator accounts used by the WebADM framework (super_admin) or other administator with an access granted through an administartor role.

When a WebADM administrator (super_admin) logs in to the WebADM Admin Portal, they always access and manage the LDAP resources using their own LDAP permissions.

For a WebADM other administrator (other_admins) logging in to the WebADM Admin Portal, their own permissions can be used as with super_admins, or you can choose to use proxy_user permissions in your administrator role configuration. In that case, refer to the proxy_user ACLs documentation.

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 the ACLs listed below, depending on what the administrator is allowed to change in the user’s attributes. If your WebADM Administrator(s) are par of Domain Administrator groups, then all ACLs listed here are not needed.

This documentation is fully dedicated to the super_admins rights.

The necessary permissions for that administrator group(s) depend on the WebADM schema setup chosen during installation. As a reminder, there are two options:

  • Extended Schema setup
  • Not Extended Schema setup

In this documentation, we focus on the domain rcdevsdocs.com.

The User Search Base configured in WebADM Domain is pointing to CN=Users,DC=rcdevsdocs,DC=com.

The Group Search Base configured in WebADM Domain is pointing to CN=Groups,DC=rcdevsdocs,DC=com.

Information needed to setup ACLs and related to the domain:

PS C:\Users\administrator> (Get-ADRootDSE).rootDomainNamingContext
DC=rcdevsdocs,DC=com
PS C:\Users\administrator> (Get-WmiObject Win32_NTDomain).DomainName
RCDEVSDOCS

The super_admins group name value is webadm_admins.

When writing to AD administrators or any privileged AD accounts with a domain user account, additional permissions are necessary due to the fact that AdminSDHolder overwrites these permissions every hour on privileged accounts. Refer to Privileged Accounts sections in that documentation.

AD ACLs for Extended Schema

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

Domain Users

Found below, the different ACLs needed:

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmData'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmSettings'

If you are using the VOICE biometric feature of OpenOTP, then you need the following ACLs:

  • webadmVoice: is the attribute used to store the voice fingerprint. It is useless to configure that ACLs if you are not using that OpenOTP feature under license option.
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmVoice'

Privileged accounts

For writing on AD administrators, rights previously settled are 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. These rights must be applied only if you want to perform OpenOTP logins, Spankey logins or use self-service application with your Domain Admins accounts:

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmData'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmSettings'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;webadmVoice'

AD ACLs for Not Extended Schema

  • bootfile : is the attribute where the applications store the user data (ex. OpenOTP enrolled Token states).
  • bootparameter: is the attribute where WebADM stores user-specific settings (ex. per-user OTP policy).

Domain Users

Found below, the different ACLs needed:

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;bootfile'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;bootparameter'

If you are using the VOICE biometric feature of OpenOTP, then you need the following ACL:

  • audio: is the attribute used to store the voice fingerprint. It is useless to configure that ACLs if you are not using that OpenOTP feature under license option.
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;audio'

Privileged Users

For writing on AD administrators, rights previously settled are 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. These rights must be applied only if you want to perform OpenOTP logins, Spankey logins or use self-service application with your Domain Admins accounts:

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;bootFile'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;bootParameter'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;audio'

Common Permissions

From now on, ACLs are no longer dependent on your schema setup.

Users Actication (licensing)

Activating accounts modifies the objectClass attributes of users you intend to activate.

Domain Users

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;objectClass'

Privileged Users

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;objectClass'

Extra permissions

Provide the following permissions to your super_admins if you want to allow these modification for your WebADM administrators.

Domain Users

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;mail'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;mobile'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;preferredLanguage'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;userPassword'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;unicodepwd'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;lockouttime'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;useraccountcontrol'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:CA;Reset Password'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:WPRP;userCertificate'

Privileged Users

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;mail'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;mobile'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;preferredLanguage'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;userPassword'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;unicodepwd'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;lockouttime'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;useraccountcontrol'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:CA;Reset Password'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:WPRP;userCertificate'

Mobile badging operations

There are no specific permissions needed for your super_admins, as all badging operations are conducted using the permissions of the service account (proxy_user). Refer to proxy_user ACLs documentation.

Permissions for Web Applications

There are no specific permissions needed for your super_admins, as all web application operations done by the end-users are conducted using the permissions of the service account (proxy_user). Refer to proxy_user ACLs documentation.

Spankey purposes

For the following attributes, it makes sense to set the corresponding permissions only if you intend to use Spankey and POSIX extensions in order to retrieve AD users on systems using Spankey client.

  • uidnumber
  • gidnumber
  • unixhomedirectory
  • loginshell

For the following attribute, set the corresponding permissions only if you intend to use Spankey and POSIX extensions in order to retrieve AD groups on systems using Spankey client

  • gidnumber is an attribut used for Spankey groups.

Domain Users

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RPWP;uidnumber'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RPWP;gidnumber'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RPWP;unixhomedirectory'
dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RPWP;loginshell'

Domain Groups

dsacls "CN=Groups,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RPWP;gidnumber'

Privileged Users

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:RPWP;uidnumber'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:RPWP;gidnumber'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:RPWP;unixhomedirectory'
dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:RPWP;loginshell'

Privileged Groups

dsacls "CN=AdminSDHolder,CN=System,DC=rcdevsdocs,DC=com" /G 'RCDEVSDOCS\webadm_admins:RPWP;gidnumber'

ACL on the user search base

The webadm_admins needs to read user objects and user attributes. This can be done thorugh the following ACLs:

dsacls "CN=Users,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:RP'

ACL on the WebADM Configuration Container

In this example CN=webadm,DC=rcdevsdocs,DC=com is our config_container defined in /opt/webadm/conf/webadm.conf:

dsacls "CN=webadm,DC=rcdevsdocs,DC=com" /I:S /G 'RCDEVSDOCS\webadm_admins:GA'

Viewing effective access

In case you are not sure if the permissions are set correctly on a specific user account, you can view the effective access a super_admin user has to another account.

  1. Open Active Directory Users and Computers and find the user experiencing login issues.
  2. Open the "Properties > Security > Advanced Security Settings" page for the user.
  3. First, check permission inheritance. If you see the "Enable inheritance" button, it means the AD object is NOT inheriting permissions from the parent object. This could be because the user was previously in the Domain Admin group.
  4. Next, open the effective access page and select the webadm_admins group you have configured in webadm.conf.
  5. Click the "View Effective Access" button. This will show you the detailed permissions that the super_admin user have on the selected user account.