User Account – 2000Trainers.com

Securing the Administrator Account

The most powerful account on any Windows machine is the local administrator account. Anyone having access to this account pretty much has the keys to the castle, as far as Windows machines go. (Note: Although domain controllers don’t have a local administrator account per se, the domain administrator account that resides on them is effectively the same thing.) Even on a Windows box joined to a domain, the local admin account is sometimes even more powerful than the domain administrator account, simply because the local administrator can remove the domain admin account out of the computer’s local administrators group at any time and effectively take away a domain admin’s privileges on a machine. (Of course, there are ways to prevent that from happening as well, usually through the use of Group Policy.) The only account that is more powerful on the local machine is the built-in SYSTEM account. With the local administrator account, any action that can be taken on the machine can be accomplished with its privileges, including creating users, adding or removing resources, managing the network, and so forth. That’s why it’s definitely necessary to secure it.

With this in mind, there some generally accepted things you should do to secure this account. These steps are equally effective on both Windows 2000 and XP workstations as well as the Windows family of server operating systems. Keep in mind also that you may not want to take these measures on every single workstation and server on your network, maybe just those that are of particular value or have a high risk factor associated with the information they contain. Of course, a word of caution is in order: applying these security measures to your machine or domain may increase your security, but also may cause reduced functionality of certain applications if they were set up to rely on the local administrator account to function. As always, test these security measures on a test box or lab network and make sure they don’t break anything before implementing them in your live network. (Note: Some of these steps can be applied to domain and enterprise administrator accounts as well, to better secure them).

Pages: 123

Windows Password Recovery and Reset Tool

It’s your first day on the job and you’re rearing to go. The previous administrator left two weeks ago so the servers have been running on their own with no administrative maintenance. Microsoft decides that today is also the day they are going to release a number of critical update patches to the Windows Server platform. You head into the server room ready to update the servers but realize that you don’t know the administrative password to log on to the machines. To make matters even more interesting, it appears that no one else in the office does either and the previous admin didn’t document them. Thankfully, you are a dedicated reader of the articles on the 2000 Trainers site and have a solution.

Note – The following utility is not supported by Microsoft and does pose the remote possibility of permanently damaging the registry. Use at your own risk and please read all the online material before attempting. In addition, while this utility can be used maliciously, it is meant to be a “save the day” tip for administrators. Please use it responsibly.

The “Offline NT Password and Registry Editor” is located at http://home.eunet.no/~pnordahl/ntpasswd/ and can be used to reset the local administrator password on Windows platforms from Windows 3.51 to Windows 2003. The first thing you want to do is download either the floppy image or the ISO image for a CD-ROM depending on your preference. If you download the floppy image, be sure to grab the SCSI drivers if your boot partition is located on SCSI drives. For this high level walkthrough I used the floppy image.

Once you’ve unzipped the binaries, put a floppy in the drive and run the install.bat file. It will create the floppy image using the included rewrite utility. Place the floppy in the server and restart the server. After the linux kernel loads you will see the following screen:

In our example, we only have a single partition to select so we will choose device number one. The next prompt will be for the location of the registry. Just accept the default and press Enter. Since we want to reset the local administrator password, select option one at the next prompt.

At the next prompt, select option one again as we are editing user data and passwords. Notice how the local administrator account appears as an editable account at the next screen. Select the appropriate option for the administrator.

At the next screen we can change the password to whatever we want or use the asterisk wildcard to blank out the current password. Save your changes and write it back to the registry. Eject the floppy, restart the machine and log on as the administrator using the password you selected when modifying the account.

Creating Users, Contacts, and Distribution Groups

This week we are going to change gears, moving away from planning to talk about creating recipients in Exchange 2000. We have four types of recipient objects that we can create in Exchange 2000, including mailbox-enabled recipients, mail-enabled recipients, contacts, and distribution groups. We will start with mailbox-enabled recipients, which have a Windows 2000 user account, and an Exchange 2000 email address. Before we actually create our users, we will have to look at the administrative utilities we will be using in order to create our users. We will see that for creating and managing our Exchange recipients, most of our tasks will be accomplished from within Active Directory Users and Computers (ADUC). The ADUC we will use will have to have the ESM (Exchange System Manager) installed on the same system in order for us to manage our recipients from there.

Once we have the proper administrative tools in place, we can begin to create our mailbox-enabled recipients. How we go about this will depend on whether or not we already have a user account created in ADUC. In our case, we will first look at creating a new mailbox-enabled user from scratch, and then we will look at mail-enabling an existing user account. Like creating a user account in Active Directory (AD), we first want to decide where we want to create the new user object that we will be mail-enabling.

Alright, enough introduction…let’s take a look at mailbox-enabling a new user obect in Exchange 2000. I have selected the Users container in ADUC, right-clicked, and selected New User.

Pages: 12345

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).

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.

Active Directory Distinguished Names

Active Directory is the directory service of Windows 2000. A directory service is a store of information used for the purpose of both accessing information about objects (such as users, computers, domains, etc) as well as providing authentication and security services. Active Directory is very similar to other X.500-based directory services such as Novell’s NDS and Sun’s Directory Service, both in terms of basic structure and the services that it provides.

A wide range of objects can be created in Active Directory. An object represents a unique entity with the directory, and is usually made up of many attributes, which help to describe and identify it. For example, a user account is an example of an object. This type of object can have many attributes, including a first name, last name, password, phone number, address, and many others. In the same way, a shared printer can also be an object in Active Directory, and can have attributes such as a name, location, and more. The attributes of an object not only help to identify the object, but also allow us to search for it in the directory. For example, I could search Active Directory for a list of all users with first name Mark (perhaps to find his phone number), and would be returned with a list of all users whose first name attribute value is equal to Mark. Keep in mind that there are many different types of objects to be found in Active Directory – everything from domains, to users, to servers, to sites, to printers, and more. Objects are defined in something called the Schema – this is basically the ‘blueprint’ that defines the types of objects that can be created in Active Directory. However, you should be aware that it is also possible to define new types of objects and attributes by extending the Schema to meet the needs of your organization. This could include adding a babysitter’s phone number attribute to user accounts, or creating a whole new object type called Company Vehicles, for example. Much more on extending the schema later in the series.

Pages: 12

Configuring User Profiles

Much like in NT 4, a user profile defines a user’s desktop environment and settings. This can include things like the placement of desktop icons, drive and printer mappings, and mouse-related properties. In Windows 2000, two types of profiles still exist – local and roaming.

A local profile is the most simple. By default, every time a user logs onto a system for the first time, the default profile is opened for that user, and is ultimately saved on that system in a folder bearing the user’s name, under the Documents and Settings folder. Any changes made by the user are saved at logoff. When the user logs on to that system again, they receive the environment they left off with. The nature of a local profile is that it does not ‘follow’ the user. That is, if the user were to log on to another computer, they would receive the default profile, and another local profile would be created.

A roaming profile is one where the user’s environment ‘follows’ them as they move to different systems on the network. These profiles are stored on a server, and are copied back and forth as the user logs on or off. In order for a user to have a roaming profile, the location of the profile must be stored in the properties of the user’s account, in the User Profile section of the ‘Profile’ tab.

Pages: 12