Now let's say you're doing some PowerShell‑based administration.
So as you can see at left here,
we've got us working at our administrative workstation, and let's say
we're going to do some PowerShell remoting and we're going to connect as
ourselves, so we want to transmit, or project, our domain admin identity
onto that remote server, Server1.
Well,
that'll work just fine, especially in a domain environment where
you don't have to worry about the trusted hosts.
The problem comes in, and this is called the Kerberos second hop
problem, where once you've remoted into Server1,
if you then want to do a second hop and continue your PowerShell
administration from Server1 say to Server2, and in particular, the PowerShell
that you run on Server2 you want to continue to run under your credentials,
this is actually blocked by default. And it's blocked for security reasons
because if somebody were to breach a high‑value user account and you had
delegation enabled by default,
this would make lateral movement throughout your domain much, much easier.
So this is something, this notion of Kerberos constrained
delegation, or optionally CredSSP delegation,
is something that you only want to use when you need it
and you want to really constrain it.
That's why it's called constrained delegation,
because of those security concerns.
In fact, again, a callout to a previous lesson in this course,
we saw that the Protected Users group and the authentication policy silos,
part of those protections involve restricting the
ability of those accounts to be delegated.
Again,
that's all in the name of protecting and limiting
the attack surface in your domain.
So anyway,
if you do have a legit need to hop from one server to another, you can
configure using either Kerberos delegation or the CredSSP protocol those
machines to serve as CredSSP servers and clients.
So in this case, we would configure Server1 as being authorized to
delegate our credentials to yet other machines. I'll show you a bit more about how that works in the upcoming demo.