Post to Twitter
As many of you who follow my blog postings will realize, I love talking about Provisioning Services
- Provisioning Services Best Practices (6, 5, 4, 3, 2, 1, plus more to come)
- Quickly deliver XenApp Servers with Provisioning Services
- Use Provisioning Services to Create XenApp Swing Servers
I've spent a significant amount of time discussing best practices for integrating XenApp and Provisioning Services and thanks to many of you and your questions, I've been able to create and define new best practices; all of which will make it easier for you two simplify you XenApp environments.
If you are still wanting more information on the Provisioning Services for XenApp, then I highly recommend you attend this recently released TechTalk. For those of you who have attended my TechTalks before, my goal is to explain the how's, the why's and the when's for creating a solution of your own. This TechTalk is no different as I go through the following topics
- How Provisioning Services overcomes many of the ongoing challenges associated with XenApp environments
- How to create and deliver a set of XenApp servers with Provisioning Services
- How to design a Provisioning Services solution while following recommended best practices
Who do I recommend that should watch and listen to the TechTalk? Well, the following is a good idea:
- Anyone who is trying to design a Provisioning Services for XenApp environment
- Anyone who has heard of Provisioning Services and thought it sounded intriguing
- Anyone who has a XenApp environment and wants to makes management easier
- Anyone who knows already knows a lot about Provisioning Services. You might learn something new, or you might be able to provide me with some of your thoughts/insights.
After watching the TechTalk, feel free to post a question or comment on this blog as I'm always interested in hearing your thoughts, suggestions and recommendations.
BTW, you can reach me on Twitter at http://www.twitter.com/djfeller or on the blog site http://community.citrix.com/blogs/citrite/danielf
So, set aside 60 minutes, grab some food, go to this TechTalk link, sit back, relax and enjoy.
Daniel - Sr. Architect (Worldwide Consulting Solutions)
I interviewed Glenn MacDonald for this topic. Glenn is a Senior Software Engineer at Citrix. He has been with Citrix since 2003 and has worked on every release of Password Manger. He has a Masters degree in Computing Science from Simon Fraser University and over fifteen years of software development experience. The interview did not actually take place on the yacht, below. 
Q: When did CPM begin to provide provisioning?
A: The CPM Provisioning feature was introduced during the Nassau release in 2005. The intent of this feature was to empower CPM administrators with the ability to provide users' secondary credentials directly to CPM, rather than forcing users to do so. Being unable to do this had been an administrator pain point during CPM roll outs and when new applications were added to deployments.
In a sense, provisioning in CPM provides additional security, in removing the responsibility from users for providing secondary credentials, as users tend to do things like write down their passwords before entering them.
Provisioning in CPM increases the security by avoiding the initial distribution of credentials details directly to the user. Typically this is done by a less secure method such as a memo, voice mail or email.Another focus of the feature was to provide a means to integrate with existing identity management and provisioning systems (e.g. Courion Account Courier).
Q: Does CPM provisioning set up user accounts in applications?
A: No, it just informs CPM of the users' the credentials.
Q: How does it work?
A: The new web service (the Provisioning service) responsible for receiving the provisioning commands was added to the CPM Service. These commands are added to a per-user queue located in the user specific container of the central store. Eventually the Plugin executes the queued commands to complete the provisioning action.
Q: Is it really that simple?
A: Of course not! There are lots of details to do this securely, but that's the basic flow.
Q: Can you elaborate on those security details?
A: Recall that the CPM Plugin protects a user's credentials using user specific keys. (i.e. Only the Plugin running in a user session can obtain the keys). This implies that it is impossible for the Provisioning service to directly execute the commands and alter the user's central store data. (i.e. the service can't add a credential because it doesn't have the key to protect the secrets). This is why the commands are queued until a Plugin running as the user requests them. The service is completely responsible for the life cycle and encryption of the queued commands.
The Plugin does not directly access the queued commands - it obtains them from the Provisioning service over an SSL connection. Once the Plugin has successfully executed the commands, it informs the service that the queue can be deleted.
Q: Is the provisioning feature standards-based, since there are many provisioning products out there to integrate with?
A: As a matter of fact, it is. To ease third party integrations, we opted to use the SPML V2.0 open standard. The Service Provisioning Markup Language (SPML) is an XML-based framework, developed by OASIS, for exchanging user, resource and service provisioning information. Additionally, many identity management systems already support SPML 2.0. A connector is required for identity management integration.
Q: Why do I need a custom connector if my identity management system already supports SPML 2.0?
A: To understand why a custom connector is needed, you need to consider the conceptual differences between provisioning for CPM and provisioning in general.
Consider a typical provisioning scenario from the perspective of an administrator of an identity management system. A new employee has joined the company and needs to be provisioned with a domain account and specific accounts for SAP, Outlook, etc. The administrator will request that an SAP account get created. To do this, the identity management system will send a message to the Provisioning Service Provider (PSP) for SAP.
"Hey SAP PSP, create a new account with user name=baracko and password=prez"
The Provisioning Service Provider will create the account and return a reference ID for the account.
Next, the administrator would want to provision CPM with the newly created SAP credential. The message that the CPM Provisioning Service needs to receive must say:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for SAP having the user name=baracko and password=prez"
First, notice that provisioning from the CPM perspective is simply providing the user with his CPM secondary credentials. There is NO creation of the accounts accessed with those credentials. Those accounts must be created by an outside means completely separate from CPM. Essentially, CPM provisioning is the act of populating the user's credential store - i.e., the administrator is populating a small data store and not actually provisioning accounts or resources.
Q: I sort of see what you mean. The CPM provisioning command added the SAP credential for the specified domain user, it didn't actually create the SAP account. How does CPM know what "SAP" refers to in the command?
A: Good, you've noticed the second subtlety. Ultimately, the goal is to have CPM submit this credential when it detects to the SAP logon page. To achieve this, the credential needs to be associated with a specific application definition.
A unique GUID is assigned to every application definition when it is created in the CPM Administrative Console. This GUID is included in the command to provide the link between the credential and the application that the credential is for. So, the message actually needs to be:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for GUID-of-SAP-application-definition having the user name=baracko and password=prez"
The connector needs to provide the mapping between the application definition GUIDs and the credentials.
Q: How does the custom connector learn the application definition GUIDs?
A: To determine the list of applications definitions available to a user, the connector needs to send a lookupApplicationRequest. The response to this will contain a list of the applications defined in the User Configuration associated with that user. The description of each application definition will contain the GUID and the fields in the a credential (e.g. user id, password and database name). Note that the lookupApplicationRequest command is a CPM specific, custom extension to SPML v2.0.
Q: Are you saying a custom connector is needed because it has to provide the binding between the CPM application definitions and the specific credentials?
A: Exactly!
The connector needs to know:
- the mapping between the application definition GUIDs and the credentials.
- how to use the lookupApplicationRequest custom command to obtain the application definition GUIDs
- how to construct the CPM specific SPML extensions to use in the data elements of the commands.
Provisioning Server and the soon to be released Citrix Workflow Studio Customer Tech Preview will have Workflow Tasks for Provisioning Server included in the Customer Tech Preview.
Stay Tuned Here: Citrix Developer Network - Citrix Workflow Studio
Get Updates Here: Citrix Updated - Citrix Workflow Studio
Provisioning a new server in the Data Center from Bare Metal has always been a challenge. There have been some advances, but they still fall short of where we need to be for a truly self configuring and provisioning dynamic data center.
We have many methods, in which to remotely manage a bare metal server in the data center, we can call someone in the data center, use a networked KVM, use a Lights Out device, or some other creative technology.
Short of having our servers being delivered to us pre-configured for our environment, for the most part we still have to at some point connect to the server to set it up so that it will be ready to be provisioned for whatever purpose it is intended for.
I was having a flashback last week about a story I heard way back when, that was sparked by the announcement of Citrix XenServer being embedded on HP Servers. I have to tell you I don't even know if the following story is true, but here goes. The rumor was about negotiations between Citrix and Compaq way back when and how they were pondering using ICA as the protocol for connecting to their ILO devices. Like I said this rumor was from years ago, but I have never really forgotten about the "what if" scenarios if that had happened.
I love what Lights Out devices do for us, but I have never been a fan of the sluggish interface, when it comes to a console connection to the server, as the protocol used is not optimized for low speed or high latency connections. If you have ever tried to connect to a Lights Out device let's say in England or in Australia, and let's say you were Florida, then you will certainly know what I mean when I say that the current protocol for console connections to a Lights Out device isn't the greatest experience.
Also, trying to identify and manage a data center that has servers that are racked but not yet assigned or configured to be able to be provisioned can be a tough task to get a handle on, or one that can get out of control very fast.
There have been advances in Lights Out technologies that allow them to be managed from Active Directory, but it isn't a complete solution to the problem, as there is still a lot of initial work that has to go into being able to get the device into Active Directory first before one can even begin to manage it.
We need to be able to take server provisioning to the next level, and be able to drop a server onto the network, turn it on, and have it self-configure and self-provision. We have the server provisioning piece down quite well with Citrix Provisioning Server. It's the self-configuration of a bare metal server that we need to look at next, if we truly want to be able to drop ship in servers to meet the growing data center demand.