Techplus takes on Active directory tools from Specops

Techplus, has brought on management products from Toronto-based vendor, Specops, in a bid to expand its software portfolio.

The distributor will have access to the full software range and has just announced the availability of Specops Virtual Deploy, a Group Policy extension tool that allows administrators to manage Microsoft App-V virtual applications.

Specops provides a range of products allowing organisations to manage and interact with all Microsoft-based server environments through Active Directory or Group Policy platform. Techplus managing director, Paul Kern, said it was Specop’s first local channel partner.

“They have sold products in Australia to some of the larger government departments and multinationals for many years,” he said. “Customers could go online and buy it. But they’ve never been through the channel, or proactively sold products here before.”

Kern said the products were suitable for any organisation – small or large – running Microsoft servers, and claimed they were straightforward to use.

“The core differentiation against other vendors who provide these kinds of products is that users can manage everything through Active Directory – it’s just not an application on top, but a fully integrated solution,” he said.

Specop’s software tools are available for a one-off licence fee. Users can then choose to subscribe to an annual maintenance and support package.

Source: arnnet.com.au

How can I delegate the right to unlock locked Active Directory (AD) user accounts?

To delegate the right to unlock locked user accounts to a user or group in AD, you must modify the permissions to read and write the lockoutTime Active Directory user object attribute.

To let administrators change these two permissions in AD, you must first make sure that the read and write permissions are visible in the advanced ACL editor that you can access from the Active Directory Users and Computers (ADUC) MMC snap-in. In Windows 2000, both permissions are hidden from ADUC by default. In Windows Server 2003 and Windows Server 2008, they show up in the ADUC’s advanced ACL editor, shown here.

The attribute permissions that are displayed in ADUC’s ACL editor can be controlled using the dssec.dat configuration file, which is stored in the %windir%\System32 directory. In dssec.dat, each object attribute can be assigned one of the following values:

* 7 : do not include the property in the ACL editor
* 2 : include only the “Read” property in the ACL editor
* 1 : include only the “Write” property in the ACL editor
* 0 : include both the “Read” and “Write” property in the ACL editor

If an attribute isn't listed in the dssec.dat file, it will show up in the ACL editor. In Windows Server 2003 and Windows 2008, lockoutTime is by default not included in the dssec.dat file, so it shows up in the ACL editor.

Dssec.dat uses an ini file data format to list the properties of each object class that should be filtered out of the list in the Properties section of the ACL Editor. The file is structured as follows:

[objectclass-name1]
@=value
attribute-name1=value
attribute-name2=value
.
.
attribute-nameX=value

[objectclass-name2]
@=value
attribute-name1=value
attribute-name2=value
.
.
attribute-nameX=value

where objectclass-nameX refers to the AD schema object class for which the visibility in the ACL editor should be controlled and attribute-nameX to the attribute. The "@" placeholder controls the visibility of the object itself.

To modify the filter for the lockoutTime attribute in Windows 2000, open dssec.dat in Notepad. You can find the lockoutTime attribute under the [user] heading. You must reset the value for the lockoutTime attribute from 7 to 0 then save the changes to the dssec.dat file.

Note that you only need to edit the dssec.dat file on the Windows 2000 computer where you set up the actual delegation. Also, keep in mind that the dssec.dat file is read only when an administrator opens ADUC. This means that changes you make to dssec.dat won’t take effect until you close and reopen ADUC.

To delegate the right to unlock user accounts on the OU or domain level in ADUC, you can modify the permissions for the lockoutTime attribute directly in the ACL editor or use the AD delegation wizard. In the latter case, you must perform the following steps.

1. Right-click the OU or domain in ADUC and select Delegate Control... from the context menu.
2. Click Next in the Welcome dialog.
3. Click Add... to select the user or group to which you want to delegate control and click OK.
4. Click Next.
5. Select Create a custom task to delegate and click Next.
6. Select Only the following objects in the folder then, in the list, check User objects and click Next.
7. Clear the General checkbox and check the Property-specific box.
8. Check both the Read lockoutTime and Write lockoutTime boxes and clicks Next.
9. Click Finish.

Source: http://windowsitpro.com/article/articleid/102025/q--how-can-i-delegate-the-right-to-unlock-locked-active-directory-ad-user-accounts.html

Win Server 2008: Owner Rights in Active Directory Domain Services

Windows Server 2008 introduces new capabilities for Active Directory Domain Services object ownership. These new capabilities do not change the default permissions that the owner of an object is granted; however, they do provide the ability to modify the permissions granted to the owner of an object. The ability to restrict the permissions for the owner on an object is a welcome security enhancement in Windows Server 2008.

Each Active Directory Services object has a security descriptor, which facilitate the ability to secure the object by using permissions. A security descriptor contains all information related to access control for a given object, including:

* The owner of the object
* The primary group of the object (rarely used)
* The discretionary access control list (DACL)
* The system access control list (SACL)
* Control information

By default, the owner of the object is given the WRITE_DAC permission and READ_CONTROL permission. These permissions provide the owner with the ability to change permissions on an object and to read the permissions assigned to an object, respectively.

Issues with Pre-Windows Server 2008 Behavior of Object Ownership

There are a number of issues with the pre-Windows Server 2008 behavior of object ownership. It is important to cover these issues to provide a better understanding of the benefits.

One of the biggest security risks with the pre-Windows Server 2008 behavior of object ownership is that it provides the ability to escalate privileges. Consider the scenario in which you've granted your help desk permission to create user accounts but not the permission to delete user accounts. When a member of the help desk subsequently creates a user account, he becomes the owner of that user account object in the directory. With the pre-Windows Server 2008 behavior of object ownership, they automatically receive the ability to change permissions on the user. If they want to delete the user object, or grant anyone the ability to do so, they can grant the ability to do by modifying the permissions on the user account object.

With the pre-Windows Server 2008 behavior of object ownership, you are limited to taking ownership of an object. As a safeguard, members of the Administrators group can always take ownership of an object, even if the current owner has denied Administrators the permissions to modify the object. However, taking ownership of an object is essentially a reactive step. The pre-Windows Server 2008 behavior of object ownership did not have any means to be proactive.

By default, Windows Server 2008 designates the creator of an object as the owner, which is the same as the pre-Windows Server 2008 behavior. Furthermore, Windows Server 2008 still grants the owner the ability to change permissions of an object and read permissions, which is also consistent with the pre-Windows Server 2008 behavior. However, Windows Server 2008 introduces a new well-known security principal called, Owner Rights, which can be used to restrict the permissions that the owner of an object is granted. In Windows Server 2008, you can add the Owner Rights well-known security principal to the Discretionary Access Control List (DALC) of an object, and control the permissions that assigned to the owner of that object. When you add the Owner Rights well-known security principal to the DALC of an object, you can specify the permissions assigned to the owners of objects. This new capability overrides the default pre-Windows Server 2008 behavior of object ownership.

Source: enterpriseitplanet.com

Windows Server 2008: Install Active Directory Domain Services

Active Directory provides the structure to centralize the network and store information about network resources across the entire domain. Active Directory uses Domain Controllers to keep this centralized storage available to network users.

In this scenario we are going to install Active Directory fresh with a brand new Domain Controller after a fresh install of Windows Server 2008.

Requirements for Active Directory Domain Services

Let’s go through some of the requirements for a fresh install of active directory services. Some of these will be required to be done before hand; others as noted can be done during the install:

* Install Windows Server 2008

* Configure TCP/IP and DNS networking configurations

* The disk drives that store SYSVOL must be on a local drive configured NTFS

* Active Directory requires DNS to be installed in the network. If it is not already installed you can specify DNS server to be installed during the Active Directory Domain Services installation.

Once you verify that these requirements have been met we can get started.

Install Active Directory Domain Services via Server Manager

For the first example let’s start by installing Active Directory through Server Manager. This is the most straight forward way, as a wizard will guide you through the steps necessary.

1. Start Server Manager.

2. Select Roles in the left pane, then click on Add Roles in the center console.

3. Depending on whether you checked off to skip the Before You Begin page while installing another service, you will now see warning pages telling you to make sure you have strong security, static IP, and latest patches before adding roles to your server.

If you get this page, then just click Next.

4. In the Select Server Roles window we are going to place a check next to Active Directory Domain Services and click Next.

5. The information page on Active Directory Domain Services will give the following warnings, which after reading, you should click Next:

* Install a minimum of two Domain Controllers to provide redundancy against server outage (which would prevent users from logging in with only one)

* AD DS requires DNS which if not installed you will be prompted for

* After installing AD DS you must run dcpromo.exe to upgrade to a fully functional domain controller

* Installing AD DS will also install DFS Namespaces, DFS Replication, and Filer Replication services which are required by Directory Service

6. The Confirm Installation Selections screen will show you some information messages and warn that the server may need to be restarted after installation.

Review the information and then click Next.

7. The Installation Results screen will hopefully show Installation Succeeded, and an additional warning about running dcpromo.exe (I think they really want us to run dcpromo).

After you review the, click Close.

8. After the Installation Wizard closes you will see that server manager is showing that Active Directory Domain Services is still not running. This is because we have not run dcpromo yet.

9. Click on the Start button, type dcpromo.exe in the search box and either hit Enter or click on the search result.

10. The Active Directory Domain Services Installation Wizard will now start.

There are links to more information if you want to learn a bit more you can follow them or you can go ahead and click Use advanced mode installation and then click Next.

For more detail: Source

Restartable Active Directory Domain Services Explained

Windows Server 2008 includes a service that allows you to start, stop, and restart Active Directory Domain Services on a domain controller. This new functionality facilitates more streamlined operations when it comes to performing offline tasks on a domain controller. This article takes a closer look at the new restartable Active Directory Domain Services in Windows Server 2008.

Overview of the Active Directory Domain Services Service

Every domain controller that has Windows Server 2008 installed includes a service called Active Directory Domain Services, which can be manipulated like any other service. This new service and functionality is enabled by default on all domain controllers that have Windows Server 2008 installed; there are no domain or forest functional-level requirements for this functionality.

With the Active Directory Domain Services running as a service on a domain controller, you can use familiar tools to manipulate the status of the service. For example, you can use the Services console or sc.exe to stop, start or restart the Active Directory Domain Services service.

The Active Directory Domain Services service has a number of other services that depend on it. As a result, when you change the status of the Active Directory Domain Services service, the dependent services will also be affected. These dependent services include the following:

• DFS Replication
• DNS Server
• Intersite Messaging
• Kerberos Key Distribution Center

It is common to have domain controllers run other services that do not depend on Active Directory Domain Services. The fact that Active Directory Domain Services runs as a true service, which can be manipulated independently from nondependent services, facilitates the ability for the nondependent services to continue to function when the Active Directory Domain Services service is stopped.

The Active Directory Domain Services service can be in one of two statuses: Started or Stopped. The tasks that can be performed on a domain controller differ based on the status of the service. Furthermore, the directory service functionality is also different depending on the status of the Active Directory Domain Services service.

Active Directory Domain Services Service -- Started

When the Active Directory Domain Services service is started, the domain controller functions just like any other domain controller. In this state, Active Directory Domain Services, and other dependent and nondependent services running on the domain controller, operate just as they do on a Windows Server 2003 or Windows 2000 Server domain controller. The domain controller will process authentication and authorization requests, for example, because the domain controller is online.

Active Directory Domain Services -- Stopped

When the Active Directory service is stopped, the domain controller is said to be offline and functions similar to a domain controller running in Directory Services Restore Mode. When the Active Directory Domain Services service is stopped, the Active Directory Domain Services database (NTDS.dit) is offline. As a result, changes cannot be made to the Active Directory Domain Services database, directly or by virtue of replication.

The fact that the Active Directory Domain Services database is offline when the Active Directory Domain Services service is stopped provides the ability to perform offline maintenance tasks without restarting the domain controller into Directory Services Restore Mode. These tasks include performing an offline Active Directory Domain Services database defragmentation, marking an object or objects as authoritative, and forcefully removing Active Directory Domain Services from the domain controller.

Because the Active Directory Domain Services database is offline when the Active Directory Domain Services service is stopped, the domain controller will not process authentication requests. In this case, authentication requests, and all other Active Directory Domain Services client and service requests, will be referred to an online domain controller. If no other domain controllers can be contacted to process the authentication request, you must logon to the domain controller using the Directory Services Restore Mode account.

Directory Services Restore Mode Account and the Active Directory Domain Services Service

By default, the Directory Services Restore Mode account can be used only when logging onto a domain controller in Directory Services Restore Mode. However, Windows Server 2008 provides the ability to enable the use of the Directory Services Restore Mode account when logging onto a domain controller when the Active Directory Domain Services service is stopped. This functionality is enabled by modifying HKLMSystemCurrentControlSetControlLsaDSRMAdminLogonBehavior registry key. The table that follows lists the three options for the DSRMAdminLogonBehavior registry key:

Value	Description
0 (Default)	The DSRM account cannot be used for logon.
1	The DSRM Administrator account can be used to log on only when the AD DS service is stopped
2	The DSRM Administrator account can be used to log on at any time.

Source: enterpriseitplanet.com/networking/features/article.php/3814246

Google Apps gains LDAP support

Google Apps has gained a directory tool designed to simplify and accelerate the setup of this hosted collaboration and communication suite.

With the new Directory Sync, Apps can tap into existing LDAP-based user directories, such as the ones in IBM's Lotus Domino and Microsoft Active Directory, so that administrators don't have to set up a separate directory in the Google suite.

Google Apps has mostly been adopted in small and medium-size companies, and groups within large organizations, although the suite has nabbed large deployments in universities and government settings.

The new tool, which comes from technology Google acquired when it bought Postini, runs behind customers' firewalls and offers a one-way delivery of directory information to Google Apps.

"The utility offers many of the customization settings, tests and simulations originally developed and refined for the Postini directory sync tool," wrote Navneet Goel, Google enterprise product manager, in a blog posting Thursday.

The LDAP (Lightweight Directory Access Protocol) component is available at no additional cost for administrators of the Premier, Education and Partner versions of Apps.

For detail info: http://www.reuters.com/article/idgSmallBusiness/idUS210295645120090501