Now another principle of delegation.
Let me open up Visual Studio Code,
and because I have the Active Directory RSAT tools,
that means that I have the Active Directory module installed and
it's available in my Windows PowerShell session.
Here is a script file I created called credssp.ps1,
and I have this here, I give it to you in the course files as well,
and it's going to walk us through how we can do Kerberos,
well not Kerberos, but CredSSP‑based delegation.
While I'm on the subject of Kerberos delegation,
you can do that, rather you don't have to do that,
but you can do that here in the context of Active Directory Users and Computers.
You can right‑click a computer account, go to Properties,
and go to Delegation, and notice that, by default,
your member servers here are not trusted for delegation,
and the idea of constrained delegation would be where you trust the
computer for delegation to specified services only,
and then you can add those services in here specifically.
This is the preferred way.
If you're going to delegate credentials from machine to machine that you
not do it just globally or in an unconstrained way,
but you do it in a very intentional constrained way there.
Now, as an alternative to Kerberos constrained delegation,
we have CredSSP, and that's what I'm going to show you here using PowerShell.
So I'm going to right‑click Line 5 here, and I'm going to run that selection.
That's going to use PowerShell WinRM remoting to get me into mem1.timw.info.
Next, I'm going to run Line 6 where from mem1,
I'm going to invoke a command Get‑WindowsFeature to enumerate
the installed features on dc1.timw.info.
Now watch what happens when I do that.
We get a whole bunch of error text mentioning Kerberos.
This is the Kerberos second hop problem.
It was just fine for me to connect with my current
administrative credentials to mem1,
but then when we ran invoke command from mem1,
mem1 was not a delegate, it wasn't given permission to forward my credentials,
hence we bombed out.
So let me exit the PSSession.
To come back to the client machine, again,
just as a check, I'll run hostname, I'm on client1,
and I'll run whoami.
I am signed in as a domain administrator here, so let's clear the screen.
Okay,
so the commands that you should know about
regarding CredSSP delegation are these.
Let me run Line 9.
There is Disable‑WSManCredSSP, Enable‑WSManCredSSP, and Get‑WSManCredSSP.
And the way it works, it's a client server model.
Now the machine that I'm on is going to be the client.
So on Line 12 here, I'm going to say Enable‑WSManCredSSP with the Client role,
the DelegateComputer is going to be mem1,
and I do want to force that.
And again, we can echo back our current settings by running Get‑WSManCredSSP,
and it tells us in very user‑friendly language that the machine is
configured to allow delegating fresh credentials to mem1,
but the computer is not configured to receive
credentials so that's the server piece.
So we have on Line 18,
I'm going to issue a remote command using Invoke‑Command to mem1,
and there I'm going to run Enable‑WSManCredSSP Role‑Server.
But let me right‑click, let me run that selection,
and that'll configure the machine just in the opposite way
to how my current machine is set up.
Matter of fact, I can modify this and make the Scriptblock Get‑WSManCredSSP,
and let's take a look at the configuration of mem1.
Let me run that selection.
So this machine is not configured to delegate,
but it is configured to receive credentials from a remote client computer,
so far so good.
So to finish this out here on Line 21, let's now enter another PSSession to mem1.
I'll specifically mentioned my domain credentials, but this is important.
I'm specifying authentication CredSSP.
So let me right‑click, Run that selection,
put in my password here, and now I'm connected to mem1.timw.info.
So we should find now, if we attempt to run Line 23,
there is the installed feature so we're able to complete the
configuration and work past the Kerberos second hop problem.
Let me Ctrl+C to break that output.
Alright, good.
Now to reset things back to how they were originally,
let me again do an Exit PSSession to close that
session and come back to the client.
I can do a Disable‑WSManCredSSP on my local machine.
And then lastly, I can undo the server configuration.
Now, why do I mention that?
Well, it's because by opening up CredSSP in this way,
even though I'm doing it pretty intentionally,
I'm just doing it from my one workstation to one particular server,
that still expands the attack surface of mem1,
and to a degree, client1.
So unless CredSSP is something that you really
legitimately need enabled all the time,
it may be best to consider it a temporary technique that you then can disable after you finish needing it.