The upgrade process is based on the fact that multiple releases of VDS can be installed at the same workstation, at the same time. New versions get installed in their own directory adjacent to the rest, so that the user can choose which Administration Console to start, and quickly switch from one to other.
It's even possible that instances from different versions run at the same time. The only requirement is that no instance listens on the same ports as any other, but this is also required for different instances within the same version.
In Windows, a new folder is also created in the Start Menu. All shortcuts that were created manually will also need to be manually updated to point to the new version.
These instructions assume the upgrade is performed from a recent version of VDS (6.0.3 or later). Older versions (such as 5.5) may need additional steps; more information can be found in other solutions from the Knowledge Base
We highly recommend that, for production instances, the upgrade is first performed and tested in a proper testing environment.
1) Locate the configurations that should run in the new version
2) Install the new version normally, using the installer
3) Open the Admin Consoles of both old and new versions
4) Follow the next steps for each configuration to be upgraded:
Open the old configuration in the old Admin Console; check it is running normally and receiving traffic.
Windows: Go to "Global Parameters -> Running Parameters" and make sure "Lock Windows Service Details" is unchecked, so that the service is uninstalled when the instance is stopped
Copy the instance to the new release. There are two ways you can do this:
Export the instance in the old Admin Console and import it in the new one (preferably including passwords and not logs)
Copy the whole configuration folder from the confs directory of the old version, to the confs folder in the new one (optionally, delete all logs under the logs folder)
Open the new configuration in the new Admin Console
It is recommended to perform a visual inspection to check that everything present in the old configuration still exists in the new one (plugins, values in different sections, etc.)
If applicable, review passwords in connection pools, and use the test button to verify
If applicable, review SSL certificate paths of Listeners and DataSources (they might need to be updated to the path of the new version)
Save the configuration. To be fully sure it is updated go to Global Parameters, click on Ok, and then save it
Go to the old Admin Console and stop the old instance. You can choose between normal stop and "Graceful Shutdown", which might make the process more smooth for applications that are currently sending traffic
Go to the new Admin Console and start the new instance
Take some time to monitor logs and traffic to check that everything runs well with the new instance. If you experience any trouble, you can follow the Rollback steps below
5) Once this process has been followed for all the configurations, the upgrade process is complete. At this point you can choose between uninstalling the old version of VDS or leave it in the system. We recommend that it is uninstalled after a while, when it's certain a rollback will not be needed, so that in the future there is no confusion between the two versions.
If by any chance one or more configurations start misbehaving after the upgrade (either right after the process or later in time), they can be quickly rolled back to the old, running version with these steps:
1) (If needed) Open the Admin Consoles of both old and new versions
2) Follow the next steps for each configuration to be rolled back:
(If needed) Open the new (misbehaving) configuration in the new Admin Console
Windows: Go to "Global Parameters -> Running Parameters" and make sure "Lock Windows Service Details" is unchecked, so that the service is uninstalled when the instance is stopped
(If needed) Open the old (working) configuration in the old Admin Console
Go to the new Admin Console and stop the new instance. You can choose between normal stop and "Graceful Shutdown", which might make the process more smooth for applications that are currently sending traffic
Go to the old Admin Console and start the old instance
Check that everything is running as it used to do in the old instance
3) Analyze the logs and any other information available to find out what caused the problems with the new version. If needed, contact Support to open a case and include all this information (at least the configuration itself and its logs)
VDS is a 32 bit application, which sets a limit on the amount of memory it can address. This solution describes the maximum amount that can be expected depending on the OS.
While 64 bit applications can address more than 4 GB of memory, 32 bit applications can only address up to 4 GB, but depending on the OS this limit can be even lower.
It's important to know the memory limit because VDS will typically restart with code (b370:40) when it is reached. However, the limits are high enough so that they should never be reached with a normal use:
In Linux (32 & 64 bits), VDS can manage up to 4 GB of memory.
In Windows (32 & 64 bits), the limit is set to 2 GB by the OS (See Memory Limits for Windows Releases). VDS versions after 6.1.0 will be compiled with the LARGE_ADDRESS_AWARE option to overcome this OS restriction, so that the natural limit of 4GB can be reached as well.
This chapter describes how to integrate VDS with other products from Dell Software to support additional functionality.
VDS listeners can accept different protocols for example HTTP, Radius and also LDAP, which is the most commonly used. SAML is not a protocol that is supported natively; however this can be accomodated by using Dell One Identity Cloud Access Manager.
Cloud Access Manager understands SAML and is able to carry out all required operations using LDAP. By placing it between VDS and client applications, they will be able to perform SAML authentication, authorization and Single-Sign-On.
More information is available at the following link: http://quest.com/products/cloud-access-manager
As starting point we will take a VDS instance that provides a fully virtualized environment. This is typically achieved by combining the Virtual Tree functionality with plugins such as MapDNValues, to make sure that the data seen by the client applications conforms to a coherent virtual view. It may also involve access to a database, for example to obtain additional user information.
The different applications are, by using LDAP protocol to connect to the instance, able to carry out authentication and authorization. From the VDS point of view Cloud Access Manager will be one of these applications, however by having Cloud Access Manager in the forefront; the environment will have SAML available as an authentication method in addition to LDAP.
It is possible to install Cloud Access Manager on the same machine where VDS is running if it fulfills Cloud Access Manager's requirements, nevertheless it is equally possible to install Cloud Access Manager on a different machine provided they have network connectivity to each other. For more information on a Cloud Access Manager installation, please refer to the appropriate product documentation.
As explained in the previous section, Cloud Access Manager will communicate with VDS using LDAP.
In Cloud Access Manager you need to configure VDS as a Front-end Authenticator. For this you will need to provide information on both the VDS location (for example hostname or IP address and port) and the data layout (for example search base, objectclasses and attributes). As VDS typically behaves as an LDAP proxy, the setup is highly dependent on the actual directories used as a backend, although it is possible to set up VDS functionality to fully manipulate this data.
Once this has been completed, users from the multiple Data Sources behind VDS will be able to log in to the Cloud Access Manager Application Portal.
It should be noted that in order to authenticate each user Cloud Access Manager will send several different LDAP operations to VDS and the VDS setup must be ready to process them all. They typically involve the following:
LDAP Bind as the service account of Cloud Access Manager
LDAP Search for the user with the Login Name that was entered
LDAP Bind with the actual user DN and Password that was entered
LDAP Search for the user data
LDAP Search for the groups that have the user as a member, for authorization.
Authentication may fail if the VDS configuration is unable to properly process any of these items. For example credential validation could be working correctly but a problem in the authorization query might result in a failed authentication. VDS logging plugins such as Operation Dumper or Access Log can be used to verify that all operations are returning the expected results.
The client application will behave as a Service Provider (SP), while Cloud Access Manager will act as an Identity Provider (IdP). The protocol can be either SAML 2.0 or WS-Federation (which uses SAML 1.1 tokens).
Cloud Access Manager will require a new application to be configured with an SSO method using SAML as a backend. This can be done by importing the SP metadata, or by providing the individual sections of information for example endpoints and certificates.
In addition the SP side will require a similar setup, which can be completed by importing the Cloud Access Manager IdP metadata (if supported) or by configuring endpoints and certificates.
Multiple Service Providers can be added to the system using the same method.
There may be some variation, but once everything is set up the basic user experience is as follows:
The user opens a web browser and goes to the client application (SP) landing page. For authentication the browser is eventually redirected to the Cloud Access Manager (IdP) login page, carrying an embedded SAML Authentication Request message issued by the SP. Once a user provides their username and password, Cloud Access Manager will initiate a behind-the-scenes process to validate their credentials and obtain user data.
This process involves Cloud Access Manager sending a number of LDAP operations (for example Search and Bind) to VDS. These will be transformed by VDS to manage virtualization and adapt them to multiple back ends. As virtualization works both ways VDS will also transform the responses before they reach Cloud Access Manager. Once this process has completed, Cloud Access Manager will create a SAML Authentication Response / Assertion / Token with the combined result of the authentication and user data and direct it to the SP. These interactions are transparent to a user and work in a similar way if the SP-IdP communication is using WS-Federation protocol instead of SAML 2.0.
Finally, the SP will process this information. This will result in the user logged in at the application, which will now have the additional identity data to carry out its service.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Feedback Términos de uso Privacidad Cookie Preference Center
