Skip to content
This repository was archived by the owner on Dec 8, 2021. It is now read-only.

Kerberos configuration for -Auth Negociate #202

Closed
eladent opened this issue Oct 30, 2019 · 4 comments
Closed

Kerberos configuration for -Auth Negociate #202

eladent opened this issue Oct 30, 2019 · 4 comments

Comments

@eladent
Copy link

eladent commented Oct 30, 2019

Polaris Bug Report

Description of the bug


When using start Polaris with "-Auth Negociate", Authentication always uses NTLM and it seems there's no working configuration for Kerberos.

Steps to reproduce

in an AD domain.

Considering this old thread Polaris should be running under "SYSTEM" or "Network Service" so it can gain machine credential. So run the script with psexec, taskscheduler or nssm with one of these account.

You aslo need to set an HTTP SPN for the server :
setspn.exe -S HTTP/<your.server.fq.dn>:8000 Server_machine_account

Note : As testing purpose I also tried running Polaris with a useraccount on which I set SPN for the serveur, no success.

Here's a code sample :

New-PolarisRoute -Method GET -Path '/whoami' -ScriptBlock {
	$Response.Send(($Request.User.identity | ConvertTo-Json))
}
Start-Polaris -hostname "<your.server.fq.dn>" -Port 8000 -Verbose -Auth Negotiate

And send a request with
`Invoke-RestMethod -UseDefaultCredentials -Uri http://<your.server.fq.dn>:8000/whoami

In the server answer "AuthenticationType" is stuck on NTLM on every configuration i tried...

Expected behavior

Auth should use Kerberos in this kind of setup.

Additional context

Version Information

Polaris 0.2.0
powershell
$Version= 5.1.14409.1018

@Tiberriver256
Copy link
Contributor

Hi TiTi, thanks for the question. I'm not too familiar with Kerberos myself. Have you tried the IntegratedWindowsAuthentication scheme?

@eladent
Copy link
Author

eladent commented Oct 31, 2019

Hi Micah, thanks for your answer, and yes i tried this morning with with IntegratedWindowsAuthentication : it does pretty much the same and falls back to NTLM eventualy.

But I find my issue : I was calling Invoke-WebRequest localy on the server, and a PCAP capture showed that the client wasn't requesting on the public IP of the server but on an internal private one. Kerberos is a sensitive protocol when it comes to DNS, IP, SPN, URL coherence.
So i tried again from an external client requesting the server name (i.e. on the public IP) and I finally had an kerberos SSO on the service. Thanks for your help !

I'll propose an update of about_Authentication soon, including a qucik instruction to setup kerberos "cleanely".

@Tiberriver256
Copy link
Contributor

Cool, that would be great thank you.

@eladent
Copy link
Author

eladent commented Oct 31, 2019

Cf. pull request #203 and closing this issue

@eladent eladent closed this as completed Oct 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants