Hello, Cloud Gurus,
and welcome back for this lesson
where we're going to take a look
at solving the second hop problem.
Let's take a look at what we're going to cover.
First up, we'll take a moment to understand
what is the second hop problem.
And then we'll take a look
at making the second hop with CredSSP.
And we'll do a bit of a demo of configuring CredSSP
for PowerShell remoting.
And then we'll take a moment to explore Kerberos delegation.
And we'll wrap up with a demo of configuring resource-based
Kerberos constrained delegation.
All right, that's quite a mouthful.
Let's jump into the lesson.
So what exactly is the second hop problem?
Well, by default, when you connect using PowerShell remoting
using either NTLM or Kerberos for authentication,
credentials are not sent to the remote computer.
Now, this is not a problem
when you're accessing the remote computer
and only the resources on that remote computer.
But what if you need to grab a file
from another remote computer?
Say, a file server,
and it has a PowerShell script that you'd like to run?
The computer you're connected to using PowerShell remoting
has no credentials to send to the file server,
so this file access will fail.
This is known as the second hop problem.
And there are 2 ways to solve this problem.
The first is CredSSP,
or Credential Security Service Provider.
And the second solution is Kerberos delegation.
And Kerberos delegation comes in 2 flavors:
constrained and resource-based.
Now it's important to point out here
that you can also solve the problem
by passing credentials to the remote computer,
or using functionality like Just Enough Administration
in which you can use the session configuration
run as property, but these are not covered by the exam.
And to be honest, they're a little less than ideal.
So first up, we'll take a look at CredSSP in more detail
and then we'll take a look at Kerberos delegation.
CredSSP solves the second hop problem
by caching your credentials on the intermediate server,
and that intermediate server
is the server that you are connected to
using PowerShell remoting.
Its biggest advantage
is that it's supported on all versions of Windows
after Windows Server 2008,
but it has some serious disadvantages.
Let's take a look at those.
The first is that it's disabled by default
and must be configured on the client and the server.
And because it uses cached credentials,
it's also vulnerable to a number of security vulnerabilities
including credential theft.
And the final disadvantage
is that it can't be used with the Protected Users group,
which is a special group introduced
in Windows Server 2012 R2
that protects a list of accounts that you specify
with a range of enhanced security options.
And due to this decent list of disadvantages,
the use of CredSSP should be carefully considered.
All right, let's take a look at a demo of CredSSP
and specifically using it to solve the PowerShell remoting
second hop problem.
We have our CORP-BNE-ADM01 server
and I want to use PowerShell remoting
to connect to our Active Directory Connect Server.
And there's a script that I want to run
on our Active Directory Connect Server
that reports on inactive user accounts.
And that script is stored on a separate file server
called BNE-FS01.
In this demo,
we will attempt the second hop without CredSSP.
Then we will enable CredSSP on the intermediate server,
we'll configure CredSSP on the client,
and finally, we will connect with PowerShell remoting
using CredSSP and test the second hop.
Let's take a look at the demo.
All right, so here I am log on to CORP-BNE-ADM01,
our administrative server.
Let's check and see if we have access
to our get inactive users PowerShell script
on our file server.
To do that, we're going to use test-path
and then we'll specify the path we want to test.
All right, and we can see that that file path exists.
Now let's connect to our Active Directory Connect Server
using PowerShell remoting.
To do that, we'll use the Enter-PSSession PowerShell cmdlet
and specify the computer name for CORP-BNE-ADC01.
Now let's attempt to run the test-path again
using our remote PowerShell session.
And we can see we're getting an error,
and that's because we're trying to make that second hop
and our intermediate server,
which is our Active Directory Connect Server,
doesn't have credentials to pass to our file server.
Let's enable CredSSP on our intermediate server ADC01
using the Enable-WSManCredSSP cmdlet.
And we'll specify the perimeter role
and indicate that this is the server.
And we'll just select Yes to confirm.
And now let's exit the PowerShell remoting session
and return back to our local server,
which is our administrative server ADM01.
And now let's configure CredSSP on our client,
which is our administrative server,
using the same Enable-WSManCredSSP PowerShell cmdlet.
We're going to specify the role as client
and we'll specify the delegate computer
as any computer in the corp.barrierreefaudio.com domain.
We'll go ahead and confirm that.
All right, now let's connect using PowerShell remoting again
but this time we're going to specify to use CredSSP
as the authentication mechanism.
Now you'll notice here that I'm connecting
using the fully qualified domain name for the computer name,
and this is required when you have the delegate computer
set to a wildcard, which is what we did
when we enabled CredSSP on this client just a moment ago.
Let's go ahead and connect
and we'll provide our credentials.
Now let's attempt a test-path again
to see if we can get access to that script.
And we can see we're now able to access that script
because CredSSP has cached our credentials
on the Active Directory Connect Server,
which is our intermediate server,
and then pass those credentials to the file server.
All right, that concludes this demo.
Let's continue on with Kerberos delegation.
Now the other alternative to solve the second hop problem
is Kerberos delegation.
And Kerberos delegation has been around for quite some time
and it's improved quite a lot over the years.
What's great about Kerberos delegation
is that it allows credentials to be delegated
without the credentials needing to be stored,
which solves a number of the security issues
that you see with CredSSP.
Instead, Kerbeross will check with Active Directory
if the credentials can be delegated.
Not the actual credentials, like a user and password,
but a ticket that confirms those credentials.
And you can think of it as a domain controller
issuing a ticket to a user
and then that user presenting that ticket
to prove they're paid the price of admission,
which is the authentication process.
Now there are a few different methods
to implement Kerberos delegation.
Let's take a look at these.
The first and oldest implementation of Kerberos delegation
is unconstrained delegation.
Unconstrained delegation is configured
by configuring the computer account
of the intermediate server in Active Directory.
And you set the setting as shown in the screenshot here
to trust this computer
for delegation to any service, Kerberos only.
Now unconstrained delegation is not recommended
because you don't have any control
over which credentials are delegated
and what they are delegated to.
So let's take a look at some of the other alternatives.
Constrained delegation allows you
to configure the computer object for the intermediate server
and which services it allows to delegate credentials.
Constrained delegation requires domain admin privileges
and it doesn't work in cross-forest scenarios.
The screenshot shows that we've configured CORP-BNE-ADC01
to delegate credentials for our file server CORP-BNE-FS01
for the cifs service, which is used for Windows file shares.
But what we're going to focus our efforts on
is the latest and most secure option,
which is resource-based constrained delegation.
That's a mouthful, that one.
It was introduced in Windows Server 2012,
and it is configured easily on the computer object
for the target resource to specify
where it will accept delegated credentials from.
And it's done using PowerShell.
It's important from a delegated responsibility standpoint
that it is configured on the target resource,
because in a large distributed Active Directory environment
you might delegate the responsibility
of managing workload service to workload teams.
And with this option, they can now configure
where they will accept delegated credentials from,
instead of having to rely on a central team
with domain admin privileges to configure this for them.
All right, let's take a look at a demo
of resource-based constrained Kerberos delegation.
In this demo, we're going to configure resource-based
constrained Kerberos delegation
on our file server CORP-BNE-FS01 computer object
in the Active Directory database.
This will allow it to receive delegated credentials
from our intermediate server CORP-BNE-ADC01.
And then we will confirm
and test the resource-based constrained delegation
by connecting from our administrative server ADM01
to our intermediate server ADC01 using PowerShell remoting,
and then attempting to access the same script
we accessed earlier on our file server CORP-BNE-FS01.
Let's take a look at the demo.
All right, so here we are logged onto
our administrative server.
Let's confirm that we have no Kerberos delegation in place
by entering a PSSession
to our Active Directory Connect Server,
and then testing the path to a script on our file server.
To do that, we'll run Enter-PSSession
and connect to the computer CORP-BNE-ADC01.
And now let's test access to that script on our file server
using the test-path cmdlet.
All right, and that confirms we don't have access.
Let's exit this PSSession.
All right, now let's configure resource-based
Kerberos constrained delegation
for our file server computer account using PowerShell.
Now we're logged into our administrative server
which has the Active Directory tools installed,
including the Active Directory PowerShell module.
Let's start by creating a PowerShell variable
to store the computer account object for our file server.
And to do that, we're going to use Get-ADComputer
and pass the identity parameter our file server's name.
And now let's do the same for our intermediate server,
which is our Active Directory Connect Server.
And now let's use the Set-ADComputer PowerShell cmdlet
to specify that our file server is allowed
to receive delegated credentials
from our Active Directory Connect Server.
And we can see here
that our resource server is our file server
and it's allowed to receive delegated credentials
from our Active Directory Connect Server,
which is our intermediate server that we've connected to
using PowerShell remoting.
Now let's confirm
that the delegation has been configured correctly
using the Get-ADComputer PowerShell cmdlet.
We'll pass the identity of the file server
and we'll look for just the principles allowed
to delegate to account property,
and then we'll select that property as well.
All right, and we can see here
that our Active Directory Connect Server
is allowed to delegate credentials to our file server.
Let's test this by connecting
to our Active Directory Connect Server
using PowerShell remoting.
And to do that, we'll use EnterPSSession.
And now, let's try and access the script
on our file server again.
All right, and we can see we've successfully configured
resource-based constrained Kerberos delegation.
That concludes this demo.
Let's wrap up with a bit of a summary
of what we're covered in this lesson.
All right, so what have we covered in this lesson?
You can solve the second hop problem using CredSSP,
which caches credentials on the intermediate server.
And you can enable CredSSP
using the Enable-WSManCredSSP PowerShell cmdlet
on both the client and the intermediate server.
And you use the role parameter
to set the value to either client or server.
And you can also resolve the second hop problem
with Kerbeross delegation.
And Kerberos constrained delegation
is configured on the intermediate server object
in Active Directory, which is used to access the resources.
Or you can use the most recent and secure option,
which is resource-based constrained delegation.
And it is configured on the resource server
Active Directory computer object
with the Set-ADComputer cmdlet
and the principles allowed to delegate to account parameter.
All right, thanks for being with me in this lesson
and I hope you found it useful.
And I look forward to seeing you in the next lesson.