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 of 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 of 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 of 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 other 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.
Recommend
More recommend
