FAQ

Softerra Adaxes does not extend the AD schema. Moreover, Softerra Adaxes does not store its data in Active Directory and doesn't modify the native permissions assigned in AD. If you uninstall Softerra Adaxes, you can use Active Directory just you did before the product installation.

In Adaxes, permissions are granted via Security Roles. To view the Security Roles that grant permissions to a user:

1. Launch Adaxes Administration Console.
2. Right-click the user you need and then click Properties in the context menu.
3. Activate the Security Roles tab.
4. In the dialog box that opens, the Security Roles that grant permissions to the user will be displayed. To locate a Security Role, right-click it and then click Locate Role in Tree in the context menu.

By default, SSL is not configured for the Adaxes Web Interface and network transmissions are not encrypted. However, you can configure SSL on the Adaxes Web Interface the way you do it for any other website hosted by IIS. If you configure SSL on the Adaxes Web Interface, it will work in both cases: with Windows-integrated authentication and with forms-based authentication.

Softerra Adaxes is licensed in packages based on the number of enabled and not expired user accounts in your AD domain(s). To check the number of enabled and not expired user accounts in all managed Active Directory domains:

• Launch Adaxes Administration Console.

• In the Console Tree, right-click your Adaxes service and click Properties.

  

• In the Licensing section, the total number of all enabled and not expired user accounts in managed AD domains is displayed.

  

Once you've purchased a license for Softerra Adaxes, all you need to do is activate your license key. No need to reinstall or reconfigure the product. After that you can continue using Adaxes just as you did during the evaluation period.

Adaxes service uses the LDAP protocol to communicate with Active Directory. Interaction between the Adaxes service and Active Directory is secured for security-sensitive operations only. For example, prior to change or reset a password for an AD user, an SSL connection is established and the data are sent via an encrypted channel.

Interaction between Adaxes clients and Adaxes services is always performed using an encrypted TCP channel.

You can search for objects in all the Active Directory domains managed by Adaxes. Just select Everywhere in the Look in drop-down menu when performing a search.

All operations performed via Adaxes service are logged in the Service Log. You can view the log using Adaxes Administration Console.

To find the initiator of an operation:

1. Launch Adaxes Administration Console.
2. In the Console Tree, expand the service node.
3. Select Logging.
4. All operations performed via the Adaxes service will be displayed in the Result Pane on the right. The user who performed an operation is displayed in the Initiator column.
5. To view log records only for operations manually performed by users, select User in the Filter Initiator drop-down list.
6. To locate the user who initiated an operation, right-click the operation, navigate to Locate in Tree, and click Initiator.

Use the built-in Empty Groups and Empty OUs reports:

1. Launch Adaxes Administration Console.
2. In the Console Tree, expand the service node.
3. Navigate to Reports / All Reports.
4. Select the report you need:
   • Organizational Units \ OU Contents \ Empty OUs
   • Groups \ Empty Groups
5. Generate the report.

Adaxes itself doesn't store the password for the Adaxes service account. Adaxes service is installed as a Windows system service that runs under the Adaxes service account. The logon information for this system service is specified during Adaxes installation and is stored by Windows.

Credentials for managed AD domains are encrypted using the Data Protection API (DPAPI) provided by the Windows operating system. These encrypted credentials are stored locally on the computer where the Adaxes service runs and associated with the Adaxes service account, which means that only processes running under this account can unprotect the data.

To check for pending approval requests using Adaxes Administration Console:

1. In the Console Tree, expand the service node.
2. Expand Configuration and select Approval Requests.
3. In the Result Pane on the right, select My Approvals and then select Pending.

To check for pending approval requests using Adaxes Web Interface:

1. In the top right corner, click your username.
2. Click My Approvals.
3. Requests awaiting your approval will be displayed.

1. Install the first instance of Adaxe service. This will create a configuration set with only one Adaxes service.

2. During installation of the second instance of Adaxes service, join it to the configuration set:

   • Launch the Softerra Adaxes Installer.
   • On the Service Configuration page, select Shared configuration.
   • Specify the DNS host name of an Adaxes service from the configuration set.
   • Provide the credentials of the Adaxes service account of any Adaxes service in the configuration set.
   • Follow the instructions in the wizard.

For more details, see Multi-Server Deployment for High Availability.

In Adaxes, permissions are granted via Security Roles. To view the Security Roles that grant permissions on an object:

1. Launch Adaxes Administration Console.
2. Right-click the object you need and then click Properties in the context menu.
3. Activate the Effective Objects tab.
4. Click Security Roles.
5. In the dialog box that opens, the Security Roles that grant permissions on the object will be displayed.
   To locate a Security Role, right-click the role you need and then click Locate Role in Tree in the context menu.

Using Property Pages

1. Launch Adaxes Administration Console.
2. Select the user accounts you need, right-click and then click Properties in the context menu.
3. Select the checkbox for the property you need.
4. Specify a new property value and click OK.

Using the Add/Modify Property wizard

1. Launch Adaxes Administration Console.
2. Select the user accounts you need, right-click and then click Add/Modify Property in the context menu.
3. Follow the instructions in the wizard that opens.

You need to grant users the permissions to modify properties of their own account and add fields for the properties to the corresponding form in Adaxes Web Interface. For details, see Allow Users to Modify Specific Properties of Their Accounts.

To automate user deprovisioning, you can use the built-in Custom Command Deprovision. For information on how to configure this Custom Command, see tutorial Configure User Deprovisioning.

Also, to deprovision user accounts automatically, you can use other automation facilities provided by Adaxes, such as Scheduled Tasks. For detailed description on how to use Scheduled Tasks for user deprovisioning, see tutorial Automatically Deprovision Inactive AD Users.

You do not need to create a trust between AD domains to manage them with an Adaxes service. When registering an AD domain, an account with administrative permissions is specified. All operations performed via the Adaxes service in this AD domain are executed using this account. To control the user access to the managed resources, the Adaxes service uses Security Roles.

Adaxes Service

To enable communication between Adaxes service and Active Directory, the following ports (TCP and UDP) must be open for outgoing connections on the computer where your Adaxes service is installed, and for incoming connections on the Domain Controller(s) that you want Adaxes to connect to.

• 389 LDAP - to connect to Active Directory
• 636 LDAP (SSL) - to connect to Active Directory via SSL
• 3268 GC - to connect to AD Global Catalog
• 88 Kerberos - for authentication
• 135 RPC - to resolve AD user names
• Dynamic RPC ports* - to communicate with Active Directory

• 80 HTTP - if Adaxes service and Exchange are installed in the same forest
• 443 HTTPS - if Adaxes service and Exchange are installed in different forests

Also, you need to allow Adaxes service to ping Active Directory domain controllers. To do this, enable Echo ICMP Requests (ping) in the firewall settings.

Adaxes Clients

Adaxes Web Interface and Adaxes Administration Console use the following ports (TCP and UDP):

• 389 LDAP - to connect to Active Directory
• 135 RPC - to resolve AD user names
• 54782 - for communication with the Adaxes service
• Dynamic RPC ports* - to communicate with Active Directory

It is possible to change the port used for communication between Adaxes service and Adaxes clients (Web Interface and Administration console). For this purpose you need to change the port attribute of the following XML element of the Adaxes service configuration file (Softerra.Adaxes.Service.exe.Config):

<configuration>
  ...
    <system.runtime.remoting>
    <customErrors mode="Off" />
    <application>
      <channels>
        <channel ref="tcp" port="54782" priority="2" secure="true">

The Softerra.Adaxes.Service.exe.Config file is located in the folder where the Adaxes Service is installed (by default, C:\Program Files\Softerra\Adaxes 3\Service).

* To enable communication through dynamic RPC ports:

• Open the full range of dynamic RPC ports (1024-5000 for Windows 2003, 49152-65535 for Windows 2008 and higher).
  OR
• On Windows Server 2008 or higher, you can configure the Windows firewall to open RPC ports dynamically. If you do this there is no need to open a port range for dynamic RPC. For details, see Allowing Inbound Network Traffic that Uses Dynamic RPC.
  OR
• Explicitly specify which RPC port must be used by Active Directory, and open that port. For details, see Restricting Active Directory replication traffic and client RPC traffic to a specific port

To upgrade to a new version and keep all configuration settings, you need to backup the current configuration, re-install Adaxes and then restore the configuration.

For details, see Upgrade to New Version.

Sometimes, if an Adaxes service was not uninstalled properly, Adaxes Administration Console shows the removed instance in the list of available Adaxes services.

The easiest way to clear the registration information is to install Adaxes service on the same computer again, register all the AD domains, and uninstall the service. If you cannot do this, read the rest of this article.

Information about available Adaxes services is stored in Active Directory. To publish the information, Adaxes uses Service Connection Points (SCPs). To clear the registration information, you need to delete appropriate Service Connection Point entries in Active Directory:

1. Launch Adaxes Administration Console.

2. In the Console Tree, expand the node of your Adaxes service, right-click Active Directory, and then select Find.

   

3. In the dialog that opens, select the LDAP Search tab.
4. Type the following LDAP filter: (&(objectCategory=serviceConnectionPoint)(keywords=1.3.6.1.4.1.15741.2.3.1))

5. Click Find Now. Adaxes will search for all the SCPs of Adaxes services in all managed Active Directory domains:

   

By default, the language of Self-Password Reset screen is selected based on the original locale that was specified when installing Windows. To change it, you need to update the configuration of Internet Explorer.

Configuring the language for a specific computer

1. Log on to the computer you want to configure.
2. Run the registry editor (regedit.exe) as Administrator:
3. • Click Start.
   • Type regedit.
   • Right-click the icon.
   • Click Run as Administrator.
4. Navigate to the following registry key: HKEY_USERS\.DEFAULT\Software\Microsoft.

5. Right-click the Internet Explorer key, select New and click Key.

   If Internet Explorer key is missing you will need to create it manually:
   - Right-click the Microsoft key, select New and click Key.
   - Type Internet Explorer and press Enter.

6. Type International and press Enter.
7. Right-click the International key, select New and click String value.
8. Type AcceptLanguage and press Enter.
9. Right-click the AcceptLanguage string and click Modify.
10. In the Value data field enter the language code (e.g. fr-FR for French).
11. Click OK.

Configuring the language for multiple computers

If you want to configure the language administratively for multiple computers in your AD environment, you can do that via Group Policies.

1. Log on to your domain controller as a Domain Administrator.

2. Run the Microsoft Management Console:

   • Press Win+R.
   • Type mmc/a.
   • Press Enter.
3. Press Ctrl+M. This will bring up the Add or Remove Snap-ins dialog.
4. Select Group Policy Management and click Add >.
5. Click OK.

6. In the Group Policy Management console, navigate to the OU with the target computers and right-click it.

   - or -

   Right-click the domain if you want to apply the settings to the whole domain.

7. Click Create a GPO in this domain and Link it here.
8. Enter a name for the GPO and click OK.
9. Right-click the GPO you've created and click Edit.
10. Navigate to Computer Configuration\Preferences\Windows Settings node.
11. Right-click Registry, select New and click Registry Item.

12. Specify the following settings:

    • Action: Create.
    • Hive: HKEY_USERS.
    • Key Path: .DEFAULT\Software\Microsoft\Internet Explorer.
    • Value name: Select the Default checkbox.
    • Value type: REG_SZ.
    • Leave the Value data field empty.
13. Click Apply and then click OK.
14. Right-click the Registry node, select New and click Registry Item again.

15. Specify the following settings:

    • Action: Create.
    • Hive: HKEY_USERS.
    • Key Path: .DEFAULT\Software\Microsoft\Internet Explorer\International.
    • Value name: Select the Default option.
    • Value type: REG_SZ.
    • Leave the Value data field empty.
16. Click Apply and then click OK.
17. Right-click the Registry node, select New and click Registry Item again.

18. Specify the following settings:

    • Action: Replace.
    • Hive: HKEY_USERS.
    • Key Path: .DEFAULT\Software\Microsoft\Internet Explorer\International.
    • Value name: AcceptLanguage.
    • Value type: REG_SZ.
    • Value data: input the language abbreviation (e.g. fr-FR for French).
19. Click Apply and then click OK.

The settings will be applied to computers within the GPO scope as soon as they refresh group policies applied to them.