Premkumar Yogeswaran's Blog

Active Directory | PowerShell | DNS | DHCP | Exchange Server | VM Ware

Posts Tagged ‘Active Directory’

How to create an external trust between two seperate domains/forests

Posted by Premkumar Yogeswaran on April 17, 2012


A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. There are different type of trust like External, Realm, Forest and shortcut. In this article, I am going to talk about external trust. This can be applied in windows 2003 and windows 2008 also using same principle. External trust is necessary when users from two different domain wants to access resources such as printers and file server of two domains. There are few requirements to fulfill this goal.

Both domain controller must ping each other IP. If both domain controller sits in different subnet then proper routing required.

DNS records of both domain controller must be added in both server (Example: DNS record of bollywood.com must be added in desibaba.com and vice versa).

FQDN must be added in both DC (Example: FQDN of dns1.bollywood.com must be added in dc1.desibaba.com and vice versa).

Now dc1 will be able to ping dns1 by name and FQDN. Now ready to create an external trust. However, you still can’t ping by FQDN then type IP of PDC of forest A as secondary/alternative DNS in the TCP/IP property of PDC of forest B. Do vice versa. Now you will be able to ping by FQDN.

One way Trust between two DC. Example: One way trust allows users from dc1 (outgoing) get access to dns1 (incoming) but dns1 doesn’t get access to dc1).

Creating incoming trust in dns1

1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain for which you want to establish a trust, and then click Properties.

3. On the Trusts tab, click New Trust, and then click Next.

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the external domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next.

6. On the Direction of Trust page, click One-way: incoming, and then click Next.

7. On the Sides of Trust page, click This domain only, and then click Next.

8. On the Trust Password page, type the trust password twice, and then click Next.

With the administrator of the other domain, agree on a secure channel password to be used in establishing the trust.

9. On the Trust Selections Complete page, review the results, and then click Next.

10. On the Trust Creation Complete page, review the results, and then click Next.

11. On the Confirm Incoming Trust page, do one of the following:

· If you do not want to confirm this trust, click No, do not confirm the incoming trust.

· If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain.

12. On the Completing the New Trust Wizard page, click Finish.

Creating outgoing trust in dc1

1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain for which you want to establish a trust, and then click Properties.

3. On the Trusts tab, click New Trust, and then click Next.

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the external domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next.

6. On the Direction of Trust page, click One-way: outgoing, and then click Next.

7. On the Sides of Trust page, click This domain only, and then click Next.

8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next:

· Click Domain-wide authentication.

· Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next.

10. On the Trust Selections Complete page, review the results, and then click Next.

11. On the Trust Creation Complete page, review the results, and then click Next.

12. On the Confirm Outgoing Trust page, do one of the following:

· If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time that the trust is used by users.

· If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain.

13. On the Completing the New Trust Wizard page, click Finish.

Note : if you want both sides get access to both sides then change that config to two way and set incoming and outgoing in both sides.

Refer the below Link:

http://araihan.wordpress.com/2009/08/05/how-to-create-an-external-trust-between-two-domains/

Posted in Active Directory, DNS | Tagged: , , | Leave a Comment »

How to migrate Windows 2003 Active Directory to Windows 2008 Active Directory–Step by Step guide

Posted by Premkumar Yogeswaran on April 17, 2012


Microsoft’s new baby in their server family is Windows Server 2008. The Windows Server® 2008 operating system ease operation of IT administrator and enterprise IT planner and designer. Windows 2008 Active Directory got improved roles, AD domain services, federation services, AD rights management services, compliances and BPA. Its time to shift to Windows 2008 Active Directory. In this article, I will show how to migrate from windows 2003 AD to windows 2008 AD.

On Windows Server 2003 DC, insert the Windows Server 2008 DVD, then open command prompt and change directory to d:sourcesadprerp directory. Here D: is my dvd rom drive. In your case do as appropriate. note: you need to log on to windows 2003 domain controller as enterprise admin to run these command.

Now run following command adprep/ forestprep

After finishing forestprep run adprep/ domainprep

adprep/ rodcprep (Optional)

Install windows 2008 server and promote windows 2008 server as additional domain controller in windows 2003 forest

This is a trial version of windows 2008, I do not find any necessity to mention any cd key for this article. If you have proper cd key, you can mention here.

Windows 2008 will ask you to reset password for the first time. note: password complexity is enabled by default.

Now you have completed installing Windows 2008 machine. Log on as an administrator. Add active directory role in windows 2008 server. follow the screenshot as shown below

Mention your existing domain name, provide domain admin credentials to add this server to domain.

A restore password is required in case you need to restore AD.

Now restart windows 2008 server. It takes few minutes to replicate all AD container, AD object and DNS records. I would prefer to wait more then hours and see all the records are available in windows 2008 active directory. or you can force replicate all record if necessary.

Now transfer all the FSMO roles from windows 2003 AD domain controller to windows 2008 AD domain controller. Log on to windows 2003 domain controller as enterprise admin. open command prompt type as follows:

ntdsutil

roles

connections

connect to server WIN2008SERVERNAME

q

Transfer domain naming master

Transfer PDC

Transfer Schema Master

Transfer RID master

Transfer infrastructure master

Now you are ready to demod windows 2003 domain controller. log on to windows 2003 domain controller as domain admin . Open AD sites and services from administrative tools, expand default first site name, expand windows 2003 domain controller, right click on NTDS settings and go to properties. uncheck global catalog, click ok.

open run from start menu type dcpromo

LEAVE THIS ABOVE BOX UNCHECKED, this will enable windows 2003 domain controller transfer all AD database to windows 2008 domain controller.

Click next, provide password and follow next prompt, wait until demotion completed. Restart…. That’s all.

Refer Below Link:

http://araihan.wordpress.com/2009/08/25/migrate-from-windows-2003-active-directory-to-windows-2008-active-directory-step-by-step/

Posted in Active Directory, DNS | Tagged: , , | 1 Comment »

DCDIAG – Advertising DC in Domain error

Posted by Premkumar Yogeswaran on April 4, 2012


Find the error below for the DC advertising error.

C:\>dcdiag /test:Advertising

Domain Controller Diagnosis

Performing initial setup:

Done gathering initial info.

Doing initial required tests

Testing server: APAC-SITE\DC1

Starting test: Connectivity

……………………. DC1 passed test Connectivity

Doing primary tests

Testing server: APAC-SITE\DC1

Starting test: Advertising

Warning: DC1 is not advertising as a time server.

……………………. DC1 failed test Advertising

Resolution:

Try each of these solutions one step at a time, re-testing after completing each step until the problem is resolved.

  1. Ensure the Windows Time service is running. On a DC it is part of the core AD functonality and should be runing even if synchronised time is not essential.

net start w32time

  1. Restart the Windows time service

net stop w32time && net start w32time

  1. Check that Network problems are not stopping NTP form functioning. Note that Windows clients do not synchronise with the DCs via NTP, this only tests the ability for DC themselves to check an external time source:

w32tm /stripchart /computer:time.windows.com /samples:2 /dataonly

Error 0x800705B4 is a network timeout on the port – 123. Time.winfows.com should be replaced with the external time server you are using for a more complete test.

Try:

netdiag /fix

Netdiag is part of Windows Server 2003 Service Pack 1 Support Tools. This can also be used on Server 2008.

  1. If you received the error message: The service name is invalid earlier the Windows Time service is not even registered. Re-registering the W32time service can also fix some issues so perform these steps anyway: Re-registering the Windows Time Service
  2. Try:

w32tm /resync /redisscover

  1. Check that the DC has the PDC role:

netdom query fsmo

If it is run the following command:

w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update

Microsoft’s own free NTP server can be used as shown here, but I would recommend using one in your country if not in thr US. For the UK I can recommend ntp2d.mcc.ac.uk but there are many others.

  1. Ensure that the DC is announcing itself correctly through changing the AnnounceFlags are set correctly in the Registry. Edit the [HKLM\SYSTEM\CurrentControlSet\Services\w32time\Config\AnnounceFlags] key to a (the letter a) in hexadecimal. To allow the w32time service read the config change:

w32tm /config /update

Re-registering the Windows Time Service

w32tm /unregister
rem Ignore Access denied message if it appears and repeat
w32tm /unregister
w32tm /register
rem Before the re-register command will work you may have to reboot.

This gives a vanilla set of settings, after which the service can be restarted:

net start w32time

If you receive an error message regarding SIDs then DC will need to be rebooted again.

Posted in Active Directory | Tagged: | 1 Comment »

Active Directory components process screenshot

Posted by Premkumar Yogeswaran on April 2, 2012


Posted in Active Directory | Tagged: | Leave a Comment »

DC Locator Process in W2K, W2K3(R2) and W2K8

Posted by Premkumar Yogeswaran on April 1, 2012


By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

  • _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

  • _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

  • NLTEST /DSGETSITE

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

  • NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN><DC> /OU:<distinguished name of OU> /USERD:<DOMAIN><USER> /PASSWORDD:<PASSWORD>
  • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

  • For W2K DCs
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  • Registry value name: DnsAvoidRegisterRecords
  • Registry value type: REG_MULTI_SZ
  • Registry value data: <list of ENTER-delimited mnemonics>

For W2K3(R2)/W2K8 DCs and later:

  • GPO setting path: "Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records"
  • GPO setting: "DC Locator DNS records not registered by the DCs"
  • GPO setting mode: Enabled
  • GPO setting value: <list of SPACE-delimited mnemonics>

List of "mnemonics" that should not be registered by branch office DCs:

  • Dc
  • DcByGuid
  • Gc
  • GcIpAddress
  • GenericGc
  • Kdc
  • Ldap
  • LdapIpAddress
  • Rfc1510Kdc
  • Rfc1510Kpwd
  • Rfc1510UdpKdc
  • Rfc1510UdpKpwd

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process.

Make sure you also see MS-KBQ247811, as there it mentions: "After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client."

Looking at this all, the DC locator process as explained above still applies to Windows Vista and to Windows Server 2008 and later. Are there any differences or additions? Yes, there are!

Basically the client either queries for a DC in the AD site it is in or it queries for a DC in the AD domain it is in. I have always asked myself why the DC locator process did not support following the site topology based on the site cost to find the next closest DC for authentication. The answer to that is unknown to me, but both Windows Vista and Windows Server 2008 provide an additional possibility that exists between "a DC in the AD site" (the closest end) and "a DC in the AD domain" (the far end). The new possibility is "a DC in the next closest site". 😉

Both Windows Vista and Windows Server 2008 still use the default behavior W2K, WXP, W2K3(R2) have. For both Windows Vista and Windows Server 2008 to locate a DC in the next closest site, it needs to be enabled explicitly. That can be done by using the following:

  • For WVT/W2K8 and later:
  • GPO setting path: "Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records"
  • GPO setting: "Try next closest site"
  • GPO setting mode: Enabled

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

To determine a writable DC within a set of DCs in the next closed AD site from the client’s perspective that could authenticate the client:

  • NLTEST /DSGETDC: <FQDN DOMAIN> /WRITABLE /TRY_NEXT_CLOSEST_SITE

Until now I talked about locating a DC for authentication. What I did not talk about yet is locating the SYSVOL to apply GPOs and to use the legacy NETLOGON share. Let’s see how that works.

Each AD domain contains one system domain DFS that allows access to the SYSVOL and NETLOGON share. After a computer or user has been authenticated a referral is requested at the authenticating DC for \<Domain Name><SYSVOL or NETLOGON>. The authenticating DC creates two lists being one list with random referrals IN the same AD site as the computer/user and one list with random referrals OUTside the AD site of the computer/user. As you can see the authenticating DC is not by default (it can be however) also the DC that provides access to the SYSVOL or NETLOGON shares. It can thus be another DC in the same AD site as the computer/user that will provide access to the SYSVOL or NETLOGON shares. To make sure the authenticating DC in the same AD site as the computer/user is at the top of the DFS referrals in-site list an update needs to be installed on the DCs and a registry configuration needs to be made on the same DCs. For more information see MS-KBQ831201.

In addition to installing the update on the DCs the following configuration needs to be made on the DCs to put the authenticating DC on top of the DFS referrals list:

  • Registry key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDfsParameters
  • Registry value name: PreferLogonDC
  • Registry value type: REG_DWORD
  • Registry value data: 1

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8.

It gets even worse if a computer/user is authenticated outside its AD site because its DC is not available or because it is a DC-less AD site. In that situation it will use ANY DC to gain access to the SYSVOL or NETLOGON shares and in the worst case it will use some DC on the other side of the world with the tiniest WAN link you can imagine. That kinda sucks!

For both W2K and W2K3 a solution exist so that the referral process uses the nearest referral based upon site link costs. To achieve this the following is needed:

  • For W2K SP4 (!) DCs
  • Install update as mentioned in MS-KBQ823362
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsDriver
  • Registry value name: DfsEnableSmartClient
  • Registry value type: REG_DWORD
  • Registry value data: 1

For W2K3(R2) DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SiteCostedReferrals
  • Registry value type: REG_DWORD
  • Registry value data: 1

To determine DFS referral information:

  • DFSUTIL /SPCINFO
  • DFSUTIL /PKTINFO

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8. If it is the most probably you need to use the W2K3 configuration

Now imagine the client used a DFS referral for the SYSVOL or NETLOGON outside of its AD site because its local DC was not available for some reason. Of course you want the client to fallback to its local DC in the AD site as soon as it becomes available to either access the SYSVOL or NETLOGON share. But will it do that? No! It will use the DFS referral outside its AD site until it is rebooted or its cached is reset. W2K3 SP1 allows a client to fallback to its local DFS referral target as soon as it becomes available again and it needs to access the SYSVOL or NETLOGON share.

On W2K3 SP1 DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SysvolNetlogonTargetFailback
  • Registry value type: REG_DWORD
  • Registry value data: 1

On WXP SP2 clients and W2K3 SP1 servers:

For additional information, make sure to have a look at:

  • SRV record

How to verify that SRV DNS records have been created for a domain controller

SRV Resource Records

How to optimize the location of a domain controller or global catalog that resides outside of a client’s site

How DFS Works

http://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/11/domain-controller-locator-in-depth.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 1
http://blogs.dirteam.com/blogs/jorge/archive/2007/06/30/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-1.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 2
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-2.aspx

DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 3
http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-3.aspx

Posted in Active Directory, DNS | Tagged: , | 7 Comments »