1

Goal: I am utilizing Implicit Remoting to centralize modules for access to over 150 employees. Some of these modules make queries outbound to different sites around the internet.

Problem: Although the users can successfully remote into the server using:

$session = New-PSSession -ComputerName ServerA -Authentication Kerberos

They are being blocked at the proxy, while making queries to the internet because of lack of authentication. However, the users are able to send queries to internal productions.

Question:

How can I attach Kerberos Authentication, in my powershell scripts, to the queries that are going outbound to the internet to make it past the proxy?

Additional information:

-To my knowledge according to: https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/

-Kerberos Authentication uses 'unconstrained delegation.'Therefore, it should delegate the auth correctly before querying outbound. I also checked the outer scope for the session variable and it isn't null.

Alexander Sinno
  • 554
  • 5
  • 24

1 Answers1

2

Ah I remember that article. I think you're reading the part about unconstrained delegation incorrectly. That's not the default setting; it's off by default (which is why the double-hop issue exists), as it should be. When it says no coding is required, that's because it's configured completely outside of the code.

You'll need to use some kind of delegation, whether it's through Kerberos or CredSSP or whatever.

CredSSP can be used fairly securely if you understand exactly what's it doing and what the risk is, and for the use case of having a single machine delegating credentials to a single other machine, I think it could be a good use case.

A lot of people don't and just let every machine delegate to every other which is pretty bad.

It's hard for me to tell from your description what kind of proxy it is, where the credentials really need to go, etc., so maybe this is a bad idea..

If you don't want to (or shouldn't) delegate, another way is to set up a session configuration on ServerA that uses a RunAs user; all code running in that session will be able to go one hop, but this can be bad as well; all the code will run as that user, not the connecting user. It can make auditing a challenge. This approach should be used only in specific circumstances and it sounds like this isn't one of them. I wrote an answer here that talks about session configurations.

Community
  • 1
  • 1
briantist
  • 45,546
  • 6
  • 82
  • 127
  • Hello Brian, thank you once again for your help. I would prefer to use delegation with Kerberos if possible. I would prefer not to open up any security gaps if possible by sending clear-text passwords. Is it possible to delegate with Kerberos? – Alexander Sinno Jan 19 '17 at 18:46
  • 1
    @Badlarry yes it's possible; use constrained delegation if you can (the article you linked to). I haven't implemented it before so I don't have any direct advice on it, but the post seems comprehensive, and there's more in the comments. Unconstrained delegation is not quite as good, but it is possible too (without the new-ness requirements of unconstrained), but it involves SPNs which are always icky. TBH my preferred method of solving this problem is to avoid it (change the process or implementation to not need delegation). Whether that's possible or not depends on the exact issue at hand. – briantist Jan 19 '17 at 18:53
  • Would you be able to give me an example of your other suggestion? For example: 'ServerA that uses a RunAs user' Meaning, how would I spell this out in a script? – Alexander Sinno Jan 19 '17 at 18:56
  • 1
    @Badlarry it's something that requires additional configuration on ServerA, at which point the only thing that would change in your code would be to add `-ConfigurationName` to `New-PSSession`. [I wrote an answer here that talks about session configurations](http://stackoverflow.com/a/30061125/3905079). – briantist Jan 19 '17 at 19:03
  • I am one step away from finishing this implementation. Currently, 'RunAsUser' is blank in my SessionConfig File. How do I modify this? I looked through your other links, I didn't manage to get that information. – Alexander Sinno Jan 19 '17 at 19:32
  • 1
    @mjolinor a virtual account is local only though, is it not? It won't be able to then use kerberos for another hop. – briantist Jan 19 '17 at 20:11
  • 1
    @Badlarry it's set with `Register-PSSessionConfiguration -RunAsCredential`. It takes a `[PSCredential]` object. – briantist Jan 19 '17 at 20:12
  • 1
    The virtual account is local. Ideally, you would create constrained sessions on all of your servers using virtual accounts to prevent lateral movement. – mjolinor Jan 19 '17 at 20:26
  • @mjolinor I agree, for the purpose they were built for, virtual accounts not being able to do anything outside of the machine is a virtue, but for the use case in the post, they're unusable. – briantist Jan 19 '17 at 20:52
  • I'll withdraw the comment. – mjolinor Jan 19 '17 at 20:54
  • 1
    @mjolinor I don't know if it has to be removed.. I think it's still good to know about them – briantist Jan 19 '17 at 20:55
  • Brian, one of the issues is that I am only the administrator of this one PSRM sever. If I create a credential object on ServerA and use that object under 'RunAsUser:' would that fix the issue? Or would I have to speak to the system admin in control of the AD for the company to get this done? – Alexander Sinno Jan 19 '17 at 21:19
  • 1
    @Badlarry you need to make sure you understand what a RunAsCredential does. All of the code that runs in the session on the server, will be running _as that user_, no matter who connected to the session (with their own credentials). Given what little I know about your situation, I can't even say for sure if this is a good fit for what you want (I guessed "no"). The typical use case for this is a constrained endpoint for delegating administrative tasks to a user without giving them the actual underlying credentials, like using a privileged RunAsAccount, allowing non-priv acct to connect session – briantist Jan 19 '17 at 21:23
  • Hey Brian! Thanks a lot. Your fix worked like a charm, once again! – Alexander Sinno Jan 19 '17 at 21:31