Identity Manager 2.0 and Citrix MetaFrame Presentation Server 3.0. - - PDF document

Identity Manager 2.0 and Citrix MetaFrame Presentation Server 3.0.

Introduction

Identity Manager 2.0 is a very powerful and far reaching technology which can provide the ability to use eDirectory as a MetaDirectory source to many different operating system and applications. In the context of a Citrix Implementation, Novell Identity Manager 2.0 has the potential to completely change how the technology deployed and implemented.

The Citrix Authentication Tree (CAT)

Introduction

With a Corporate eDirectory implementation with respect to a medium to large size company the directory design will be partitioned and replicated to allow for separate geographical locations. Corporate implementations may in all probability be running multiple versions of the server operating system and the directory service. Upgrade schedules both with respect to Server OS and Hardware tend to have limited windows when they have a direct impact on the line of business corporate environment. A number of separate factors may combine to make implementing Citrix Integration to the Corporate Tree unworkable. In general Citrix Farms implementations tend to be based at one geographic location with a Citrix Farm being split over multiple sites only happening with the largest installations. This can be at odds with a geographically dispersed heavily hierarchical corporate Novell directory environment. One possible solution is the concept of a Citrix Authentication Tree, synchronised to the corporate environment via Identity Manager 2. This can present a best of both worlds solution which allows for the Citrix Tree to exist at limited geographic locations whilst having to carry out minimal change to the corporate environment to support the synchronisation of account information. This scenario would allow for the synchronisation of user and group information between the trees (including passwords) and allow the administrators to provision a user account with Citrix Applications just from within the corporate

• tree. IDM2 would then synchronise the changed information to the Citrix Tree.

Challenges of the Solution Access to Corporate Tree Resources

Even though a user is authenticating to Citrix via the ‘Citrix Tree’ there may still be a requirement to access corporate tree resources such as mapped drives and printers.

Access to Corporate Tree Mapped Drives

The users login script in the ‘Citrix Tree’ can be made to refer to the corporate tree by the use of the TREE command. This command can take an eDir user attribute as a parameter. This attribute would be created via IDM2 and held against the user object. The contents of this attribute would be created when the user is first created in the Citrix Tree. The attribute would hold the context

• f the user within the Corporate Tree. This information when used as a

parameter to the Tree command would allow the transparent authentication of the user to the Corporate Tree from within the Citrix Session. The Tree command is always supplied in pairs. The first tree command would switch the context of the login script to the Corporate Tree. Any use of environment variables such as %HOME DIRECTORY would refer to the users home directory within the Corporate environment. The use of the Tree command (even though the user has authenticated via the Citrix Tree) allows the users environment to appear the same from within the thin-client session as from normal workstation access. This access to Corporate Tree resources could also be managed by group so that no mappings take place if the user was not a member. This also has the benefit

• f putting another layer of security between a user and the Corporate Tree.

The extra advantage of this solution is that the profile directory for the Citrix/Terminal Server connection is held within the Flat Authentication Tree and not in the Corporate Tree. Since the AUTH Tree is at the same physical location as the Citrix Server Farm there is never the situation that a user will have to pull their roaming profile from a server that is remote from thee Citrix Server that is hosting their session. Also the Corporate Tree does not have to worry with regards to holding any Terminal Server Profiles and is just responsible for providing a Citrix User with their 'normal' drive mappings.

Access to Corporate Tree Printers

Many printers within a corporate environment are connected via a dedicated print server box of some description. This would allow IPRINT from the ‘Citrix Tree’ to refer to already installed printers within the Corporate Tree via LPR/LDP type functionality. This also gives the option of limiting the scope of network printers available from the thin client session.

Provisioning Users and Applications

Using IDM functionality this will allow users and their attributes to be synchronised from one tree to another in accordance with pre-defined business

• rules. This synchronisation includes all password related information. This

would allow the management of users purely within the Corporate Tree. Groups can be synchronised in a similar manner which would allow the creation

• f a Citrix Access group and individual groups to grant access to applications

just within the Corporate Tree. This Citrix Access Group would only allow the creation of a synchronised Corporate Tree user within the Citrix Tree if the user was a member of the group. Access to application would operate in the same way. Applications objects would be the most difficult to manage in this scenario. This would involve the creation of a Citrix Published application within the Citrix Tree. Within the Corporate tree a ZEN application would also have to be created from an application template object as described in the 'Building a Better Mousetrap section' and pointed at the Citrix Published Application in the

• ther tree.

Benefits of the Solution

This solution would allow the deployment of a Novell Integrated Citrix environment in parallel to a companies existing Corporate Tree. If the Corporate environment requires extensive updates with respect to Directory Service and OS version the implementation of a IDM2 synchronised solution would involve much less work within the Corporate environment. Many companies Corporate Trees are responsible for the provision of critical line of business applications and unless issues exist customers are justifiably wary of extensive changes. Also to be considered is that many Corporate Trees are geographically replicated and partitioned, whereas a Citrix Farm tends to be based at one

• location. Whilst many Citrix Farms have been successfully integrated with

existing Corporate Trees the structure of the existing tree may not be best suited to the integration. The other big benefit of the solution is that users within the CAT are in a much flatter structure than the corporate tree and as such the Citrix Servers could be hard coded to look at one particular context only for all user authentication. If the requirement is also to allow external access to the Citrix Farm via the Internet this architecture can provide another layer of security for users from the outside world. The user will only make a connection to Corporate Tree resources if they have first successfully authenticated to the Citrix Tree and that the user has the group memberships required for an authentication to the Corporate Tree even to be attempted. The CAT also breaks the one-one link between Citrix Farms and eDirectory. It use to be the case that if you had two trees you would require two farms. No

with this concept any number of separate eDir trees could talk to the one Citrix Authentication Tree.

Synchronisation of Zen Application Objects to Citrix Published Applications

Introduction

This section of the document details a work in progress at the moment that should be finished in the April to May 2005 time-frame. The aim of this functionality is to utilise IDM 2 to link eDirectory to the Citrix IMA Data Store and therefore allow the majority of application management operations to be carried out through ConsoleOne. There is no reason why this work cannot be applied to iManager except that the Zen snapins are not available for iManager at this time. This work is based on a custom produced IDM driver that allows information to be stripped out from an eDirectory event and that information be used as parameters for a defined command on the remote system. This driver is java based and as such is not just applicable to windows systems The custom driver can be triggered by defined eDirectory events and those events can call custom code on a Citrix Server that is part of the Farm. The custom code is based on VBSCRIPT calling MFCOM which is the Citrix Server side

• API. This api exposes almost all of the management functionality available

through the Citrix Management Console. The end result is that the creation of an object in eDirectory can automatically create and manage a Citrix Published

• Application. The other components of this solution are:

1. Schema extensions to handle Citrix Published App properties, Citrix Farm Object and a Citrix Server Object. 2. A ConsoleOne snap-in written using the Advanced Snap-in tool that is freely downloadable from Cool Solutions.

Managing Citrix Through ConsoleOne

Through the use of an axillary class placed on the Zen Application Object Citrix Published Application information can be held on that object and subsequently synchronised to Citrix via IDM 2.

Creation of a New Published Application

Creating a new published application uses the same process as any other Zen Application object.

The application is created as a simple application and not as a Terminal Server Application. The name of the object will also serve as the Citrix Published Application Name.

The application object is associated in the same way as any other Zen Application Object. The synchronised Citrix Published Application will have the same Associations. Once finish has been selected on the final screen examine the newly created application object. At this point it is just an empty object with an assignment to a container in e-directory. For this object to be synchronised to Citrix the Published Application information is required to be filled in.

The previous screen shot shows the Citrix Published Application snap-in that has been created with the ConsoleOne Advanced Snap-in tool. This allows you to enter Citrix specific attributes that are used to manage and synchronise the

• bject. On the previous screen there exists a dialog for assigned servers. When

the add button is selected the following dialog box is displayed This dialog box shows the Citrix Farm and the servers that exist within the

• farm. All of these objects are defined in eDirectory with two schema
• extensions. This dialog allows the selection of the servers in the Farm that host

the published application. Once this has been completed then the synchronisation process starts and the application will be added to the Farm.

The previous screen shows the CMC with the newly synchronised application.

Looking at the Farm Object in eDirectory

Through the use of extensions to the schema a Farm Object has been added to

• eDirectory. This object has been created as a container for Citrix Server objects

which have also been created as a new class in the schema. These objects at the moment are manually created to match the information in the Farm but in future a periodic process will run which will interrogate the Farm and update the server objects in eDirectory. If you examine the properties of a Citrix Server object the following screen is displayed.

This show the Published applications that have been assigned to a particular server and will allow the removal of a Published Application from a Server.

Practical Benefits of Synchronisation from eDirectory to Citrix Introduction

A colleague within Novell Consulting paraphrased the work here in the following was ' Cool but what does it actually mean?' This section is an attempt to answer that particular question.

Ease of Administration

ConsoleOne becomes a standard front end for the help desk. The use of the Citrix Management Console whilst not eliminated can become substantially less for day to day help desk personnel.

One Object for Both environments

Combining this piece of work with the section on launching applications gives us the following possibility. The same Zen Object could be used to control both how the application will be displayed through NAL and how Citrix WebInterface displays and executes the application.

edirectory for Farm Fault Tolerance

Since the objects held in eDirectory synchronised one way from eDir to the Citrix Farm the following scenario becomes a possibility. If the Farm is destroyed a clean Farm could be rebuilt and the IDM Driver told to do a re-sync. This will have the effect of putting all of the Published Application Definitions back as they were with the correct user assignments.

NAL/Myapps as a Multi Farm Application Launcher

Since the Farm is an object in eDirectory, the possibility of multi-farm support also arises. In this scenario there would be one instance of the IDM Driver per farm and this would allow NAL to be used as a tool to both display and execute Published Applications from multiple farms.

Eradicate Some of the Citrix/Novell Integration Issues

Without IDM the following issue can arise in a Novell Integrated Farm. A Citrix Published Application is assigned an eDirectory group to identify the users of the Published Application. This eDirectory group is later moved or deleted. The Farm cannot resolve the change and so can only make the entry invalid. This is shown through the CMC with an assignment made up question marks. With IDM the deletion of the group is an event that eDirectory picks up on and flags the event to the IDM Driver. The Driver then forces the ACL List on the back-end Citrix Application to be re-written using eDirectory as the legitimate source. eDirectory has inbuilt referential integrity which means that any object being moved or deleted is automatically resolved by the system. This capability can enforce the correct resolution of object moves/deletes that are used to assign users to Citrix Published Applications.