Workspace Streaming

 View Only

Working with Symantec Workspace Streaming and Active Directory/LDAP 

Sep 30, 2010 12:08 PM

Active Directory is by no means a small area to cover, but I thought it would be important to discuss what functionality is supported when it comes to AD connections. One of the product features is the ability to establish a connection to the Active Directory and provision applications to users and user groups on the domain. Depending on the size of your organization, you may be looking at more than just a single domain. However, when you configure the connection you will notice that today the product connects to one domain and enumerates objects from there. The default configuration used by SWS for the search filter is subtree scope. This is a function provided by Microsoft and what it does is allows for a query/response from all domains starting with the Root at which a user account was provided to establish the AD connection. There are three different search scopes, but we use subtree as it provides the largest search scope. For more detail regarding search scope, please see this article on MSDN. http://msdn.microsoft.com/en-us/library/aa746467%28VS.85%29.aspx

I thought that in addition to covering our officially supported connection, I would cover the non-supported as well. The reason I want to do that, is so that everyone can get a bird's eye view of the difference when working with this configuration in their environment.

Requirements

  • Implementation in a single-forest architecture
  • Global Catalog: The GC is a server on the AD that collects details about users and groups from all domains in the same forest
  • Two-way Transitive Trust: This provides a "pass-through" trust between multiple domain parents and child domains without explicitly creating a trust between all the domains. If you create a two-way transitive trust between domainA.com and domainB.com and domainC.com, any domains that have a trust with the parent in their respective domains will inherit the transitive trust

SUPPORTED

  • Parent child domain tree in a single-forest: This consists of a single domain parent and one or more child-domains
  • Global Catalog should be enabled on the parent domain and the Streaming product should be connected to the GC on port 3268
  • The search base should be at the tree root (parent domain). This is accomplished by supplying a user account at that level for the connection
  • Provisioning should be done using Universal Security Groups. This will allow you to provision to one group for users/groups across domains

How to confirm the GC has replicated objects from other domains

  • Log on to any machine on the domain with a domain admin account
    • If you have a large organization with many objects in the AD (Active Directory) you should probably run this directly on the DC (Domain Controller) that has the GC (Global Catalog). Otherwise you'll be taking up bandwidth for the duration of this process. Plus, running locally as opposed to over the pipe will provide quicker results
  • From the command line: Dsquery * -gc -s ServerName -limit 5000 > c:\results.txt
    • Replace 5000 with a higher number if more objects exist. There is no special significance to -limit 5000. It's just the number I chose for my example.
    • -gc is used to query the global catalog.
    • Make sure "ServerName" contains the host name of the GC
    • Open c:\results.txt and see if all needed objects are listed. If your domain structure is correct than you should see objects from all domains. If you only see the objects in the parent domain, it's possible replication hasn't happened yet. Did you just enable the GC? If it has been enabled for more than 24 hours and objects are not showing up, you should review your domain configuration to verify everything is configured as needed.

Provisioning Best Practice

In this type of configuration, provisioning should be done in the following manner:

  • Create one or more Universal Security Groups in the parent domain
  • As needed, add Parent/Child domain users/groups to the Universal Security Group(s) you setup
  • Provision packages to the Universal Security Group(s)

Example

  • Parent domain: parent.com
  • Child domain: child.parent.com
  • Streaming Backend installed on a server which is a member of parent.com
  • Streaming Frontend installed on a server which is a member of parent.com
  • On the parent.com domain create a Universal Security Group and add users and/or groups from both parent.com and child.parent.com
  • Provision applications to this Universal Security Group

There is one exception. In the same example as above, if the domains are not setup as parent child but are in the same forest you can still provision to users/groups in other domains as long as the two-way transitive trust is in place and on the Streaming Management Console you null out the Search Base.

  • Open the Management Console
  • Click User Data Source under Configuration in the navigation panel on the left
  • Select Edit current settings(recommended) and click Continue
  • Delete the Search Base and leave the field blank (Fig. A)

Fig. A

What is NOT supported?

It is important to keep in mind that Symantec Workspace Streaming just like any other application is subject to available functionality and enforced security that Active Directory has built in. Once connected to a domain, SWS enumerates users and groups from that domain using the supplied user account on that domain. SWS can't simply connect to one domain and discover others and fetch information without meeting security requirements. For example, if the domains don't have a two-way trust it is not possible to read information from another domain, even if you use a domain admin account that is not on said domain. To accomplish what is described above, SWS requires that the functionality provided by Active Directory to enable inter-domain connectivity is setup. Furthermore, a server has to act as the GC so that it will contain user/group information from other trusted domains. At this point SWS can connect to the GC on port 3268 and will be able to read whatever is available on the GC. This is not a function of SWS, and SWS will only be able to enumerate whatever information is available on the GC. When this connection is established but the objects enumerated are not as expected, the AD configuration needs to be reviewed to troubleshoot why the GC is not collecting information from other domains.

So what is not supported today? The Global Catalog is designed to collect information from a single forest. What this means is that any server that is a member of Forest A can be read by the GC. However, Microsoft does not have functionality to read the same information from domains in Forest B. Even if the parent domains in Forest A and B have a two-way trust. So when SWS connects to the GC on Forest A, it will only get the information contained there. It will not get user/group objects in Forest B. The reverse is true as well. In a multi-forest architecture as described here, a separate Streaming installation is needed on Forest A and Forest B to be able to provision and stream applications to users/groups in both.

Using the dsquery example provided above will show that only objects in one forest show up in the GC queried. Since Microsoft does not provide this functionality, SWS is not able to establish the needed connection from a single Backend.

Supported Architecture

Not supported Architecture
Requires SWS installed on both Forests

Sometimes the network admin is not available to provide answers you need about architecture. In many large organization, the group implementing SWS is not the same group that manages the network and you may be faced with the question of how do I determine if our network is a single or multi-forest architecture? Here is a simple way.

Copy the following into Notepad.exe and save it. Rename the file with a .vbs extension (i.e. checkForest.vbs). Place a copy of the file on a computer at each of your sites and double-click it. You will get a pop-up that shows you the Forest root domain.

Set objSysInfo = CreateObject("ADSystemInfo")
Wscript.Echo "Forest Root Domain: " & objSysInfo.ForestDNSName

Once you have the name displayed on all the sites, it becomes simple math. If the domain name is the same everywhere, you have a single forest.

The script uses Wscript Object which is part of Windows Script Host. You should be able to run it from any path. Below is a link for more details regarding Wscript.

http://msdn.microsoft.com/en-us/library/at5ydy31(v=VS.85).aspx

Statistics
0 Favorited
0 Views
4 Files
0 Shares
0 Downloads
Attachment(s)
doc file
SWS_AD_Connection.doc   180 KB   1 version
Uploaded - Feb 25, 2020
jpg file
swsad-01.jpg   29 KB   1 version
Uploaded - Feb 25, 2020
jpg file
swsad-02.jpg   35 KB   1 version
Uploaded - Feb 25, 2020
jpg file
swsad-03.jpg   28 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Oct 03, 2010 04:29 AM

Great Read.. LDAP simplified...!

Oct 01, 2010 03:48 PM

Nice Article cool

The last part .....

Good to use when u don't have admin to get the stuff needed and to debug whacky n/w issues

Related Entries and Links

No Related Resource entered.