It sounds like you need a Session Event Trigger of some sort.
Triggers are defined in an IF-THEN format (or should I say Filter-Action, to use Control's jargon).
In your case, that would be:

IF

THEN and

The IF (or Filter) part is easy enough to define:

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND Session.SessionType = 'Access'

So go to the Triggers page, create a new trigger and enter the above into the Event Filter.

The THEN (or Action) part is the tricky one.
That's because there are two significant limitations on executing commands, one set by Windows and the other set by Control.
Let me explain.

Action #1: Changing the password
This action would be a QueuedCommand event.
So choose 'Add as Session Event' and for Event Type select 'QueueCommand'.
Then, in the Data field, enter the following (replace the words in CAPITALS with the relevant values):

net user USERNAME NEWPASSWORD

If only you could use {Session.GuestLoggedOnUserName} as the USERNAME value, that would make life so simple.
But for some reason Control doesn't let you use variables in the Data field of Event Actions, even though they work perfectly fine in the Body and Subject fields of HTTP and SMTP Actions.
This is the Control limitation I was talking about. It's really annoying, I know.

It means that you have to create a trigger for each machine you have and specify the username. Ugh.

Action #2: Logging the user off
This action would be also a QueuedCommand event.

If only you could use shutdown /l command, but it doesn't work when executed remotely.
And this is the Windows limitation I was talking about earlier.
The only alternative, as far as I know, is to use the command:

logoff SESSION

But you need to know the SESSION value to use that, which you can get with the command query session
But this means you need at least two steps. But a trigger can't be defined to retrieve a value from the output of one command and plug it into the input of another command.

Your best bet then is to assume that the SESSION value is 1. It's an assumption that won't always pan out, but I reckon it'll work in most cases?

But I'm not an expert on cmd.exe, so maybe there is a workaround?
The next version of Control will support PowerShell, so maybe that'll allow you to log off in one step? I'm not an expert on PowerShell either, so I don't know.

Oh, right. Having mentioned the Control limitation, I should've gone on to specify the Event Filter further. Sorry about that.
You can use a variety of values for this purpose: Session.SessionID, Session.Name, Session.GuestMachineName (see the reference at the bottom of the Triggers page).
For simplicity's sake, let's append a Session.Name condition to our Event Filter:

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND Session.SessionType = 'Access' AND Session.Name = 'NAME'


This should be the Logged On User, who is identified both on the session list and in the General Info tab on the right, like this:




Use double quotes, so:

net user "Matt Dimock" NEWPASSWORD

When the two actions are successfully triggered, the Commands tab should look like this:



The success depends on the session value, as I explained in the previous post.
In the screenshot example above, it worked because the session value was indeed 1:



But unless the user has the habit of logging on and off on their own laptop, 1 should work.

The only problem with the net user command is it won't work if they have a Microsoft account setup.