AppLocker will block applications from running based on the descriptor. You can block programs by publisher, path, version, file name, publisher description or even hash. This feature is only available in Windows 7 and Microsoft Windows Server 2008 R2. While it can be used on an active directory domain, I use local group policy. You can also create exceptions to allow some programs through the rules.

AppLocker is a feature introduced that plays of the old hash rules to block programs.

Hash rules are rules created in group policy that analyze software. It considers the “footprint” of software to recognize it. This means that if the program is renamed, it will still be recognized. Renaming the software is an old trick used by people who write viruses. these hash rules in Group Policy can be used to either allow or disallow a program to run. The problem is that if the software is updated or the users simply download an old version, the software can run. This hash rule and many like it can stop a virus or trojan from running rampant in your network. This is available in local or domain group policy, although this video is made using the local GPO. It affects all users of that computer. This video was made on Windows 7, but is possible on XP, Vista, 2000, Windows Server 2003 and 2008.

this tutorial shows how to block USB drives by local group policy. This GPO setting was first available on Windows Vista. I perform this on Windows 7. Group Policy objects are only available to the professional and ultimate versions of Windows 7. These flash drives, also called thumb drives, pose a security threat to many businesses. They make it easy to remove sensitive data from the workplace.

Windows System Resource Monitor will evaluate how you applications are being used and apply management policies.  It is important to test your policies thoroughly before implementing them. It is vitally important to understand how WSRM monitor functions before it is fully implemented. It is an extremely powerful tool that when implemented incorrectly can cause vital applications to come to a screeching halt. Once you are comfortable with the policies you have developed, you may use the calendar to schedule when they may be implemented.

WSRM will log Events and Alerts similar to Event Viewer. It becomes very useful on multiprocessor systems with large amounts of RAM. It starts with four management policies, but more may be added. It will ensure that mission critical applications, such as Active Directory, are always available. It is a tool that is intended for multipurpose Domain Controllers. If your DC is only a DC, then WSRM is not for you. Microsoft recommends that Domain Controllers only serve that purpose, but if you are unable to use other server for other application, then WSRM is the tool to manage all the roles that DC will fill. WSRM is also very resource intensive in itself. If you plan to use it for several servers, it would be a very good idea to run a dedicated WSRM server.

Trusts in domains operate in a similar fashion. One domain will trust the second domain to authenticate accounts. There are two domains in every relationship, the trusted domain and the trusting domain. The trusted domain will have an identity store that is trusted to authenticate user in the trusted domain. The user then can log into the trusting domain and still authenticate and access resources.

There are some important terms to understand about trusts.

• Transitivity: If the first domain trusts the second domain, and the second domain trusts the third domain, does the first domain trust the third domain? If it does, the links are transitive. If the first domain does not automatically trust the third domain, you must create another trust between the first and third domain.
• Direction: Trusts sometimes only work one way. Using the previous example, it is possible that the first domain trusts the second domain, but the second domain does not trust the first domain. First domain users can not access resources in the second domain, but second domain users can access first domain resources.
• Automatic or Manual: Some trusts are created automatically. Some require manual creation.
• One-way or two-way: The trusts may only work in one direction. Domain A might have a trust where it trusts Domain B, but Domain B doesn’t have to trust Domain A. This means users from Domain B can sign into Domain A, but users from Domain B can’t sign into Domain A.
• Trusted and trusting domain: Users in domain A wish to access resources in domain B. They are able to do so because there is a trust between the two domains. Domain A is the trusted domain. Domain B is the trusting domain. Domain B is trusting domain A to verify the users.

Within a forest all domains are trusted. There is usually a root domain. The root domain becomes the default reference which all other domains refer. It becomes a central point of reference for authentication. It will know who to consult for authentication. Effectively all links in a forest become transitive. Any automatically created trust should never be deleted. Trusts to other forests and domains outside the forest must be manually created.

There are four kinds of manual trusts. Manual trusts are trusts that are created by a person. A computer that joins a domain is not a manual trust. It is automatically created between the computer and the domain controller. There are four kinds of manual trusts.

• Shortcut Trusts: It is possible to assign a trust from the parent of one domain directly to the child of another domain. This may be a one-way or two-way trust. It is always transitive.
• External Trusts: A trust that is created to a domain outside the forest. External trusts are only one-way and non-transitive. Even attempting to create a two-way external trust, you are merely creating two one-way trusts. Microsoft allows the options of SID filtering (domain quarantine) and selective authentication.
• Realm trusts: Microsoft allows cross-platform interoperability on other Kerberos v5 platforms. This requires the account to be created in Active Directory and the name be mapped to the account in the other domain. This is done because non-Windows Kerberos domains do not contain all the authorization data required by a Windows domain. Realm trusts are non-transitive by default.
• Forest Trust: A forest trust is a trust that is built between two forests. This allows a trust between any domain in one forest to any domain in a second forest assuming the trust is a two-way trust. Forest trusts are not transitive. In a Windows domain, the forest functional level must be Windows Server 2003 or later. Also there are specific DNS requirements for this cross-forest trust. You have to create domain forwarders on your DNS servers to forward to the new domain.

A domain trust does not give access to resources. It is merely a method of authentication. That means domain administrators of the other domain are not domain administrators on your domain. This allows you to modify ACLs on your domain to include users that are not authenticated specifically to your domain. There are some occasions where they may be able to access resources because that resource is available to the Authenticated Users group. There are other groups that are similar to the Authenticated Users group.

SID filtering (domain quarantine) is enabled by default on all the external and forest trusts of a Windows domain. Every user, computer, and group have a specialized identifier attached to them called the SID. Every one is unique. There is also a descriptor on every account called sIDHistory. This has the possibility to record every SID that has been associated with the account. This is useful when using the Active Directory Migration Tool. When users are migrated from one domain to another, it is possible associate the old SIDs to the account in the new domain. Therefore it is possible to have users only have access to resources due to their sIDHistory and they are unaware of it. SID filtering strips the sIDHistory from the user. SID filtering is enabled by default on trusts that lead to external domains and forests.

When a trust is built between two forests there are two options for authentication. There is selective authentication and domain-wide authentication. With domain-wide authentication, all users in the trusted domain have are authenticated to the trusting domain. They might have access to a great deal of resources in the trusting domain simply because all authenticated users have access to those resources. With selective authentication, it is possible to specify to which resources a user may authenticate. This removes the trust from the domain, and places the trust on individual accounts. In short is give the permission for user A to authenticate to file server B even though they are in different domains. This feature is accessible when Active Directory Users and Computers is viewed in advanced mode. By looking at the properties of the computer account and selecting the security tab, you’ll see a security permission listed as “Allowed to authenticate.”

With the ADMT, you can test migrations as well. The wizards will simulate the migration and allow evaluation of potential results before you actually perform the migration. After identifying and resolving any problems, you can perform the migration. The wizard that tests the settings will also provide a migrate later option that can be used for the migration. The process can repeat several times with testing and analyzing until all problems are resolved.

There is still one problem that will never be fully repaired in the migration. That problem is that SIDs will never be migrated. SIDs are unique values that are created for every computer, user, and group on any domain. As a user or computer logs on, a token is created that contains their SID and all SIDs associated with their groups. This token contains all identifiers associated with the user or computer. Security Descriptors (SD) are associated with resources. They contain information about permissions, rights, ownership, and auditing instructions. The SD consists of two parts, the SACL and the DACL. The System Access Control List (SACL) will specify auditing instructions. The Discretionary Access Control List (DACL) will specify permissions. Often the focus is on the DACL. Within the DACL, specific Access Control Entries (ACEs) can be specified with a deny or allow permission. These ACEs are linked linked to the individual SIDs. When a user or computer tries to access a resource, the Local Security Authority Subsystem (LSASS) compares the SIDs in the users token with the SIDs in the ACEs ACL.

When copying accounts from one domain to the other, new SIDs are generated for the users. Many parts of the user will appear the same such as user name, password, and group membership. However, since the SIDs are different, they are not the same user according to the resource. This problem has been resolved in one of two ways…

• sIDHistory: sIDHistory (note capitalization.) is an attribute that was created in Windows Server 2000 domains. It allows the previous SIDs to be attached to an account as secondary SIDs. The LSASS then may check either the principal SID or the sIDHistory in the accounts token.
• Security Translation: This process involves inspecting every Security Descriptor (SD) attached to a resource in the domain and replacing the SIDs of the previous domain user with the SIDs of the new domain user. This remapping of the resources is referred to as re-ACLing and is very labor intensive. Luckily, ADMT can perform the job of inspecting rescources and remapping them to the new SIDs of the migrated accounts. In most cases, sIDHistory is used until resources can be re-ACLed.

Another concern is group membership. Often accounts are members of global groups. Global groups are good for only members of a domain. Cross-domain membership of a group requires Universal Groups. This means that when a user is migrated to the new domain, the new user will not be a member of any groups in the old domain and will probably lose access to all resources in the old domain. (Assuming that resources are assigned using the recommended Microsoft method of AGLP.) This is solved by migrating groups first. Then when users or computers are migrated, they can be placed in the new universal groups. With sIDHistory, both groups and accounts may never notice the difference. When all changes required have been confirmed the groups may be changed back into global groups. They were made universal groups because universal groups can access resources in both domains.

Other problems with ADMT concern password migration. The ADMT can migrate passwords but the passwords for the old account may not be complex enough for the new domain’s password requirements. Service accounts may be migrated but the services may not recognize the new identity. These service accounts are ones that real people never use and may not be well known enough to remember what they do. Some objects can not be migrated such as Domain Admins or domain local administrators group. ADMT will make suggestions on how to deal with these scenarios.

A domain that uses NT 4.0 domain controllers and Windows 2000 Server domain controllers is referred to as a Windows 2000 Server mixed mode domain. After all Windows NT Servers have been removed or demoted into becoming only members of their domains, the forest functional level may be raised to a Windows 2000 Server native functional level. The added functionality in a 2000 Server native forest includes…

• Universal Groups: Universal groups are groups that may be referenced anywhere in the forest.
• Raising both levels at once: You may raise the domains functional level by raising the forest’s functional level.

After all Windows 2000 Servers have been removed or demoted into becoming only members of the domains, the forest functional level may be raised to a Windows Server 2003 functional level after all the domains have been raised to Windows Server 2003 functional level. The added functionality in a Server 2003 domain includes…

• Forest Trusts: Allows authentication between domains for sharing of resources.
• Domain Rename: Allows the renaming of a domain within the forest.
• Linked-value replication: In Windows 2000, when changes were made to a group, it would mean replication of the all properties of the group. The downside to this was that if the group was being modified on two domain controllers at the same time. One of the changes might not occur due to bandwidth issues. This is why there is a recommended cap of 5,000 users in a group for Server 2003.Linked-value replication modifies the individual membership change instead of the entire member attribute.
• Support for Read Only Domain Controllers: Read Only Domain Controllers (RODC) are a new feature of Server 2008 that may be used in a Server 2003 forest. A RODC will allow the caching of credentials in a remote location to prevent WAN traffic being consumed by authentication requests. Also it is required to run “adprep /rodcprep” on the Windows Server 2003 domain controllers.
• Improved Knowledge Consistency Checker algorithms and scalability: The intersite topology generator (ISTG) enables replication within forests through links. In a Windows 2000 forest, sites links must be manually created. There are also improvements in the algorithms in a Windows 2003 forest.
• Conversion of inetOrgPerson objects to user objects: inetOrgPerson objects are used for non-Microsoft directory services. With a Server 2003 forest, it is possible to convert an inetOrgPerson into a user object and vice versa.
• Support for dynamicObject auxiliary class: Used by certain applications and developers, dynamicObject is new to Server 2003.
• Support for application basic groups and LDAP query groups: These two new group types can be used to support role-base authorization in applications that use Authorization Manager.
• Deactivation and redefinition of attributes and object class: Attributes and object classes may not be deleted. With Server 2003 forests, they can be redefined or deactivated.

After all Windows 2003 Servers have been removed or demoted into becoming only members of the domains, the forest functional level may be raised to a Windows Server 2008 functional level after all the domains have been raised to Windows Server 2008 functional level. A Server 2008 functional level does not add any functionality to the Forest.

After all Windows 2008 (Non-R2) Servers have been removed or demoted into becoming only members of the domains, the forest functional level may be raised to a Windows Server 2008 R2 functional level after all the domains have been raised to Windows Server 2008 functional level. The only new feature is a very nice one. Microsoft has introduced a recycle bin into Active Directory. This requires a command in powershell.

“Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=mydomain,DC=com’ –Scope ForestOrConfigurationSet –Target ‘mydomain.com’”

The original Windows domain used NT 4.0 domain controllers. The functionality in an NT Server domain includes…

• Local and global groups
• Global catalog support

A domain that uses NT 4.0 domain controllers and Windows 2000 Server domain controllers is referred to as a Windows 2000 Server mixed mode domain. After all Windows NT Servers have been removed or demoted into becoming only members of the domain, the domain functional level may be raised to a Windows 2000 Server native functional level. The added functionality in a 2000 Server native domain includes…

• Group nesting: Group nesting allows for groups to be placed in other groups for simplification of asset permissions. This is the method used for AGDLP method.
• Universal Groups: Universal groups are groups that may be referenced anywhere in the forest.
• Sid history: The System Identifier is a specific attribute that is applied to users and computers. It is used for identity purposes and every object in Active Directory has a unique SID.
• Group conversion: it is possible to convert a security group into a distribution group and vice versa.
• Raising both levels at once: You may raise the domains functional level by raising the forest’s functional level.

After all Windows 2000 Servers have been removed or demoted into becoming only members of the domain, the domain functional level may be raised to a Windows Server 2003 functional level. The added functionality in a Server 2003 domain includes…

• Netdom.exe: This utility is used to rename computer accounts in the domain. It can even be used to rename the domain controller! It doesn’t need to be run from server either. It can be run from any computer that is a member of the domain and has Windows Server 2003 SP1 Support Tools (suptools.msi).
• LastLogonTimestamp attribute: When a user or computer logs onto the domain, this attribute is applied to the account and replicated throughout the domain.
• userPassword attribute: There are four object classes in Active Directory. The most well known are users, computers, and groups. The fourth is inetOrgPerson. It is used with several non-Microsoft directory services in a similar fashion to users. At the Windows Server 2003 domain functional level, you can use userPassword attribute to set the same password for user and inetOrgPerson.
• Redirusr.exe and Redircmp.exe: These two commands can be used to redirect the default containers for for users or computers when joined to the domain. By default, the containers used for such a purpose are not organizational units and will not have Group Policy Objects (GPOs) applied to them.
• Authorization Manager policies: Used by applications, Authorization Manager stores authorization policies in Active Directory Domain Services.
• Constrained Delegation: It is possible with the Kerberos authentication protocol for applications to take advantage of the secure delegation of user credentials. This means that specific destination services can allowed by configuration of delegation.
• Selective Authentication: This deals with authentication between domains in the forest which is referred to a trust. This feature specifies users that when not in their domain are allowed to authenticate to the local domain controller. The local domain controller is not part of their domain either, but is able to authenticate the user do to a trust between the domains.

After all Windows 2003 Servers have been removed or demoted into becoming only members of the domain, the domain functional level may be raised to a Windows Server 2008 functional level. The added functionality in a Server 2008 domain includes…

• DFS-R of SYSVOL: File Replication Service (FRS) is the default replication method of the SYSVOL folder. In Windows Server 2008, a new method was introduced which is more robust and detailed at replication. Windows Server 2008 may be upgraded to the new replication service, Distributed File System Replication (DFS-R).
• Advanced Encryption Services: Kerberos protocol may use Advanced Encryption Services (AES 128 or AES 256) to increase security. AES replaces RC4-HMAC (Hash Message Authentication Code) encryption algorithm.
• Last interactive logon information: The time, the workstation used, number of failed logon attempts since last logon are updated in the attributes of the user object.
• Fine-grained password policies: Allows specific password policies to be applied to specific users or groups via Password Settings Object (PSO).

After all Windows 2008 (Non-R2) Servers have been removed or demoted into becoming only members of the domains, the domain functional level may be raised to a Windows Server 2008 R2 functional level.

• Authentication Mechanism Assurance: Allows group modification based on authentication method. A user can have access to different resources based on whether they authenticated with a certificate instead of just their name and password.
• Automatic SPN management: Exchange, IIS, and SQL service accounts can now be managed better. It is possible to assign the management of these accounts to specific users. Passwords of those accounts can be reset automatically. A class of domain accounts can be used to manage services on local computers.

After you have created site links in Active Directory Sites and Services, the intersite topology generator will manage the topology within the individual sites. Rarely will you need to make an intersite replication path since the process is largely automatic. These links may be made in Active Directory Sites and Services. They will be located at “Sites > Intersite Transports > IP or SMTP”

Directory Service Remote Procedure Call (DS-RPC) appears in the Active Directory Sites and Services under the folder IP. It is the preferred replication method since it is the simplest to create.

Intersite Messaging-Simple Mail Transport Protocol (ISM-SMTP) is a much more difficult configuration. It is used in networks that do not have a reliable WAN connection between sites. It requires a certificate authority (CA) and dedicated domain for the site with the poor connection. This is because SMTP replication is not supported in the domain naming context. In short, if a site requires ISM-SMTP, that site must be its a different domain in the forest.

It is possible to create a link between two remote sites using a transitive link. Site links are assigned a cost of 100 by default. The lower the cost, the higher the priority of the link. Therefore, if you have a main site and two remote sites, you can assign a site link between the two remote sites with a much higher cost. The links between the main site and any remote site can be assigned a cost of 100. The two remote sites can be linked at a cost of 400. The bridgehead servers will analyze the cost of all links and realize that it is better to transfer the data between the main site. With each of it’s link having a cost of 100, the total cost from one site to another is 200. The link between the individual sites is 400 and not recommended. However, should connectivity between the main site and the two remote sites fail, the two remote sites will communicate with each other at a much higher cost. This introduces redundancy into the replication as part of a disaster recovery plan.

Intersite replication does not use notification. Updates are only received through polling. By default, polling only occurs once every three hours. The bridgehead server will contact its upstream controllers to seek out changes. Many organizations may want much more rapid updates and modify the default time to a smaller time frame. The smallest amount of time that may be assigned is 15 minutes. This metric may be modified in ADSS by selecting the links properties. This means under any circumstances, it will take a minimum of 15 minutes for changes in Active Directory to replicate to all sites.

On the general tab of properties of a site link in Active Directory Sites and Services, there is a button labeled “Change Schedule.” By default replication is configured to occur 24 hours a day. The “Change Schedule” button will open a color coded chart where an administrator may select what times replication is a available. It is possible to modify the site links so that two schedules may never overlap. This will lead to greater inefficiencies in replication and may cause replication to never happen at all. It recommended to never modify replication schedules. It also possible to specify in the properties of the IP transport protocol that a link ignore all schedules.