Problem solve Get help with specific problems with your technologies, process and projects.

Make sure you proliferate security settings on multiple Citrix servers

Learn why you should proliferate security settings on multiple Citrix servers.

This tip was submitted to the SearchSecurity Tip Exchange Contest by user Louis Caron. Let other users know how useful it is and help Louis win a prize by rating the tip below.

Our company has a safety program that keeps monthly statistics of all sub-trades on all our job sites across Canada and USA. The same front end of the application is on the C:Program Files on three Citrix servers. The back end and one security file (mdw) are kept on a common drive accessible by all three Citrix servers. Each Citrix server runs Windows 2000 and each client (150) runs Windows NT4. The users log in to Citrix servers with their Novell 5 log in.

The front end of the application has a login screen and each user who logs in has different rights depending on which group and geographical area he belongs to in security file.

The application was originally developed on my local C:Program Files/Safety, then placed in the same location (C:Program Files/Safety) on each Citrix server and worked perfectly in each location. The security mdw file was always in the same location in our network, whether accessed from my local C: or Citrix servers.

Each time I made a minor modification to front end of the application on the front end in Citrix server # 1, I copied this revised front end to Citrix servers #2 and #3. I discovered that on the Citrix server where the original changes were made, the front end worked correctly. On the other two Citrix servers, however, the revised front end the change was copied to behaved erratically (they worked fine before). Many of the forms showed only the command buttons. The areas on the form and subform that housed the text boxes, combo boxes, labels and data were completely blank.

When we reviewed the security rights from the original Citrix server #1, where the front-end revisions were originally made, and found that the security on the tables was correct (Read, Write, Insert and Delete). When we checked the security file from a Citrix server (#2 or #3), to which the front end was copied, the security on the tables was "Read" only for all users and groups on all tables, even though all Citrix servers were looking at the same security file.

When I corrected the security rights on Citrix server #2 through the local front end, the front-end application worked correctly locally, but failed to work from the original Citrix server #1 where it had worked fine before; same for Citrix server #3. This happened as well when the rights were corrected on Citrix #3; after that Citrix #1 and #2 failed to work properly. The security rights only worked on the Citrix Server where the rights were initially applied.

It appears that when a revised front end is copied from a Citrix server to another Citrix server, and is linked to a common back end and security file, the rights for all users in all groups for all tables for the Citrix Server receiving the copy default to the rights of "New Tables/Queries" which is, by default, "Read" only, not the rights previously given to selected tables. The front end on the receiving Citrix serversloses the rights it had before and the rights become the default rights for each "new" object (table, query, form).

The solution was to increase the rights of all "New Tables/Queries" to Read, Write, Insert, and Delete or to make the front end changes on my local C: then copy directly to each Citrix server (not from Citrix server to Citrix server).

When this was done the application would perform perfectly in all locations.

This was last published in March 2002

Dig Deeper on Information security policies, procedures and guidelines

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.