When a client joins a cluster, a hash is calculated on the last 3 octects of the client MAC address to create a Bucket ID for the client. Perform the following command on the MC to see the ID (1st column of output)
show aaa cluster essid-all users
From there, issue the following command to see the bucket map that the user id is referenced against.
show aaa cluster essid-all bucketmap
A list of bucket maps (lookup tables) will be displayed, one for each ESSID. Find the ESSID that the client is connecting to. Take the Bucket ID of the client, for example 130. For the ESSID, go to the line "Active Map[128-159]", based on the client id of 130. The first number is position 128. Move to the 3rd position, which is 130. There will be a number 00, 01, 02, ... This identifies the user anchor controller that this user will be assigned to. Look above the Active Map section and you will see UAC0, UAC1, UAC2, ... which maps to the IP address of the cluster node. So, whichever controller is reference, that is the user anchor controller of any client whose hash is equal to 130. If you perform this same lookup on the Standby Map table below, you can identify the Standby User Anchor Controller S-UAC for this user too.
No matter what happens with the client, the client bucket id will always be the same (unless the client's MAC address changes) and will correlate to the controller in the bucket map. I don't know of any way of changing the client UAC except for change the cluster configuration (removing a cluster controller). By removing a controller, the user will fail to the standby UAC (if you remove the controller that the client was connected to), and the bucket map will be modified based upon one less controller in the cluster. Adding a controller to the cluster will also generate a new bucket map. Once the controler is added, user load balancing may move clients to a different cluster member.
I hope this helps,