Accounts

Authentication; verification of identity. AD authenticates username and password, security subsystem builds the security access token that represents the user. Token contains users SID and group SIDs. Token used to verify user rights and access to secured resources. User object in AD includes

• username, password and SID
• contact information
• organisational information (job title, manager)
• group membership
• configuration (roaming profile, terminal services, remote access, remote control)

create account

Create users using AD Users and Computers (dsa.msc). Select appropriate container, click Action, New, User. Must be a member of Enterprise admins, domain admins or account operators to create new accounts, or you must have delegated permissions to create users in that container: 'New User' command will be unavailable if you do not have the required permissions. First page of 'New User' dialog requires the following information:

• First Name (optional)
• Initials (optional)
• Last Name (optional)
• Full Name (required) : this value used to generate several other properties: CN, common name; DN, distinguished name; name and; displayName. CN must be unique within container, hence fullname must also be unique with in container
• User Logon Name (required): normally combined with DNS suffix of container to create user principal name (UPN) of the form someone@somewhere.com. UPN must be unique within AD forest. Used for XP/2000/2003 logons
• User Logon Name (Pre-Windows 2000) (required): used to logon to downlevel clients. Must be unique within domain

Second page of 'New User' dialog allows you to seet password and password flags:

• user must change password at next logon
• user cannot change password
• pasword never expires
• account is disabled

Default Domain Policy GPO requires 'complex passwords'. At least seven characters long and must contain three of the following four character groups: [A-Z}, [a-z], [0-9], [non-alphanumeric]. User account properties override Domain GPOs, for example 'max password age' in GPO overridden by 'password never expires' in user properties. The user object contains many more properties, accessible after account creation. Some notable properties:

• store password using reversible encryption: normally AD uses non-reversible encryption hashing algoritm to store password. Some applications require knowledge of users password and therefore require reversible encyption. Naturally this weakens password security.
• account is trusted for delegation: enables a service account to impersonate a user to access network resources on behalf of that user

You can modify several users at once in dsa.msc, using CTRL or SHIFT to select multiple accounts, but omly a subset of properties are available: some properties can only be set on a per-user basis. Available prpoerties:

• General: description, office, telephone number, fax, web page, email
• Account: UPN Suffix, logn hours, cimputer restrictions, all Account Options, account expires
• Address: street, PO Box, city, state, zip, country/region
• Profile: profile path, logon script, home folder
• Organisation: title, department, company, manager

Move an object from one container to another using action menu, right-click context menu, or simply drag'n'drop. Templates can be used to create user objects: create a user, set its properties and group membership then copy the template to create a new user. With a template, the following properties are copied:

• General: Name
• Address: all except street address
• Account: all except logon names
• Profile: all, but profile and home folder modified to reflect new user's logon name
• Telephones: none
• Organisation: all except title
• Member Of: all
• Dial-in Environment, Sessions, Remote Control, Terminal Services Profile, COM+: none

Permissions or rights assigned directly to the template object are not copied to the new account: permissions applied to group memberships are as a consequence of group memberships being copied.

CSVDE

CSV Directory Exchange: command-line tool to import/export objects from/to AD. switches (see helpctr for more details):

General

• -i (import)
• -f filename
• -s servername
• -v (verbose)
• -c FromDN ToDN
• -j path (logfile location)
• -t port (default 389)
• -u (use unicode format)

Export

• -d RootDN (root of LDAP search, default to naming context)
• -r Filter (LDAP search filter, default ObjectClass=*)
• -p searchScope ([base|onelevel|subtree])
• -l list (array of attributes to search for)
• -o list (array of attributes to omit)
• -g (disable paged search)
• -m (enable SAM logic)
• -n (do not export binary values)

Import

• -k: ignore errors

Credentials

• -a UserDN [Password|*] (simple authentication)
• -b Username Domain [Password|*] (SSPI bind method)

LDIFDE

LDIF Directory Exchange: same as CSVDE. Both LDIFDE and CSVDE require you to manually set password and to enable account. Supports same switches, plus:

• -w timeoutSeconds (default no timeout)
• -h (enable SASL layer encryption)
• -y (use lazy commit for better performance, on by default)
• -e (do not use lazy commit)
• -q threads (use specified number of threads, default 1)

LDIF (LDAP Directory Interchange Format) is a draft internet standard for file format for batch operations on LDAP directories. LDIFDE can be copied to Win2K and XP workstations. Facilitates bulk manipulation of directory objects. For example, when migrating from NT4 to AD, use addusers utility to extract account information from NT4, then LDIFDE to import them to AD.

DSTOOLS

Set of commands to manipulate AD objects

dsquery object_type startNode [options]

• object_type: [computer | contact | group | OU | server | user]
• start_node: [startNode | forestroot | domainroot], startNode should be specified as a DN, eg OU=employees, DC=contoso, DC=com
• -scope [subtree | onelevel | base], subtree is default and the only valid scope when startNode=forestroot. Onelevel indicates immeadiate children of startNode, base indicates the single object represented by startNode
• -o [dn | rdn | samid], specify output. DN is default, samid is SAM account name

criteria:

• -name, uses CN value. Accepts wildcards
• -desc, accepts wildcards
• -upn
• -samid, supports wildcards
• -inactive NumberOfWeeks
• -stalepwd NumberOfDays
• -disabled

credentials:

• [-s Server | -d Domain]
• -u userName. can be given as user, domain\user or user@domain
• -p [Password | *], asterisk forces a password prompt
• dsadd user UserDN
• UserDN can be specified via pipe from another command, space seperated list on command line or left empty, which will force interactive prompting for list (type CTRL+Z to finish)

options:

• -samid, -upn, -fn firstname. -mi Initial, -ln lastname, -display displayname,
• -empid employeeID, -pwd [Password | *], -desc description, -memberOf groupDN,
• -office, -tel, -email, -hometel, -pager, -mobile, -fax, -iptel IPPhoneNumber,
• -webpg, -title, -dept, -company, -mgr, -hmdir, -hmdrv, -profile
• -loscr ScriptPath, -mustchpwd [yes | no], canchpwd [yes | no],
• -reversiblepwd [yes | no], -pwdneverexpires [yes | no], -acctexpires NumberOfDays,
• -disabled [yes | no], [-s Server | -d Domain], -u username, -p [Password | *]

use special token $username$ to use the username instead of samid in value of -email, -hmdir, -profile, and -webpg

dsadd group groupDn

options

• -secgrp [yes|no], default yes
• -scope [l | g | u]
• -samid SAMname
• -desc Description
• -memberof GroupDN
• -members MemberDN
• -s, -u, -p

dsmod user UserDN..... parameters. Same parameters as dsadd, except cannot modify SAM account name (-samid) or group membership (-memberof). You can however use dsmod group to change group membership. -c option puts DSMOD into continuous operation mode (report errors but continue)

dsmod group groupDN

same switches as dsadd, plus

• -addmbr member....
• -rmmbr member....

dsget user UserDN... parameters

get properties for one or more objects. Use same parameter list as for dsadd to specify attributes returned (does not allow use of -password). Also has -dn and -sid parameters. Note distinction between dsquery (returns a result set) and dsget (returns specified attributes)

dsmove objectDN [-newname NewName] [-newparent ParentDN]. Also supports -s, -d, -u and -p authentication parameters

dsrm objectDN

options

• [-subtree [-exclude]], exclude excludes the object itself and deletes subtree only. Without -subtree only the object itself is deleted (must not be a container)
• -noprompt
• -c
• -s, -d, -u, -p

User Profiles

'My Documents' should be redirected to a network share through group policy, so that they can be backed-up, scanned for viruses and remain available as users roam. They can also be made availabel as 'offline files'. Local user profiles are created by copying the 'Default User' profile folder. The copy is named after the user's logon name and combined with the 'All Users' profile to create user's local environment. By default only users can modify the 'All Users' profile. Roaming user profiles (RUPs) allow for backup, virus scanning and centralised control. To use RUPs, create server share, giving 'Everyone' full control share permissions and edit the user's profile property to \\server\share\%username%. The policy 'Only allow local user profiles' if linked to an OU containing computer accounts, will disable the use of roaming profiles on these machines. Windows XP/2000/2003 use synchronisation to load user profiles: only changes need to traverse the network. This is far more efficient than it was with NT4 which uploaded and downloaded the whole profile at logoff and logon. Create a preconfigured profile:

1. create a local profile as required
2. logon as administrator
3. use sysdm.cpl to copy profile to UNC (\\server\share\username)
4. change permissions
5. set profile path for user

Create a preconfigured group profile:

1. copy desired profile to unc
2. change permitted to use to required group
3. multiselect all users of group and set their profile path (do not try to set profile for group account)
4. make profile mandatory (rename ntuser.dat to ntuser.man)

Authentication Policies

Authentication process should be both secure and user friendly: two contradictory requirements. Policy can be seet through Local Security Policy or at domain level, preferably through the Default Domain Policy.

Password Policies (computer\windows settings\security settings):

Configuring complexity and length policies will not affect existing passwords.

Auditing Policies

Auditing Policies (computer\windows settings\security settings\local policies\audit policy):

Account logon events must be monitored across all domain controllers: logon events must be monitored across all PCs.

Cross-Platform Issues

Windows 2000/2003/XP support 127-character passwords. Windows 95/98/Me support only 14. Active Directory client available for downlevel clients to enable:

• Site-awareness: clients use DCs at site instead of any available DC
• ADSI: AD scripting interface
• DFS, access DFS shares
• NTLM ver2 authentication
• AD Windows Address Book
• AD search capability integrated into 'search' and 'find' commands

AD client does not enable:

• Kerberos ver5 authentication
• Group Policy
• Change Configuration Management
• Service Principal Name, or mutual authentication

Group Accounts

Group accounts are containers for user and computer objects. Two types of group: security (to assign permissions to resources) and distribution (email distribution lists and query containers). Security groups can be used as distribution groups but not vice versa. Proper use of groups eases manageability and scalability of network. In Windows 2003, four domain functional levels are available:

• Windows 2000 mixed, supports Windows NT4, 2000 and 2003 domain controllers
• Windows 2000 native, supports Windows 2000 and 2003 domain controllers only
• Windows Server 2003 interim, supports Windows NT4 and 2003 domain controllers only
• Windows Server 2003, supports Windows 2003 domain controllers only

Group scope (applies to security and distribution groups) defines how permissions are assigned to group members. Windows 2003 groups are classified into three group scopes (Local groups are used primarily for backward compatibility, but are not included in discussions of group scope. Local groups exist on Windows 2003 member servers, not found on Windows 2003 DCs. Local groups can have members from any domain within the forest, from trusted domains in other forests or from trusted down-level domains. Local groups have only machine-wide scope: grants permissions to resources on local machine only):

Domain Local: used primarily to assign permissions to global groups for local domain resources. Exists in all functional levels. Available domain-wide only in the two native functional levels. Domain local groups function as local groups while the domain is in either mixed functional level. Can include members from any domain in the forest, from a trusted domain in other forest and from trusted down-level domains. Have domain-wide scope in the native functional levels: grants permissions to resources within the domain.

Global: used primarily to provide categorised membership in domain local groups or for direct permission assignment (particularly in mixed functional levels). Exists in all domain functional levels. Can only include members from within the same domain. Can be a member of local or domain local group. Can be granted permission within any domain. In native functional levels, can contain other global groups

Universal: exists as a security principal in native functional levels only. Are used primarily to grant access to resources in all trusted domains. Can include members from any domain in the forest. In native functional levels, can be granted permissions in any domain, including other trusted forests.

Scope of group determined at time of creation. In native functional levels, domain local and global groups can be converted to universal groups, if the groups are not members of groups of the same scope (You can change the scope of a group only in native functional levels). You cannot create universal security groups in either mixed functional levels, but you can create universal distribution groups. Domain local groups can be nested in other domain local groups. Universal groups can be nested in other universal or domain local groups. Global groups can be nested in global, universal or domain local groups. To find a users group membership use dsget user UserDN -memberof -expand. Use dsa.msc to raise functional level.

Special Identities

Computer Accounts

Computer accounts have name, SID and passwod to maintain secure relationship between computer and domain. Two steps necessary to join a computer to a domain: create an account for the PC; join the PC to the domain with the account. To create computer account you must have the same privileges required to create a user account. (Domain users can also create computer objects: when a computer is joined to a domain and an account does not exist, AD creates a computer object automatically in the Computers container, by default. Each user in authenticated users can join 10 computers to the domain in this fashion.) Creating a Computer Object:

• dsa.msc, Action, New, Computer. Only enter GUID if using RIS
• dsadd computer ComputerDN. ComputerDN has this syntax: CN=MyWorkhorse, OU=AdminPCs, DC=contoso, DC=com. CoumputerDN can be given as
• • pipe from another command
  • space seperated list on command line
  • blank, to force interactive prompting
• options: -samid SAMName, -desc Description, -loc Location
• netdom add computername /domain:domainname /userd:user /password:userpassword [/OU:OUDN]. NetDom command available in Support\Tools on CD

Once account created join computer to domain from sysdm.cpl (you must be a local administrator to do this). When selecting domain prefer DNS name to NETBIOS name: proves DNS is working (essential for AD). You'll be prompted for credentials dialogue: supply account with privileges to join domain. Once account located (or created if it didn't already exist), computer establishes a trust relation with domain, changes its SID to match domain account, and modifies group memberships. 'netdom join' can also be used to join domain, allows you to specify OU to create account in. Besides being the default OU for computers joining the domain, Computers container will also contain machine accounts for computers migrated from an NT4 domain. 2003 Resource Kit includes REDIRCMP tool, which allows you to redirect auto creation of computer objects to an OU of your choice (requires domain at 2003 functional level). Computers container, like Users and Builtin, cannot be linked to group policy objects. For this reason it is not a good choice as a location for machine accounts and pre-creating the machine account in desired OU is the recommended practice to ensure GPOs can be applied to new machines. Use OUs to organise groups of computers, users, etc. Move computer objects by Action, Move or with 'dsmove computerDN [-newname NewName] [-newparent ParentDN]' or simply by drag'n'drop. Account Operators can move objects between containers and any OU, except domain Controllers OU. Domain Admins and Enterprise Admins can move objects between any containers. When creating a computer object in AD, you can specify the group with permission to join a computer to a domain computer account. You can also set the property Assign this computer as a pre-Windows 2000 Computer or Assign this Computer Account as a Backup Domain Controller for NT4 domain controllers. Pre-Windows 2000 Computer effectively means Windows NT4, as 95/98/Me cannot join a domain. Computer Object properties:

• location and description
• group membership
• dial-in permissions
• OS properties (read-only)
• Manager - linked property, inherits address and tel from manager object

Click 'Find Objects in AD' toolbar button in dsa.msc to locate a computer account (or any other object). Context menu for found objects includes the 'Manage' command. Deleteing a computer account deletes its SID and group memberships. Recreating the account creates a new SID: all permissions, privileges, and group memberships of original account are lost. Use dsa.msc, Action, Delete or 'dsrm objectDn' to delete a computer account. When a computer is dis-joined from a domain it attempts to delete its account from AD. If it fails, you'll need to delete the account manually. Disable an account if it is not going to be used for some time (in keeping with good security practice of granting resource access only where required). In dsa.msc a disabled account appears with a red cross. A disabled computer cannot create a secure channel with the domain. Only users with cached credentials will be able to logon to the domain. Disable an account with 'dsmod computer ComputerDN -disabled [yes | no]'. Resetting a computers account resets its password, but maintains all of its properties. If you replace a machine, the new machine can join the domain using the reset account, inheriting old machines poperties and permissions. Use Action or context menus to reset machine accounts or 'dsmod computer ComputerDN -reset'. Netdom can also be used. Computer account problems generally display errors such as:

• domain controller cannot be contacted
• computer account may be missing
• trust has been lost
• secure channel failures
• domain relationship failed

Step-By-Step Computer Account Troubleshooting

• if account exists, reset
• if account does not exist, create
• remove from domain
• rejoin domain