reset trust relationship

When a trust relationship is broken, then it is necessary to reset the trust relationship. The following illustrates on how to reset a broken domain trust relationship.

1. Assume the trusting domain name is "myrootdns2003.com" and trusted domain is "myforesttest.com".
2. Open "Active Directory domains and trusts" Console diagram using the command "domain.msc".
3. Right click on domain node "myrootdns2003.com" and select properties.
4. In "myrootdns2003.com" properties dialog, select the domain "myforesttest.com" and click properties. 5. Click validate button in "myforesttest.com" properties dialog.
6. If validation fails, a dialog box comes to reset the trust relationship. Then follow up with the dialog box and complete the resetting.

Domain trust

A domain trust is a relationship between domains which allows users of one domain to access services of other domain.

By default, users of a domain can have access to resources contained in that domain. i.e domain users can use domain resources like network printer, fax service and any network share. However, users of one domain cannot access resources of other domain. By this way, a domain can provide its users with secured access to all resources in that domain. If all users accounts and services can be managed in a single large domain, then there is no problem. However, there are needs to have multiple separate domains. This is because having multiple domains is a useful way to separate the scope of each domain administrator from other domain administrators. i.e Each domain administrator is responsible for setting up scope of security policy and account policy settings on domain users and domain resources. Thus both multiple domain and trusts between domains are needed.

Trust mechanism in windows

A domain trust(trust relationship) is a relationship between two domains to allow authentication and authorization to shared resources. In authentication process, verifies the user identity and in authorization process determines what the authenticated user is allowed to do on shared network resource on target computer. i.e Once the user is authenticated by the domain containing shared network resource, the target computer compares the user’s credentials to the permissions assigned within its security descriptor table to help determine the user’s level of authorization to the shared resource. A security descriptor table contains access control lists (ACLs) that identify the users and groups that are assigned or denied access permissions on shared resource.

Trusts in Active Directory:

Domains that have domain controllers running Windows 2000 Server or Windows Server 2003 used Active Directory service. Windows NT and earlier windows versions doesn't have active directory service support.

Trust Relationship types:

The direction that a trust is assigned determines the trust path used for authentication. A trust path is defined by the series of trust relationships that authentication requests must follow between domains.

The following are the domain trust relationship types characterized by the trust path used for authentication.

One-Way Trust
A one-way trust is a unidirectional trust between two domains. i.e in one-way trust between a trusted domain and a trusting domain, trusted domain users or computers can access resources in the trusting domain. However, the trusting domain users cannot access resources in the trusted domain. Some one-way trusts can be either nontransitive or transitive, depending on the type of trust being created.
Two-Way Trust
A two-way trust is a bidirectional trust between two domains. i.e users of either domain can send authentication requests to other domain. Some two-way relationships can be either nontransitive or transitive depending on the type of trust being created.

All domain trusts in an Active Directory integrated forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain. This is not true with domains not integrated with active directory service(windows NT and earlier versions).

Trust Transitivity
Transitivity determines whether a trust between two domains can be extended beyond the two domains. A transitive trust extends trust relationships to other domains. Every time a domain created in a forest, a two-way transitive trust is created between the new domain and its parent domain automatically. The trust path flows upward through the domain hierarchy, extending the initial trust path created between the new domain and its parent.

Transitive trust relationships thus flow upward through a domain tree. Therefore a domain tree can be defined as a hierarchical structure of one or more domains, connected by transitive, bidirectional trusts, that forms a contiguous namespace.

So with transitive trusts, user accounts of any domain in the forest can be authenticated by any other domain in the forest. Consequently, with a single logon process, accounts with the proper permissions can access resources in any domain in the forest happens.

Nontransitive trust
In this, The flow is restricted to the two domains in the trust relationship and nontransitive trust does not extend trust relationships to other domains in the forest. A nontransitive trust can be either a two-way trust or a one-way trust. By default, Nontranstive Trusts are not created. On must explicitly create those.

Various Trust Deployment methodologies

There are three trust deployment strategies that are used to accommodate the resource sharing needs of an enterprise. These are intra-forest, inter-forest and Kerberos realms based trusts.

Intra Forest Trusts

Intra-forest trusts are transitive trusts that can be used only within a single forest. i.e trust can't be created across multiple forests. Intra-forest trusts includes tree-root, parent-child, and shortcut trust relationships.

Tree-root trusts

By default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain. But when a new domain tree is created in an existing forest, then a new tree-root trust is established. tree-root trusts are two-way and transitive.

Parent-child trusts

A new parent and child trust is established when ever a new child domain is created in a domain tree. Trust flows from child domain to parent domain and goes upwards till domain tree.

Shortcut trusts

Shortcut trusts are the trusts established between two domain trees within the same forest. By Default, Authentication requests must first travel a trust path between domain trees, and in a complex forest this can take time. Using shortcut trusts can create trust with domains in other domain trees. Thus authentication requests goes through shortcut trust which increases overall speed.

Inter Forest Trusts

Inter-forest trusts can be created between domains contained in different forests. Inter-forest trusts can be nontransitive or transitive. Inter-forest trusts include external trusts and forest trusts and both these trust types should be created explicitly.

External trusts

External trusts are nontransitive which can be created between domains in different forests or between an Active Directory domain and a Windows NT 4.0 domain.

Forest trusts

Forest trust is a trust relationship between two forests. Forest trusts can be a one-way or two-way transitive. A two-way forest trust is used to form a transitive trust relationship between every domain in both forests. Forest trusts can be created only between two Windows Server 2003 forests and cannot be implicitly extended to a third forest.

Kerberos Realm Trusts

A realm trust can be established between any non-Windows-based operating system Kerberos version 5 realm and a Windows 2000 or Windows 2003 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos version 5 implementations. Realm trusts can be either one-way or two-way.

Create external trust

The following illustrates on how to create trust between two domains.

1. Assume the local domain is "myrootdns2003.com" and target domain to which the trust to be created is "mydnsroot2.com".
2. Open the active directory domains and trust snapin using the command domain.msc.
3. In the left pane, right click on the domain "myrootdns2003.com" and select properties.4. In the domain properties dialog, go to trusts tab and click "new trust" button.
5. Type the NetBIOS name of the NT domain or the DNS name of the AD domain( here "dnsserver2") in the trust name dialog and click next.
6. Select "Two-way " option in direction of the trust dialog and click next.
7. Select "Both this domain and specified domain" option in sides of trust dialog and click next.
8. Enter administrative user name and password for target domain "mydnsroot2.com" and click next.
6. Verify the summary and click next.
7. Thus creation of new trust completion dialog comes up. now click click next.

8. Select "No, do not confirm outgoing trust" option and click next.
9. Thus completes creation of new trust.
10. Thus verify trust created in "trusts" tab of domain properties dialog.

Raise Functionality Level of Forest

The following illustrates on raising the functionality level of windows 2003 forest.
1. Assume the domain name is "myrootdns2003.com".
2. Open domain snapin using the command domain.msc.

3. In the left pane, right-click on Active Directory Domains and Trusts and select Raise Forest Functional Level









4. Select "Windows Server 2003" in the list box and click raise button.













To retrieve forest level, run the command
dsquery * myrootdns2003.com -scope base -attr msDS-Behavior-Version

Raise Functionality Level of a Windows Server 2003 on command line

The following illustrates changing domain functionality level on command line.
1. Assume the domain is "myrootdns2003.com".
2. Create a file raise_domain_func_level.ldf with the following contents
dn: myrootdns2003.com
changetype: modify
replace: msDS-Behavior-Version
msDS-Behavior-Version: 2
-
3. Now run the following command to change the functionality level.
ldifde -i -f raise_domain_func_level.ldf

4. Alternatively, admod tool can also be used to change functionality level.
admod -b dc=myrootdns2003,dc=com "msDS-Behavior-Version::2"

5. Also using vbscript functionality level cab be changed, The following snippet changes functionality level to windows 2003.

strDomain = "myrootdns2003.com"
' ------ END CONFIGURATION ---------

set objDomain = GetObject("LDAP://" &  strDomain)
objDomain.GetInfo
if objDomain.Get("msDS-Behavior-Version") <>
Wscript.Echo "Changing domain to  
Windows Server 2003 functional level … "
objDomain.Put "msDS-Behavior-Version", 2
objDomain.SetInfo
else
Wscript.Echo "Domain already at Windows Server 2003 functional level "
end if

DNS Mixed Mode Vs Native Mode

The mode of a domain restricts OS(Operating system) of domain controllers (DCs) in that domain to be run. In a mixed-mode domain, All Windows 2000, Windows Server 2003 and Windows NT domain controllers can run. but In a native-mode domain, Windows 2000 DCs run in windows 2000 domains and Windows Server 2003 domain controllers in windows 2003 domain.

Mixed mode imposes following limitations:

1. The domain cannot contain Universal security groups.

2. Groups in the domain cannot have their scope or type changed.

3. The domain cannot have nested groups (aside from global groups in domain local groups) 4.Account modifications sent to Windows NT BDCs, including password changes, must go through PDC Emulator for the domain.

5. The domain cannot use SID History.

The domain mode can be changed only from mixed to native mode. But not vice-verse.

Only by restoring entire Active Directory environment from a previous backup can go to mixed mode.

Raise Functionality Level to windows 2003

To raise the functionality level to windows 2003, do the following.
1. Assume the domain is "myrootdns2003.com".
2. Open ActiveDirectory domain and trust snap-in using the command domain.msc.3. In the left pane, right click on the domain and select "raise domain functionality level"









4. Select "Windows Server 2003" in the list box in the "Raise Domain Functionality Level" dialog and click "Raise" Button













Relevant Posts:
Raise Functionality Level On command prompt

Change Domain Functionality Level using script

The following snippet illustrates changing domain functionality level to windows 2000.

strDomain = "myrootdns2003.com" ' e.g. amer.rallencorp.com

set objDomain = GetObject("LDAP://" &  strDomain)
if objDomain.Get("nTMixedDomain") > 0 Then
Wscript.Echo " 
Changing mode to native … "
objDomain.Put "nTMixedDomain", 0
objDomain.SetInfo
else
Wscript.Echo "Already a native mode domain"
end if

Change Domain Functional Level to windows 200 native mode on command line

The following illustrates on how to changes domain functional level to windows 2000 on command prompt.

1. Assume the domain name "myrootdns2003.com".
2. Create a file say change_domain_mode.ldf with the following contents.
dn: myrootdns2003.com
changetype: modify replace: ntMixedDomain ntMixedDomain: 0
3. Now run the below command to change the functionality level to windows 2000 mode.
ldifde -i -f change_domain_mode.ldf

4. Alternatively, use the admod command to change the functionality level.
admod -b dc=myrootdns2003,dc=com "ntMixedDomain::0"

Get domin netbios name using script

The following vb script shows finding netbios name

1. Assume the domain name is "myrootdns2003.com"

strDomain = "myrootdns2003.com"
' ------ END CONFIGURATION --------

set objRootDSE = GetObject("LDAP://" & strDomain & "/RootDSE")
strADsPath = ";"
strFilter = "(&(objectcategory=Crossref)" & _
"(dnsRoot=" & strDomain & ")(netBIOSName=*));
strAttrs = "netbiosname;"
strScope = "Onelevel"
set objConn = CreateObject("ADODB.Connection")
objConn.Provider = "ADsDSOObject"
objConn.Open "Active Directory Provider"
set objRS = objConn.Execute(strADsPath & strFilter & strAttrs & strScope)
objRS.MoveFirst
WScript.Echo "NetBIOS name for " & strDomain & " is " & objRS.Fields(0).Value

View NetBios Name on command line

Run the following command to find the netbios name of a domain.

dsquery * cn=partitions,cn=configuration,dc=myrootdns2003,dc=com -filter "(&(objectcategory=crossref)(dnsroot=myrootdns2003.com))" -attr netbiosname
adfind tool can also be used to find netbios name of a domain.

adfind -b cn=partitions,cn=configuration,dc=myrootdns2003,dc=com -f "(&(objectcategory=crossref)(dnsroot=myrootdns2003.com))" cn netbiosname

Find NetBios Name of a Domain

The following illustrates on how to find NetBios name of a domain.

1. Assume the domain name "myrootdns2003.com"
2. Open domain snapin using the command domain.msc.

3. Right-click the domain in the left pane and select Properties.

4. Domain Name is NetBios Name of the domain.



Net Bios name can also be viewed using LDP Snapin.

1. Open LDP on command prompt.

2. from the menu, select Connection -> Connect.









3. Enter the name of a domain controller , port 389 and click OK.
4.From LDAP menu, select Connection -> Bind.
5. Enter Domain User, Password and domain name and click OK.











6.Again From LDP menu, Select Browse -> Search
7. Enter "cn=partitions,cn=configuration, dc=myrootdns2003,dc=com", "subtree" and "(&(objectcategory=crossref)(dnsHostName=dnsserver2003)(netbiosname=*))" in BaseDN, Scope and Filter respectively.

Relevant Posts:
Find domain netbios name on command line
Get Netbios Name using VBScript

DNS Active Directory Domain Services (AD DS) Integration

The DNS Integration with Active Directory Domain Services (AD DS) provides a way to locate, organize and manage the network resources.

How DNS integrates with AD DS:

By installing AD DS on a DNS server, the server will be promoted to the role of a DNS domain controller for a specified domain.

The Active Directory Domain Services (AD DS) Advantages:

1. Active Directory Domain Service provides Active Directory replication and enhanced security.

In a general domain zone storage model, DNS updates are performed on a single-master update model. Here a single authoritative DNS server for a domain zone maintains the master copy of the domain zone in a local file. Updates from DNS clients for the domain zone are processed using the single authoritative DNS server. If this server is not available or down, then DNS clients update requests for the domain zone are not processed.

But with Active directory integrated storage, dynamic updates from DNS client for the domain zone can be sent to any AD DS integrated DNS server. AD DS can be replicated on multiple DNS serves so that all these DNS server can act ad Domain Controller for the Domain Zone.

Also Active Directory Domain Services (AD DS) domain uses access control list (ACL) to edit dns Zone object in the directory tree. For example, an ACL for a domain zone resource record can be restricted so that dynamic updates are allowed only from a specific dns clients or from a secure group, such as a domain administrators group.

2. Automatically replicating and synchronizing DNS Domain Zones information to new domain controllers.

DNS Server service can be selectively removed from a domain controller with out disturbing domain zones information each active directory domain controller.

3. DNS zone with AD DS can streamline database replication planning.

4. AD replication for a dns zone is much faster and efficient than the general standard DNS replication.

Note: The Active Directory Domain Services (AD DS) for DNS is available with windows server 2003 and windows 2008 but not in windows 2000.