2. Managing User Attributes with DSMod and DSGet
The DSMod and DSGet commands are two Active Directory
command-line tools, called DS commands.
DSMod modifies the attributes of one or more existing objects. DS
commands were introduced in Lesson 1. Like other DS commands, the
basic syntax of DSMod is the following:
dsmod user UserDN . . . parameters
UserDN specifies the distinguished name
of the user to modify. The remaining parameters indicate the
attribute to change and the new value. For example, the following command changes
the office attribute of Tony Krijnen:
dsmod user "cn=Tony Krijnen,ou=User Accounts,dc=contoso,dc=com" -office "Amsterdam"
The attribute parameters do not map directly to the names of
LDAP attributes of a user object. For example, the
dept parameter of the DSMod User command
modifies the department attribute of a user
object. Additionally, DSMod User can modify only a subset of user
attributes. Type dsmod user /? for
usage information and a list of supported parameters.
Piping Multiple DNs to DSMod
The UserDN parameter of the DSMod command
does not have to be entered directly into the command line. There
are two ways to pipe DNs to it. The first is to enter the DNs into
the console. Let’s assume you need to change the
office attribute of two users, Linda Mitchell
and Scott Mitchell, to reflect their relocation to the Sydney
office. At the command prompt, type the following command:
dsmod user -office "Sydney"
The UserDN parameter is missing. The
console waits for you to enter DNs of users. Enter one per line,
surrounded with quotes, pressing Enter at the end of each DN. After
entering the last DN and pressing Enter, press Ctrl+Z at the
beginning of the next line and press Enter to indicate that you are
finished. The command will then execute against each of the DNs you
have entered.
A more sophisticated way to send DNs to the DSMod command is by piping the results of a DSQuery command. For example, to change the
office attribute of Linda Mitchell and Scott
Mitchell’s accounts to Sydney, use the following command:
dsquery user -name "* Mitchell" | dsmod user -office "Sydney"
The DSQuery User command searches Active Directory for users
whose names end with Mitchell. The resulting
objects’ DNs are then piped to DSMod User, which changes the
office attribute to
Sydney.
As another example, assume you want to assign all users a home
folder on SERVER01. The following command (typed on one line)
changes the homeDirectory and
homeDrive attributes of user objects in the User Accounts
OU:
dsquery user "ou=User Accounts,dc=contoso,dc=com" |
dsmod user -hmdir "\\server01\users\$username$\documents" -hmdrv "U:"
The special token $username$ represents
the user logon name (pre–Windows 2000)—the
sAMAccountName attribute—in the value of the
-email, -hmdir, -profile, and
-webpg parameters. For example, to configure a
home folder for a user, add the following parameter:
-hmdir \\server01\users\$username$\documents
Tip
EXAM TIP
The username token for the DS commands is
$username$, not
%username%.
Note
$USERNAME$ BUG
ALERT
Microsoft documentation suggests that the token
$username$ can be used with the DSAdd
command, so you should remember this fact for the exam. However,
testing shows that, in fact, you cannot use the
$username$ token successfully until after an
account has been created. Therefore, in practice you can use
$username$ only with the DSMod command, to
change the value of one of the four attributes listed earlier for
an existing account. Documentation that suggests you can use
$username$ with DSAdd is incorrect.
The DSGet command gets and outputs selected attributes of one
or more objects. Its syntax, like that of DSMod, is:
dsget user UserDN. . . parameters
You can supply the DNs of one or more user objects by specifying them on the command line,
separated by spaces; by entering them in the console; or by piping
the results of a DSQuery User command. Unlike DSMod, DSGet takes
only a parameter and not an associated value. For example, DSGet
takes the -samid parameter like DSMod does, but
you do not specify a value. Instead, DSGet reports the current value
of the attribute. For example, to display the pre–Windows 2000 logon
name of Jeff Ford in the User Accounts OU, use the following
command:
dsget user "cn=Jeff Ford,ou=User Accounts,dc=contoso,dc=com" -samid
To display the email addresses of all users whose
description attribute indicates that they are
in the Sydney office, use this command:
dsquery user -desc "*Sydney*" | dsget user -email
3. Managing User Attributes with Windows PowerShell
To read an attribute of a user object with Windows PowerShell,
use the Get-ADUser cmdlet and its
-Properties parameter.You can specify a
comma-separated list of attributes to retrieve as the value for the
-Properties attribute, or you can use an asterisk
(*) as the value of the attribute, which instructs the cmdlet to
return all attributes of the user object.
The Get-ADUser cmdlet was presented in
Lesson 2 with examples that retrieved a single user object. However,
you can use the cmdlet’s parameters to return a collection of users
that match specified criteria, within a scope of your Active Directory
forest. You can pipe the resulting collection of users to the
Set-ADUser cmdlet.
The Set-ADUser cmdlet, also presented in
Lesson 2, enables you to modify attributes of a user. It has several
parameters for common attributes, and you can use the -Add,
-Replace, -Clear, and -Remove
parameters to manipulate all attributes.
4. Understanding Name and Account Attributes
Two sets of attributes tend to appear on the certification exams
and to present challenges to Windows administrators: name attributes
and account attributes.
Several attributes are related to the name of a user object
and an account. It is important to understand the distinctions
between them.
-
A user’s User Logon Name (Pre–Windows
2000) is, behind the scenes, the
sAMAccountName attribute. It’s also
sometimes called the samid. It must be
unique for the entire domain. Many organizations use initials or
some combination of first and last name to generate the
sAMAccountName. This approach can be
problematic because an organization of any size is likely to
have users with names similar enough that the rules for
generating the sAMAccountName would
generate a duplicate name, so exceptions have to be built into
the system; eventually, the rules are riddled with exceptions.
This problem is solved if the employee number or some other
unique attribute of the users is used for the
sAMAccountName. If you have the ability to
direct the naming conventions at your organization, a unique,
name-independent logon name is recommended. -
The User Logon Name is the
userPrincipalName attribute, abbreviated as
UPN. The UPN consists of a logon name and a UPN suffix which is,
by default, the DNS name of the domain in which you create the object. The UPN
must be unique for the entire forest. Email addresses, which must be unique for the
whole world, certainly meet that requirement. Consider using
email addresses as UPNs. If your Active Directory domain name is
not the same as your email domain name, you must add the email
domain name as an available UPN suffix. To do this, open the
Active Directory Domains And Trusts snap-in, right-click the
root of the snap-in, and then click Properties. -
The Name of a user is shown in the
first column in the details pane of the Active Directory Users
And Computers snap-in; it is also presented as Full Name in some interfaces, including the New
Object–User dialog box. It must be unique in the OU. The Name
field is actually the common name (CN), stored as the cn
attribute. The cn must be unique in the OU
because it is the first element of the distinguished name (DN), the
distinguishedName attribute, which must be
unique within the forest. -
The RDN must be unique within an OU. For users, this
means the cn attribute must be unique
within the OU. This can be a tricky one. If you have a single,
flat OU for users that already contains a user named Scott
Miller, and you hire a second Scott Miller, his user object cannot have the same common name as
the first. Unfortunately, there’s no perfect answer to this
problem for all organizations. Design a naming standard that
applies a single rule for all CNs. Perhaps the CN should include
an employee’s number—for example, Scott Miller
(645928). If your OU structure for user accounts is
flat, be prepared to address this challenge.
Additionally, many organizations choose to configure the
cn attribute as LastName,
FirstName because by doing so, you can sort users by
last name in the Active Directory Users And Computers snap-in.
This is not a recommended method to achieve the goal. Instead of
using a last-name-first format for cn, add
the Last Name column to your view in the Active Directory
Users And Computers snap-in by clicking the View menu and
choosing Add/Remove Columns. Then click the Last Name column header to sort by last name. -
The Display Name is the
displayName attribute that appears in the
Microsoft Exchange global address list (GAL). It can be easier to locate users in the GAL
if they are sorted by last name, so you can create a naming
convention for your organization that specifies that the
displayName attribute take the
LastName, FirstName syntax. There is no
requirement for uniqueness of the
displayName attribute, although it is
certainly easier to locate users in the GAL if each has a unique
display name.
When you need to rename a user account, you must change one or
more attributes.
To rename a user in the Active Directory Users And Computers
snap-in:
-
Right-click the user, and then click Rename. -
Type the new common name (CN) for the user, and then press
Enter.
The Rename User dialog box prompts you to enter additional
name attributes. -
Type the Full Name (which maps to the
cn and name
attributes). -
Type the First Name and Last Name, Display Name, User Logon Name, and User Logon Name
(Pre–Windows 2000).
From a command prompt, you can use the DSMod command with
the following syntax:
dsmod user UserDN [-upn UPN][-fn FirstName][-mi Initial][-ln LastName][-display DisplayName]
[-email EmailAddress]
where UserDN is the distinguished name
(DN) of the user object. Each parameter,
-display, for example, is preceded by a dash
and followed by the value to which the corresponding attribute will
be configured.
You cannot change the sAMAccountName
attribute by using DSMod, and you cannot change the CN of the object
using DSMod.
You can use the DSMove command with the
-newname parameter to change the CN of the
object.
Use the Set-ADUser Windows PowerShell
cmdlet to change name attributes of a user.
On the Account tab of a user’s Properties dialog box, shown in
Figure 3, you can find
the attributes that are directly related to the fact that a user is
a security principal, meaning that it is an identity to
which permissions and rights can be assigned. Other security principals include computers, groups, and the
inetOrgPerson object class.
Several of the account properties are worth highlighting
because they are potentially quite useful and not self-explanatory.
Table 1 describes these
properties.
Table 1. User Account Properties
|
PROPERTY |
DESCRIPTION |
|---|
|
Logon Hours |
Click Logon Hours to configure the hours during
which a user is allowed to log on to the network. | |
Log On To |
Click Log On To if you want to limit the
workstations to which the user can log on. This is called
Computer Restrictions in other parts of
the user interface and maps to the
userWorkstations attribute. You must
have NetBIOS over TCP/IP enabled for this feature to have
any effect, because it uses the computer name rather than
the Media Access Control (MAC) address of a computer’s
network card to restrict logon. | |
User Must Change Password At Next
Logon |
Select this check box if you want the user to
change the password you have entered the first time he or
she logs on. You cannot select this option if you have
selected Password Never Expires. Selecting this option
automatically clears the mutually exclusive option
User Cannot Change Password. | |
User Cannot Change Password |
Select this check box if you have more than one
person using the same domain user account (such as Guest) or
to maintain control over user account passwords. This option
is commonly used to manage service account passwords. You
cannot select this option if you have selected User Must Change Password At Next
Logon. | |
Password Never Expires |
Select this check box if you never want the
password to expire. This option will
automatically clear the User Must Change Password At Next
Logon setting because they are mutually
exclusive. | |
Account Is Disabled |
Select this check box to disable the user
account—for example, when creating an object for a newly
hired employee who does not yet need access to the
network. | |
Store Password Using Reversible
Encryption |
This option, which stores the password in
Active Directory without using Active Directory’s powerful,
nonreversible encryption hashing algorithm, exists to
support applications that require knowledge of the user
password. If it is not absolutely required, do not enable
this option because it weakens password security
significantly. Passwords stored using reversible encryption
are similar to those stored as plaintext. | |
Smart Card Is Required For Interactive
Logon |
Smart cards are portable, tamper-resistant
hardware devices that store unique identification
information for a user. They are attached to, or inserted
into, a system and provide an additional, physical
identification component to the authentication
process. | |
Account Is Trusted For
Delegation |
This option enables a service account to
impersonate a user to access network resources on behalf of
a user. This option is not typically selected, certainly not
for a user object representing a human being. It is used
more often for service accounts in three-tier (or multitier)
application infrastructures. | |
Account Expires |
Use the Account Expires controls to specify
when an account expires. |
Note
LOCK DOWN ACCOUNTS THAT HAVE PASSWORDS
THAT DO NOT EXPIRE
It is not best practice to configure an account with a
password that does not expire. In situations that require such an
approach, be sure you use a long, complex password for the
account. If the account needs access to a limited number of
systems, you can increase the security of the account by
configuring the Log On To property with the list of computers to
which the account requires access. In the past, nonexpiring
passwords were often configured for service accounts.
|
