Softerra Adaxes 2011.1 comes with several long-awaited features aimed to simplify the daily routine of AD administrators and introduces an entirely new user experience for Help Desk technicians and regular users. Features included in the new release are focused around customization of the Active Directory Web Interface, enhancing Active Directory automation facilities, streamlining user password management, AD administration and access control. Below are the highlights of the new major features and important changes in Softerra Adaxes 2011.1.
It often happens that you regularly need to perform a similar set of actions to accomplish a particular task in AD. For example, every time an employee goes on a vacation, you need to disable the account of the employee, forward the employee's e-mail to another user, set an out-of-office message for the employee's mailbox, etc. Some AD administrators tend to create scripts to perform such custom tasks. Unfortunately, scripts are not easy to use, and are hardly appropriate when you need to delegate AD tasks to non-administrative users like Help Desk operators or HR managers. To solve such problems a higher-level solution is needed.
With the new version of Adaxes you can define your own custom commands to perform complex and routine AD management tasks at the click of a mouse.
Users can execute custom commands in the same way they execute any other operations in the Adaxes Administration Console or Web Interface:
With the help of Custom Commands you can perform practically any operations on AD objects, including:
If necessary, certain Custom Command actions can be performed only if certain conditions are met:
For more details, see tutorial: Create a Custom Command
To perform Custom Commands, users must be granted appropriate permissions. It is possible to allow or deny the execution of either a specific custom command or all custom commands defined in Adaxes. The rights for Custom Command execution, as well as any other rights in Adaxes, are granted with the help of Security Roles. This enables you to, for example, allow specific users or groups to perform specific custom commands only on the AD objects located in a specific OU, on the members of a specific group or Business Unit, on all objects located in several AD domains, etc.
For more details, see tutorial: Grant Rights to Execute Custom Commands
When an employee leaves an organization, the account of this employee should be properly deprovisioned. In the majority of cases you would disable the user account, hide the user's mailbox from the global address list, move the user to a specific OU, change group membership of the user, move the user's home directory to another location, etc. Performing all these tasks manually not only takes a lot of time, but is very error prone, tedious, and can lead to various security breaches.
With the help of Custom Commands you can deprovision users with a single mouse click!
Custom Commands allow you to automate and standardize the whole process of user deprovisioning and ensure that all necessary operations are done timely, quickly, and accurately. Adaxes provides a built-in custom command for user deprovisioning called Deprovision. This Custom Command performs a set of standard deprovisioning operations that can be customized to meet the specific needs of your company.
For more details, see tutorial: Configure User Deprovisioning
The Active Directory Web Interface provided by Adaxes can be used to handle various tasks related to AD administration, user account management, and self-service. Administrators need a robust feature-rich interface to perform various kinds of Active Directory operations to cover all aspects of identity management, AD administration, and maintenance. At the same time, Help Desk operators need a simple, clear, and intuitive interface that allows them to perform only a specific set of tasks related to user account management. Regular users require an even more simple and easy-to-use tool for self-service activities, like updating private information, changing passwords, and searching information about colleagues. A successful solution for enterprise AD management must be flexible enough to meet all the requirements above. That's why in this release we focused a lot on enhancing customization capabilities and enriching the feature set of the Adaxes Web Interface.
To increase flexibility and ensure that Web Interface users have access only to the functionality they need to perform their duties, Adaxes enables you to install three different Web Interfaces for different roles - Administrators, Help Desk, and Self-Service. This gives you much more freedom in the Web Interface customization. For example, you may want Help Desk operators to use simplified forms for user creation and modification, have access to a limited set of AD reports, and not be able to view the Active Directory structure. At the same time, AD Administrators may require access to all the functionality provided by the Web Interface. Now this dilemma is easily solved, as you can configure Web Interfaces for Administrators and Help Desk separately.
By default, each Web Interface type allows users to handle tasks that are typically assigned to their job role in the company:
Web Interface for each role can be customized to meet the specifics of your company with the help of a very powerful and easy-to-use Web Interface Customization Tool.
The new release of Adaxes significantly enhances customization capabilities of the Web Interface. This suggests a need for a tool that would help users to effectively cope with all these new capabilities. So, we created a special application that allows you to quickly and easily configure Adaxes Web Interface via an intuitive and user-friendly graphical interface.
It's very often that you need to simplify the process of creation and modification of AD objects, especially when the process involves non-administrative users. For example, you may want Help Desk technicians to specify only the name, department and title for new users, and the rest of the fields to be filled in automatically. Or, you may want regular users to be able to modify their membership only in distribution groups and view only their personal and business information.
Adaxes Web Interface allows you to do all this and much more. You can customize how AD objects are displayed and configure forms for their creation, modification and renaming. For each AD object type you can configure which fields will be shown, how these fields will be grouped, options for group membership modification, etc.
For more details, see tutorial: Customize Forms for User Creation and Editing
Although the Web Interface displays only those operations that a user can perform, sometimes you still need to hide certain functionality from the UI. For example, when working with multiple AD objects, the Web Interface doesn't check whether a user can perform an operation on each object, and displays all available operations. Or, you may just want to simplify the user interface by removing unnecessary features that may distract or confuse users.
Adaxes enables you to allow or disallow any operation in the Web Interface. You can make certain operations unavailable only for specific AD object views or grids, specify whether an operation should be located in the 'Other' menu, hide specific Custom Commands, etc.
For more details, see tutorial: Disable Operations on Active Directory Objects
Very often it is essential to abstract non-technical users away from all those technical details related to the Active Directory configuration and structure. For example, it is not necessary for a Help Desk operator to know in which OU a new user should be created, or to which group a user should be added to gain access to certain resources. Users require a one-click interface that allows them to perform their tasks in the minimum steps possible.
This can be accomplished with Adaxes. Now, the Web Interface allows users to launch frequently used operations right from the Home page in a single mouse click. Each operation can be configured to minimize the steps necessary for its execution and simplify the user experience.
The Home page can be customized to allow users to create new AD objects, execute any operations on existing objects, perform Custom Commands, Exchange tasks, etc. To integrate various applications used in your company with Adaxes Web Interface, the Home page can contain external links.
To eliminate unnecessary execution steps, you can configure options for execution
of each operation displayed on the Home page.
For example, you can specify that an operation can be executed for:
Another great feature of the Web Interface is the ability to create and edit AD objects using custom forms with pre-defined fields. For example, you can add 'Create User in Sales Department' command on the Home page, and define a custom form for this command. With the help of this form users will be able to fill in only the minimum required fields, like Name, Title and Password; the rest of the fields will be set automatically. For example, Department will always be set to 'Sales'. As a result, users will not be able to specify a different value for the Department property, and thus, will not make a mistake.
To simplify the object creation process, you can configure how users will select
the location for new objects.
You can specify that:
For more details, see tutorial: Configure Actions Pane
Now, the Active Directory pane can be configured to display either managed Active Directory domains, or specific Active Directory objects. This enables users to access objects located deeply in the Active Directory hierarchy without having access to the whole Active Directory structure. Also, this significantly speeds up users' access to frequently used Active Directory objects, as all the objects they need are placed right on the Home page. If necessary, the objects displayed in the Active Directory pane can be organized into groups.
If a user doesn't have rights to view an Active Directory object, this object will not be displayed in the Active Directory pane for this user.
Among widely used object types, like User, Group, Contact, and OU, Active Directory can contain objects of many other types. It is even possible to define your own object types by extending the Active Directory schema. Adaxes Web Interface allows you to design and customize forms for viewing, creating, and editing AD objects of any type. For example, if you use the Room object type to store information about rooms in your office, you can easily customize the Web Interface to allow you to manage Room objects.
For more details, see tutorial: Manage Active Directory Objects of a Custom Type
In Adaxes, access to Active Directory resources is controlled by Security Roles. Adaxes Web Interface will display only those objects that a user has permissions to view. If a user doesn't have rights to perform an operation, this operation will not be available and even visible for this user.
Additionally, you can allow or deny specific users or groups access to the Web Interface. For example, you can allow only the members of the Administrators group to access the Web Interface dedicated to administrators.
For more details, see tutorial: Control User Access to Web Interface
Adaxes Web Interface provides very powerful and flexible capabilities for Active Directory search. For example, you can search for users whose accounts expired during the last week, or users whose passwords never expire, or Universal Security groups that contain a specific member, etc. But most probably, such queries will be useful for administrators only, while for regular users it will be enough to search for colleagues by their names, departments and titles.
In order not to confuse regular users with too many search options, you can restrict them to search only for specific object types (e.g. users and contacts) and only by a very limited set of search parameters. If necessary, you can completely disable Active Directory search in the Web Interface.
For more details, see tutorial: Customize Active Directory Search
It is incredibly frustrating for users when their passwords are rejected and they have no idea why it has happened. Such situations frequently lead to account lockouts and unnecessary delays. The only way to overcome this, is to inform users about password requirements, like minimum length and complexity, at the point of password entry.
Now it is possible to configure Adaxes Web Interface to display custom password policy messages to help users choose compliant passwords. Also, users can view which password policy settings are applied to them by clicking the View Password Policy link.
For more details, see tutorial: Put a Custom Message on the Change Password Form
Adaxes Web Interface now can be branded with your company logo and colors.
For more details, see tutorial: Set Custom Logo and Colors
Now, all the passwords passed between the user's web browser and the Web Interface are always securely protected, even if you don't use SSL. Passwords are encrypted using a public key, and can be decrypted back only with the help of a private key that is known exclusively to the Web Interface. The private key is never passed across the network. Now, when users login to the Web Interface, change their passwords, or reset passwords for other users, the passwords they enter are always strongly protected.
Managing user accounts in Active Directory is quite a challenge to every administrator, especially when it comes to handling lots of AD objects. Seeking to simplify and speed up the management process, we've extended the set of actions that can be performed in bulk using the Web Interface. Now, the Web Interface allows you to:
Bulk password reset enables you to set a unique password for each selected user in one operation using password generation templates. For example, if you specify the password generation template as '%username%-secret', it will be replaced with the login name of each user, plus '-secret' (e.g. johndoe-secret).
When creating or editing Active Directory objects, you may need to specify some properties that are not available on the form for object creation or modification. For example, you may want to update the 'Forward To' property of a user, but there is no field for this property on the form.
From now on, any form for object creation and modification in the Web Interface can contain the 'Additional Properties' section that allows you to specify any AD object property.
Previously, when creating or editing AD objects using the Web Interface, users had to scroll the entire page to save or cancel the changes. That was particularly inconvenient and annoying for long pages and forms. Now, the Save and Cancel buttons are always within reach of your hand and you don't have to scroll screens to get to these buttons.
When delegating permissions, it is very often that you want users to be able to view and manage only specific objects in Active Directory and nothing else. Absolutely everything outside the scope of the user's authority must be hidden.
This used to pose certain problems for our customers and required facilitation. So, we have made some significant changes to the Access Control module aimed at simplifying the process of permission assignment, especially when it concerns hiding Active Directory objects. In addition to this, now Adaxes includes built-in Security Role called Blind User that can be used to hide Active Directory objects.
The Blind User role contains only one permission 'Deny Read all object types' and is very simple to use. To hide an AD object from a user, you just need to assign the Blind User role to this user and include the object you want to hide to the assignment scope. In this way you can hide objects located in an OU, members of AD groups, objects that belong to a Business Unit, specific AD objects, etc.
For more details, see tutorial: Hide Active Directory Objects from Users
When creating new users in Active Directory, some administrators often choose a simple initial password and require the new user to change the password to a strong one at the first logon. For instance, some administrators always set the initial password equal to the user's login name.
Adaxes enables you to do this automatically. With the help of Property Patterns you can set up a template for the generation of initial passwords. During creation of a new user, the user password will be automatically generated according to the template, letting you avoid manual password input. For example, you can define the following template for initial passwords: %username%secret. In this case, initial passwords will be set to the value of the user's login name, plus 'secret' (e.g. jdoesecret).
For more details, see tutorial: Generate Initial Password on User Creation
Now, Business Rules and Custom Commands are enriched with a new action that can be used to automate the user password reset. For example, with the help of this action you can automatically set the user's password to a random value during the deprovisioning process. The Reset Password action can be configured to set either random passwords, or generate passwords from a template (e.g. %firstname%%lastname%).
With the help of the Update Object action, Business Rules and Custom Commands can perform various operations on AD objects. Unfortunately, sometimes it may not be obvious what a Business Rule or Custom Command actually does by changing this or that object property.
Now, to make Business Rules and Custom Commands more self-descriptive, you have an option to specify a custom description for the Update Object action.
If you use Terminal Services in your organization, you probably spend a great deal of time configuring various Terminal Services settings for users. For example, every time you create a new user in Active Directory, you have to manually enter the Terminal Services Profile path for this user, modify various connection preferences and timeout settings. Adaxes allows you to automate this process, and gives you the ability to configure the Terminal Services settings for multiple Active Directory users in bulk, specifying unique settings for each user at the same time.
In Active Directory, Terminal Services settings are configured via the User Parameters property of user objects. Now, Adaxes allows you to use value references (e.g. %username%) when editing the User Parameters property. This enables you to automatically set unique Terminal Services settings for new users, and update the settings for multiple users in a single operation using modification templates. For example, with the help of Business Rules or Property Patterns you can automatically set the Terminal Services Profile path for new users using a template like '\\SERVER\Profiles\%username%'.
For more details, see tutorials:
Automatically Set Terminal Services Profile Path for New Users
Modify Terminal Services Settings in Bulk
Now, with the help of Property Patterns, you can configure Adaxes to automatically pre-populate the account expiration date when creating new users. During user creation, the predefined date will be automatically filled in to the Account Expires field, preventing you from doing it manually. The expiration date can be calculated by taking the current date and adding a specified time interval to this date (e.g. the current date plus 30 days - %datetime,+30d%).
For more details, see tutorial: Automatically Set Account Expiration Date for New Users
Now, when you edit properties of multiple Active Directory objects using the Properties dialog, you can use value references (e.g. %username%, %department%, %title%). This allows you to specify unique property values for multiple AD objects in one operation.
In Adaxes, value references are used to update Active Directory objects in bulk, automatically generate property values on object creation and modification, pass parameters to scripts executed by Business Rules and Custom Commands, send e-mail notifications that contain information about AD objects, etc. This new version contains a lot of new enhancements that leverage the capabilities of value references and extend the scope of Active Directory management tasks that can be addressed with their help.
Value references to date/time properties now support options that allow modifying the resulting value by adding or subtracting specific time intervals. For example, to set multiple user accounts to expire in 3 months after their creation, using the Add/Modify Property wizard, you can set the Account Expires property of these users to %whenCreated,+3M%. The account expiration date in this case will be calculated individually for each user.
Now it is possible to change the case of the values generated using value references to lower or upper case. For example, if you want the login name generated on user creation to be always lowercase, you can use the following template in your Property Pattern: %firstname:lower%%lastname:lower%. In this case, the login name will be automatically generated by concatenating the user's first name and last name in lowercase (John Doe - johndoe).
Now, when modifying AD object properties using modification templates, you can use value references that refer to the property that is being modified. For example to prolong the account expiration date of multiple users by 1 year, you can set their Account Expires property to %accountExpires,+1y%. In this case, the Account Expires property will be set to the value of the Account Expires property of each user, plus 1 year.
In addition to usual Active Directory properties, value references can refer to the so called calculated or virtual properties defined by Adaxes. These properties are not physically stored in Active Directory, and are calculated every time their value is requested. In the new version you can use the following calculated properties:
|adm-RandomInteger||A random integer (e.g. 230368161).|
|adm-RandomString||A random text of 256 characters. For example, this property can be used to set the user login name to a random value as a part of deprovisioning process. If you specify the value reference %adm-RandomString,20% for the user logon name, it will be replaced with a random text of 20 characters in length (e.g. Cz8i3ZLu9p7M6GbYj25J).|
|The date and time at the moment, when the property is calculated (e.g. 1/1/2011 09:00:00 AM). For example, this property can be used to set the user account expiration date. If you specify the value reference %datetime,+1M% for the Account Expires property, the user's account will expire in one month after the date, when the value is set.|
|The login name of the user, who performed the operation. For example, you can create a Business Rule that will be triggered after creation of new users, and update their Description property using the following template: 'Created by: %initiator%'. In this case, the Description property of new user objects will contain login names of users who created these objects ('Created by: email@example.com').|
|adm-InitiatorDN||The distinguished name (DN) of the user, who initiated an operation (e.g. CN=John Doe,CN=Users,DC=company,DC=com).|
|adm-InitiatorSid||The security identifier (SID) of the user, who initiated an operation (e.g. S-1-5-21-252-2120680786-72637).|
Starting from Windows Server 2008 onwards, it is possible to define different password and account lockout policies for different sets of users in Active Directory. In Windows Server 2000 and 2003 domains, only one password and account lockout policy could be applied to all users in the domain (via the Default Domain Policy). That caused plenty of problems, and organizations had to either use third party password filters or deploy multiple Active Directory domains for different categories of users.
Fine-grained password policies enable you to define multiple password and account lockout policies within a domain. This capability allows you to apply different levels of security to different users and groups. For example, you can apply strict policies to privileged users (such as administrators and help desk personnel) and less severe policies to other users.
Adaxes 2011.1 gives you the ability to configure and manage fine-grained password policies using a very user-friendly and intuitive user interface.
For more details, see tutorial: Manage Fine-Grained Password Policies
The new version enables you to generate complex random user passwords with a single mouse click. The generate password feature is available in the Web Interface and Administration Console when you create new users, change or reset user passwords.
If necessary, you can configure parameters for password generation (such as minimum length or allowed characters) via the Softerra.Adaxes.Service.exe.Config file. By default, this file is located in the folder C:\Program Files\Softerra\Adaxes 3\Service on the computer where the Adaxes service is installed.
Adaxes Web Interface and Administration Console now help you to spell out passwords specified during user creation and password change/reset. This is useful if you need to communicate a password on the telephone and allows avoiding confusion caused by unintelligible sounds.
If necessary, you can modify the replacement words used to spell out passwords via the SpellOutDictionary.xml file. By default, this file is located on the computer where the Adaxes service is installed in a system directory that contains application data for all users.
Adaxes enables you to quickly view and edit the effective password policy settings applied to a particular user. When you view user's properties, create new users, change or reset user passwords, you can click the View Password Policy link to view the password restrictions applied to the user.
The View Password Policy dialog displays the password restrictions enforced by the Default Domain Password Policy, Fine-Grained Password Policies, and third-party password filter software, like Anixis PPE.
If you use Anixis Password Policy Enforcer in your environment, Adaxes will display Anixis PPE restrictions when creating new users, changing or resetting user passwords. If users enter passwords that do not comply with password policies set via Anixis PPE, correct rejection reason messages will be displayed to them.
Adaxes settings for Anixis PPE can be found in the Softerra.Adaxes.Service.exe.Config file. By default, this file is located in the folder C:\Program Files\Softerra\Adaxes 3\Service on the computer, where the Adaxes service is installed.
Now you have an option to register managed Active Directory domains using the credentials of the default Adaxes service administrator (the default administrator is specified during Adaxes service installation).
Also, the Active Directory domain of the default service administrator is registered automatically during the installation of the Adaxes service.
The Find and Build Query dialogs have been enhanced to allow for easier selection of object types. Now you can select object types with a minimum of mouse clicks.
Now, Adaxes Administration Console lets you easily edit date/time properties of Active Directory objects with a special property editor.
With the help of Adaxes Administration Console, now you can copy Active Directory objects to the clipboard in various formats with a couple of mouse clicks. This allows you to quickly copy AD objects in CSV, LDIF, and DSML formats, copy their ADS Paths, DNs, and RDNs.
Also, it is possible to copy properties of Active Directory objects in the form of an LDAP filter. This feature significantly facilitates the creation of LDAP filters. For example, if you want to construct a filter to search for a specific Active Directory object by its GUID, you simply need to copy the Object GUID property of this object as an LDAP filter.