Tip

Active Directory: Easing DNS configuration concerns and user login woes

Gary Olsen

Requires Free Membership to View

Recently, Active Directory expert Gary Olsen has ended his articles by urging readers to send him their own Active Directory queries. The following is a sample of just a few of the questions Gary received, along with his responses.


I'm responsible for creating a new global domain structure and I'm concerned about Active Directory DNS configuration and security. Specifically, I want to know if I should have the DNS name for my internal forest/domain be the same as the name on the outside of the firewall or should it be different?

Gary Olsen: This question is an oldie but goodie. There really is no security issue with having the same DNS domain name on the outside and inside of the firewall. Of course, you are exposing your domain name, but that, by itself, won't compromise security.

Remember that you want an Internet presence for your company to host its public Web pages, and you need the DNS zone for Active Directory internally. In terms of administration, it is much easier to have separate names. To implement this, you would have Company.com registered and used as an external name space for your company Web site, and Corp.net as the DNS zone internally for Active Directory. To make them the same, Company.com would be the external name and it would be the name of the Active Directory namespace.

The problem involves internal users trying to get to the external Web site like www.company.com. This is fairly easy to do with alias records, but it does take some work to set it up. There are arguments for both sides of this issue, but in my experience, it's more common to have separate name spaces.

I worked with one customer several years ago who had three namespaces, all the same name. Back in the NT4 days, an engineer (not in IT) decided he wanted to register the company namespace with the Internet, ABC.com. Then he called his internal DNS zone ABC.com and the NT domain was ABC. Then the IT folks got up to speed and wanted an NT domain, so they named their domain ABC and used the ABC.com namespace. In that case, the ABC.com name was used twice internally and once externally. It all worked surprisingly well. NT could get away with it (having two domains with the same name) as long as the clients pointed to the right DNS server. When they migrated to Windows 2000 Server, they merged the domains to a common ABC.com and kept ABC.com for the external space for their public Web site.

We have a Windows Server 2003 domain. Our current problem is that user login is taking as long as five to 15 minutes. It is a small environment and we only have a few Group Policy Objects (GPOs) applied. The problem affects most users, across site and group boundaries.

GO: obviously more troubleshooting would have to be done here, but here are three common causes of this problem (other than a virus):

  1. Subnets improperly mapped to Active Directory sites. This causes the client to be authenticated by a DC in another site. A quick way to list all such clients is to look at the Netlogon.log. You would see something like the example below. The subnets noted are not mapped to a site. Correct this by defining them in the Sites and Services snap-in.
  2. 08/29 14:43:03 NO_CLIENT_SITE: ALFPC01 175.26.8.134
    08/29 14:43:10 NO_CLIENT_SITE: LKBPC12 10.1.15.60
    08/29 14:43:11 NO_CLIENT_SITE: CXODL1 177.2.28.121
    08/29 14:43:12 NO_CLIENT_SITE: BRUX-201 10.46.11.6
    08/29 14:43:14 NO_CLIENT_SITE: LRGN27-10 10.29.32.12

  3. Large, roaming profiles. Depending on what the users have in their "My Documents" folder or if they are using Folder Redirection, this could take some time. One way to test this is to create a new user, then go to a problem machine and log on with that user. Since the problem is somewhat inconsistent, you might want to log on several times over a day and see if you can log on in an acceptable time period. If the problem goes away, then look at reducing profiles, restricting roaming profiles and so on.
  4. Group Policy applied from a DC in another site. I recently worked on an issue with a customer in Europe who had four large sites, each with three DCs connected on fast network links, and a number of remote sites connected with slower network links with DCs. The problem was that users in the large sites would be authenticated by a DC in their "home" site but, intermittently, they would get policy applied from a DC in another site. When the client used a site on one of the slow links, it would take 20 minutes or so to log in. The problem moved around between the users and sites and was not consistent.

The solution was found in a Microsoft hotfix, KB831201. It indicates that SYSVOL is really a domain-based DFS (distributed file system) root and that each domain controller hosts a replica of the share. It turns out that when the client gets a list of all DCs that host SYSVOL, the DCs are in random order. Thus, a user can be authenticated by one DC and get policy from another.

The solution was to apply the 831201 hotfix, which updates dfs.sys and dfssvc.exe. It then allows you to specify a preferred DC for DFS to find. This is done by modifying the following Registry value on each DC:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dfs
Create a new DWORD value called PreferLogonDC and set the value to 1.

This will have the effect of placing the DC that authenticates the user at the top of the DFS list and allows the client to have GPOs applied from their logon server.

Note: KB831201 is included in SP1, so if you are using at least Windows Server 2003 SP1, all you have to do is define the Registry key noted here. Also note that KB905846 discusses related issues with DFS shares (other than SYSVOL).
My question is about your article Kerberos protocol: What every admin should know about Windows authentication. When entering in the realm principal name into the "user name mapping" area of Active Directory, does one just put in the hostname of the Unix machine that's trying to access resources on a Windows domain? Essentially, what goes into the "Kerberos Principal Name" field in Active Directory?

GO: It is the principal name (user name) from the Kerberos realm. Remember that you are mapping realm users with Windows domain users, so when a realm principal (user) logs in, it will be associated with a Windows user account to get the SID, security groups, etc.

Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at glo11749@yahoo.com. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.

Did you find this article useful? Tell SearchWinIT.com!

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.


This was first published in June 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.