Showing posts with label windows 2008. Show all posts
Showing posts with label windows 2008. Show all posts

Sunday, March 1, 2009

Create SRV record

Service (SRV) record. Allows administrators to use several servers for a single DNS domain, to easily move a TCP/IP service from one host to another host with administration, and to designate some service provider hosts as primary servers for a service and other hosts as backups. DNS clients that use a SRV-type query ask for a specific TCP/IP service and protocol mapped to a specific DNS domain and receive the names of any available servers.

The following shows on how to create SRV record

1. Assume the dns server is "dnsserver2003" and dns zone to which the srv record to be added is "myrootdns2003.com"
2. Open dns management snap-in console using the command dnsmgmt.msc.
3. In the console tree, go to the dns zone "myrootdns2003.com", right click on it and select "other new records"
4. Select "Service Location (SRV)" in new resource record type dialog and click "Create Record" button.
5. Enter the SRV server details in new resource record dialog, and select "Allow any authenticated user to update all dns records with the same name" check box and click ok.
6. Thus creates new srv record.

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.

netdom - reset trust

If a trust relationship between two domain is broken, then it is necessary to reset the trust. netdom.exe is a command tool which can be used to reset the trust. Follow the steps below to reset the trust.

1. Assume the trust exists between the domains "myrootdns2003.com" and "myforesttest.com". Passwords of both the domains are "Mydns123" and "Myforest123" respectively.
2. Now run the below command to reset trust.


netdom trust myrootdns2003.com /domain:myforesttest.com /userd:myforesttest\Administrator /passwordd:Myforest123 /usero:myrootdns2003\Administrator /passwordo:Mydns123 /reset


3. If the trust is between windows domain and non-windows realm (kerberos) , then run the below command to reset the trust,

netdom trust myrootdns2003.com /domain:myforesttest.com /userd:myforesttest\Administrator /passwordd:Myforest123 /usero:myrootdns2003\Administrator /passwordo:Mydns123 /reset /Passwordt:Mytrust123

Note, the passwordt has to be provided to reset the trust with Kerber0s realm.

Thursday, February 26, 2009

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.

Thursday, February 19, 2009

what is Top-level domain

A string of letters used to indicate a organization or an institution.

The following is a list of the top-level domains most often used on the Internet

.arpa: This is Owned by Advanced Research Project Agency (ARPA). Used to register reverse mapping of Internet Protocol version 4 (IPv4) addresses assigned by the Internet Assigned Number Authority (IANA) to DNS domain names for computers that use those addresses on the Internet. This is used by in-addr.arpa domain.

.com: This is used for business and commercial use.

.int: Reserved for international use. Currently planned for use in RFC 1886 to register reverse mapping of Internet Protocol version 6 (IPv6) addresses assigned by IANA to DNS domain names in the ip6.int domain for computers that use those addresses on the Internet.

what is root domain

root domain is a root of domain tree when used in a DNS domain name, it is stated by a trailing period (.) to designate that the name is located at the root or highest level of the domain hierarchy.

The following shows root domain.

Wednesday, February 18, 2009

Set GlobalQueryBlockList using dnscmd

To set GlobalQueryBlockList on command prompt using dnscmd, do the following

1. Assume the dnsserver is "dnsserver2008" , domain is "myrootdns2008.com" and host name which is to be blocked from querying is "dnsclient.myrootdns2008.com"
2. Now run the command below
dnscmd dnsserver2008 /config /GlobalQueryBlockList "dnsclient.myrootdns2008.com"



3. To reset query block (remove all block listed hosts), run
dnscmd dnsserver2008 /config /GlobalQueryBlockList
4. To find block listed host names, run
dnscmd dnsserver2008 /info /globalqueryblocklist

Globalqueryblocklist Registry key

The globalqueryblocklist reg key contains list of host names whose name resolution to be blocked from querying.
Key Name: Globalqueryblocklist
Type: reg_sz
Default: Doesn't exists
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dns\parameters
Functionality: Specifies list of host names to be blocked from querying.
If a host name to be blocked from querying, then set the reg key to contain that host name.
The following shows blocking host name "dnsclient.myrootdns2008.com"
reg add HKLM\SYSTEM\CurrentControlSet\Services\dns\parameters /v Globalqueryblocklist /t reg_sz /d "dnsclient.myrootdns2008.com" /f
Relevant Posts:
Enable Global Query Block List on command prompt
Set QueryBlockList on command line

Enable EnableGlobalQueryBlockList using dnscmd

To enable EnableGlobalQueryBlockList through command prompt, do the following.

1. Assume the dns server on which to enable global query block list is "dnsserver2008"
2. Now run the following command to enable EnableGlobalQueryBlockList.

dnscmd dnsserver2008 /config /EnableGlobalQueryBlockList 1



3. To disable Global Query BlockList, run
dnscmd dnsserver2008 /config /EnableGlobalQueryBlockList 0
4. To view or find status of EnableGlobalQueryBlockList, run
dnscmd dnsserver2008 /info /EnableGlobalQueryBlockList

Allows DnsSuffix Appending To Unqualified Multi-Label Name Queries Group Policy

"Allows Dns Suffix Appending To Unqualified Multi Label Name Queries" Group Policy determines appending suffixes to an unqualified multi-label name if the original name query fails.

A domain name containing dots, but not terminated by dot is called an unqualified multi-label name, for example "mytootdns.cm". A fully qualified multi label name will have a terminating dot, for example "myrootdns.com.".

If this policy is enabled, if the original multi label name query fails, dns suffixes are appended to an unqualified multi-label name.
For example, an unqualified multi-label name query for "myrootdns.cm" will be queried by the DNS Client first. If the query succeeds, the response is returned to the client. If the query fails, the unqualified multi-label name is appended with DNS Suffixes configured for the computer for queries. These suffixes can be derived from a combination of the local DNS Client's primary domain suffix, a connection-specific domain suffix and/or DNS Suffix Search List.

For example, if the local DNS Client receives a query for "myrootdns.cm", and a primary domain suffix is configured as "forest.com", with this setting the DNS Client will send a query for "myrootdns.cm.forest.com."

To enable the policy, do the following
1. Open group policy editor using the command gpedit.msc.

2. In the console tree, browse to the node Computer Configuration -> Administrative Templates -> Network -> DnsClient, righ click on policy "Allows DnsSuffix Appending To Unqualified Multi-Label Name Queries Group Policy" and click properties.

3. In the properties dialog, check "Enabled" button, click apply and click OK button.

If the policy is disabled, then no suffixes are appended to unqualified multi-label name queries if the original name query fails.

If you do not configure this setting, computers will use their local DNS Client configuration to determine the query behavior for unqualified multi-label names.

Turn Off Multicase Name Resolution Group policy

Local Link Multicast Name Resolution (LLMNR) is a secondary name resolution protocol, in which Queries are sent over the Link Local subnet from a client machine using Multicast to another client using same multicast(LLMNR).

This group policy determines the usage of Local Link Multicast Name Resolution(LLMNR)

If the policy is enabled, will turnoff LLMNR for all the client machines on all configured network adapters.

To enable the policy, do the following.

1. Open group policy editor using the command gpedit.msc.

2. In the console tree, browse to the node Computer Configuration -> Administrative Templates -> Network -> DnsClient, righ click on policy "Turn Off Multicase Name Resolution" and click properties.

3. In the properties dialog, click "Enabled" option button, click apply and click OK.

If the policy is disabled, will turn on LLMNR for all client machines on all available configured network adapters.


If the policy is not configured, will turn on LLMNR for all client machines on all available configured network adapters by default.

Note: This policy is available only on windows 2008 server.

GlobalNamesQueryOrder Registry key

The Global Names Query Order registry key determines the order in dns query names to be resolved. By default, the DNS server, Instead GlobalNamesZone" uses it's local zone data to respond to a dns query.
Key Name: GlobalNamesQueryOrder
Type: reg dword
Default: 0(Key doesn't exists)
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dns\parameters
Functionality: Specify the order of zones (Local Zone, GlobalNames Zone) to respond to a dns query.
if the reg key is set to 1, then GlobalNames zone is first used to resolve queries.
To set the reg value to 1, run
reg add "HKLM\SYSTEM\CurrentControlSet\Services\dns\parameters" /v GlobalNamesQueryOrder /t reg_dword /d 1 /f
Note: This reg key applies only if globalnames zone exists.

Saturday, February 14, 2009

Create NS Record using dnscmd

The following illustrates on how to add NS (Name Server) to a dns on command prompt.

1. Assume the subdomain is "subdomain.myrootdns.com", parent domain is "myrootdns.com", parent domain's dns server is "dnsserver", the name server (dns server) for subdomain.myrootdns.com is "childdnsserver.myrootdns.com" .
2. Now run the below command to add NS for "childdnsserver" at "myrootdns.com" dns zone.

dnscmd dnsserver /recordadd myrootdns.com subdomain /Aging /OpenAcl NS childdnsserver.myrootdns.com




To set timeout(20) for the record, run

dnscmd dnsserver /recordadd myrootdns.com subdomain /Aging /OpenAcl 20 NS childdnsserver.myrootdns.com

To remove NS reocord, run

dnscmd dnsserver /recorddelete myrootdns.com dnsserver NS childdnsserver.myrootdns.com

Thursday, February 5, 2009

EnableEDNSProbes Registry Key

This reg key is used to enable or disable EdnsO response to EdnsO requests containing OPT resource records. To configure a DNS server to respond to EDNS0 requests containing OPT resource records with EDNSo response containing OPT resource records, must set this registry key to 1(enable). This reg key is enabled by default in Windows Server 2003 and Windows Server 2008. To disable it, just set the reg key to 0.

The following shows the reg key info:
Key Name: EnableEDNSProbes
Type: reg_dword
Default: enabled
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dns\parameters
Functionality: enables or disables EDNS Probes.

set EdnsCacheTimeout using dnscmd

To set EdnsCacheTimeout to some value, say 1000 secs, run

dnscmd /config /EdnsCacheTimeout 1000












To verify the timeout, run

dnscmd /info /EdnsCacheTimeout

EDNSCacheTimeout Registry Key

This reg key determines the amount of time the EDns information should be kept in cache.

Key Name: EDnsCacheTimeout
Type: reg_dword
Default: 604,800 secs (one week)
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters
Functionality: Determines the EDnsCacheTimeout
By default, the default value of EDnsCacheTimeout is set to 604,800 seconds (one week).
The EdnsCacheTimeout Can range from 3,600 secs (1 hour) and 15,724,800 secs (182 days).

Note: This reg key specifies the cachetimoout, on this dns server, of EDns extension information supported by other DNS servers that have responded to a query, from this dns server, with a OPT resource record.

Saturday, January 31, 2009

SecureResponses Registry Key

This registry determines whether to cache all or only the Name Sever (NS) records in the same subtree of the domain.

By default, the DNS server saves all the NS records of recursive name queries in the dns memory cache. However, if the reg key value is 1, then DNS server saves only those NS query response records for names that are in the same subtree as the server that provided them.

For example, the DNS server will save all name server (NS) records for subtree.mydns.com from the mydns.com server, but it will not save the Name Sever(NS) record for subtree.notmydns.com the mydns.com server.

The registry key is located at "HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters".
Key Name: SecureResponses
Type: DWORD (Boolean)
Default: NoKey (No secureresponses)

Value: 0 (The DNS server saves all name query records in its memory cache)
1 (The DNS server saves only those NS records that are in the same
subtree of origination dns server)

To set value of this key, then run

reg add HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v SecureResponses /t reg_dword /d 1
Note,
The changes through regedit.exe are will be effective only after restarting the DNS server.

To change secureresponses with out restarting dns server, do the following

1. Open DNS manager using dnsmgmt.msc command
2. In the dns manager console tree, right click on the dns server node and click properties.
















3. In the dns server properties dialog, go to AdvancedTab and check
"Secure cache against pollution" option, click apply and finally click OK button.




Friday, January 30, 2009

Set MaxCacheTtl using dnscmd command

To following shows setting MaxCacheTtl using dnscmd.exe,


dnscmd.exe /config MaxCacheTtl 500.

To verify the MaxCacheTtl set to 500

run the command command

dnscmd /info /MaxCacheTtl

MaxCacheTtl Registry key

Recursive query records are saved by the DNS server. The length of cache time of saved records is determined by the TimeToLive (TTL) field in the record. This registry key determines maximum cache time of records saved by dns server irrespective of TimeToLive (TTL) field in the record. The DNS server deletes records from the cache when MaxCacheTime expires, even if the value of the TTL field in the record is greater than MaxCacheTime.

The registry key is located at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters"


Key Name:
MaxCacheTtl
Type : DWORD
Default : NoKey (Cache for up to one day)
Range : 0x0 | 0x1–0xFFFFFFFF seconds

To change the value the registry key to some cache time say 200 seconds, run the following

reg add "HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v MaxCacheTtl /t reg_dword /t 200



Note: 1. The changes to registry key through regedit will be effective only after restarting the DNS server.
2. This registry key doesnot have effect on WINS records saved in the DNS memory cache.

3. This registry key is supported by windows 2ooo, windows 2003 and windows 2008.

ForwardDelegations Registry key

This registry key applys only if the delegated subzone is within the DNS server's authoritative zone. This reg key determines whether the DNS server should forwards dns queries about delegated subzones(delegated subzone is with in the DNS Server zone) to servers outside of its authoritative zone or to the delegated subzone itself.

The registry key is located at "HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters"

Key Name: ForwardDelegations
Type: DWORD (Boolean)
Default: NoKey (doesnot forward delegations.)

By default, whenever a DNS server receives a dns query for a normal zone(not a delegated zone) name outside its authoritative zone, it simply forwards to a similar name server outside of its zone. However, when it receives a query for a delegated subzone, it sends the query directly to the delegated subzone and does not forward it.

But,if the registry key is set to 1, then the query for a delegated subzone (with in the authorative zone) should be sent to outside of authorative zone just as it does by default.

Forexample, A dns server has a delegation for blogspot.com to blogger.com, if the server receives a query for dns-info.blogspot.com then the server should send the query to delegated zone blogger.com. if the registry key is set to 1, then the server sends the query to blogspot.com.

To change the reg key value to 1, then run the following on command prompt

reg add "HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v ForwardDelegations /t REG_DWORD /d 1 /f

Note:
1. Changes to ForwardDelegations reg key will be effective only after restarting the server.

2. This reg key used only when forwarding is enabled. If forwarding not enabled then queries to delegated zones not forwarded.

3. Forwarding should be enabled if the delegation itself was at a remote site that is reachable only through the forwarder.



Design by infinityskins.blogspot