Configuring DNS Search Suffixes

Configuring DNS Search Suffixes


Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer


First published 2/12/2011


 


Preface


The search suffix is used by the client side resolver to “suffix” a DNS query.


For example, if I were to ping a hostname called “serverName,” if a search suffix has been configured, whether automatically (being joined to a domain), or manually (variety of methods discussed below), it will “suffix” the search suffix to my query.


For example, if there is a suffix configured for “domain.com,” and I type in “ping serverName,” the resulting query will be “serverName.domain.com.” If there is no suffix, it will just ping the single name.


More on how the client side resolver algorith works, can be found in my other blog:


DNS, WINS NetBIOS & the Client Side Resolver, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down Does a Client logon to Another DC, and DNS Forwarders Algorithm if you have multiple forwarders.
http://msmvps.com/blogs/acefekay/archive/2009/11/29/dns-wins-netbios-amp-the-client-side-resolver-browser-service-disabling-netbios-direct-hosted-smb-directsmb-if-one-dc-is-down-does-a-client-logon-to-another-dc-and-dns-forwarders-algorithm.aspx


 


More on Suffixes


By default, a freshly installed machine, out of the box, has no Suffixes created.


When you join a machine to an Active Directory domain, the machine takes on the domain’s DNS FQDN as the Primary DNS Suffix. The Primary DNS Suffix also becomes the default Search Suffix, and will apply to all interfaces on the machine.


For example, if a machine is not joined to an AD domain, and no search suffixes have been configured (out of the box), the top portion of an ipconfig /all would look like this. Notice there are no suffixes:



C:\>ipconfig /all


Windows IP Configuration


   Host Name . . . . . . . . . . . . : TestBox
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No



If the AD domain name is ‘domain.com,” and the machine was joined to the domain, the top portion of an ipconfig /all would look like this.


C:\>ipconfig /all


Windows IP Configuration


   Host Name . . . . . . . . . . . . : TestBox
   Primary Dns Suffix  . . . . . . . : domain.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : domain.com



If the AD domain name is a child domain, such as childDomain.domain.com, the ipconfig /all would look like this. Notice how the Search Suffix is configured to devolve the parent domain, which is an automatic function. This can be altered or disabled, in the NIC’s properties (IP properties, Advanced, DNS tab -> “Append parent suffixes of the primary DNS suffix”), a GPO or in the registry.


C:\>ipconfig /all


Windows IP Configuration


   Host Name . . . . . . . . . . . . : TestBox
   Primary Dns Suffix  . . . . . . . : childDomain.domain.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : childDomain.domain.com
                                                           domain.com


 


Windows 7, Windows 2008 & Windows 2008 R2 Devolution Nuances


With Windows 2003 and older, what you see above is default behavior, that is to append the parent suffix. However, with Windows 7 & Windows 2008, this was changed. Windows 2008, Windows 2008 R2, and Windows 7 by default have changed the way the Append parent suffixes of the primary DNS suffix (also known as “devolution”) setting works. This is even if you have the “Append parent suffixes of the primary DNS suffix” setting enabled, it will still set the devolved parent zone.


To fix it and make the newer operating systems work like 2003 and older, you have to make somce changes. Read the following nicely assembled article for specifics on how to handle this with registry entried, if you feel this is affecting your environment:


Windows 2008 Append parent suffixes of the primary DNS suffix does not work
http://networkadminkb.com/kb/Knowledge%20Base/Windows2008/Windows%202008%20Append%20parent%20suffixes%20of%20the%20primary%20DNS%20suffix%20does%20not%20work.aspx



More info on this from Microsoft:


DNS DevolutionPublished: October 21, 2009, Updated: July 7, 2010
Applies To: Windows 7, Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/ee683928(WS.10).aspx


 


Multi-Domain Forests with two or more child domains


If you are in a multi-domain forest with two or more child domains, besides understanding the suffixes that need to be added, you’ll also need to understand your DNS design options in this type of scenario. More on this in my other blog:


DNS Design Options in a Multi-Domain Forest – How to create a Parent-Child DNS Delegation
http://msmvps.com/blogs/acefekay/archive/2010/10/01/dns-parent-child-dns-delegation-how-to-create-a-dns-delegation.aspx


If the environment includes Windows 7, 2008 & R2, you may want to take a look at the subsection in the section above on the nuances of the newer operating systems and how to deal with it.


 




Choices to Configure a Suffix


In some scenarios where either in an AD environment with multiple child domains that you need to populate the suffix of the other child domains, or with a non-joined machine (such as a home user machine in a workgroup), that you need to populate additional suffixes to resolve names in partner or specific zones, you can add them a variety of ways, some of which are:


With Active Directory

  • Group Policy
  • WSH script, Registry script, or some other type of scripting
  • DHCP Option 015 (however this has its limits)
  • DHCP 119 or DHCP Option 135 – (This is not supported with Windows DHCP and Windows clients)


In a Workgroup

  • DHCP Option 015 (however this has its limits)
  • Local Group Policy
  • WSH Script, Registry script, or some other type of scripting
  • DHCP 119 or DHCP Option 135 – (This is not supported with Windows DHCP and Windows clients)

 



Using Group Policy


If you are in an AD environment, this is a great option to populate a custom Search Suffix for all interfaces on a machine. It’s easy, too, because it’s done once and it’s automatic. It works for Windows 2008R2, 2008, Windows 7, Vista, 2003, XP,  and all newer operating systems. If you’re still using Windows 2000 Active Directory, you’ll need to upgrade the GPOs using a Windows 2003 or XP machine.


Upgrading Windows 2000 Group Policy for Windows XP:
http://support.microsoft.com/default.aspx?scid=kb;en-us;307900


Group policies for DNS in Windows Server 2003 and newer
http://support.microsoft.com/kb/294785


After the GPOs have been upgraded, or if the sysetm is already at the latest operating system version and service packs, expand the Group policy section to add the custom search list to the following location:


Computer Configuration
   -Administrative templates
         -Network
               -DNS Client


Also…


Take a look at the following article. You will want to alter the Primary DNS Suffix Devolution value. Just make sure you document it, so when one day comes up you don’t want it anymore, you don’t go crazy trying to figure out where’s it coming from. You would be surprised that this question comes up once in awhile, and one of the suggestions is to check if they’re coming from a GPO.


It refers to the registry key controlled by GPO – this will over-ride the standard internal registry setting at:
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\UseDomainNameDevolution


If you want to kill the devolution tickbox, have a look at this article:
http://www.insidetheregistry.com/regdatabase/viewvalue.asp?valueid=320



Just a reminder, you do not want to alter the Default Domain Policy GPO or the Default Domain Controllers GPO. You would want to create a separate GPO, and link it to the OU where the computers reside that you want apply the suffix.


 


 


Scripting


You could also use populate the regkey by a WSH or VB cript if you didn’t want to pull in the extra ADMX GPO template… and this will force your client to JUST resolve hosts on internal.domain.com or whatever:



Windows Registry Editor Version 5.00


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“SearchList”=”domain1.com,domain2.com”



Or use the command:
reg add HKLM\system\currentcontrolset\services\tcpip\parameters /v “SearchList” /d “domain1.com,domain2.com” /f



The key thing to observe with manual suffix lists, (from KB275553, link below), is that if you distribute a suffix list then it blocks devolution and use of primary or connection-specific suffixes… therefore you’ll want to enter the list carefully with exactly what you need.


How to configure a domain suffix search list on the Domain Name System clients
http://support.microsoft.com/?id=275553


 



DHCP Option 015


You can assign a connection specific DNS suffix using DHCP option 015, which is added to the search list. But, you can assign only one DNS suffix per client using this DHCP Option.


Because it’s called the “Connection Specific Suffix, it’s only good for the specific connection that received a DHCP assignment. This means that the connection that receives a DHCP config from DHCP, will get this suffix as the Search Suffix.


Just to illustrate what this means, you can test it by setting a suffix in Option 015 that’s different than the domain’s zone name. First, if the AD domain’s zone name is ‘domain.com,’ then the Primary DNS Suffix become ‘domain.com’  when you join the machine to the domain. The default Search Suffix becomes the default Search Suffix. Now in DHCP Option 015, configure ‘domain1.com’ as the connection specific suffix. Now go to the workstation and run a /release and /renew. You will now see the suffix you configured in 015 in addition to the machine’s default.


So if you are trying to simply add one additional suffix, this will work for your DHCP clients. However, if you’re trying to add more than one additional suffix, and/or if you have numerous statically configured machines (such as servers), then a GPO will be the better alternative, which Tiger and JM already suggested.


 


DHCP Option 119


This is not supported under Windows DHCP or Windows clients. For non-Windows DHCP servers, you can use DHCP Option 119, which populates Search Suffixes based on RFC 3397. However, it’s not supported under Windows DHCP at this time.


RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Sea
www.faqs.org/rfcs/rfc3397.html


 


DHCP Option 135


You can use DHCP Option 135, however DHCP Option 135 is not supported by Microsoft DHCP. DHCP option 135 is usually used for devices, such as a phone system, based on RFC 4578, unless it was superceded, or this one superceded a prior one
defining such an option value. Take a look at the list of DHCP options in the following article, but keep in mind, Microsoft does not support all of them and many are used by IP based device manufacturers.


RFC 4578 – Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
http://www.faqs.org/rfcs/rfc4578.html


DHCP and BootP Options
http://www.networksorcery.com/enp/protocol/bootp/options.htm


You can *possibly* create the option in DHCP, but that would require some testing on your part.
http://www.isaserver.org/img/upl/isaedukit/5automate/5automate_files/image057.jpg


 


Summary


If in an Active Directory environment, you’ll find it much easier to populate suffixes using a GPO.


If in a workgroup, you can use DHCP Option 015, or a script. But as I mentioned above, Option 015 is just the “connection specific suffix,” which only the interface that gets a DHCP configuration from this scope will apply to, meaning that if there are additional interfaces, they will not receive it. The GPO method applies to the machine for all interfaces.


 



Ace Fekay

Share Permissions and NTFS Permissions Folder Access Control & Folder Permissions

Share Permissions and NTFS Permissions Folder Access Control & Folder Permissions


Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer


Original Creation Date: 2/4/2010


 


Prelude


This question has come up from time to time in the public newsgroups and Technet forums. I thought to lay it out to make it as easy to understand as I would when I’m teaching this topic in a classroom.


 


Basic Understanding of Share and NTFS Permissions


To understand Sharing and NTFS permissions (Security Tab), when connecting to a Shared Resource (folder, printer, etc), the NTFS permissions are combined with the Share permissions to provide the Most Restrictive.


This means that if a user has Full Control on the Share permissions, and only Read on the NTFS permissions (Security Tab), the Effective (resulting) permissions is the user will only have Read. That’s why we can set higher Share permissions at the parent for the initial access, then control the resulting or Effective permissions with NTFS. No passwords are needed other than the user being successfully logged on to the domain. When a user is logged on successfully to a domain, an access token is given the user account. The access token is compared to the ACL (Access Control List) in the Share and NTFS (security tab) permissions to determine access. That’s why no passwords are required, and is much easier than trying to deal with multiple passwords. The system simply uses the AD user account for access enumeration.


Therefore due to the Most Restrictive evaluation, the easiest way to set permissions is to provide the Users (preferrably by Groups), Full Control on the Share side, but lock it down on the NTFS side (Security Tab). It works nicely, all the time, and is easier to document and keep track.


 


The Basic Rules


The basic rules are:


NTFS Permissions:   


  •  
    • All NTFS permissions for a specific account, whether a specific account is added, or the account is part of a group, are combined to provide an Effective Permission using the Least Restrictive rule.
    • This applies to a user accessing the folder directly on the hard drive while logged on to the machine.

Share Permissions: 


  •  
    • All Share permissions are combined to provide the Effective Permissions using the Least Restrictive rule.
    • This applies to a user accessing the share via a UNC, Network Neighborhood browsing, or mapped drive.

Accessing a Share across the network:    


  •  
    • The NTFS & Share permissions are combined and evaluated to provide the Effective Permissions using the Most Restrictive rule.
    • This is the end result of accessing files or folders across the network whether UNC, Network Neighborhood browsing, or mapped drives.
    • The first permissions that are looked at when accessing across a share across a network are the Share Permissions. If the Share permissions are set to Read, that is the best a user will get.


Access Deny Permission


If there are any Access Deny Permissions set on either the Share ACL or the NTFS ACL for an account, whether it was placed on the user account OR the group account  it is part of,  the user or group will be denied permissions to the resource.


 Default Share Permissions on Windows 2003 and newer are set to Everyone = Read


For example, if you provide theFull Control permissions for an account in the NTFS ACL and do not change the default Share Permissions on Windows 2003 or newer,  when the account attempts to acess the share across the network, the user will get ONLY Read and Read & Execute, therefore will not be able to change anything no matter if you even give the user Full Control in the NTFS permissions (Security tab).


Share permissions do NOT Logged on Locally


Share permissions do NOT apply to someone logging on locally accessing the resource in Windows Explorer. However, the NTFS permissions will apply.


 


Use Groups To Control Access


The best way is to do it with groups instead of individual user accounts. Using individual user accounts will tax the system trying to enumerate the ACL entries for each account.


 


Simple Examples


Consider the following scenario:


Joe needs Read on the shared network folder. No other user has access.


We’ll set it up as follows:


Share Permissions:

  • Click on Advanced Sharing
  • Share the Folder
  • Click on Permissions
  • Remove the default Everyone = Read Permissions
  • Add Administrators = Full Control
  • Add Authenticated Users = Full Control

 

NTFS (Security Tab Permissions):

  • Click on the Security Tab (NTFS Permissions)
  • Remove Inheritance
  • Remove Users = Read
  • Keep Administrators = Full Control
  • Keep System = Full Control
  • Add Joe = Read


 


Results:


 In the above scenario, Joe will only have Read.


The reason is when Joe connects to the folder across the network, the Share Permissions provide initially Full Control, then the system evaluates the NTFS permissions (Security Tab), which Joe only has Read, then it combines the Share Permissions and NTFS permissions, resulting in the Most Restrictive, which become Read Only, therefore Joe ONLY has READ.


 


 


Advanced Example


Keep in mind as I’ve stated above, the Share permissions controls the intial connection. If they are set to Read, and the NTFS permissions are set to Full Control,  then all they get is Read. You need to understand this basic principal with the Sharing feature to provide the proper permissions for your users and groups.


Then the NTFS permissions are combined with the Share permissions to provide the Most Restrictive. This means that if a user has Full Control on the Share permissions, and Read on the NTFS permissions, the Effective (resulting) permissions is the user will only have Read. That’s why we can set higher Share permissions at the parent for the initial access, then control the resulting or Effective permissions with NTFS. No passwords are needed other than the user being successfully logged on to the domain. When a user is logged on successfully to a domain, an access token is given the user account. The access token is compared to the ACL (Access Control List) in the Share and NTFS (security tab) permissions to determine access. That’s why no passwords are required, and is much easier than trying to deal with multiple passwords. The system simply uses the AD user account for access enumeration.


Let’s say you have the following folder structure.


Office Data
     Accounting Folder
     Marketing Folder
     Sales Folder
     Operations


Your users are as follows. They require access to their respective folders but to no others.
   Joe and Sally are accountants.
   Bob and Sue are Marketing reps.
   Tom and Jerry are in sales.
   Wyle E and the Road Runner are in operations.


You create the following groups and add the appropriate users into those groups.
   Accounting Group
   Marketing Group
   Sales Group
   Operations Group


Then you share the Office Data folder, but not the others below it. You’ve set the Share permissions and NTFS (security tab) permissions as follows:


   Office Data Folder:
       Sharename = Office Data
       Share Permissions on the Office Data Share:
       Domain Admins = FC
       Authenticated Users = Change


The following are the NTFS (security tab) Permissions you will set. This is assuming the respective users will require read/write access to their respective folders. If they only need Read, then alter the Modify permissions in the suggested instructions below to Read, Read + Execute.


It is important that inheritance is disabled, as stated below in each folder, so you that can remove the default Everyone or Domain users, if they exist. Otherwise, that will thwart security control.


   Office Data Folder
      Click Advanced, uncheck Inherited, click on Copy when the message pops up
      Remove Everyone and Domain users. Leave everything else. Add the following:
      Domain Admins = FC
      Authenticated Users = Modify


    Accounting Folder:
          Click Advanced, uncheck Inherited, click on Copy when the message pops up
          Remove Everyone and Domain users. Leave everything else. Add the following:
          Domain Admins = FC
          Accounting Group = Modify (not full control)


      Marketing Folder:
          Click Advanced, uncheck Inherited, click on Copy when the message pops up
          Remove Everyone and Domain users. Leave everything else. Add the following:
          Domain Admins = FC
          Marketing Group = Modify (not full control)


     Sales Folder:
          Click Advanced, uncheck Inherited, click on Copy when the message pops up
          Remove Everyone and Domain users. Leave everything else. Add the following:
          Domain Admins = FC
          Sales Group = Modify (not full control)


     Operations:
          Click Advanced, uncheck Inherited, click on Copy when the message pops up
          Remove Everyone and Domain users. Leave everything else. Add the following:
          Domain Admins = FC
          Operations Group = Modify (not full control)


With the permissions set as suggested, Bob in Marketing cannot access any other folder other than Marketing, and Jerry in Sales cannot access anything else other than Sales. They can see the other folders, but they simply can’t get into them.


If just Bob in Marketing needs Read Only access to the Sales folder, simply create an additional group, and call it “Marketing Group Access to Sales Folder,”  and place Bob in that group. Then in the NTFS (security tab) permissions, add the “Marketing Group Access to Sales Folder”  group to the Sales Folder group, and set the permissions to Read and Read + Execute. This way Bob has read only permissions to see the files in that folder.



Regarding Read and Read/Execute Permissions:


If an executable needs to be run, a user will need Execute, otherwise Read will suffice. You can view the specific permissions set by going into Advanced to see exactly what permissions are being provided. The ACL (the first list of permissions) are standard pre-canned permissions. Advanced will show you specifics. You can also set permissions in Advanced, but you must understand what they mean. If you do it in Advanced, and hit Ok, the ACL will show “Special Permissions” because what you set in ADvanced does not equal to any of the pre-canned permissions. the system provides.


 


Related links:


Planning Access to Shared Folders
http://technet.microsoft.com/en-us/library/cc787768(WS.10).aspx


Windows 2003 NTFS and Share Permissions
http://www.mcmcse.com/microsoft/guides/ntfs_and_share_permissions.shtml


When NTFS Mixes With Share
http://www.lockergnome.com/it/2004/10/01/when-ntfs-mixes-with-share/


Share permissions vs. NTFS permissions
http://www.ntfs.com/ntfs-permissions-share.htm


Combining Shared Folder Permissions and NTFS Permissions
http://www.ntfs.com/ntfs-permissions-combined.htm


 


I hope that helps understanding this feature.


Ace