Articles

1,773 Articles
How to Pass the MCSA Windows Server 2012 Exam?

How to Pass the MCSA Windows Server 2012 Exam?

by Webmaster 0 Comments

The MCSA Windows Server 2012 exam is a true necessity for you to complete. This will provide you with the skills you need to keep IT functions working in any business. Completing your MCSA certification will especially ensure that you can enter into the field of computer networking or systems administration. It is also important for your overall efforts in becoming a Microsoft Certified Solutions Expert.

You will have to complete the MCSA Windows Server 2012 exam in order to attain your certification. There are three particular exams that you will have to look into so you can get the most out of your work.

Three Key Exams

There are three exams for you to take a look at when getting your MCSA certification:

  • Exam 70-410 focuses on installing and configuring Windows Server 2012. This includes working with Active Directory and other key services.
  • Exam 70-411 is on how to administer the server operating system to a number of computers. Group management, network access and general security are among the keys covered in the exam.
  • Exam 70-412 is all about configuring the operating system. Fault tolerance, identity analysis and many other advanced functions are profiled in this particular exam.

All three of these exams should be used in order. You can only qualify for the more advanced exams if you have completed them in their proper order.

Try Different Strategies

A good idea to consider when aiming to get the most out of your MCSA certification plans is to test the operating system yourself. Many points in the exams will focus on how you can configure different settings. Exam 70-411 focuses on how to configure the Active Directory, Group Policy and NPS infrastructure among other necessary points.

You will have to look at how well you are able to handle different functions within the system to get the most out of how it can work. This is especially important when you consider how well each exam will focus on a variety of specifics dedicated to getting the most out of the operating system. Checkout – Things to follow before you choose MCSA windows server 2012

Complete a Training Program

You can always look for a variety of resources to help you get the most out of the training process. But it is best to look for an online training program that can help you learn about the many things that are covered in the exam. These include a variety of points relating to how well you can control the operating system and how to work with many of the more technical aspects of the system. This is to help you figure out what you can get out of the system while making it as easy to follow and utilize as possible.

Look For Trial Software

As you work on a training program, you can use a trial edition of the Windows Server 2012 program. Microsoft does offer a trial version of the program that can be used for 180 days before it locks you out and asks you to register for it.

This could help you with getting plenty of firsthand experience with the operating system. Be sure you sign up for the trial with enough time during your training program so you will get the most out of your efforts.

When you get enough training, you will find that it is not too difficult for you to pass the MCSA test. You have to watch for how well you can complete the testing process so you can get the most out of your work in general. Be sure to look at how you can get experience with the operating system before your test as well. By following the right rules, it should be easier for you to get the most out of your work for getting your certification.

Importance of Web-Based Applications in Banking and Finance Industry

Importance of Web-Based Applications in Banking and Finance Industry

Banking and finance industry now abundantly relies on web-based applications for a host of their activities and providing services to the customers. Many of the large corporations all over the world are now giving considerable importance to the startups and spotting the right talent for commercializing and operationalize innovative web-based application ideas to generate profits.

But why is the industry so focused on using such applications? Let us try to find out.

  • Easier Account Management

In the banking sector, one of the most important activities is to create, maintain and update the customer accounts. With the help of financial application development offered by professional IT firms the accuracy of this process has significantly increased. The applications manage all the transactions with the help of a centralized data record system which can be instantly accessed by the banks and financial institutions.

  • Enhanced Safety

While there were banking software and applications in the past too, they required the employees and employers to save the data to their computers, laptops, hard drives, or USB drives. However, computers are hardly backed-up in the right way, laptops can get stolen, and not every machine has the best security solutions. On the other hand, with the latest web-based applications, the data is stored on a secure, daily backed-up, always-updated enterprise-class server in highly secure, state-of-the-art data centers. This ensures maximum protection of sensitive financial data.

  • Centralized Storage of Data

Another major benefit of the web-based applications is the fact that all the data is centrally stored and can be easily accessed anytime and from anywhere through the web. You cannot ever leave anything on a wrong computer as all the data is stored in a single place. Needless to say, everything is safe and password-protected.

  • Automatic Updates

Unlike the traditional applications which required you to download and install the updates manually, web-based applications update automatically. So, every time you use one such application you can rest assured that you are using the latest version of the application. Moreover, most of the traditional applications usually have some costs associated with every upgrade. However, updates on web-based applications are usually free.

  • Smaller Institutions Can Compete Effectively

As the application is available to everyone, smaller banking and finance institutions can compete with the larger counterparts more effectively as both are using similar technologies. This allows the smaller institutes to offer similar products and services to the customers while also experiencing the same benefits which the larger institutes experience.

These are some of the reasons which make web-based applications very important for the banking and finance industry. With banking sector growing, it is evident that technology will keep playing an important role in the growth of this integral sector.

Why Database Management Professionals Should Do Oracle 11g Dba Certification?

Why Database Management Professionals Should Do Oracle 11g Dba Certification?

It is really important to keep up with the developments and advances in your field regularly and that too even more if you’re in the IT field. If you’re a database administrator and want to achieve higher credentials in the database industry then Oracle certified professional (OCP) or Oracle 11g DBA certification can validate your authority in database management not only in Oracle environment but even on other positions which employ different database management systems.

Various companies are looking for people with expertise in the oracle database management system or individuals who are OCP certified to work in ecosystems of their database management, even the companies which do not incorporate Oracle database management system. This fact cannot be overlooked by an individual in determining the future goals of his career and consolidating his chances at the highest level. The certification can very well make the difference between you working in a small database management enterprise and taking up a big role in a reputed firm with awesome pay scale and other underlying benefits. With oracle gaining more and more recognition and central stage for maintaining high level and demanding databases by business organisations and companies all over the world; it is highly imperative for a database management professional to get the much needed validation from the highly rated and acclaimed certification to make sure that the skills set required for a top notch database administrator position match with the level of his credential over a period of time.

Eligibility Criteria for DBA Certification

The certification provides you with enough leverage in terms of performing in demanding database technology of Oracle enterprise and operating other key roles in general database environment of a reputed organisation with certified expertise and authority. Checkout Top 5 Oracle Certification Preparation Book In 2017

In order to deem eligible for the certification one must be OCA (Oracle Certified Associate) certified and that requires you to pass Oracle SQL and Oracle DBA certification exams first. After gaining the OCP certification, one can even pursue the highest level Oracle certification, OCM (Oracle Certified Master) to strengthen the opportunities of a career in Oracle database management system further. The certification tests your abilities to operate in Oracle database with essential skills of security management, application development, SQL integration and networking as a database administrator.

Significance of DBA Certification

  • The role of database administrators are getting more and more diverse nowadays and the certification can give you a much desired edge over other database management professionals seeking the same position in a reputed IT firm.
  • The global team leaders and recruiters are increasingly giving importance to certified professionals to increase efficiency and cut costs for their companies and organisations and that has increased the demands of advanced certifications in various IT fields.
  • The OCP certification can validate your skills of managing complicated database management situations with expertise at the highest level and that too with expertise and skills needed to secure and maintain the databases in a much more refined level of security.
  • The undertaking of the DBA course imparts a great amount of authority and expertise in installing, managing, updating, troubleshooting and securing a database in high pressure situations of a real time Oracle enterprise.

Conclusion

The certification not only improves your chances of database management in Oracle enterprise but increases your general database management skills on an advanced level to perform meticulously well in highly demanding situations of database management and that can give you the impetus to succeed everywhere and not just Oracle database management systems.

Resource Access for Users from Trusted Domains

Resource Access for Users from Trusted Domains

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

In this article we will discuss Resource Access for Users from Trusted Domains.

Overview of Resource Access for Users from Trusted Domains

When you configure a trust relationship that enables your domain to trust another domain, you open up the possibility for users in the trusted domain to gain access to resources in your domain. The following sections examine components related to the security of a trusting domain’s resources.

Domain Quarantine

By default, domain quarantine, also called SID filtering, is enabled on all external and forest trusts. When a user is authenticated in a trusted domain, the user presents authorization data that includes the SIDs of the user’s account in the groups to which the user belongs.
Additionally, the user’s authorization data includes security identifiers from other attributes of
the user and his or her groups.
Some of the SIDs presented by the user from the trusted domain might not have been created in the trusted domain. For example, if a user is migrated from one domain into another, a new SID is assigned to the migrated account. The migrated account will, therefore, lose access to any resources that had permissions assigned to the SID of the user’s former account. To allow the user to continue to access such resources, an administrator performing a migration can specify that the sIDHistory attribute of the user’s migrated account include the former account’s SID. When the user attempts to connect to the resource, the original SID in the sIDHistory attribute is authorized for access.
In a trusted domain scenario, it is possible that a rogue administrator could use administrative credentials in the trusted domain to load SIDs into the sIDHistory attribute of a user that are the same as SIDs of privileged accounts in your domain. That user would then have inappropriate levels of access to resources in your domain.
Domain quarantine prevents this problem by enabling the trusting domain to filter out SIDs from the trusted domain that are not the primary SIDs of security principals. Each SID includes the SID of the originating domain, so when a user from a trusted domain presents the list of the user’s SIDs and the SIDs of the user’s groups, SID filtering instructs the trusting domain to discard all SIDs without the domain SID of the trusted domain.
Domain quarantine is enabled by default for all outgoing trusts to external domains and forests. Disable domain quarantine only if one or more of the following are true:

  • You have extremely high levels of confidence in the administrators of the trusted domain.
  • Users or groups have been migrated to the trusted domain with their SID histories preserved, and you want to grant those users or groups permissions to resources in the trusting domain based on the SIDHistory attribute.

To disable domain quarantine, type the following command:

netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:no

To re-enable domain quarantine, type this command:

netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:yes

Note:You might encounter either term—domain quarantine or SID filtering—on the 70-640 exam. Remember that this procedure is used so that users from a trusted domain are authorized using only the SIDs that originate in the trusted domain. An effect of domain quarantine is that the trusting domain ignores SIDs in the SIDHistory attribute, which typically contains the SIDs of accounts from a domain migration.

Authenticated Users

A trust relationship itself does not grant access to any resources; however, it is likely that by creating a trust relationship, users in the trusted domain will have immediate access to some
of your domain’s resources. This is because many resources are secured with ACLs that give permissions to the Authenticated Users group.

Membership in Domain Local Groups

As you learned in Chapter , “Managing Groups,” the best for managing access to a resource is to assign permissions to a domain local group. You can then nest users and groups from your domain into the domain local group and, thereby, grant them access to the resource. Domain local security groups can also include users and global groups from trusted domains as members. Therefore, the most manageable way to assign permissions to users in a trusted domain is to make them or their global groups members of a domain local group in your domain.

ACLs

You can also add users and global groups from a trusted domain directly to the ACLs of resources in a trusting domain. This approach is not as manageable as the previous method,
using a domain local group, but it is possible.

Transitivity

When you create a realm trust, the trust is non-transitive by default. If you make it transitive,
you open up the potential for users from domains and realms trusted by the Kerberos v5
realm to gain access to resources in your domain. It is recommended that you use
non-transitive trusts unless you have a compelling business reason for a transitive realm trust.

Selective Authentication

When you create an external trust or a forest trust, you can control the scope of authentication of trusted security principals. There are two modes of authentication for an external or forest trust:

  • Selective authentication
  • Domain-wide authentication (for an external trust) or forest-wide authentication (for a forest trust)

If you choose domain-wide or forest-wide authentication, all trusted users can be authenticated for access to services on all computers in the trusting domain. Trusted users can, therefore, be given permission to access resources anywhere in the trusting domain. With this authentication mode, you must have confidence in the security procedures of your enterprise and in the administrators who implement those procedures so that inappropriate access is not assigned to trusted users. Remember, for example, that users from a trusted domain or forest are considered Authenticated Users in the trusting domain, so any resource with permissions granted to Authenticated Users will be immediately accessible to trusted domain users if you choose domain-wide or forest-wide authentication.

If, however, you choose selective authentication, all users in the trusted domain are trusted identities; however, they are allowed to authenticate only for services on computers that you have specified. For example, imagine that you have an external trust with a partner organization’s domain. You want to ensure that only users from the marketing group in the partner organization can access shared folders on only one of your many file servers. You can configure selective authentication for the trust relationship and then give the trusted users the right to authenticate only for that one file server.

To configure the authentication mode for a new outgoing trust, use the Outgoing Trust Authentication Level page of the New Trust Wizard. Configure the authentication level for an existing trust, open the properties of the trusting domain in Active Directory Domains And Trusts, select the trust relationship, click Properties, and then click the Authentication tab, shown in Figure 1.

Resource Access for Users from Trusted Domains 1

Figure 1 The Authentication tab of a trust relationship’s Properties dialog box

After you have selected Selective Authentication for the trust, no trusted users will be able to access resources in the trusting domain, even if those users have been given permissions. The users must also be assigned the Allowed To Authenticate permission on the computer object in the domain.

To assign this permission:

  1. Open the Active Directory Users And Computers snap-in and make sure that Advanced Features is selected on the View menu.
  2. Open the properties of the computer to which trusted users should be allowed to authenticate—that is, the computer that trusted users will log on to or that contains resources to which trusted users have been given permissions.
  3. On the Security tab, add the trusted users or a group that contains them and select the Allow check box for the Allowed To Authenticate permission, shown in Figure 2.
    Resource Access for Users from Trusted Domains 2

    Figure 2 Assigning the Allowed To Authenticate permission to a trusted group

Administering Trusts

Administering Trusts

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

By Administering Trusts, you can validate a trust relationship between any two Windows domains. You cannot validate a trust relationship to a Kerberos v5 realm. To validate a trust relationship, complete the following steps:

  1. Open Active Directory Domains And Trusts.
  2. In the console tree, right-click the domain that contains the trust that you want to validate, and then click Properties.
  3. On the Trusts tab, select the trust you want to validate, and then click Properties.
  4. Click Validate.
  5. Do one of the following, and then click OK:
    • Click Yes, Validate The Incoming Trust. Enter credentials that are members of the Domain Admins or Enterprise Admins groups in the reciprocal domain.
    • Click No, Do Not Validate The Incoming Trust. It is recommended that you repeat this procedure for the reciprocal domain.

You can also verify a trust from the command prompt by typing the following command:

netdom trust TrustingDomainName /domain:TrustedDomainName /verify

There can also be reason to remove a manually created trust. To do so, follow these steps:

  1. Open Active Directory Domains And Trusts.
  2. In the console tree, right-click the domain that contains the trust you want to validate, and then click Properties.
  3. On the Trusts tab, select the trust you want to remove, and then click Remove.
  4. Do one of the following, and then click OK:
    • Click Yes, Remove The Trust From Both The Local Domain And The Other Domain.Enter credentials that are members of the Domain Admins or Enterprise Admins groups in the reciprocal domain.
    • Click No, Remove The Trust From The Local Domain Only. It is recommended that you repeat this procedure for the reciprocal domain.
  5. To delete a manually created trust by using the command prompt, use the Netdom.exe command with the following syntax:

    netdom trust TrustingDomainName /domain:TrustedDomainName/remove [/force] /UserD:User /PasswordD:*

    The UserD parameter specifies a user with credentials in the Enterprise Admins or Domain Admins group of the trusted domain. Specifying the PasswordD:* parameter causes Netdom.exe to prompt you for the password to the account. The /force switch is required
    when removing a realm trust.

Shortcut Trusts

Shortcut Trusts

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

In an earlier section, you followed 11 steps of the process used to grant a session ticket for a client to access a resource in another domain within a forest. Most of those steps involved referrals to domains on the trust path between the user’s domain and the domain of the shared folder. When a user from one domain logs on to a computer in another domain, the  authentication request must also traverse the trust path. This can affect performance, and, if a domain controller is not available in a domain along the trust path, the client cannot authenticate or access the service.
Shortcut trusts are designed to overcome those problems by creating a trust relationship directly between child domains in the forest trust path. Two shortcut trusts are illustrated in
Figure 1  below.

Shortcut Trusts 1

Shortcut trusts optimize authentication and session ticket requests between domains in a multidomain forest. By eliminating the trust path, they eliminate the time required to traverse the trust path and, thereby, can significantly improve performance of session ticket requests.

Shortcut trusts can be one-way or two-way. In either case, the trust is transitive. In Figure 12-10, a one-way shortcut trust exists whereby wingtiptoys.com trusts asia.tailspintoys .com. When a user from asia.tailspintoys.com logs on to a computer in wingtiptoys.com or requests a resource in wingtiptoys.com, the request can be referred directly to a domain controller in the trusted domain, asia.tailspintoys.com. However, the reverse is not true.

If a user in wingtiptoys.com logs on to a computer in asia.tailspintoys.com, the authentication request traverses the trust path up to tailspintoys.com and down to wingtiptoys.com. A two-way shortcut trust is illustrated between usa.wingtiptoys.com and europe  .tailspintoys.com. Users in both domains can be authenticated by and can request resources from computers in the other domain, and the shortcut trust path is used.

External Trusts

When you need to work with a domain that is not in your forest, you might need to create an external trust. An external trust is a trust relationship between a domain in your forest and
a Windows domain that is not in your forest. Examples are shown in Figure 2.

Shortcut Trusts 2

In Figure 2, you can see a one-way trust between the sales.worldwideimporters.com domain and the europe.tailspintoys.com domain. The Europe domain trusts the Sales domain, so users in the Sales domain can log on to computers in the Europe domain or connect to resources in the Europe domain. Figure 2 also shows a two-way trust between the worldwideimporters.com domain and the asia.tailspintoys.com domain. Users in each domain can be given access to resources in the  other domain. Technically, all external trusts are nontransitive, one-way trusts. When you create a two-way external trust, you are actually creating two one-way trusts, one in each direction.

When you create an outgoing external trust, Active Directory creates a foreign security principal object for each security principal in the trusted domain. Those users, groups, and computers can then be added to domain local groups or to ACLs on resources in the trusting domain.

To increase the security of an external trust relationship, you can choose Selective Authentication on the Outgoing Trust Authentication Level page of the New Trust Wizard. Additionally, domain quarantine, also called SID filtering, is enabled by default on all external trusts. Both of these configurations are detailed in the “Resource Access for Users from Trusted Domains” section, later in this chapter.

Realm Trusts

When you need cross-platform interoperability with security services based on other Kerberos v5 implementations, you can establish a realm trust between your domain and a UNIX Kerberos v5 realm. Realm trusts are one-way, but you can establish one-way trusts in each direction to create a two-way trust. By default, realm trusts are non-transitive, but they can be made transitive.
If a non-Windows Kerberos v5 realm trusts your domain, the realm trusts all security principals in your domain. If your domain trusts a non-Windows Kerberos v5 realm, users in
the realm can be given access to resources in your domain; however, the process is indirect.

When users are authenticated by a non-Windows Kerberos realm, Kerberos tickets do notcontain all the authorization needed for Windows. Therefore, an account mapping system is used. Security principals are created in the Windows domain and are mapped to a foreign Kerberos identity in the trusted non-Windows Kerberos realm. The Windows domain uses only these proxy accounts to evaluate access to domain objects that have security descriptors. All Windows proxy accounts can be used in groups and on ACLs to control access on behalf of the non-Windows security principal. Account mappings are managed through Active Directory Users And Computers.

Forest Trusts

When you require collaboration between two separate organizations represented by two separate forests, you can consider implementing a forest trust. A forest trust is a one-way or two-way transitive trust relationship between the forest root domains of two forests.
Figure 12-12 shows an example of a forest trust between the tailspintoys.com forest and the worldwideimporters.com forest.

Shortcut Trusts 3

A single forest trust relationship allows the authentication of a user in any domain by any other domain in either forest, assuming that the forest trust is two-way. If the forest trust is one-way, any user in any domain in the trusted forest can be authenticated by computers in the trusting forest. Forest trusts are significantly easier to establish, maintain, and administer than are separate trust relationships between each of the domains in the forests. Forest trusts are particularly useful in scenarios involving cross-organization collaboration, mergers and acquisitions, or within a single organization that has more than one forest, to isolate Active Directory data and services.

When you establish a forest trust relationship, domain quarantine—also called SID filtering—is enabled by default. Domain quarantine is discussed in the “Domain Quarantine” section, later in this chapter. You can specify whether the forest trust is one-way, incoming or outgoing, or two-way. As mentioned earlier, a forest trust is transitive, allowing all domains in a trusting forest to trust all domains in a trusted forest. However, forest trusts are not themselves transitive. For example, if the tailspintoys.com forest trusts the worldwideimporters .com forest, and the worldwideimporters.com forest trusts the northwindtraders.co forest, those two trust relationships do not allow the tailspintoys.com forest to trust the northwindtraders.com forest. If you want those two forests to trust each other, you must create a specific forest trust between them.

Several requirements must be met before you can implement a forest trust. The forest functional level must be Windows Server 2003 or later. In addition, you must have a specific DNS infrastructure to support a forest trust.

Manual Trusts

Manual Trusts

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

Manual Trusts can be created in four types. These four types can be listed as:

  • Shortcut trusts
  • External trusts
  • Realm trusts
  • Forest trusts

Each of these types of trusts is discussed in the following sections

Creating Manual Trust Relationships

The steps for creating trusts are similar across categories of trusts. You must be a member of the Domain Admins or Enterprise Admins group to create a trust successfully. To create a trust relationship, complete the following steps:

  1. Open the active directory domains and trusts snap-in.
  2. Right-click the domain that will participate in one side of the trust relationship and click Properties.You must be running Active Directory Domains And Trusts with credentials that have permissions to create trusts in this domain.
  3. On the Trusts tab, click New Trust. The New Trust Wizard guides you through the creation of the trust.
  4. On the Trust Name page, type the DNS name of the other domain in the trust relationship, and then click Next.
  5. If the domain you entered is not within the same forest, you are prompted to select the type of trust, which will be one of the following:
    – Forest
    – External
    – Realm
    If the domain is in the same forest, the wizard knows it is a shortcut trust.
  6. If you are creating a realm trust, you are prompted to indicate whether the trust is transitive or non-transitive. (Realm trusts are discussed later in this lesson.)
  7. On the Direction Of Trust page, shown in Figure 1, select one of the following:
    Two-Way Establishes a two-way trust between the domains.
    One-Way Incoming Establishes a one-way trust in which the domain you selected in step 2 is the trusted domain, and the domain you entered in step 4 is the trusting domain.
    One-Way Outgoing Establishes a one-way trust in which the domain you selected in step 2 is the trusting domain, and a domain you entered in step 4 is the trusted domain.
  8. Click Next.

    Manual Trusts 1

    Figure 1 The Direction Of Trust page

  9. On the Sides Of Trust page, shown in Figure 12-9, select one of the following:
    Manual Trusts 2

    Figure 12-9 The Sides Of Trust page

    Both This Domain And The Specified Domain Establishes both sides of the trust. This requires that you have permission to create trusts in both domains.
    This Domain Only Creates the trust relationship in the domain you selected in step 2. An administrator with permission to create trusts in the other domain must repeat this process to complete the trust relationship.

    The next steps depend on the options you selected in steps 7 and 9. The steps involve one of the following:
    • If you selected Both This Domain And The Specified Domain, you must enter a user name and password with permissions to create the trust in the domain specified in step 4.
    • If you selected This Domain Only, you must enter a trust password. A trust password is entered by administrators on each side of a trust to establish the trust. It should not be an administrator’s user account password. Instead, it should be a unique password used only for the purpose of creating this trust. The password is used to establish the trust, and then the domains change it immediately.

  10. If the trust is an outgoing trust, you are prompted to choose one of the following:
    • Selective Authentication
    • Domain-Wide Authentication or Forest-Wide Authentication, depending on whether the trust type is an external trust or a forest trust, respectively.Authentication options are discussed in the section “Resource Access for Users from Trusted Domains,” later in this chapter.
  11. The New Trust Wizard summarizes your selections on the Trust Selections Complete page. Click Next. The wizard creates the trust.
  12. The Trust Creation Complete page appears. Verify the settings, and then click Next. You then have the opportunity to confirm the trust. This option is useful if you have created both sides of the trust or if you are completing the second side of a trust.

If you selected Both This Domain And The Specified Domain in step 9, the process is complete. If you selected This Domain Only in step 9, the trust relationship will not be  complete until an administrator in the other domain completes the process:

  • If the trust relationship you established is a one-way, outgoing trust, an administrator in the other domain must create a one-way, incoming trust.
  • If the trust relationship you established is a one-way, incoming trust, an administrator in the other domain must create a one-way, outgoing trust.
  • If the trust relationship you established is a two-way trust, an administrator in the other domain must create a two-way trust.
How Trusts Work

How Trusts Work

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

Within a forest, all domains trust each other. That is because the root domain of each tree in a forest trusts the forest root domain—the first domain installed in the forest—and each child domain trusts its parent domain. All trusts automatically created should never be deleted and are transitive and two-way.Users and global groups from any domain in the forest can be added to domain local groups, can be given user rights, and can be added to ACLs on resources in any other domain in the forest. Trusts to other forests and to domains outside the forest must be manually established. With that summary, you can look at the details of trusts within and outside of an Active Directory forest.

Authentication Protocols and Trust Relationships
Windows Server 2008 R2 Active Directory authenticates users with one of two protocols—
Kerberos version 5 (v5) or NT LAN Manager (NTLM). Kerberos v5 is the default protocol
used by computers running Windows Server 2008 R2, Windows Server 2008, Windows Vista,Windows Server 2003, Windows XP, and Windows 2000 Server. If a computer involved in an authentication transaction does not support Kerberos v5, the NTLM protocol is used
instead. Group Policies can be used to disable NTLM authentication.

Kerberos Authentication Within a Domain
When a user logs on to a client running Kerberos v5, the authentication request is forwarded
to a domain controller. Each Active Directory domain controller acts as a Key Distribution
Center (KDC), a core component of Kerberos. After validating the identity of the user, the KDC
on the domain controller gives the authenticated user what is known as a ticket-granting
ticket (TGT).
When the user needs to access resources on a computer in the same domain, the user must
first obtain a valid session ticket for the computer. Session tickets are provided by the KDC
of a domain controller, so the user returns to a domain controller to request a session ticket.
The user presents the TGT as proof that he or she has already been authenticated. This enables
the KDC to respond to the user’s session ticket request without having to re-authenticate the
user’s identity. The user’s session ticket request specifies the computer and the service that
the user wants to access. The KDC identifies that the service is in the same domain based on
the service principal name (SPN) of the requested server. The KDC then provides the user with
a session ticket for the service.
The user then connects to the service and presents the session ticket. The server determines that the ticket is valid and that the user has been authenticated by the domain.
This happens through private keys, a topic that is beyond the scope of this . The server,
therefore, does not need to authenticate the user; it accepts the authentication and identity provided by the domain with which the computer has a trust relationship.
All these Kerberos transactions are handled by Windows clients and servers and are transparent to users themselves.

 Kerberos Authentication Across Domains in a Forest
Each child domain in a forest trusts its parent domain with an automatic, two-way, transitive
trust called a parent-child trust. The root domain of each tree in a domain trusts the forest root domain with an automatic, two-way, transitive trust called a tree-root trust.
These trust relationships create what is referred to as the trust path or trust flow in a forest.
The trust path is easy to understand with a diagram, as shown in Figure 12-7. In this example,
the forest consists of two trees, the tailspintoys.com tree and the wingtiptoys.com tree.
The tailspintoys.com domain is the forest root domain. On the top of Figure 12-7 is the forest as seen from a DNS perspective. On the bottom of the figure is the trust path. It indicates that the wingtiptoys.com tree root domain trusts the tailspintoys.com domain.

70-640-f130

Figure 12-7 An Active Directory forest from a DNS perspective and from a trust path perspective

Kerberos authentication uses the trust path to provide a user in one domain a session ticket to a service in another domain. If a user in usa.wingtiptoys.com requests access to a shared folder on a server in europe.tailspintoys.com, the following transactions occur:
1. The user logs on to a computer in usa.wingtiptoys.com and is authenticated by a domain controller in usa.wingtiptoys.com, using the authentication process described in the previous . The user obtains a TGT for the domain controller in usa.wingtiptoys.com.
The user wants to connect to a shared folder on a server in europe.tailspintoys.com.
2. The user contacts the KDC of a domain controller in usa.wingtiptoys.com to request a session ticket for the server in europe.tailspintoys.com.
3. The domain controller in usa.wingtiptoys.com identifies, based on the SPN, that the desired
service resides in europe.tailspintoys.com, not in the local domain.

The job of the KDC is to act as a trusted intermediary between a client and a service.
If the KDC cannot provide a session ticket for the service because the service is in a trusted domain and not in the local domain, the KDC provides the client a referral to help it obtain the session ticket it is requesting.
The KDC uses a simple algorithm to determine the next step. If the KDC domain is trusted directly by the service’s domain, the KDC gives the client a referral to a domain controller in the service’s domain. If not, but if a transitive trust exists between the KDC and the service’s domain, the KDC provides the client a referral to the next domain in the trust path.
4. The usa.wingtiptoys.com domain is not trusted directly by europe.tailspintoys.com, but a transitive trust exists between the two domains, so the KDC in the usa.wingtiptoys.com domain gives the client a referral to a domain controller in the next domain in the trust path, wingtiptoys.com.
5. The client contacts the KDC in the referral domain, wingtiptoys.com.
6. Again, the KDC determines that the service is not in the local domain and that europe .tailspintoys.com does not trust wingtiptoys.com directly, so it returns a referral to a domain controller in the next domain in the trust path, tailspintoys.com.
7. The client contacts the KDC in the referral domain, tailspintoys.com.
8. The KDC determines that the service is not in the local domain and that europe .tailspintoys.com trusts tailspintoys.com directly, so it returns a referral to a domain controller in the europe.tailspintoys.com domain.
9. The client contacts the KDC in the referral domain, europe.tailspintoys.com.
10. The KDC in europe.tailspintoys.com returns to the client a session ticket for the service.
11. The client contacts the server and provides the session ticket; the server provides access to the shared folder based on the permissions assigned to the user and the groups to which the user belongs.
This process might seem complicated, but recall that it is handled in a way that is completely transparent to the user.
The reverse process occurs if a user from usa.wingtiptoys.com logs on to a computer in the europe.tailspintoys.com domain. The initial authentication request must traverse the trust
path to reach a KDC in the usa.wingtiptoys.com domain to authenticate the user.
Although it is not necessary to master the details of Kerberos authentication between domains in a forest for the 70-640 , it can help you in the real world to have a basic understanding that cross-domain authentication in a forest follows a trust path.

Understanding Trust Relationships

Understanding Trust Relationships

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

Whenever you are implementing a scenario involving two or more AD DS domains, it is likely
that you will be working with trust relationships, or trusts. It is important that you understand
the purpose, functionality, and configuration of trust relationships.
Trust Relationships Within a Domain
In Chapter , you were guided through what happens when a domain member server or workstation joins a domain. While in a workgroup, the computer maintains an identity store in the security accounts manager (SAM) database, it authenticates users against that identity store, and it secures system resources only with identities from the SAM database. When the computer joins a domain, it forms a trust relationship with the domain. The effect of that trust is that the computer allows users to be authenticated, not by the local system and its local identity store but by the authentication services and identity store of the domain:
AD DS. The domain member also allows domain identities to be used to secure system resources. For example, Domain Users is added to the local Users group, giving Domain Users the right to log on locally to the system. Also, domain user and group accounts can be added to ACLs on files, folders, registry keys, and printers on the system. All domain members have similar trust relationships with the domain, enabling the domain to be a central store of identity and a centralized service providing authentication.
Trust Relationships Between Domains
With that foundation, you can extend the concept of trust relationships to other domains.
A trust relationship between two domains enables one domain to trust the authentication service and the identity store of another domain and to use those identities to secure resources. In effect, a trust relationship is a logical link established between domains to enable pass-through authentication.

Every trust relationship has two domains: a trusting domain and a trusted domain. The trusted domain holds the identity store and provides authentication for users in that identity store. When a user in the directory of the trusted domain logs on to or connects to a system in he trusting domain, the trusting domain cannot authenticate that user because the user is not
in its store, so it passes the authentication to a domain controller in the trusted domain.
The trusting domain, therefore, trusts the trusted domain to authenticate the identity of the
user. The trusting domain extends trust to the authentication services and the identity store of
the trusted domain.
Because the trusting domain trusts the identities in the trusted domain, the trusting domain can use the trusted identities to grant access to resources. Users in a trusted domain can be given user rights such as the right to log on to workstations in the trusting domain.
Users or global groups in the trusted domain can be added to domain local groups in the trusting domain. Users or global groups in the trusted domain can be given permissions to
shared folders by adding the identities to ACLs in the trusting domain.
The terminology can be confusing, and it is often easier to understand trust relationships with a figure. Figure 12-5 shows a diagram of a simple trust relationship. Domain A trusts Domain B. That makes Domain A the trusting domain and Domain B the trusted domain.
If a user in Domain B connects to or logs on to a computer in Domain A, Domain A passes the authentication request to a domain controller in Domain B. Domain A can also use the identities from Domain B—users and groups, for example—to grant user rights and resource
access in Domain A. A user or group in Domain B can, therefore, be added to an ACL on
a shared folder in Domain A. A user or group in Domain B can also be added to a domain local group in Domain A.

70-640-f128

————————————————————

Note:Trust relationships are highly likely to appear on the 70-640 . Be certain that you
completely understand the terms trusted, trusting, and trust. It is helpful when taking the exam to draw trust relationships so that you can more easily analyze which domain is trusted and has users and groups that the trusting domain can use to grant access to resources. Always make sure that the trust is extended from the domain with resources, such as computers and shared folders, to the domain with users.

————————————————————————

Characteristics of Trust Relationships
Trust relationships between domains can be characterized by three attributes of the trust:
Direction A trust relationship can be one-way or two-way. In a one-way trust, such
as the trusts illustrated in Figure 12-5, users in the trusted domain can be given access to resources in the trusting domain, but users in the trusting domain cannot be given access to resources in the trusted domain. In most cases, you can create a second, one-way trust in the opposite direction to achieve that goal. For example, you can create a second trust  relationship in which Domain B trusts Domain A. Some trust relationships are by nature two-way. In a two-way trust, both domains trust the identities and authentication services of the other domain.
Transitivity Some trusts are not transitive, and others are transitive. In Figure 12-6, Domain A trusts Domain B, and Domain B trusts Domain C. If the trusts are transitive, Domain A trusts Domain C. If they are not transitive, Domain A does not trust Domain C.
In most cases, you could create a third trust relationship, specifying that Domain A trusts Domain C. With transitive trusts, that third relationship is not necessary; it is implied.

Automatic or Manual Some trusts are created automatically. Other trusts must be created manually.

Moving Objects Between Domains and Forests

Moving Objects Between Domains and Forests

This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.

In multidomain scenarios, you might need to move users, groups, or computers between domains or forests to support business operations. You might need to move large quantities of users, groups, or computers between domains or forests to implement mergers and acquisitions or to restructure your domain model.
In each of these tasks, you move or copy the accounts from one domain (the source domain) into another domain (the target domain). Domain restructuring terminology, concepts, and procedures apply to inter-forest migration—between a Windows NT 4.0 or Active Directory
source domain and an Active Directory target domain in a separate forest—and to intra-forest migration—that is, the restructuring or moving of accounts between domains in the same forest.
An inter-forest domain restructure preserves the existing source domain, and clones (or copies) accounts into the target domain. This nondestructive method enables an enterprise to time the transition and even migrate in phases. Operations go uninterrupted because both domains are maintained in parallel to support operations for users in either domain. This method also provides a level of rollback because the original environment remains unaltered in any significant way. After the migration is complete, you can simply decommission the source domain by moving any remaining accounts, member servers, and workstations into the new domain and then taking source DCs offline, at which point you can redeploy those DCs for roles in the new domain.
An intra-forest migration involves moving objects from the source domain to the target domain without decommissioning the source domain. After you have migrated objects, you can restructure your domains to consolidate operations and build a domain and OU structure
that more accurately reflects your administrative model. Many organizations consolidate multiple domains into one Active Directory domain. This consolidation can result in cost savings and simplified administration by reducing administrative complexity and the cost of
supporting your Active Directory environment.

Understanding the Active Directory Migration Tool
The Active Directory Migration Tool (ADMT) version 3 can perform object migration and security translation tasks. You can download ADMT v3 from http://go.microsoft.com/fwlink/?LinkID=75627. On that page, you will also find a detailed guide to the tool.

You can use ADMT to migrate objects between a source and a target domain. The migration can take place between domains in the same forest (an intra-forest migration) or between domains in different forests (an inter-forest migration). The ADMT provides wizards that automate migration tasks such as migrating users, groups, service accounts, computers, and trusts and performing security translation. You can perform these tasks by using the ADMT console or the command line, at which you can simplify and automate the Admt.exe command with option files that specify parameters for the migration task. Then, with a simple text file, you can list objects to migrate rather than having to enter each object on the command line.
ADMT also provides interfaces that allow you to script migration tasks with languages such as Microsoft Visual Basic Scripting Edition (VBScript). Run the ADMT console and open the online Help function for details about how to use ADMT from the command line and about scripting the ADMT.

When you are performing migration tasks, ADMT allows you to simulate the migration so that you can evaluate potential results and errors without making changes to the target domain. Wizards provide the Test, The Migration Settings And Migrate Later option. You can then  configure the migration task, test the settings, and review the log files and wizard-generated reports. After identifying and resolving any problems, you can perform the migration task. You repeat this process of testing and analyzing results as you migrate users, groups, and computers and perform security translations.

Security Identifiers and Migration
Uninterrupted resource access is the primary concern during any migration. Further, to perform a migration, you must be comfortable with the concepts of security identifiers (SIDs), tokens, access control lists (ACLs), and sIDHistory.SIDs are domain-unique values that are assigned to the accounts of security principals—users, groups, and computers, for example—when those accounts are created. When a user logs on, a token is generated that includes the primary SID of the user account and the SIDs of groups to which the user belongs. The token thus represents the user with all the SIDs associated with the user and the user’s group memberships.
Resources are secured using a security descriptor (SD) that describes the permissions, ownership, extended rights, and auditing of the resource. Within the SD are two ACLs.
The system ACL (SACL) describes auditing. The discretionary ACL (DACL) describes resource access permissions. Many administrators and documents refer to the DACL as the ACL.
The DACL lists permissions associated with security principals. Within the list, individual access control entries (ACEs) link a specific permission with the SID of a security principal. The ACE can be an Allow or Deny permission. When a user attempts to access a resource, the Local Security Authority Subsystem (LSASS) compares the SIDs in the user’s token against the SIDs in the ACEs in the resource’s ACL.
When you migrate accounts to a new domain, the accounts are copied or cloned from the source domain to the target domain. New SIDs are generated for the accounts in the target domain, so the SIDs of new accounts will not be the same as the SIDs of the accounts in the source domain. That is, even though the cloned accounts have the same name and many of the same properties, because the SIDs are different, the accounts are technically different and will not have access to resources in the source domain. You have two ways to address this problem: sIDHistory or security translation:

sIDHistory Enterprises typically prefer to take advantage of the sIDHistory attribute to perform effective domain restructuring. The capitalization, which appears odd, reflects the capitalization of the attribute in the Active Directory schema. An Active Directory security principal (which can be a user, group, or computer) has a principal SID and a sIDHistory attribute, which can contain one or more SIDs that are also associated with the account. When an account is copied to a target domain, the unique principal SID is generated by Active Directory in the target domain. Optionally, the sIDHistory attribute can be loaded with the SID of the account in the source domain.
When a user logs on to an Active Directory domain, the user’s token is populated with the principal SID and the sIDHistory of the user account and groups to which the user belongs. The LSASS uses the SIDs from the sIDHistory just like any other SID in the token to maintain the user’s access to resources in the source domain.
Security translation Security translation is the process of examining each resource’s SD, including its ACLs, identifying each SID that refers to an account in the source domain and replacing that SID with the SID of the account in the target domain.
The process of re-mapping ACLs (and other elements in the SD) to migrated accounts in the target domain is also called re-ACLing. As you can imagine, security translation or re-ACLing would be a tedious process to perform manually in anything but the simplest environment. Migration tools such as ADMT automate security translation.
ADMT can translate the SDs and policies of resources in the source domain to refer to the corresponding accounts in the target domain. Specifically, ADMT can translate:
• File and folder permissions.
• Printer permissions.
• Share permissions.
• Registry permissions.
• User rights.
• Local profiles, which involves changing file, folder, and registry permissions.
• Group memberships.
In most domain restructuring and migration projects, sIDHistory is used to maintain access
and functionality during the migration; then, security translation is performed.

Group Membership
The final concern related to resource access is that of group membership. Global groups can
contain members only from the same domain. Therefore, if you clone a user to the target domain, the new user account cannot be a member of the global groups in the source domain to which the source user account belonged.
To address this issue in an inter-forest migration, first migrate global groups to the target  domain. Those global groups will maintain the source groups’ SIDs in their sIDHistory attributes, thus maintaining resource access. Then, migrate users. As you migrate users,
ADMT evaluates the membership of the source account and adds the new account to the same group in the target domain. If the group does not yet exist in the target domain, ADMT can create it automatically. In the end, the user account in the target domain will belong to
global groups in the target domain. The user and the user’s groups will contain the SIDs of the source accounts in their sIDHistory attributes. Therefore, the user will be able to access resources in the source domain that have permissions assigned to the source accounts.
In an intra-forest migration, the process works differently. A global group is created in the target domain as a universal group so that it can contain users from both the source and the target domain. The new group gets a new SID, but its sIDHistory is populated with the SID
of the global group in the source domain, thereby maintaining resource access for the new group. After all users have been migrated from the source to the target domain, the scope of the group is changed back to global.

Other Migration Concerns
You must address several issues when planning for and executing the migration of objects between domains and forests. Each issue is detailed in the ADMT user guide, available from the ADMT download page listed earlier. Among the greatest concerns are:
Password migration ADMT supports migrating user passwords; however, it cannot confirm that those passwords comply with the policies of the target domain regarding  password length and complexity. Nonblank passwords will migrate regardless of the target domain password policy, and users will be able to log on with those passwords until they expire, at which time a new, compliant password must be created. If you are concerned about locking down the environment at the time of migration, this might not be a satisfactory process. You might, instead, want to let ADMT configure complex passwords or script an initial password and then force the user to change the password at the first logon.
Service accounts Services on domain computers might use domain-based user accounts
for authentication. As those user accounts are migrated to the target domain, services must be updated with the new service account identity. ADMT automates this process.
Objects that cannot be migrated Some objects cannot be seamlessly migrated. ADMT cannot migrate built-in groups such as Domain Admins or the domain local  Administrators group. The user guide provides details for working around this limitation.

——————————————————————–

Note:Migrating a forest
For information on creating a new forest and migrating its contents from one forest to another, look up Windows Server 2008: The Complete Reference by Ruest and Ruest (McGraw-Hill Osborne, 2008). This book describes how to build a complete infrastructure based on Microsoft Windows Server and migrate all of its contents from one location to another.

————————————————————————