Sunday, September 8, 2013

MCITP 70-640:Delegation of Control

Delegation of control allows a user to have permission to perform administration actions on a selection of users. This video looks at how to achieve this using delegation of control wizard and what the wizard changes in order to provide this access.

Delegation of control
Although there is almost an endless amount of options in the Delegation wizard, the most common one use for administrators are to do with users and groups. Used correctly, you could give a user permissions to perform user administration of a particular OU rather than giving them access to perform administration for all users in the domain.

Demonstration
To use the delegation wizard, first open Active Directory Users and Computers.
Right click the OU you want to perform delegation on and select the option Delegate Control.

In the wizard select the users that you want to administration to be delegated to. It is recommended to create a group as if you want to remove or add additional users later it is a simple matter of changing the members in the group.

When asked in the wizard, choose which tasks to want to delegate to that user or users when prompted.

If you open the properties for the OU and select the security tab, you can see the permissions that have been assigned to the OU.

The delegation wizard effectively changes the permissions on the OU. The administrator could have change the permissions in the OU manually. If they want to reverse the changes done by the wizard modify the permissions for the OU and remove any permissions assigned by the delegation wizard.

MCITP 70-640:Organizational Unit & Shadow Groups

Organizational Units (OU) allow you to divide up objects in Active Directory into different locations, the same way that you would organize files into folders on your hard disk. Since OU's cannot be used directly in security, a shadow group can be created with the object inside that OU. This shadow group can be used in security. This videos looks at how to create OU's and use shadow groups.

Organizational Units
Like the folders on your hard disk, Organizational Units allows Active Directory objects to be organized into separate folders. Most administrators will create an OU hierarchy that matches their company layout. A common layout out is geographical, department and than computers. Group Policy is applied to Organizational Units and thus places users and computers into separate OU's can be beneficial when using Group Policy.

Shadow Groups
A shadow group is a regular Active Directory group that contains the objects under an Organizational Unit. Since a shadow group is a regular group it can be used for security, for example it can be used to assign NTFS permissions in a folder. A Shadow group effectively bridges the gap between not being able to use a OU with security. A shadow group needs to be manually updated or updates performed using a script. There is no automated method in Windows to do this.

An example script to keep shadow groups up to date can be found in Administration Resource Kit: Productivity Solutions for IT Professionals by Dan Holme (Microsoft Press, 2008).
None Microsoft version
http://www.sole.dk/active-directory-s...

Default OU
When you promote your first Domain Controller and thus create your Active Directory environment, a number of OU's are created automatically. These default OU cannot be deleted. Also these OU's can't have Group Policy applied to them expect for the Domain Controllers OU which can have Group Policy applied to it.
Builtin: When a server is promoted to a Domain Controller it local user database is no longer accessible. To make up for this, any users accounts that exist in Builtin are shared between all Domain Controllers.
Users: This is the default location for user accounts when a location is given. In most case, when creating a new user the administrator will decide which OU the user account will be created in.
Computers: This is the default location for computer accounts. When a computer is added to the Domain, the computer account for this computer is placed in this OU. Since Group Policy cannot be applied to this OU, and administrator will normal move computer accounts of the Computer OU to another OU.
Domain Controllers: This OU contains all the computer accounts for the Domain Controllers in your domain. Unlike the other OU's, Group Policy can be applied to this OU. By default, the Default Domain Controller Group Policy is applied to this OU.

Demonstration
To perform administration of your OU's this can be done using the Active Directory Users and Computers tools.
To create an OU, right click where you want it created, select new and than select new Organizational Unit.
When creating the Organizational Unit, you have the option to protect the container from accidental deletion.
In the properties of the OU, there are a lot of settings that can be configured. In a lot of case the information is informational only but does help.

What is an Organizational unit?
An organizational unit is effectively a container for storing Active Directory objects.
What is the difference between an OU and a group?
An OU is essentially used for Group Policy and delegation besides providing an infrastructure to sort and organize objects in Active Directory. Since an Active Directory object can only exist in one location at one time, OU's are limited to what they can achieve.
A group is contains objects from anywhere in the domain. The main different is that a group can contain an object that is used in anther group. For example, a user that travels between New York and Washington Offices could not be a member of a multiple OU's, however they could be a member of two groups called New_York_Users and Washington_users. With this extra flexibility that groups offer, group can be applied to resources like NTFS permissions which OU's cannot.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" pg 11 46-48
"Organizational Units " http://technet.microsoft.com/en-us/li...
"Organizational Unit" http://en.wikipedia.org/wiki/Organiza...

MCITP 70-640: Offline Domain Join

Normally a Domain Controller needs to be available in order to add a computer to the domain. With Windows 7 and Windows Server 2008 R2 comes a new tool called Offline Domain Join. This allows a computer to be added to the domain without a Domain Controller being available. This video looks at different ways Offline Domain Join can be used.

No Networking
In the simplest case Offline Domain Join can be used to join a computer to a domain without a domain controller. For example, if a new site was being set up and the networking at the new site had not been installed as yet.

No networking installed
Offline Domain Join can also be used to join a computer to a domain that does not have networking installed as yet. In some cases a reboot may be required before networking is working. This is often the case with virtual computers. With Offline Domain Join you can join the computer to the domain before any network drivers are installed on the computer.

Unattended installation
Offline Domain Join can also be used with an unattend.txt file. An unattend.txt file is used with automated installs of Windows. The file contains the answer to the setup questions as well as any other required customizations. Using Offline Domain Join like this means you could automate the complete install of Windows 7 using a script including having it added to the domain.

Limited network connectivity
In some cases the network between two locations may only be available at certain times. For example, in a secure environment replication between the main network and the secure network may happen rarely. If the secure network has a writeable Domain Controller then a computer can be added to the Domain at any time. If the secure network only has a read only Domain Controller, a computer cannot be added to the domain unless a writeable Domain Controller is contactable. Using Offline Domain Join, the computer can be added to the Active Directory database ahead of time and replicated to the secure network. Since the read only Domain Controller contains data for the new computer, the computer will be able to be added to the domain using Offline Domain Join even though a writeable Domain Controller is not available.

Add a computer to the domain without a username and password
Offline Domain Join can also be used to add a computer to the domain without the use of a username and password. All that is needed is the file Offline Domain Join generates. This file is considered to have sensitive information so should only be given to people who are trusted.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition" pg 217-221
"Offline Domain Join (Djoin.exe) Step-by-Step Guide" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Managed Service Accounts

This video looks at some of the new features in Windows Server 2008 R2 and Windows 7 that can automate the management of service accounts. If your application supports it, using managed service accounts means that the password of the service account is automatically changed periodically without any interaction from the administrator.

What is a service account
A service account is a user account that is created to run a particular service or software. In order to have good security, a service account should be created for each service/application that is on your network. On large networks this will mean a lot of service accounts and the management of these service accounts can become difficult, thus this is where Managed Service Accounts can help.

Computer Accounts
A computer account is like a user account in that it has a password. The difference is that the password for a computer account is automatically updated by Windows with no interaction from the user. Managed Service Accounts uses the same process to manage the password for a Managed Service Account

Managed Service Accounts Passwords
The password that is associated with a Managed Service Account (MSA) is automatically changed every 30 days. It is a random string of 120 characters so it offers better security than standard passwords even if the standard password uses upper and lower case letters combined with non alphanumeric characters. Unless of course the administrator wants to use their own 120 character password which is difficult for an administrator to work with. Like a computer account, the Managed Service Account is bound to one computer and thus cannot be used on a computer that it was not designed to work with. This provides additional security.

Requirements
In order to start using Managed Service Accounts you need to meet a few requirements.
Domain Functional Level: This needs to be Windows Server 2008 R2 or above.
Forest Functional Level: Does not require any particular forest level.
Schema changes: The schema needs to be up to date. Run ADPrep /ForestPrep to update the schema to the latest version using a Windows Server 2008 R2 DVD or above.
Client: The Managed Service Account can only be used on Windows Server 2008 R2 or Windows 7.
Software components: .Net Frame work 3.5 and Active Directory module for Windows Powershell are required for Managed Service Accounts.
Supported Software
Not all software will work with a Managed Service Accounts. Managed Service Accounts do not allow the software to interact with the Desktop. Thus a Managed Service Account cannot be used to login and cannot be used to display GUI based Windows. Listed below are common software and if they can use a Managed Service Account.
Exchange: Yes, but the Managed Service Account cannot be used for sending e-mail.
IIS: Yes, can be used with application pools.
SQL Server: Some people have got Managed Service Accounts to work with SQL but Microsoft does not support it.
Task Scheduler: No
AD LDS: Yes, Active Directory Light Weight Service works with a Managed Service Account, however a special procedure does need to be followed in order to get it to work.

References
"Service accounts step-by-step guide" http://technet.microsoft.com/en-us/li...
"Managed Service Accounts Frequently Asked Questions (FAQ)" http://technet.microsoft.com/en-us/li...
Keywords: "Managed Service Accounts" "MSA" "Active Directory" 70-640 MCITP MCTS ITFreeTraining

MCITP 70-640: Service Accounts

A service account is a user account that is created to isolate a service or application. This video looks at how to create and use service accounts in your organization.

What is a service account
A service account is user account that has been created to run a particular piece of software or service.

Principle of least privilege
The principle of least privilege is giving the user only the minimum required amount of access. For example, if a user only requires access to certain files than they should only have access to those files. If the user only requires access to certain servers or workstations, they should only have access to those. The advantage of this is that it minimizes the amount of damage that can be done if the user account was to become comprised. When used with service accounts, one service account should be created for each service or application. If the same service account is shared between services and applications, and this service account was to stop working (for example the account became locked) all software using this service account would be effected.

Using the same user account for multiple services
Some administrators will choose to run multiple services and applications using the same user account. To ensure that there are no problems running their software, some administrators will use a user account that has Domain Administrator access. If you use the same user account for multiple pieces of software, and the user account was to fail for any reason, all the software using that service account would also be affected. Also if the account was to become compromised, this service account could be used to access resources on the network. The more access the service account has the more potential damage that it could do. The service account could prevent applications and services using it from running by simply changing the password of the account.

Service Account Lockout
When the password for a service account is changed, the password must be updated in all locations that use the service account. A user account can become locked after to many wrong password attempts. When the service account is used in multiple locations and the password is not updated in all locations, the old password will still be used. After Windows Server 2003 with Service Pack 1, Active Directory will check the last two passwords used. If there is a match, the service account will not be locked.

Service account expires
It should be noted that if a service account password was to expire, this will prevent the user account from being able to be used until the password for the user account has been changed.

Demonstration
The following procedure can be used to create a service account.
Run Active Directory Users and Computers.
Right click the OU where you want the user to be created.
When prompted, ensure user must change password at next logon is not ticked. This will prevent the service account from being used until the password has been changed.
To prevent the password for the service account from expiring, tick the tick box password never expires. To maintain high security, when ticking this option, the password for the user account should be changed at regular interval.
For additional security for your service account, you can create a domain group and place the service account in that group. Once service account has been added to this group, you can remove all other group membership. This will ensure the service account does not have any permissions, not even Domain User permissions unless they are allocated to the service account.
To give the service account access to a particular service, type lusrmgr.msc in the start menu to edit the local users and groups. Add the service account to the local groups as required.
To the change the password that is being used for a service account, open services from the start menu. Open the properties for the service you want to change the password for and change the password on the log on tab.

References
"Create a Service Account" http://technet.microsoft.com/en-us-li...
"principle of least privilege" http://en.wikipedia.org/wiki/Principl...
"managed service accounts" http://technet.microsoft.com/en-us/li...
"Account Lockout and Password Concepts" http://technet.microsoft.com/en-us/li...
"Securing Critical and Service Accounts" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Protected Admin

Protected Admin is essentially a term used to describe the administrator account being protected using User Account Control. This video looks at how User Account Control is used in Windows Server to protect the administrator's account.

User Account Control
User Account Control was first added in Windows Vista and Windows Server 2008. It addresses an issue that was common practice in Windows XP where a user would create an administrator account and use it for day to day activity. On most computer systems, the extra rights that an administrator account provides are only used for a small amount of time. For example, if you need to install software on the computer you would need administrator access to install the software, however to run the software it is unlikely that you would require administrator access. User Account Control essentially divides the administrator account into two,a user part and an administrator part. For normal activity the user part of the administrator account is used. When administrator access is required, the administrator part of the user is used.

To force an application to run with administrator rights, right click the application and select the option "run as administrator".

Saturday, September 7, 2013

MCITP 70-640: Windows Contacts

Active Directory allows you to create contacts to hold information about 3rd parties like their phone numbers and e-mail addresses. This kind of information can also be added to a user account, however creating a contact to hold this information means that contacts cannot be used to login like a user can and thus is less of a security concern.

Security Identifier (SID)
The fundamental difference between a user account and contact is a contact does not have a security identifier or SID. A SID is used with security in Windows. Any time that you assign permissions to objects or files the SID is required. Since a contact does not have a SID, by design it cannot be used with security. Also since a contact does not have a SID it cannot be used to login.

Benefits of Active Directory Contacts
Having contacts for your organization stored in Active Directory means that any users can perform searches for this information. Since the contact data is stored in the Active Directory database, this means that data is stored once and thus is also easy to update. Without a centralized system like this, individual users would store multiple copies of the same data making it hard to update when changes occur.

Windows 7 Contacts
Windows supports contacts that can be stored on the local Windows computer. This was first introduced in Windows Vista. The contact data is stored in an XML file which means that it can also be used by non Microsoft software. Windows 7 does not come with any software that uses contacts. Contacts in Windows 7 are there for back compatibility only. The main use of contacts in Windows Vista would most likely be Windows Mail which is no longer included in Windows 7. Microsoft offer a free e-mail software called Windows Live Mail that can be download from the Microsoft web site. This software does not support contacts, but any existing contacts can be imported.

Creating a contact in Active Directory
To create a contact, open Active Directory Users and Computers.
Right click where you want to create the contact and select new contact.
Complete the wizard in order to create the contact.
To configure additional options and properties for the contact, right click the contact and open the properties.

References
"Windows 7 Inside Out" Microsoft Press, pg 276
"Windows Contacts" http://en.wikipedia.org/wiki/Windows_...
"Is Windows Contacts integrated with Windows Live Mail in Windows 7?" http://answers.microsoft.com/en-us/wi...
"Looking for Windows Mail?" http://windows.microsoft.com/en-us/wi...

MCITP 70-640: Universal Group Membership Caching

Universal groups are stored on a Domain Controller that has been made a global catalog server. If a user is a member of a universal group, and a global catalog server is not available, the user will not be able to login. In some cases you may have only a few users at a site and do not wish to deploy a global catalog server due to the extra replication this will cause. This video looks at how you can use universal group membership caching to allow users to authenticate from a Domain Controller when a global catalog server is not available.

Authentication process
When a user authenticates from a Domain Controller, a security token is created for that user that contains all the groups that the user is a member of. If the user is a member of universal group, then a global catalog server must be contacted in order to obtain this membership. If no global catalog server is available, and universal group membership caching is not enabled, the following occurs: The user will be able to login locally on their computer if their user has been cached on the computer. This may be the case if they were the last person to login to that computer. This will allow the user local access, but when they attempt to connect to a computer, for example a file share on a server, the computer will double check the user. This is done to ensure the user has not been locked out or disabled. If no global catalog server is available to the computer that the user is trying to connect to, the user will be denied access.

How Universal Group Membership Caching works
When a user authenticates from the domain controller, the domain controller will contact a global catalog server in order to determine the universal group membership for that user. This information, once obtained, is stored on the Domain Controller forever. To make sure the cache is keep up to date, the cache is updated from a global catalog server every 8 hours.

How to enable Universal Group Membership caching (UGMC)
UGMC can only be enabled at the site level, so once enabled, all Domain Controllers in that site that are not global catalog servers will start caching universal group membership. To enable UGMC, do the following:
1) Open Active Directory Sites and Services
2) Open the site that you want to enable UGMC.
3) Open the properties for NTDS site Settings. These settings should not be confused with NTDS Settings that are found under the Domain Controller.
4) From the properties tick the option "Enable Universal Group Membership Caching."
5) If you wish, you can also select the option "refresh cache from". This will allow you to select which site you want the Domain Controller to refresh its cache from. If this is not configured, the Domain Controller will update its universal groups caching from the closest domain controller.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" pg 524-525
"Cache universal group memberships" http://technet.microsoft.com/en-us/li...

MCITP 70-640: AGUDLP Group Strategy

This video looks at role based Strategy for Active Directory called AGUDLP. AGUDLP can be used in multiple domain environments to provide distributed control between different domain administrators while still being able to provide access to resources at the forest level.

What AGUDLP standards for
A Accounts
G Global Groups
U Universal Groups
DL Domain Local Groups
P Permissions

Advantages of AGUDLP
Allows administration to be divided up between different administrators in the forest. Administrators can have control at the forest level or control can be separated at the domain or resources level.

Since AGUDLP is a role base strategy, when a user changes their role, for example promoted or transferred, access can quickly and easily be changed.
AGUDLP also allows easy auditing. By looking in the group it can quickly be determined who has access to which resources.

Why each group is used
Global Groups
Global groups only contain users, computers, and other global groups from the same domain. Using a global group allows the administrator to divide up control between different domains. For example, if you wanted a sales group that had all sales users from all domains in the forest, you would first create a global group for the sales users in each domain. This allows the domain administrators in each domain to be responsible for keeping this group up to date.

Universal Groups
Universal groups allow users, computers, global groups and other universal groups to be members. Because of this, they can have the global groups from all the other domains to be members of this group. For example, a universal group could have as members the sales group from all the other domains. Universal groups are available forest wide and thus are replicated using the global catalog server. For this reason, you will want to reduce replication as much as possible in the forest. Replication will only occur when membership of the universal group has changed. Since the universal group contains global groups, the membership of the global groups can change without affecting the membership of the universal group. The only time the universal group would need to be replicated is when a global group is added or removed from the universal group.

Domain Local Group
The domain local group is applied to the resources as a permission. Domain local groups can only be used in the domain that they were created in. By using domain local groups, a local domain administrator can simply add the domain local group to the resources and configure the appropriate permissions. This administrator may not have access to change the membership of the other groups, which means that they do not have control over which users go into the group. This does not affect their ability to use the group on local resources. This means that by using a domain local group, the scope of the group can be limited to use for that domain only and also be delegated out to other administrators. At this level, it is easy to add or remove the universal group to any domain local group as required, making changing access very quick and flexible.

MCITP 70-640: Group Strategy AGDLP


AGDLP is a role based strategy that is designed to provide flexible resource management using groups. This video looks at how you can effectively use AGDLP in your company to manage permissions to your resources. Since AGDLP is designed for larger networks, it is generally used in networks that have more than 500 users. AGDLP can be used in multiple domain environments but is generally used in a single domain environment.

Advantages of AGDLP
Since AGDLP is a role base strategy for applying permissions, as a user changes their role in an organization, it is easy to change the permissions associated to that user by making them members of the appropriate groups. Since the users are being put into groups at the role level, this means that the administrator does not require knowledge of how the permissions were applied to the resource. Lastly, by looking at the users in the groups, you can quickly determine who has access to which resources in your domain.

AGDLP
ADDLP stands for the following.
A for Accounts.
G for Global Group.
DL for Domain Local Group.
P for Permissions.

The basic way to use AGDLP is as follows:
Accounts go into Global Groups; Global Groups go into Domain Local Groups; Domain Local Groups are than applied to Permissions.
The advantage to using each group is as follows:

Global Groups allow users from the same domain to be members. This means that when using multiple domains, you can be assured that only users and computers and other Global Groups from that domain are members. This means you can force administration to be divided up between domains. If you do not use Global Groups you could never be sure if an administrator from a domain is only adding users from that domain.

Domain Local Groups can only be used in the domain that the group was created in. This helps with auditing. If the group could be used in other domains, you could never be sure that the group had been applied to resources outside your domain.
AGDLP can be used in a single forest, single domain environment and also a multi domain environment. It provides a framework, but the administrator is free to decide themselves how best to implement group strategy given their business environment.

References
"AGDLP" http://en.wikipedia.org/wiki/AGDLP
"Selecting a Resource Authorization Method" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Special Identities

This video looks at the special identities that exist in Windows. Special identities work a lot like groups, but unlike a group, the membership of a special identity cannot be modified. Membership of special identities is determined by the way the user was authenticated or the type of connection.

The above special identities exist on all editions of Windows. The scope of the special identity is the local computer only. When you copy a file from one computer to another computer, any permissions that are configured using special identities are retained. Even though the scope of the special identity is limited to the local computer, Windows can achieve this retention because special identities always use the same Sid or security Identifier. For example, the everyone special identity is always S-1-1-0.

Anonymous Logon
Allows access without a username and password.
When a connection is made and no username and password is given, this is classed as anonymous access. Anonymous access in Windows will generally be disabled by default and needs to be enabled. Remember this before configuring a file on a share with anonymous access.

Authenticated Users
This includes any user authenticated locally or via a domain controller. The user can be in the current forest or in an external domain separated by a forest. The only account that is not included in this group is the local guest account.

Everyone
Includes authenticated users and the local built-in guest account.
Before Windows Server 2003, the everyone special identity also included anonymous logon.

Interactive
This is when the user is physically in front of the computer or connected to the computer using remote desktop.

Network
Any user that accesses the computer via a network connection.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" Microsoft Press, pg 179-180

MCITP 70-640: Domain Groups

This video looks at the groups created in Active Directory that are available to all computers in your domain.

Enterprise Admins
This group is the most powerful group in Active Directory. It is automatically made a member of the Domain Administrators group for all domains in the forest thus giving members of this group administrator's rights on all domains in the forest. This group also has additional rights forest wide like changing forest wide information and adding/removing domains from the forest.

Schema Admins
This is the only group that can make changes to the schema. The schema defines the active directory database. This group only exists in the root domain of the forest.

Domain Admins
The domain admins group has administrator's rights to all users and computers in the domain including domain controllers. When a computer is added to the domain, this group is added to the local administrators group on that computer.

Domain Users
Members of this group can login in to workstations, run applications and change computer settings that relate to them. This group is automatically added to the local users group on a computer when it is added to the domain.

Domain Guests
This group has no rights or permissions in the domain. It is not added to the local guest on any computer when they are added to the domain and thus does not have any rights on any computers in the domain. For this reason, a user that is added to this group will not be able to login to any computers in the domain unless they are a member of another group that grants them this right.

Domain Computers
This group contains all the computers in the domain expect domain controllers. When you add a computer to the domain, the computer account for that computer automatically gets added to this group.

Domain Controllers
This group contains all the computer accounts for all the domain controllers in the domain except for domain controllers that are in read-only domain controllers. When a server is promoted to a domain controller, if the computer account is in the domain computers group, it will be moved in the domain controllers group.

Read-only Domain Controllers
This group contains all the read-only domain controllers in your domain. This group does not contain writeable domain controllers or computer accounts.

Enterprise Read-Only Domain Controllers
This group exists only in the root of the forest. It has no members by default, even if you add read only domain controllers to the root domain, the computer account for these read only domain controllers does not get added to this group.

Allowed RODC Password Replication Group
Members of this group will have their password cached on the read-only domain controller when they are authenticated using this read-only domain controller. Remember that the password attribute is not normally replicated to a read-only domain controller. This means that if they attempt to authenticate off the read-only domain controller during a network outage they will still be able to authenticate from the read-only domain controller even though a writeable domain controller is not available.

Denied RODC Password Replication Group
If a user account is a member of this group, their user password will not be cached on a read-only domain controller. Passwords will not be cached on a read-only domain controller if it has be configured. If a user is a member of this group and password caching has been configured their password will not be cached. Deny always overrides allow.

References
"Default groups" http://technet.microsoft.com/en-us/li...
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" Microsoft Press, pg. 177
"Administering the Password Replication Policy " http://technet.microsoft.com/en-us/li...
"How to configure DNS dynamic update in Windows 2000 " http://support.microsoft.com/?id=317590
"DCHP Group" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Built-in Groups Domain Controllers and Server


This video looks at the unique built-in groups available only to Domain Controllers and locally on Windows Server 2008.

DC Promotion Process
If you attempt to edit the local users and groups on a Domain Controller (this can be done using lusrmgr.msc from the start menu) you will find the local accounts database on the computer will be disabled. The local groups on a Domain Controller have been moved to Active Directory and can be found in the OU Builtin. If you use one of these groups, the change will affect all Domain Controllers.

Server Operators
This group allows members to login to Domain Controllers, start and stop services on the Domain Controllers, perform backup and restore operations, format disks, create shares, and shut down and restart Domain Controllers. This group has no default members and does not give the user access to any other servers that are not domain controllers. This group is aimed at someone who is performing maintenance on Domain Controllers. For this reason, members cannot perform Active Directory administration.

Account Operators
Members of this group can perform Active Directory administration such as create new users and groups. Although it is not required for Active Directory administration, members of this group can login to a Domain Controller. Once logged in, they can only perform Active Directory Administration: they cannot perform other tasks on the Domain Controller like rebooting. It should be remembered that account operators are not administrators in the domain, and thus some Active Directory administration cannot be done due to security reasons. This includes making changes to the Domain Controllers OU, changing members of the Domain/Enterprise Administrations group, or changing properties for any user that is an administrator.

Print Operators
Members of this group can manage printers on Domain Controllers and printer objects in Active Directory. In order to manage printers on a Domain Controller, member of this group can also login to a Domain Controller. Allthough they don not have the rights to perform day to day administration on the Domain Controller, members of this group can shut down the Domain Controller.

Terminal Server Licenses Servers
Inside an Active Directory user account is information stored about terminal server licenses. The terminal services licensing server needs to access this information. In order to only give this server the minimum required access to Active Directory to get this information, you can add the computer account of the licensing server to this group.

Incoming Forest Trust Builders
To create a trust between two domains, normally an administrator in each domain will create and approve the trust. If you place a user from another domain in this group, they will be able to create an incoming trust from another domain to that domain without an administrator in the other domain having to create or approve the trust.

Certificate Services DCom Access
This group exists on both Domain Controllers and member servers. If users that use DCom need access to certificates, they need to be added to this group.

Windows Authorization Access Group
In the user account in Active Directory there is a computed token. This is a computed version of the same security token that is created when a user logs in. You only need to add users to this group for special software that requires this access.

Pre-Windows 2000 Compatible Access
Members of this group are allowed read access to users and group in the domain. This group should only be used if you have Windows NT computers in your domain.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" Microsoft Press, pg. 177-179
"Default groups" http://technet.microsoft.com/en-us/li...
"Terminal Services Per User Client Access License Tracking and Reporting" http://technet.microsoft.com/en-us/li...
"An overview of groups used by Active Directory Certificate Services" http://morgansimonsen.wordpress.com/2...

MCITP 70-640: Default Local Groups

Default local groups exist locally on a Windows computer and available only on that computer. This video looks at the local groups that are created by default on every Windows 7 and Windows Server 2008 operating system.

Administrators
Any user added to this group has full control over that computer. By default, the administrator will have access to everything, for example all files and folders. If an administrator has been denied access they can take ownership of the object in question and give themselves permissions to the object.

Users
This group is designed for the general user. It allows them to run software and change settings that relate to them.

Power Users
The power users group was introduced in Windows XP to give the user more access than the user group but less than an administrator. In Windows Vista this group was removed and in Windows 7 it was added again. In Windows 7, the Power Users group does not provide any access other than user access and is included only for legacy reasons. If you want to give this group the same permissions as Windows XP, you can apply a security template as explained below. This security template should only be applied as a last resort. The process is not reversible and may not function as expected with newer software.

To apply the security template to the Power Users Group
1. Open mmc and add the snap-in Configuration and Security Analysis
2. Right click Security Configuration and Analysis and select open database
3. Enter a new database name or open an existing database
4. When prompted open c:\windows\inf\puwk.inf. If not prompted, right click Security Configuration and Analysis and select open template
5. Right click Security Configuration and Analysis and select configure computer now

Guests
The guest group gives the user the ability to login and run software. Any changes that are made by that user, for example changing the wallpaper, will be lost when the user logs off. The guest account is usually used for computers that are set up as kiosks. In this case, you want the user to have access to run software and make changes if they need to, but when the next user uses the computer, you want to ensure that the new user gets the default settings and not the modified settings.

References
"Default local groups" http://technet.microsoft.com/en-us/li...
"Understanding Built-In User and Group Accounts in IIS 7" http://learn.iis.net/page.aspx/140/un...
"Crypto Operators security group" http://support.microsoft.com/kb/949299
"Offering Remote Assistance" http://technet.microsoft.com/en-us/li...
"List of features removed in Windows 7" http://en.wikipedia.org/wiki/List_of_...

MCITP 70-640: Active Directory different group types available

This video looks at the different group types available in Active Directory. These include Local, Domain Local, Global, and Universal. The video also covers membership requirements which can be used in each of the different groups and converting between different groups. Finally, this video looks at distribution vs security groups.

Distribution Group
Any group in Active Directory can be created as either a distribution group or a security group. Distribution groups do not have a SID (Security Identifier) associated with them. For this reason distribution groups can't be used for security. That is, a distribution group cannot be used to assign permissions to files or objects. Distribution groups are mainly used with e-mail programs like Exchange to send e-mails to groups of people. Since there is no SID associated with the group, when you make a user a member of a distribution group, this does not affect the size of the security token for that user. A security token is created when the user logs in and contains their SID and any SID's for any security groups of which they are a member.

Security Group
A security group has a SID and thus can be used for assigning permissions to files or objects. A security group can also be used as a distribution group in e-mail software like Exchange. Thus, the difference between a security group and a distribution group is simply that a security group is security enabled whereas a distribution group is not. If you are not sure which group to create, create a security group since it can do everything a distribution group can do and can also be used in security related operations.

Local Group
Local groups exist only on the computer on which they were created. A local group can have as a member any user or computer account as well as any other type of valid group.

Domain Local Group
Domain Local groups can only be used in the domain in which they were created. A Domain Local group allows membership from any other group as well as any user or computer. Domain Local groups from other domains cannot be used as members because they are limited in their use outside of the domain in which they were created. Universal groups can only be used as members when the Universal group exists in the same forest as the Domain Local group.

Global Group
Global groups have the most restrictive membership requirements, only allowing users, computers, and other Global groups from the same domain to be used as members. However, Global groups can be used as members of any other group, including other forest and external domains. This means a Global group has the most restrictive membership requirements of all the groups but is the most flexible when being used as members of other groups.

Universal Group
The Universal group is replicated via the global catalog server. For this reason, it is available to any domain in the forest but not to other forests or external domains. Since the Universal group is available forest wide, it does not allow Domain Local groups to be members even when the Universal group has been created in the same domain as the Domain Local group.

Summary of Groups' Membership
1) Users and computers can go into any group in any domain and any forest or external domain if the group supports it.
2) Local and Domain Local groups allow the same membership requirements.
3) Universal, Domain Local and Local groups have the least strict membership requirements allowing any valid group with appropriate scope to be a member.
4) Global groups can contain only users, computers and other Global groups from the same domain only.
5) Global groups can be used everywhere, any domain, forest or external domain.
6) Universal groups are available only in the same forest since they are replicated using the global catalog. Since they are forest wide, Domain Local groups can't be members since the Domain Local scope is limited to the domain in which they were created.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" pg 145-152
"Active Directory Users, Computers, and Groups" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Active Directory Groups

Windows allows the creation of groups which simplifies permissions assignment for users. This video looks at how to use groups in Windows and also looks at the basics of how to use role based access control, one strategy used to simplify group administrator in a domain.

Groups
Each group that is created has a security identifier or SID associated with it. This SID is added to the local access list for the resource that you are controlling access to. A group can be created that does not have a SID that is used for distribution lists. These groups are covered in the next video.

Nesting
When you place one group inside another group, it is called nesting. Nesting also allows two or more groups to be placed in the same group. This essentially means that administration could be divided between two or more administrators. When administration is separated like this it is often referred to as granular control because each administrator has administrative control over a small part of the whole effects of that group that contains the other groups
Using nesting, you could create groups for the users in New York, Washington and London. Using nesting you could create a group called All_Users in which the groups for each location could be put in. Nesting can also be broken down further. For example you could divide New York users into two groups called NY_Sales and NY_Marketing. These two groups could be placed in NY_Users and this group placed in All_Users. If you wanted to create a group for All_Sales users, you could place all the sales groups from each location in this group. Notice using nesting like this means that a new user only needs to be put into the one group. Once in this group, membership of the other groups like the All_Users and All_Sales group through nesting is also achieved, allowing simple administration.

Role based access control
Role based access control is a strategy of group management generally used in large enterprises. This approach is generally used in companies with more than 500 employees. The approach involves not adding the user or users directly to the resource. In order to grant access, another group is created and assigned permissions to the resource. For example, if you had a share called general you would create two groups called general_share_modify and general_share_read. These would be assigned to the general share and given the required access.

In order to give users access to a resource, groups containing users are added to the groups based on the roles in the organization. For example, if all sales users need modify access, the sales group would be added to general_share_modify. If the marketing group needed read access, the marketing group containing all the marketing users would be added to group general_share_read. If a user were to change departments, for example, from sales to marketing, the user's account would simply be removed from the sales group and added to the marketing group. When assigning roles to a user, or removing roles, the resource never needs to be modified.

References
"MCTS 70-640 Configuring Windows Server 2008 Active Directory" Microsoft Press, pg 141-144
"Active Directory Users, Computers, and Groups" http://technet.microsoft.com/en-us/li...
"Role-based access control" http://en.wikipedia.org/wiki/Role-bas...

MCITP 70-640: Active Directory Computer Accounts

This video looks at computer accounts in Active Directory. Each time you add a computer to the domain, a computer account is created for that computer in the Active Directory database. This video looks at how these computer accounts work and how to reset the computer accounts if the password in the computer accounts becomes out of sync with the password stored on the local computer.

Computer Account
A computer account in Active Directory is very simpler to a user accounts in Active Directory. Fundamentally, a computer and user account are made from the same attributes. Like a user account, the computer account has a password. Unlike a user account this password is randomly generated. This password is supply to the domain when the computer starts up which allows a secure connection to be created between the computer and the Domain Controller. This password is automatically changed after 30 days. If the computer has not connected to the domain for more than 30 days, the computer will still be able to access the domain. The password for the computer account will be changed next time the computer connects up to the domain.

Resting the computer account
Sometimes the password used on the local computer and that stored in the domain for the computer accounts become out of sync. When this occurs you will receive a message "The trust relationship between this workstation and the primary domain failed." When this occurs the computer will need to be readded to the domain.

Pre-Stage Computer Accounts
A computer accounts is automatically created for a computer when it is added to the domain. You can also manually create the computer account in advance before the computer is added to the domain. When this is done this referred to as pre-stage. There are a number of reasons why you may want to pre-stage the computer account:

1) Deployment solutions like Windows Deployments Solutions (WDS) can be configured to use only pre-stage accounts. This stop computers from being deployed unless a computer account has been created for them. This essentially puts some controls on images that are deploy using system like WDS.

2) A pre-stage computer account ensures that the computer is put into the correct organizational unit. If you do not use a pre-staged computer account, the computer account will be created in the default location of computers. The computers OU can't have additional group polices apply to it so limits how the computer can be administered. By pre-staging the computer ensures that administrators can control the computer using group policy as soon as the computer is added to the domain.

3) A pre-stage account allows a general user to be granted the right to add that computer to the domain. This means allows more granular administration to achieved rather than having to use an account like the administrators account.

Demonstration
To perform administration on computer accounts inside Active Directory , open Active Directory Users and Computers from administrative tools under the start menu.

If you select a computer account, you can access the properties of the computer account by right clicking and selecting properties. The properties contains information about the computer like what type of computer it is. For example, a "workstation or server" or a Domain Controller with or without it being configured as global catalog server.

To create a pre-stage computer account, open Active Directory User and Computers. Inside Active Directory User accounts, navigate to the OU that you want to create the computer account in. In the new computer dialog you can also set a user account that will be allowed to add the computer to the domain.

To add a computer to the domain, open Windows Explorer and right click on computer and select properties. From the system properties, select the option change settings and then press the button change. This will allow you to remove or add the computer to a domain.

To reset the password on a computer account, right click the computer account and select reset account. The computer will need to be removed from the domain and re-added again. When you remove the computer from the domain and palace it in a work group, you do not need to reboot the computer before adding it to the domain again. Once it is added to the domain, you will need to reboot the computer to complete the process.

References
"User and computer accounts" http://technet.microsoft.com/en-us/li...
"Resetting computer accounts in Windows" http://support.microsoft.com/kb/216393
"Machine Account Password Process" http://blogs.technet.com/b/askds/arch...
"Pre-Stage Computer Account in Windows Server 2008" http://www.pctips3000.com/pre-stage-c...

MCITP 70-640: Creating a user

This video looks at how to create a new user in Active Directory and the properties that can be configured for that user. Once a user is created in Active Directory, this user can be used as a template for other users on the system. This video covers how to create a template and use it later on to create additional users.

UPN Suffix
Each user that is created has a UPN suffix assigned to them. The UPN suffix by default will be the DNS domain name. It is possible to have more than one UPN suffix defined. If multiple UPN suffixes are defined when the user is created, a UPN suffix can be chosen that is different from the domain. For example, if the domain is ITFreeTraining.local, another UPN suffix may be created called IFTraining.com. This allows the internal domain to be referenced via a DNS name that is not discoverable on the internet. This method also provides a friendlier DNS name for staff when they login.

User properties
For the properties of each user, there are a number of settings that can be configured. Listed below are the settings for a user account in Active Directory organized by the tab the setting can be found on.

General Tab
This tab contains a number of fields for the user name, office location, telephone number, etc. Filling in these fields helps a user when performing searches on the network. For example, if they wanted to search for all staff in a certain office they could search based on the office field. All the fields are informational only and do not affect how the account operates.

Address Tab
The address tab has details about the physical location of the user. These include the street number, city, etc. All the fields are informational only and do not affect how the account operates.


References
"Logon hours and other user settings" http://technet.microsoft.com/en-us/li...
"preauthentication" http://technet.microsoft.com/en-us/li...
"Primary group" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Active Directory Accounts

Active Directory accounts are required for security for users and computers. An account contains a Security Identifier or SID to uniquely identify the account. The account also contains a password and the attributes associated with that account. This video looks at how accounts work and how they are used with security.

Security Identifier (SID)
A SID is used in security to identify a user or computer account. Short SID's like S-1-1-0 are used in local accounts. Regardless of which computer it is used on, whether in a domain or not, a short SID like this always represents the same thing. For example, S-1-1-0 will always mean everyone on any Windows system.

Longer SID's like S-1-5-21-1218951425-845968048-208583963-­2209 are used in a domain. Since a SID provides a unique way of representing a user, attributes of the user can change. For example, the user's first and last names are free to change at any time and do not affect which objects the SID has been used on.

Account Management
When you change the attributes of a user like their name, since the account is associated with the SID rather than their name, changing these attributes will not affect security or other systems. Some changes may be noticeable; for example, the folder the user profile is stored in will be stored under their old user name after the username is changed.

If a person leaves the company, it is a common practice for the account to be disabled rather than deleted. Disabling the account preserves the SID, the security applied to that user, and any certificates associated with that user. When the user's replacement is hired, the account can simply be enabled and renamed to the new user.

User Authentication Process
When a user logs on to a network, an access token is generated for that user. Inside the access token is the user's SID. When this access token is presented to another system, the other system can read the user's SID from the access token.

If the user is a member of any group, the SID for that group will also be placed inside the access token. Another system can look at this access token and also determine the group membership for that user.

Any changes made to group membership for a user will require a new token to be created. For this to occur, the user must log off and log back on again to create a new token.

User Naming Standards
Before you start creating accounts in Active Directory, your company should come up with a standard for these accounts. For user accounts, you could use first initial dot last name. Whichever standard you come up with, it should be designed to reduce the number of people that will have the same username. For example, John Doe and Jane Doe will both have the username J.Doe using the standard first initial dot last name. Since Active Directory does not support two or more users having the same usernames, one of the usernames will need to change. A lot of administrators will add a number to the end of the username to ensure that it is unique in the organization.

User Log On Standards
Active Directory supports two Log On Standards for accessing the Domain. The first dates back to Windows NT and is the form of domain \ username. The second is just like an e-mail address in the form username@domainname.

Pre Windows 2000 Logon Name
When creating a new account in Active Directory, a pre-Windows 2000 logon name will be configured that will match the username where possible. You are free to change the pre-Windows 2000 logon name but in most cases, it is best to keep it the same as the username. The pre-Windows 2000 logon name is limited to 20 characters. Very old clients like Windows NT will only use the pre-Windows 2000 logon name. Modern non-Microsoft systems should not need the pre-Windows 2000 logon, but if you are using a very old system it may require it.

References
"What Are Security Identifiers?" http://technet.microsoft.com/en-us/li...
"Security Identifier" http://en.wikipedia.org/wiki/Security...
"Users Can Log On Using User Name or User Principal Name" http://support.microsoft.com/kb/243280
"SAM-Account-Name attribute" http://msdn.microsoft.com/en-us/libra...
"Active Directory Maximum Limits -- Scalability" http://technet.microsoft.com/en-us/li...

MCITP 70-640: Active Directory Replication

This video looks at how Domain Controllers in Active Directory replicate data between each other. Domain Controllers can either replicate at the site level or between sites. A different approach is used for each because at the site level you want changes to happen quickly. Between sites replication may be reduced and may even be configured to happen only outside business hours.

Intrasite replication
This is replication that happens inside one site between the Domain Controllers in that site. Active Directory will automatically connect all the Domain Controllers together to form a ring. Each Domain Controller will have two incoming connections and two outgoing connections. This ensures some redundancy in the site if a Domain Controller were to become unavailable.

Intrasite replication happens 15 seconds after a change is made to the Active Directory database. If there are more than 3 hops between Domain Controllers in the one site, then more connections will be made between the Doman Controllers until the hop count is less than 3 between all Domain Controllers. This ensures that a change will reach all Domain Controllers in the one site in less than a minute.

Intersite replication
Intersite replication is replication that happens between different sites in Active Directory. These connections are not made automatically and need to be made by an Administrator.

Bridge Head Server
In each site, a Domain Controller is selected to replicate changes from that site to another site. This Domain Controller is called a Bridge Head Server. The Bridge Head Server is selected automatically but you can also manually select a Domain Controller or Domain Controllers to be a Bridge Head Server in a site. If you do manually select the Bridge Head Server/s and all the Bridge Head Servers are down, replication will not occur form that site.

Site Links
A site link is created by an Administrator to link sites together. Site links can have a replication schedule applied to them to determine when replication occurs.

Site Link Cost
Each site link can have a cost associated with it. This is a numeric value that weights the site link. The site links with the lowest cost between two sites will be used. This allows you to configure Active Directory to use backup site links when the primary site link goes down.

Site Transports
Site links support two different transport protocols. These are RPC over IP and SMTP. SMTP does not support file replication and thus on most networks only RPC over IP will be used. SMTP could be used between domains in the forest as this kind of replication does not require file replication. RPC over IP is often referred to as just IP.

Knowledge Consistency Checker (KCC)
The KCC is responsible for creating connections between different Domain Controllers inside a site and between sites. It does this with information from the Active Directory database so, given the same data, it should always make the same decisions about which connection to create. The KCC runs every 15 minutes.

To create site links in Active Directory, open Active Directory Sites and Services from administrative tools under the start menu.

Site links are under Inter-Site Transports. Under here are the two folders for IP and SMTP transports.

Under IP there may be a site link called DEFAULTSITELINK. This is created automatically when Active Directory is installed. You can use this site link or create a new site link. If you do use this site link, it is recommended that you rename the site link to a more meaningful name.

To create a new site link, right click IP or SMTP and select New Site Link. From the wizard you need to select which sites will use that site link. Microsoft recommends that you should not put more than 3 sites in the one site link.

In the properties of the site link you can configure the schedule for the site link, how often replication will occur and also the cost that will be used with the site link.

If you want to see the connections that have been created automatically or manually between different Domain Controllers, expand down until you reach NTDS. In here you will see all the incoming connections for that Domain Controller. To see the outgoing connections, you can open the properties for NTDS and select the connection tab.

If you want to force the KCC to run, right click NTDS settings, select all tasks and then check replication Topology.

To force a replication, right click a connection and select replicate now. Even through the connection is incoming only, this will replicate data in both directions.

Command line
To force the knowledge consistency checker to run, enter the following (without the site parameter this will only run on that Domain Controller):

RepAdmin /KCC site:(Site name)

To force a replication run the following:

RepAdmin /SyncAll

This will show the bridge head servers:

RepAdmin /BridgeHeads


Thursday, September 5, 2013

MCITP 70-640: Sites and Subnets

Active Directory allows you to model your physical network topology using sites. This video looks at how to create sites in Active Directory. Creating sites allows you to control how data is replicated in your organization.

Sites Definition
Microsoft defines a site as a group of well-connected networks.

Advantages of sites
1) Sites automatically direct users to the closest resource.
2) Schedules can be configured that allow the administrator to control when replication will occur.

Site design
Multiple networks can be combined together regardless of which IP address ranges they use. If you have two networks separated by a high speed networking device, you may want to combine these networks together. Usually networks that are separated by a Wide Area Network will be put into different sites. You could also place different networks into different sites for security reasons. For example, if you had a secure network holding your intellectual property separated by a firewall, you may decide to put this network in its own site to reduce the amount of traffic travelling between the networks. Less traffic travelling between the networks means fewer rules that have to be created on the firewall between the networks.

Protect objects from accidental deletion
A lot of objects in Active Directory have the option to protect the object from accidental deletion. The tick box for this will be found in the properties for the object on the object tab. If the option is ticked and an attempt to delete the object or move the object is made, an access denied message will be displayed. To perform either of these actions, the tickbox needs to be cleared first.

Demonstration
To create or change the site configuration, open Active Directory Sites and Services from administrative tools under the start menu.

When you first install Active Directory, a site will be created called Default-First-Site-Name. This site can be renamed to another site, deleted when no longer required, or simply not used.

Under the site container, the Domain Controller/s for that site will be listed. When you promote a server to a Domain Controller, the wizard will look at the IP address of the server and suggest a site in which to put the Domain Controller or you can choose your own. For this reason, the Domain Controller should be put into the correct site when it is promoted assuming the site existed. If you need to physically move the Domain Controller or it has been put into the wrong site, you can move the Domain Controller object to another site at any time.

To create a new site, right click sites and select new site. The network address will then need to be entered (either the IPv4 or IPv6 network address).

MCITP 70-640: Active Directory Trusts


Trusts in Active Directory create the pathways for authentication to occur. They are used to link Active Directory domains to each other and also link Active Directory domains to non Microsoft systems.

In order to share resources between two domains, there must a trust or trusts connecting the two domains. Trusts do not provide access they only create a pathway to the destination. Think of trusts like roads: if you need to get to a house and there is a road between you and the house, you can drive to the destination. If the house is locked you won't be able get in unless you have the key. The same applies with trusts: you need the path to the resource via a trust and permission to access the resource.

Trust direction (One-way or two)
Trusts can be one-way or two-way. If the trust is two-way, then the domain on either side can access the other side. If the trust is one-way, the terminology used to describe the trust will usually be "Domain A trusts domain B." This means that domain A is the trusting domain and domain B will be the trusted domain. For a user in a certain domain to access a resource in another domain, the user needs to be in the trusted domain.

Transitive trusts
A transitive trust is when a trust can be extended outside of the two domains in which it was created. A domain connected via a transitive trust can thus access any other domain when there is a path of transitive trusts between that domain and the target domain.

Non-transitive trust
A non-transitive trust is a trust that will not extend past the domains it was created with. If domain A was connected to domain B and domain B connected to domain C using non-transitive trusts the following would occur. Domain A and domain B would be able to access each other. Domain B could access domain C. Domain A, however, could not access domain C. Even though the domains are indirectly connected, since the trust is non-transitive the connection will stop once it gets to domain B. In order for domain A and domain C to communicate using non-transitive trust you would need to create another trust between domain A and domain C. Think of it like having to catch two buses to get to your destination but only having one bus ticket. Transitive and non-transitive trusts will work together. When using both, the pathway through the network will simply stop as soon as a non-transitive trust is travelled over.


MCITP 70-640: Uninstalling Active Directory


At any stage you can add and remove domain controllers from Active Directory. This video looks at how to remove the last domain controller from a child domain. When this occurs, the Active Directory database will be removed and with it anything that was stored in it. This video looks at how to remove a child domain; however, the same process could be used to remove the last domain controller in the forest.

Operational Master Roles
If the domain controller is holding any operational master roles, these can be moved manually or DCPromo will automatically move them to another domain controller when the domain controller is demoted. Refer to our video on moving operation master roles for information on how to move operational master roles: http://70-640m.blogspot.in/2013/09/active-directory-70-640-free-course_7046.html 

If you want to check if your domain controller is holding any operational master roles you can run the following command from the command prompt:

NetDom Query FSMO

Global Catalog Servers
If you are removing a domain controller that is a global catalog server, you should consider the effect that this will have on your domain. Even in a single forest, single domain environment global catalog servers are used by applications for performing searches in Active Directory. For this reason you should always have at least one domain controller in your domain. 

Effects of removing the database
Before removing the last domain controller and thus Active Directory, you should consider what is stored in Active Directory and thus what you are losing. Removing the database will remove any accounts in that domain but will also remove any certificates that are stored in Active Directory as well. Before removing the last domain controller it is recommended that the domain controller be shut down for a period of time before it is demoted. If no problems are found, start the domain controller back up and then demote it.

Demonstration
To check if the domain controller is holding any operational master roles run the command:

Run NetDemo Query FSMO

To demote the server run the command DCPromo. The wizard will ask you if this is the last domain controller in the domain. If this domain controller is the last domain controller, tick this box. If you still have other functional domain controllers on the network you should remove these before ticking this box to ensure the domain is removed cleanly. If there are domain controllers that are still in the domain but are not operational and thus will not be used on the network again, tick the option this is the last domain controller in the domain. Ticking this box will remove the domain even if there are domain controllers that are still registered in the Active Directory database.

If you are getting errors in DCPromo, run DCPromo with the /forceremoval switch and it will ignore these errors.

DCPromo will ask you to set a local administrator password. When Active Directory has been removed you will need this password to login locally to the server. If you still have a domain controller left in the domain, the server will become a member server and you can still use a domain account to login to the server.


MCITP 70-640: Active Directory adding a child domain

This video looks at how to add a child domain to an existing domain in Active Directory. Child domains can access resources from the parent and also from any other domain in the forest. This video will look at adding the east domain to the existing domain.

Things to consider before adding a child domain
The more domains that you have in your forest, the harder it will be to administer your network. When possible, you should attempt to reduce the number of domains in your forest. Sometimes due to company needs or security reasons, extra domains may be created. It should be remembered that in Windows Server 2008 there have been a number of improvements and features which in previous versions of Windows would have required additional domains. These are:

1) Active Directory could previously only have one password policy per domain. If your domain functional level is Windows Server 2008 or higher, you can support multiple password policies for the same domain.
2) With Windows NT the database was limited to 40 MB, which was around 40,000 objects. Because of this multiple domains may have been required, whereas Active Directory now only requires one.

New domains may also be created due to different business unit requirements. In a lot of cases you can separate departments and even companies using organization units inside Active Directory; however, dealing with things like different company budgets is not as simple. If the companies have different IT support staff, they will probably want different domains.

Demonstration
Creating a new domain or adding a domain controller to an existing domain is all done using DCPromo.

1) When asked, select the option at the top existing forest. Under this, select the option, "create a new domain in an existing forest." This will create the first domain controller in your new domain in the existing forest.
2) You will next be asked for the credentials for a user to add the domain to the existing forest. This needs to be a user in the enterprise administrators group; however, the user does not need to be in the root domain: they can be located in any domain in the forest.
3) Next you need to enter in the name of the parent domain of the child domain. If you are creating a new tree, enter in the new namespace. DCPromo will understand this is a new tree rather than a child domain.
4) Once the relevant details are entered, a Domain Naming Master will be contacted to see if this domain already exists. If the Doman Naming Master can't be contacted DCPromo will fail.
5) Once the Domain Naming Master has been contacted and it has been confirmed this domain does not already exist, you will be asked for the domain functional level. What is available will be determined by what the current forest functional level is.
6) Next you need to select the site where the domain controller will be. If no sites have been created, you can use "default first site name" for the site.
7) Next you can decide if the domain controller is a DNS server and/or a global catalog server. Even if you are creating a completely separate domain you can use a DNS server or even a 3rd party DNS system like UNIX.
8) The wizard will ask you where to put the database, log file and SysVol folder. In most cases leave this on the default.
9) The next screen will ask for an Active Directory recovery password. This is used in certain recovery situations including restoring deleted objects.

MCITP 70-640: Upgrading Active Directory

This video looks at upgrading your current Active Directory environment so that you can deploy Windows Server 2008/R2 domain controllers in your environment. The video looks at the prerequisites required, the commands you need to run and a demonstration of how to prepare your environment for Windows Server 2008/R2

The following only needs to be done if you are planning to deploy Windows Server 2008 or Windows Server 2008 R2 Domain controllers on your network. If you only want to use Windows Server 2008 as a member server (that is, you do not want to promote it to a domain controller), you can do this without having to perform any of the steps in this video.

Upgrading Prerequisites
Remove all NT4 Domain controllers
Upgrade all Domain controllers to Windows Server 2000 SP4 or above
Domain functional level needs to be Windows 2000 or higher
Forest functional level needs to Windows Server 2000 or higher
The user performing the upgrade needs to be a member of the following groups:
Schema /Enterprise/Domain Administrator

For more information on the domain and forest functional levels, please see the following videos.
Forest Functional Level Video
http://70-640m.blogspot.in/2013/09/active-directory-70-640-free-course_4313.html

Domain Functional Levels Video
http://70-640m.blogspot.in/2013/09/active-directory-70-640-free-course_5489.html

Preparing your environment
In order to prepare your environment you need to run a tool called ADPrep. This can be found on the Windows Server 2008/R2 DVD under the Support folder. ADPrep has been updated since Windows Server 2008 and thus the first two commands listed below need to be run again when installing your first Windows Server 2008 R2 Domain Controller on a network with Windows Server 2008 Domain Controllers.

This command needs to be run once per forest. The command needs to be run on the server holding the schema operational master role.
ADPrep /ForestPrep
The following commands need to be run once on every domain in which you are going to deploy Windows Server 2008/R2 Domain Controllers. The following commands need to be run on the Domain controller holding the infrastructure master.
ADPrep /DomainPrep
ADPrep /DomainPrep /GPPrep
The following command only needs to be run if you are going to deploy Windows Server 2008 Read Only domain controllers. If you are not sure, run the command anyway as it does not affect the run of Active Directory if Read Only Domain Controllers are not deployed.
ADPrep /RODCPrep

Upgrading demo
To check the forest level, run Active Directory Domain and Trusts, right click the domain and select raise domain functional level. Make sure it is Windows Server 2000 native or higher.
To find out which domain controllers are holding which operational master roles, run the following command:
netdom query fsmo
To upgrade the forest, on the Domain Controller holding the schema operational master role, run the command line ADPrep /ForestPrep.
The process normally takes about 5 minutes or so. Once it is completed, allow some time for the changes to replicate through your network or force a replication.

To check whether your domain meets the minimum requirement for the domain functional level Windows Server 2000, run the command Active Directory Users and Computers. Right click the domain and select raise domain functional level.

The following commands need to be run on all domains on which you want to deploy Windows Server 2008 domain controllers. The following commands also need to be run on the Domain Controller holding the infrastructure operational master role.
ADPrep /DomainPrep
ADPrep /DomainPrep /GPPrep
The following command only needs to be run if you are planning on using Windows Server 2008 Read Only Domain Controllers.
ADPrep /RODCPrep