This document focuses on the options which can be utilized achieving the single sign on while accessing resources across the forests in different scenarios outlined below.

Mergers and acquisition

Mergers and acquisition is one of the common scenarios we face in today’s world where companies having two different IT infrastructure running different platforms and applications, most of the time mergers and acquisition of the companies end up with merging their IT infrastructure as well but depending on the size of the companies and their IT infrastructure there is always a period of coexistence when both IT infrastructure are to be in fully functional mode and need some kind integration, or there might be a situation where IT heads and Application owners take decision about not migrating their applications across the forest, or legal boundaries and geographical boundaries do not allow companies to host their applications across the geographical boundaries but the identity objects are hosted in a directory services hosted in different geographical location than the application resources, there can be many more situation where resources are in one forest and user identities are in another forest and users would like to have single sing on experience maintaining the security of the resources and directory systems.

There is a lot of information available on the net in bits and pieces, I am trying to gather and put the information together, for easy understand we will take an example of two different forests contoso.com and fab.com, contoso.com is an account forest and also has some local application servers, and fab.com is a resource forest which has some application servers and users from contoso.com need to access the applications in fab.com

Diagram 1

Both contoso.com and fab.com are situated in two different geographical location protected with firewall, while we design the single sign on solution for such scenario we need to consider following.

1. 1.       Network connectivity between Contoso.com and Fab.com
2. 2.       Name resolution between Contoso.com and Fab.com
3. 3.       Security
4. 4.       High availability
5. 5.       Authentication and Authorization

Network Connectivity between Contoso.com and Fab.com

As mentioned above contoso.com and fab.com are two different IT infrastructure situated in two different geographical locations and we need to have some means of connectivity between contoso.com and fab.com, keeping high availability and best practices in mind it is recommended to have dual connectivity links between two organizations and depending on the SLA of your ISP, it is worth having two different ISP providers providing network connectivity services, planning network connectivity should include the redundancy of every component of the network, firewall, routers, switches, network cards etc. so that if any one of the component along the way fails the redundancy of the component will cover the failure and prevent service interruption for users and also ensure that only required ports are opened on the firewall to ensure the security of the active directory and other application servers. Detailed planning of the networking is beyond the scope of this document

This document will focus on three options to achieve single sign on across

Part 1: Singe sing on with active directory forest trust

Part 2: Single sign on with Active directory Lightweight directory service

Part 3: Active Directory Federation Service

Active Directory Forest Trust

Trust Overview

• ·         A trust is a relationship established between domains that enable users in one domain to be authenticated by a domain controller in the other domain.

Trust Architecture

Trust is creating secure channel between two domains, two forests or two realms the authentications coming from the other domains, forest, or realms. There are numerous number of components help to form the trust architecture such as authentication protocols (Kerberos, NTLM), the Net Logon service, the Local Security Authority (LSA), and the Trusted Domain Objects (TDOs) stored in Active Directory.

The trust relationships that we can view in Active Directory Domains and Trusts is represented by Trusted Domain Objects (TDO) stored in the System container within its domain. For a domain trust, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO.

The architecture of trusts comprises a range of mutually dependent components; these components contain authentication, the Net Logon service and AD DS, which all rely on DNS to locate domain service records. AD DS provides the base for trust relationships by supplying a central management system through which domain administrators can grant access to trusted authorities in other domains. Trusts then provide the mechanism of authentication between domains or forests.

Trust Directions

The direction that a trust is assigned determines the valid trust path used for authentication. A trust path is defined by the series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running on Windows 2003 Server or Windows Server 2008 must determine whether the trusting domain has a trust relationship with the trusted domain. To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. All domain trust relationships have only two domains: the trusting domain and the trusted domain.

Diagram 2

There are four types of Trust available

1. 1.       External Trust
2. 2.       Realm Trust
3. 3.       Forest Trust
4. 4.       Shortcut trust

For more information about the trust, refer to article https://technet.microsoft.com/en-us/library/cc775736(WS.10).aspx

In this document we will focus on Forest Trust, there are two types of forest trusts

1. 1.       One Way Forest Trust
2. 2.       Two Way Forest Trust

Both one way and two way forest trust are transitive in nature, transitive trust extends the trust relation other domains in the forest; by default all domains in a forest are transitive in nature

Trusted Domain Object

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time that a trust is established, a unique TDO is created and stored in its domain (in the System container). Attributes such as trust transitivity, type, and the reciprocal domain names are represented in the TDO.

Forest trust TDOs store additional attributes to identify all the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security identifier (SID) namespaces.

Impact Analysis

Opening the forest trust will introduce the following impacts to both ends of the trust; the following lists the identified impacts and its mitigating measures to minimize impacts.

As per the diagram 1 above we have resources in Fab.com and users and computers are part of contoso.com, so to access resources across the forest we would need resource forest trusting account forest, we will see how we can achieve single sign on using One Way Forest Trust

• One-way forest trust support cross forest Kerberos and NTLM authentication while external trust only support NTLM (Kerberos authentication is the preferred method in SOEasy, NTLM is provided for backward compatibility)
• A one-way, forest trust between two forests allows members of the trusted forest to use resources that are located in the trusting forest. However, the trust operates in only one direction.

In this scenario users and computers which are logically part of contoso.com domain but situated physically in same subnet as fab.com forest would use contoso.com credentials to access the resources in fab.com, we will see what are the requirements for users to authenticate against contoso.com and access resources in fab.com forest.

Diagram 3

Prerequisites to establish One Way Forest Trust

1. 1.       Name Resolution mechanism for both active directory forest, to establish active directory trust relation between contoso.com and fab.com a DNS name resolution needs to be configured properly 
2. 2.       Required TCP/IP ports needs to be opened on all the firewalls falling underway 
3. 3.       Enterprise or Domain admin credentials from both forests 
4. 4.       PDC emulator role domain controller should be up and running and reachable across the forest 
5. 5.       Trusting Domain and Trusted Domain should have following in common 
   1. a.       SID (Security Identifier) 
   2. b.      Domain Naming System (DNS) name 
   3. c.       NetBios Name 
6. 6.       All domain controllers are in correct time zone (For Kerberos Authentication time difference more than 5 minutes will cause authentication to fail) 

Trust Limitations

1. Number of TDOs - Testing indicates that the time to complete operations related to TDOs, such as authentication across domains, deteriorates noticeably if the Active Directory implementation in an organization contains more than 2400 TDOs
2. Trust Path Limits - Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in another domain
3. Trust Search Limit - When a client searches out a trust path, the search is limited to trusts that are established directly with a domain and those that are transitive within a forest.
4. Trust Flow - The flow of communication over trusts is determined by the direction of the trust (one-way or two-way) and the transitivity of the trust (transitive or non-transitive)

 Resolution between Contoso.com and fab.com

As we discussed above to establish a trust we do need a healthy name resolution mechanism between the forests, let’s see what options do we have using Active Directory DNS, third party DNS is out of the scope of this document

Best practices for designing the DNS namespace and providing DNS support for deployment of a single Active Directory forest are provided in the “Best Practice Active Directory Design for Managing Windows Networks.” You can view this document on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=10478 . In the process of designing your multiforest Active Directory deployment, follow these recommendations for each individual forest. After you have completed the DNS design for each individual Active Directory forest, you must analyze the requirements to enable name resolution across the forest boundaries.

The ability to resolve the names from the namespace of a different forest is required by the following activities:

User or computer needs to locate a resource (for example, an Exchange server, file share, or service) that is hosted on a computer that is joined to a different forest.

User or computer needs to locate a domain controller in a different forest for the purpose of authenticating to a resource in that forest.

There are multiple ways of configure DNS name resolution across the forest, for example

1. 1.       Conditional Forwarding
2. 2.       Creating a secondary zone
3. 3.       DNS zone delegation

Conditional Forwarding

DNS servers are configured to forward the queries with a specific name suffix to a DNS server in different forest, contoso.com DNS server is configure to forward the queries with fab.com name suffix to fab.com DNS server and fab.com DNS server is configured to forward queries specific to contoso.com name suffix to contoso.com DNS server

Diagram 4

Creating a secondary DNS zone

DNS servers hosting high-level zones in the namespace hierarchy can be configured to host secondary zones that contain the highest-level zone data for other forest as

Diagram 5

TCP/IP ports required for establishing trust

Please refer to article below for complete list of ports required to be opened on firewall to establish trust across the forest

https://support.microsoft.com/kb/179442

https://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx

As we have users and client machines sitting across the network firewalls to reach their domain controllers for authentication, we also need to configure firewall and network connectivity to allow clients to logon into the domain, how interactive logon process works and what are the ports required to be open across the firewalls refer to article

 https://technet.microsoft.com/en-us/library/cc780332(WS.10).aspx#w2k3tr_intlg_how_unsl 

Since our end result is to give users seamless experience while accessing the applications across the forest with single sign on process, it is not uncommon in today’s world that you have applications in the environment which would require object picker functionality, so we also need to consider opening firewall ports for object picker functionality, below is the list of ports required

TCP/UDP 135, 137, 138, 139 (RPC)
TCP/UDP 389 by default, customizable (LDAP)
TCP 636 by default, customizable (LDAP SSL)
TCP 3268 (LDAP GC)
TCP 3269 (LDAP GC SSL)
TCP/UDP 53 (DNS)
TCP/UDP 88 (Kerberos)
TCP/UDP 445 (Directory Services)
TCP/UDP 749 (Kerberos-Adm) [Opt.]
TCP port 750 (Kerberos-IV) [Opt.]

Authentication Protocols

Active Directory domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.

Kerberos Version 5 Protocol

The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and remote procedure call (RPC), as well as the client and server applications that use these protocols. In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is true:

NTLM

The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a domain controller in the client account domain. The authentication protocol of choice for Active Directory authentication requests, when there is a choice, is Kerberos version 5. When the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority.

Trust Password

Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory as part of the trust creation. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO automatically, without the correct trust password, trust connection cannot be established. Trust password must meet the requirements enforced by domain policy.

Kerberos

To allow application access across the forest, users accessing the applications should be authenticated first with the authentication provider using Kerberos authentication mechanism, below diagram explains the process of Kerberos authentication while accessing the applications

1. 1.       User logged into the computer and tries to access the application in fab.com, application server doesn’t recognize the user, user needs to get some token to present to application to prove the identity
2. 2.       User contacts its domain controller KDC (Key Distribution Center)and requests a service ticket for application access
3. 3.       Domain Controller checks its database for the SPN since the domain controller / global catalog has limited information about its own domain, the SPN is not found, then global catalog checks its database about forest trusts that are established with its forest and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found,  the domain controller gives the referral ticket to Client for domain controller in fab.com
4. 4.       Client computer connects to fab.com for service ticket for application access
5. 5.       Domain controller in fab.com connects its global catalog server to find the SPN and the global catalog finds the match for SPN
6. 6.       Client computer connects the domain controller KDC in fab.com to negotiate the ticket for user from contoso.com to access the application in fab.com
7. 7.       Once client has a service ticket, it goes back to application server with the service ticket and gains the access to application

Kerberos Delegation (a.k.a. Kerberos Double-hop)

Typically, clients call a service to have the service perform some action on the client’s behalf. Impersonation allows the service to act as the client to perform an action. Delegation allows a front-end service to forward the client’s request to a back-end service in such a way that the back-end service can impersonate the client. Impersonation is most commonly used as a way of checking whether a client is authorized to perform a particular action, while delegation is a way of flowing impersonation capabilities, along with the client’s identity, to a back-end service.

Delegation is a Windows domain feature that can be used when Kerberos-based authentication is performed. Delegation is distinct from identity flow and, because delegation transfers the ability to impersonate the client without possession of the client’s password, it is a much higher privileged operation than identity flow.

Both impersonation and delegation require that the client have a Windows identity. If a client does not possess a Windows identity, then the only option available is to flow the client’s identity to the second service.

With the assumption that client has already has the TGT from contoso.com Domain. When trying to access resource at the fab.com AD, the steps are:

1. 1.       Desktop connects to Web Application and provides both TGT and service ticket.

Web Application uses the clients TGT to request a service ticket from the fab.com domain controller so Web Application can connect to Database Server.

1. 2.       Web Application connects to Database Server using the client’s credentials.

Ability to delegate is one of the Kerberos authentication protocol capabilities as defined in RFC 1510 (https://www.ietf.org/rfc/rfc1510.txt). With this capability, user accountability will be improved, since users credentials will be used to access the services end to end, at the other hand, this introduce the risk on misuse of user credential (even though setting application with this capability requires admin privileges at fab.com Network end).

Implement Kerberos Constrained delegation: The constrained delegation extension allows a service to obtain service tickets (under the delegated users identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 1510, or in the protocol transition extension.

NTLM

In case of NTLM authentication, the authentication referral process is shown in below diagram

In this scenario user and computer object are in contoso.com domain and application servers are in fab.com domain and users are trying to access resources in fab.com

1. 1.       The initial request for authentication goes directly from the client to the web server in the fab.com domain
2. 2.       This legacy web server creates a challenge to which the client responds.
3. 3.       The legacy web server then sends the user’s response to a fab.com domain controller in its computer account domain.
4. 4.       This domain controller checks the user account against its security accounts database. If the account does not exist in the database, domain controller sends the credentials of the client to a domain controller in the user’s domain, in this case constoso.com for pass-through authentication.
5. 5.       Again, constoso.com domain controller checks the user account against its security accounts database and verifies the user credentials, and returns the result to the sender. If the verification is successful, the message contains the user's authorization data. If the verification is unsuccessful, logon is denied.

Authentication Scope

For the forest trust, the following authentication scope can be selected:

• Forest-wide authentication: An authentication setting that permits unrestricted access by any users in the specified forest to all available shared resources that are located in any of the domains in the local forest.
• Selective authentication: An authentication setting that restricts access over an external trust or forest trust to only those users in a specified domain or specified forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the local domain or the local forest

Based on the requirement we need to made a decision about the scope of the authentication, if the requirement is to give access to specific number of users across the forest it is recommended to use selective authentication which would restrict access to the group of users who have been explicitly given “Allow to authenticate” access on the server in resource forest.

Authorization can be controlled on the resource forest by creating Domain Local Groups and assigning required permissions.

Above article discusses the aspect of configuring cross forest authentication using Active directory forest trust, watch out for 2^nd part of the series which discusses about the Single Sign on using Active directory Lightweight directory service

NOTE:The online meeting Add-On will match the 32bit or 64bit version of version of Office 2007/2010 installed, regardless of the Lync client architecture installed.

It is not uncommon in todays world that there are multi architecture clients (x86 and x64) running in the environment, and it is possible that you dont have any software or tool available to automate the software distribution with right set of bits to the clients, and it can be bit difficult to automate the software distribution using Group Policy as well, The rest of the document will demostrate how we can deploy Lync client 2010 in multi architecture environment using a simple batch file and GPO toghether

I will break this complete process in three parts, to make it look easy and undrestandable

1.  Preparing the environment

2.  Configure GPO to deploy the login script on client machines

3.  Deploy the software bits on the client via the configured login script.

Note: Installation of the client software would require a user to have administrator rights on the local machines, for that reason we will use computer startup script to deploy the software as the software will be installed using local system account which by default has permissions

As there are Windows XP, Windows Vista and Windows 7 clients in both X86 architecture and X64 architecture, we need to ensure that the right bits are installed on the clients, so we need to make the right bits available to clients.

• Create a file Share on your file server or any other server which is accessible from the network and users can communicate with, for example your file server “FileServer1” and name the folder and file share as “Client_Software_bits”
• Share the folder and give everyone read permissions on the share to ensure all users can read for this share
• Create two folders inside the folder create in step 1 and name them as Lync2010 and Office365
• Create two folders inside each of the above new folders and name them X86 and X64 respectively
• Now we will have a UNC path like
  • \\FileServer1\Client_Software_bits\Lync2010\X86
  • \\FileServer1\Client_Software_bits\Lync2010\X64
• Now though we have all the four UNC paths created and available for clients to access, copy the correct platform to the respective version of client software into the folders, X86 bit of client software to X86 folder and X64 bit of client software to X64 folder

• Check the file name for the client software, it might look like LyncSetupx86 or LyncSetupX64, rename the files to LyncSetup in both the folders to have common file name which will be used in script
• Test to access the shares from one of the client machines to ensure you are able to see the files in these folders
• The script also fires the results of the installation onto a file; in order for that to happen, an additional file share is required which must be accessible by all users and users must have create/write access which can be used to centrally track the installation success
• In the same file share, create a folder named "Client_deployment_results" on the file server and share the folder with everyone or to be more specific share the folder with Domain users and Domain Computers groups and assign “Create and Modify” permissions to “Domain Users” and "Domain Computers" groups
• The UNC path for the results folder would look like \\FileServer1\Client_Deployment_Results

The script is broken into 3 parts,

• This part of the scripts sets a condition about which platform (Architecture) software to install x86 or x64 and if the software is already installed exit the script

If Exist %systemroot%\%computername%.txt goto END
If Exist "C:\Program Files (x86)\" goto X64

Set ARCHITECTURE=x86

This part of the login script automates the creation of the respective folders under the user’s profile in the desktop

REM Creating Lync and office suite Client folder on %USERPROFILE%
IF NOT EXIST "%USERPROFILE%\Lync_Client\X86" MKDIR "%USERPROFILE%\Lync_Client\X86"

Note: Since we are using computer startup GPO to apply the script on the client machines %userprofile% refers to directory “C:\windows\system32\Config\systemprofile” on windows 7 machines and on windows Xp machines %userprofile% refers to the logged in users profile "Documents and Settings\Users", to manually check whether software bits are copied you need to check the respective directory as per your operating system

• This part of the script copies the required installation files into the folders created from the previous step.

REM Copying Lync software to Lync Software folder on %USERPROFILE%
pushd "\\fileserver1\Lync2010\Lync_Software\x86\"
XCOPY "*.exe" "%USERPROFILE%\Lync_Client\X86" /I /Y /Q

• This part of the script will setup the Lync2010 and Office365 suite silently and end user would not experience any GUI or any interferences.

Note: End users should still be informed that their computer is going to have a change so that users aren’t surprised to see the Lync, Silverlight, Visual C++ Distribution installed in their machine. Silverlight and Visual C++ distribution are pre-requisites for Lync2010 client and are installed automatically by LyncSetup.exe

"%UserProfile%\Lync_Client\%ARCHITECTURE%\LyncSetup.exe" /install /silent /fulluisuppression
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% > %systemroot%\%Computername%.txt
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% >\\fileserver1\Client_Deployment_Results\%computername%.txt

• The Login Script will first of all set the architecture to X86 and then check on the system if “C:\Program Files (X86)” exist, as this folder is available only on 64-bit machines with 64-bit operating system, if the condition is true then the script will set the architecture to x64, and then run the setup locally from the folders we created in first part of the script, Since we have set the architecture to either x86 or x64 and we are using variable %Architecture% in the command line to ensure the right bit of software is run, after the Lync2010 is immediately office 365 suite software will be installed.
• X64 bit portion of the script will follow the same process as above

:X64

If NOT EXIST "C:\Program Files (x86)\" goto END

Set ARCHITECTURE=x64

REM Creating Lync Client folder on %USERPROFILE%
IF NOT EXIST "%USERPROFILE%\Lync_Client\X64" MKDIR "%USERPROFILE%\Lync_Client\X64"
REM Copying Lync software to Lync Software folder on %USERPROFILE%
pushd "\\fileserver1\Lync2010\Lync_Software\x64\"
XCOPY "*.exe" "%USERPROFILE%\Lync_Client\X64" /I /Y /Q
"%UserProfile%\Lync_Client\%ARCHITECTURE%\LyncSetup.exe" /install /silent /fulluisuppression
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% > %systemroot%\%Computername%.txt
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% >"\\fileserver1\Client_Deployment_Results\%Computername%.txt"

:END
EXIT

• At the end of the script it will create two results files one in the local drive and one on the remote writable file, the environmental variable %COMPUTERNAME% is used to have text file created with the ‘machine_name.txt’ to keep the track.

To get the individual machines to run this login script, GPO is used to help enforce the Startup script to machines to run at startup.

• The startup script is the file that does the actual action. It could be almost any action, as noted above. Unlike the "old fashioned" method of using ADUC and the Profile tab of the users' account properties, the default location for GPO-initiated logon scripts is the deep within the SYSVOL special folder, which, by default, is shared on all Domain Controllers in an Active Directory forest, and is located in the following folder:

%SystemRoot%\SYSVOL\sysvol\<domain DNS name>\Policies\{GUID}\machine\Scripts\startup

• Where %SystemRoot% is usually “C:\Windows”, <domain DNS name> is the DNS name of the domain, ‘dc.capitaland.com’, and {GUID} is a hexadecimal string representing the GUID (unique identifier) of the specific Group Policy Object in use. This folder, which is a part of the SYSVOL special folder, is replicated to all the Domain Controllers in the domain. Each GPO has its own internal User and Machine subfolders, and under them it has, if used, a Logon, Logoff, Startup and Shutdown subfolder where appropriate
• Copy the logon script (CTRL+C) at the file level, during the creation of the GPO it will be necessary to paste the file into the UI.
• Startup and Shutdown scripts run under the machine credentials. It is recommended that the “Domain Computers” group shall be given permission to any resources used by either of these scripts. For example, if the startup or shutdown script writes to a log file, the group “Domain computers” should be given read/write access to the file or the folder where the log file is located.
• In order to assign the GPO and edit it, Group Policy Management console, or GPMC in short is used. This tool is not installed by default in Windows Server 2003, and neither is it installed by default in Windows Server 2008. In Windows Server 2008, GPMC is considered to be a "Feature", and you must install it before being able to use it. However, unlike in Windows Server 2003 where you must download and install the tool, in Windows Server 2008, GPMC is already a part of the operating system, you simply need to add it. If the Windows Server 2008 server is also a Domain Controller, GPMC will be automatically installed as part of the DCPROMO procedure. If it's not a DC, you'll need to manually add it.
• Open Group Policy Management Console from the Administrative Tools folder (or gpmc.msc from RUN)

• As described in the above paragraph, you decided to apply the script to ONLY a SPECIFIC SET of computers, expand the domain tree, locate the OU where the computers are located. Right-click the OU and select Create and Link a GPO Here 

 Note: It might be possible that a GPO already exists and it is linked to the object level you need. In that case you don't need to create a new GPO; you can use the existing one

•   In the New GPO window, give the new GPO a descriptive name, such as "Client Logon Script GPO". Click Ok 

• If you don't see it already, refresh the GPMC view and find the new GPO you've just created under the OU
• When you click on the new GPO you might be prompted with a message window. Click Ok 

• Right-click the new GPO and select Edit 

• In the Group Policy Object Editor window, expand Computer Configuration > Windows Settings > Scripts 

• Double-click Startup in the right-hand pane
• In the Startup Properties window, click Show Files 

• A window will open. The path will be a folder similar to the following: \\domain.com\SYSVOL\testdomain.com\Policies\{Guid}\machine\Scripts\startup. Paste the logon script you've copied in the previous part of this article. Close the window
• Back in the Logon Properties window, click Add 
• In the Add a Script window, click Browse and you will see the logon script step #11. Whatever you do, DO NOT manually browse for the file, it should be in front of your eyes. If it's not there, check the previous steps for a mistake. Click Ok

• Back in the Startup Properties window, see if the logon script is listed, and if it is, click Ok 

• Since we are targeting multi Architectural environment where we have windows xp, windows vista, and windows 7 machines, on windows vista and windows 7 machines “User Access Control” feature is enabled by default and any installation would require administrator to allow installation, to silently install the software we would need the feature to be disabled using GOP, follow the steps below

• In Group Policy Management Editor expand Security SettingsèLocal PoliciesèSecurity Options
• In the right hand page scroll down and locate User Account Control:Behavior of the elevation prompt for Administrators in admin approval mode, double click on the option and click on check box Define this policy and from the drop down menu select Elevate without prompting and click OK

• Next locate User Account Control:Run all Administrators in Admin Approval mode, double click on the option and click on Define this Policy and select the option Disable, click on OK
• Close the Group Policy Object Editor window
• Close the GPMC window

To replicate the DCs in the domain by using either Active Directory Sites and Services, Replmon, Repadmin, or wait a few moments (depending on the number of DCs). As a simple follow up to this article, I suggest you use Active Directory Sites and Services.

• On one of the computers that is part of the domain, logoff the specific user account
• Logon and test. If you don’t see the client software installed after about 15 minutes, go to command prompt

• Type following commands, this command will generate a report where you can see whether the policy is applied on the user or not, if you don’t see the policy applied type following command
  • C:\>GPresult  /H: >C:\gpresult.html  /Scope:Computer (windows 7)
  • C:\>Gpresult /Scope:Computer >C:\Gpresult.txt
  • To force the GPO update on the client machine apply the following command, logoff and login again to test
    • C:\>Gpupdate /force
•  It is possible sometimes logon process completes but the script doesn't run properly, it can happen on clients running windows xp, or later running on fast network, the first thing to look at would be the event viewer at client machine and you can also look at the longon process logs Userenv.log file which is located in %systemroot%\debug\usermode directory, to enable debug loggin refer to article https://support.microsoft.com/kb/221833

Please post your comments and feedback on this post, shall you have any questions regarding this please post the questions in technet