Category: Windows 2000

Windows 2000 Tutorials

Creating Custom MMC Consoles

As mentioned earlier in the series, it is possible to create custom MMC consoles that restrict the administrative tools that a user has access to. For example, you could create a custom tool that includes access to AD Users and Computers as well as Event Viewer.

To do this, open an empty MMC window (mmc.exe from Run), choose Add/Remove Snap-ins from the Console menu item, and then add the appropriate tools. In saving the tool, there are two major options available, Author Mode and User Mode. In User Mode, the user cannot make changes to the console (which is good if you want a consistent environment). In Author mode, a user could add or remove snap-ins, for example. The mode should be selected prior to saving the tool, using the Options setting under the Console menu item.

Note that a user can still right-click a saved console and open it in Author mode by default. This can be restricted via group policy, but can also be easily accomplished by only giving the user the NTFS read permission to the file. Note that the consoles you create do not actually contain the tools. In order for a user to access the administrative tools with the console, Adminpak.msi (the installer for the administrative tools) must be installed on their machines. After you have created and customized MMC consoles, they can easily be distributed via group policy or as email attachments.

Another option that is a little different than creating custom MMC consoles is creating what are called Taskpads. These are still administrative consoles, albeit simplified versions. The idea is that you might create Taskpads for users with limited administrative knowledge, such as a junior staff member who you want to create computer accounts for you. Taskpads are created by right clicking the appropriate object (such as an OU) within the MMC console and choosing New Taskpad View (the interface is really not consistent – you may need to choose the ‘New Windows from here’ option first). A wizard will walk you through the Taskpad and task creation process. Taskpads can also be used to launch scripts such as batch files through the Taskpad interface, which is useful if you’ve scripted a complex task that you want a less experience user to be able to run.

Object Ownership and Inheritance

By default, objects are owned by the person who creates them. Who can create objects is controlled by the ACL of the object in which they are being created. For example, a user needs appropriate permissions on a container (such as an OU) in which they want to create a user object. In order to find out who owns an object, access the Security tab of an object, and then click the Advanced button. The owner tab will show you the current owner of the object, and give you choices as to who is allowed to take ownership of the object. Remember that much like NTFS ownership, ownership can only be taken, and not given.

One of the reasons all of this is important is because Active Directory allows us a much more granular level of possible administrative control if we choose to take it. That is, we can delegate control of objects to other users or groups without giving them more control than we want to. For example, I could place all users in an OU called Company Users, and then delegate the ability to reset passwords to all Help Desk users. This allows members of the Help Desk group to Reset passwords, but not change anything else about a user’s account. By the same token, I could delegate full control over the HR OU to a single user who is responsible for controlling HR resources. This user could then create users, change properties, and so forth, but only within the HR OU.

Delegation can be controlled by directly editing the DACL associated with the object you wish to delegate and changing permissions, but this can be cumbersome and confusing. Instead, Active Directory Users and Computers provides the ability to run the Delegation of Control Wizard, a tool which provides a simplified way of delegating control according to common administrative needs. To run the tool, right-click on the appropriate object (an OU for example) and choose Delegate Control.

The Delegation of Control Wizard starts, allowing you to choosing to whom you wish to delegate control. I have chosen to delegate control of the Company Users OU to Help Desk staff.

When I click next, it will ask what type of control I wish to delegate. This screen focuses on the most common task-based delegations.

However, if I were to choose to create a custom task, I could give a user or group full control of the OU, or get even more granular, allowing a group the ability to only read and change the postal code properties of an account (shown in second screen shot below). You also have to choose whether you wish to grant the ability to control all objects, or only a particular type of object.

Of course, the DACL of the object (and potentially child objects) will automatically change based on the settings you choose with the wizard. The wizard is highly recommended as the much simpler way of delegating administrative control in Active Directory. Remember that by default any permission that gets set on an object will be inherited by all child objects. If you wish to have a child object not inherit the permissions, you can simply uncheck the ‘Allow inheritable permissions parent to propagate to this object’ check box on the Security tab. You will be given the choice of either copying existing permissions to the object directly, or removing all associated permissions from the ACL.

Object Permissions and ACLs

Although the concepts of permissions and ACLs were just discussed, you’ll need to know a little more about them. First of all, every object in Active Directory has an associated ACL. This controls who can do what to an object. By default, the ACL associated with an object is hidden, but can be viewed in the object’s properties after choosing to view Advanced Features from the View menu item in Active Directory Users and Computers.

After this has been done, access the ACL from the security tab in the object’s properties. The list of ACEs will be different based on the type of object, and will control what users can and cannot do with respect to that object. As a best practice, you should note that it is generally not a good idea to change the ACL of individual objects. Instead, change the ACL on a parent object, and by default these changes will be inherited by all child objects.

You will note that a DACL has two main columns in which ACEs can be modified – Allow and Deny. The rule is simple – the effective permissions that will apply to a user when accessing an object are the combination of all permissions that apply to the user, but an explicit deny always overrides an allow. The deny permissions should be used for special cases, such as when you want to give all users in the Help Desk group the ability to change object information for user accounts, but need to explicitly deny a single user who is a member of that group the same privilege.

Note also that the ACL that you see when viewing the permissions on an object is the standard list. If you click on the Advanced button, you are presented with a list of users and groups and their associated permissions.

By choosing an entry from the list and then choosing View/Edit, you can access an even more granular level of permissions for the object, which includes controlling how inheritance settings will be applied to the object by default, as shown below.

Active Directory Object Security

A great way to begin looking at object security in the Active Directory environment is with an overview of the different security elements that you must be familiar with. Many of the concepts covered here were first introduced in earlier articles, though with much less detail.

The first thing you’ll need to remember when taking a look at object security is the concept of a security principal. In most simple terms, a security principal is an account type to which permissions can be assigned. This includes users, security groups, or computer accounts, which are characterized by the fact that they have a security identifier (SID) assigned to them. Every security principal is assigned a SID, made up of a domain identifier (also referred to as a SID), and a relative identifier (RID), the combination of which uniquely identifies the principal.

When a user attempts to access a resource (such as another object in Active Directory) the applicable SIDs (for the user, groups he/she is a part of, and the associated computer account) are compared to the object’s access control list (ACL). The ACL lists who can access the object and to what extent.

ACLs for Active Directory objects (such as users, groups, computers, etc) are very similar to those you might already be familiar with, such as those associated with NTFS permission assignment. Note, however, that the actual permissions found in the list (called access control entries, or ACEs) can be very different depending on the object type.

There are two types of ACL that you should be aware of – discretionary access control lists (DALCs) and system access control lists (SACLs). A DACL is the list of permissions that security principals have on an object (as shown in the previous screen shot), while a SACL is the list of entries set up for auditing purposes on an object.

You should also be aware of the concept of an access token. The access token contains the user and group SIDs, and is created when a user logs on to the domain. This token is subsequently compared to ACLs whenever a user attempts to access a network resource. The token is created with information provided by the domain controller that authenticates the user (user SID as well as SIDs for domain local and global group membership) as well as a global catalog server (which provides universal group SIDs).

Publishing Resources in Active Directory

One of the benefits of Active Directory is that it is useful for more than just user authentication. As a store of information, Active Directory can be queried to find details about objects that we know about (such as a user’s telephone number), as well as to find objects that we perhaps didn’t know existed at all. Many objects are published in Active Directory by default, such as users, groups, and computers. However, it is also possible to publish information about other useful objects, most notably printers and shared folders. Once a resource has been published, the resource can be moved, and users will still be able to find it, as long as you update the shortcut to the object in Active Directory.

Let’s start with a look at printers. Printers are published automatically in Active Directory as long as they were created on a print server running Windows 2000. However, it is possible that you have a printer that is using a downlevel system as a print server, say Windows 98 or Windows NT. These can also be published to AD, either by using Active Directory Users and Computers, or by using the file pubprn.vbs found in the Windows 2000 system32 directory. Printers are published using their UNC path, in the format \\print_server\printer. The screen below shows a printer being published in AD Users and Computers.

The pubprn.vbs script needs to be run from the command prompt, using the cscript scripting host. The command needs to specify the container into which the printer(s) should be published, in LDAP format. The example below first shows a single printer being published into the printers OU, and then the command to have all printers from a print server published to the printers OU.

Cscript %systemroot%\system32\pubprn.vbs \\ntserver\hp4 “LDAP://OU=Printers, DC=2000trainers, DC=com”

Cscript %systemroot%\system32\pubprn.vbd ntserver “LDAP://OU=Printers, DC=2000trainers, DC=com”

Once the printer has been published, it is then possible for users to search for it in Active Directory, using the Search command from the Start menu. Note that the only printers that will be returned by a search are those to which the user has access.

Among the most useful features in the ability to search for a printer is the ability to search by location, according to the location listed on the properties of the printer itself. It is also worth noting that there is a very powerful option associated with locations called printer location tracking. In this setup the location field is automatically populated with the location name of the subnet where the user is located. Essentially subnets must be given location names (in AD Sites and Services, discussed below), printers must be given location names that correspond to their subnet location, and location tracking must be enabled in group policy. If these have been done, when a user tries to search for a printer, the location field will be populated with the name of the current location, based on the user’s subnet location. As such, the user would be presented with a list of printers which (in theory at least) should be close by. The screen shot below outlines the setting in group policy for printer location pre-population. The setting is found in \Computer Configuration\Administrative Templates\Printers.

In order for printer location tracking to work, all subnet objects must have an associated location. This is set in the properties of the subnet object in AD Sites and Services.

Location names follow the convention Name/Name/Name etc, where any name can be only 32 characters, and the maximum length for an entire location is 260 characters. It would be a very good idea to map out a location naming convention that makes sense and maps to the actual physical network topology. For example, in a multinational corporation with a presence in many countries might use the format:

Company/USA/Boston/Building 1/Floor 3

Or

Company/Europe/Czech/Prague/HeadOffice

Just remember that location names correspond to IP subnets. Once enabled in policy, the printer search box changes to automatically include the location.

Shared folders can also be published in Active Directory in order to simplify the ability to find information. Any folder accessible by a UNC path can be published in Active Directory. To do this, in AD Users and Computers right click and choose New Shared Folder. Users can now browse for the folder in Active Directory, or a shortcut can be created to it. The UNC location of the folder can also be changed, by accessing the properties of the published folder, making it easy to change physical locations without affecting how users see resources. Just as importantly, you can also associate keywords with the folder (these are set in the properties of the published shared folder), which would allow users to search for it by those keywords. Searching by keyword is done by using the Find command in either AD Users and Computers, or by browsing to the AD domain in My Network Places, right clicking and choosing Find.

Note that the published object, like all objects in Active Directory, has a discretionary access control list (DACL) associated with it. As such, the permissions granted to the user via the published folder may differ from the NTFS or Share permissions set on the folder itself, which may restrict a user’s ability to access it with appropriate control. To view the permissions associated with the folder, remember that you will need to have the View – Advanced Features option selected in AD Users and Computers prior to accessing the object’s properties – this will allow you to view the DACL via the Security tab.

Nesting Active Directory Groups

Some of you will remember the group usage strategy outlined by Microsoft for NT 4 domain environments. It suggested that you place user accounts into global groups according to needs, assign permissions to local groups, and then place global groups into local groups, thereby giving users access to resources. This model was often referred to as AGLP:

Accounts (get placed into) Global Groups (which are then placed in) Local Groups (who are ultimately assigned) Permissions

Although there are many different possibilities in terms of assigning permissions, the above method is amongst the most scalable. By the same token, a methodology exists in Windows 2000 that you should follow.

Accounts > Global Groups > Domain Local Groups > Permissions

Note that the model can extend beyond this, however. For example, you can nest global groups (which is useful if you have a few global groups in the same domain who you wish to further organize), or place global groups from different domains into a Universal group. With a Universal group, this would then make the model:

Accounts > Global Groups > Universal > Domain Local Groups > Permissions

The idea is simple – group users with common needs using global groups (or universal if you wish), and then place that group into a domain local group, which is assigned permissions to a resource. This allows many users to have access to the resource, while assigning permissions only once. A name for the new model that you won’t forget? Try AGULP (just remember that the L is for domain local now)

Active Directory Group Concepts

Windows 2000 Active Directory presents a number of different group options not found in the NT domain environment. The two biggest changes are the different types/scopes of groups that now exist, as well as the ability to nest groups. Group accounts for domain users are again created in Active Directory Users and Computers

First, understand that there are two types of groups: security and distribution. Distribution groups exist for the purpose of sending email, and do not have a SID. Security groups do have a SID, and as such can be used to assign permissions and rights via access control lists and policy settings.

Secondly, there are three scopes of groups: domain local, global, and universal. A quick overview of each:

Domain Local groups: domain local groups are similar to local groups in NT 4, except that they can be applied to any system within a domain, not just on the system where the group exists (since domain local groups actually reside in the AD database). These groups are usually used to assign permissions to resources.

Global groups: global groups are very similar to those found in an NT 4 domain. They are still collections of users with common needs.

Universal groups: universal groups are totally new in Windows 2000. A universal group can contain users from any domain in an AD forest. Similar to global groups, they are used as collections of users with common needs or characteristics. Only an member of the Enterprise Admins group can create a universal group.

If the option to create a Universal group is not available, this is because my domain is still in Mixed Mode. Universal groups can only be created in Native Mode. The ability to nest groups is also new to Windows 2000, and is also only available in Native Mode. Nesting refers to the ability to place a group into a group of the same type – for example placing a global group into a global group. The table below outlines group membership rules for domains in Native Mode.

Domain Local: May contain users from any domain, global groups from any domain, universal groups, domain local groups from the same domain. Can only be used to access resources in the same domain.

Global: May contain Users from same domain, global groups from same domain. Can be used to access resources in any domain.

Universal: May contain users from any domain, global groups from any domain, universal groups. Can be used to access resources in any domain.

Using CSVDE and LDIFDE to Create User Accounts

Creating user accounts in Active Directory is simply enough, seeing as a wizard walks you through the process. Simply right-click in Active Directory User and Computers, choose New – User, and you’re off to the races. The wizard only sets up basic account properties, such as names, logon names, passwords, and so forth. To get at the majority of the settings (such as group membership, home directory info, etc), you must access the properties of the user after creating it. In smaller environments, creating all user accounts one at a time may be reasonable. In larger environments, you might create a template account, and then copy that account (and common settings) in order to more quickly create new accounts. However, you should also be aware that Windows 2000 includes 2 utilities that exist for the purpose of bulk-import of user accounts and associated properties:

Csvde: This tool does bulk import to AD of comma-separated source files. Note that Csvde can only be used to import accounts – it cannot be used to delete or change information. The file used in a simply text file, with values separated by commas. The first line of the file defines the structure. For example, if I wanted to create a .csv text file to be imported that would import 2 user accounts, it might look like the one below:

dn, displayname, objectClass, sAMAccountName, userPrincipalName, telephoneNumber
“cn=dan dinicolo, cn=users, dc=2000trainers, dc=com”, Dan DiNicolo, user, dinicolo, dan@2000trainers.com, 416-555-5555
“cn=john doe, cn=users, dc=2000trainers, dc=com”, John Doe, user, doe, doe@2000trainers.com, 416-555-5556

Note that basically any user settings can be imported, as long as the file is structured correctly and the attribute names are properly defined. For a list of available attributes, click here. http://support.microsoft.com/support/kb/articles/q257/2/18.asp

Ldifde: this tool does bulk-import to AD using LDIF, the LDAP Interchange Format. It can be used to add, delete, or modify objects in Active Directory. LDIF files use a line-separated format, meaning that each attribute has its own line, and records are separated by a blank line. For example, if I wanted to create the users from the previous example using ldifde, I would create a text file with the entries shown below:

Dn: cn= dan dinicolo, cn=users, dc=win2000trainer, dc=com
DisplayName: Dan DiNicolo
ObjectClass: user
SAMAccountName: dinicolo
UserPrincipalName: dan@2000trainers.com
TelephoneNumber: 416-555-5555

Dn: cn= jown doe, cn=users, dc=2000trainers, dc=com
DisplayName: John Doe
ObjectClass: user
SAMAccountName: doe
UserPrincipalName: doe@2000trainers.com
TelephoneNumber: 416-555-5556

Note that all accounts created with these utilities are disabled by default, and that you cannot include passwords in the bulk-import process (they are left blank be default).
Of course, after user accounts have been created, a number of common management tasks may need to be performed. Note that while many of these involve setting up information relating to a particular user (phone numbers, addresses, etc), some have father-reaching implications in terms of security. Note that the most important account settings are found on the Account tab in the properties of a user account. It is from here that you can require that a user change their password at next logon, disable an account, set logon hour restrictions, account expiry, account lockout, and so forth.

Note that passwords are reset in Windows 2000 by right clicking on an account and choosing the Reset Password option. In big environments (especially ones with many OUs) you may have trouble remembering where you created an account. To quickly find the user (or other objects), right click the domain name and choose Find in Active Directory Users and Computers.

A couple of additional notes on user accounts:

Remember that an account can be renamed, without affecting the resources that the account has access to. As such, if Bob quits and Mark replaces him, simply rename the Bob’s account (and change the personal information obviously) and Mary will be a have access to everything that Bob previously did.

Deleting an account is a big deal. When you delete an account, the SID associated with the account is also deleted. As such, if you were to recreate an account with the same username, it would not have access to whatever the original account has been granted access to, since the SID would be different. Note that a deleted account can be restored using an authoritative restore (discussed later in the series).

User Accounts and Logon Names

Since the basics of this topic have already been covered in previous articles, I will keep this part short. Just as a review, remember that 3 main types of user accounts exist in a Windows 2000 Active Directory environment:

Local User Accounts: These accounts exist in the local Security Accounts Manager (SAM) database on each Windows 2000 system (with the exception of domain controllers). These accounts are created using the Local Users and Groups tool in Computer Management. Note that in order to log on with a local account, the account must exist in the SAM database of the system you are logging in from. This makes local accounts impractical for large environments, due to the administrative overhead involved.

Domain User Accounts: These accounts are stored in Active Directory, and can be used to log on to systems and access resources throughout an AD forest. Accounts are configured centrally using Active Directory Users and Computers.

Built-in Accounts: These accounts are created by the system and cannot be deleted. By default, both standalone systems and domains will have two accounts, Administrator and Guest. The guest account will be disabled by default.

Since this portion of the series covers Active Directory, we will concentrate on domain user accounts. These accounts are stored on domain controllers, which carry a copy of the Active Directory database. You will need to be familiar with the different formats in which user logon names exist, because there are differences to allow for backwards compatibility with ‘downlevel’ clients (such as Windows 95, 98, NT). The two main types of names are the User Principal Name (referred to as the user logon name in the interface) and user logon name (pre-Windows 2000).

A User Principal Name (UPN) is formatted much like an email address. It lists a logon name followed by the ‘@’ sign and domain name. By default, the domain name of the root domain will appear selected in the dropdown box, regardless of the domain in which the account is being created (the drop down list with also contain the domain name of the domain in which you are creating the account). It is also possible to create additional domain suffixes that can appear in the dropdown box and be used in the UPN if you so choose (this is done using Active Directory Domains and Trusts). The only requirement is that all UPNs in the forest be unique. When a user logs on to a Windows 2000 system using a UPN, they need only specify the UPN and the password – there is no longer a need to input or remember the domain name. Another benefit would be having UPNs map to user email addresses, again simplifying the amount of information users need to remember.

The User logon name (pre-Windows 2000) is provided for backwards compatibility with Microsoft systems not running Windows 2000. These systems still rely on traditional Netbios-based authentication, where a username, password, and domain name (in Netbios format) need to be provided. These downlevel logon user names must be unique within a domain. Note that the username portion of both the downlevel logon name and UPN need not be identical.

Troubleshooting Active Directory Installation Problems

A few notes with respect to troubleshooting Active Directory installation problems:

  • There must be sufficient disk space to install Active Directory as outlined above. If you receive an error message stating there is not enough space, you will need to delete files to create space, or create an additional volume. Be sure that there is also an NTFS partition available, and use the convert.exe command on an existing FAT partition if necessary.
  • When creating a new domain, you will need to ensure that the DNS and Netbios names of the domain are unique. If they are not, the creation cannot proceed.
  • You must have the correct privileges to install a domain controller. To create a new forest, you will only need to be a local administrator. By default, to add a child domain to an existing forest (or any new domain), you must be a member of Enterprise Admins. To create a new domain controller in an existing domain, you must be a member of Domain Admins.
  • If you get a domain not found error when adding a domain controller to an existing domain, be sure that at least one domain controller is available and that it has properly registered its SRV records in DNS.
  • In order to remove the last domain controller in a domain, you must be a member of the Domain Admins group for that domain. The last domain controller in the root domain cannot be removed if child domains still exist.