How To Create an Active Directory Server in Windows Server 2003

After you have installed Windows Server 2003 on a stand-alone server, run the Active Directory Wizard to create the new Active Directory forest or domain, and then convert the Windows Server 2003 computer into the first domain controller in the forest. To convert a Windows Server 2003 computer into the first domain controller in the forest, follow these steps:

1. Insert the Windows Server 2003 CD-ROM into your computer's CD-ROM or DVD-ROM drive.
2. Click Start, click Run, and then type dcpromo.
3. Click OK to start the Active Directory Installation Wizard, and then click Next.
4. Click Domain controller for a new domain, and then click Next.
5. Click Domain in a new forest, and then click Next.
6. Specify the full DNS name for the new domain. Note that because this procedure is for a laboratory environment and you are not integrating this environment into your existing DNS infrastructure, you can use something generic, such as mycompany.local, for this setting. Click Next.
7. Accept the default domain NetBIOS name (this is "mycompany" if you used the suggestion in step 6). Click Next.
8. Set the database and log file location to the default setting of the c:\winnt\ntds folder, and then click Next.
9. Set the Sysvol folder location to the default setting of the c:\winnt\sysvol folder, and then click Next.
10. Click Install and configure the DNS server on this computer, and then click Next.
11. Click Permissions compatible only with Windows 2000 or Windows Server 2003 servers or operating systems, and then click Next.
12. Because this is a laboratory environment, leave the password for the Directory Services Restore Mode Administrator blank. Note that in a full production environment, this password is set by using a secure password format. Click Next.
13. Review and confirm the options that you selected, and then click Next.
14. The installation of Active Directory proceeds. Note that this operation may take several minutes.
15. When you are prompted, restart the computer. After the computer restarts, confirm that the Domain Name System (DNS) service location records for the new domain controller have been created. To confirm that the DNS service location records have been created, follow these steps:

1. Click Start, point to Administrative Tools, and then click DNS to start the DNS Administrator Console.
2. Expand the server name, expand Forward Lookup Zones, and then expand the domain.
3. Verify that the _msdcs, _sites, _tcp, and _udp folders are present. These folders and the service location records they contain are critical to Active Directory and Windows Server 2003 operations.

Source

How do I undelete an object from the Active Directory Recycle Bin?

Source: Windowsitpro

Once you've enabled the recycle bin, you can undelete objects that were deleted after the recycle bin was enabled within the deleted object lifetime. You view the objects that are in the deleted and recycled states using the steps outlined in the previous FAQ.

To restore an object in the deleted state (isDeleted TRUE), simply pass the deleted object to the Restore-ADObject cmdlet. The easiest way to pass the object is to use the Get-ADObject cmdlet and pass the -IncludeDeletedObjects switch.

For example, if I know the displayName of an object is Dick Grayson, I would use the command below. PS C:\Users\savadmin> Get-ADObject -Filter {displayName -eq "Dick Grayson"} -IncludeDeletedObjects | Restore-ADObject

As you can see below, I actually use the Get-ADObject first just to view the object. I can see its Deleted attribute is True. I then pass the object to Restore-ADObject to undelete it. After that I viewed the object, and the Deleted attribute was blank, showing that it has been restored. In this example,e the object name was AFRBEnabled (After Recycle Bin Enabled).

Active Directory Vulnerabilities In Microsoft Windows

These vulnerabilities need to be taken seriously, due to the factor that if they are exploited, a DoS attack may take place.

The two vulnerabilities located in Microsoft Windows are:

1. A Memory leak error which exists in the Active Directory LDAP service. It could be exploited in order to hang an affected system. This may occur via specially tampered with LDAP or LDAPS requests, which need to consist of exact OID filters.
2. An error that exists within the Active Directory LDAP service. If this is exploited, the chances are that it may trigger the invalid memory and attackers could then execute arbitrary code. This execution of arbitrary code takes place via specially tampered with LDAP or LDAPS requests.

A malicious character with the correct computer skills will be able to take complete and utter control of an infiltrated system. He will also be able to view, change, modify, create or delete whatever he wishes.

These vulnerabilities were reported in implementations of Active Directory on the Microsoft Windows 2000 Server, Windows Server 2003 as well as the Active Directory Application Mode (ADAM), when it is installed on Windows XP Professional as well as Windows Server 2003.

The affected operating systems

Microsoft Windows XP Professional

Microsoft Windows Storage Server 2003

Microsoft Windows Server 2003 Web Edition

Microsoft Windows Server 2003 Standard Edition

Microsoft Windows Server 2003 Enterprise Edition

Microsoft Windows Server 2003 Datacenter Edition

Microsoft Windows 2000 Server

Microsoft Windows 2000 Datacenter Server

Microsoft Windows 2000 Advanced Server

The impact of these vulnerabilities may include unauthorized system access as well as DoS attacks. All Windows users will be pleased to know that these vulnerabilities only affect Microsoft Windows 2000 Server systems. This vulnerability has been rated as moderately critical. The solution to this problem is for all users to apply the relevant updates immediately with the use of update management software or the Microsoft Update service.

Source: http://www.pc1news.com/news/0717/active-directory-vulnerabilities-in-microsoft-windows.html#msg

How to Manage Object Properties In Active Directory

Instructions:

• Step 1 :Open the Active Directory Users And Computers tool.
• Step 2: Expand the name of the domain, and select the RD container. Right-click the John Q for example, an admin user account, and select Properties.
• Step 3: Here, you will see the various Properties tabs for the User account. Make some configuration changes based on the personal preferences. Clock OK to continue.
• Step 4: Select the HR Organizational Unit for example. Right-click the All Users group, and click Properties. In the All Users Properties dialog box, you will be able to modify the membership of the group.
• Click the Members tab, and then click Add. Add Monica D. President as an example and John Q. Admin User Accounts to the Group. Click OK to save the settings and then OK to accept the group modifications.
• Step 5: Select the Sales Organizational Unit,. Right-click the Workstation1 Computer object. Notice that you can choose to disable the account or reset it( to allow another computer to join the domain under the same name). From the right-click menu, choose Properties. You'll see the properties for the Computer object.
  Examine the various options and make changes based on your properties on your personal preference. After you have examined the available options, click the OK button.
• Step 6: Select the Corporate Organizational Unit. Right-click the Monica D. President User account, and choose Reset Password. You will be prompted to eneter a new password and then asked to confirm it. Note that you can also force the user to change this password upon the next logon.
• Step 7: Close the Active Directory Users And Computers tool and this lesson is complete.

Source: Ehow

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