Samiul Haque

We use Kerberos auth for the proxy, will test and report back if alpaca works

Here is a screenshot of our redacted logs, as you can see we didn't set the NTLM_CREDENTIALS environment variable and curl request to google still worked with our proxy server...

Note I am on a Mac running on Apple silicon, and I compiled the latest version of alpaca for my system from the latest commit. Also my Mac had binded...

We are using this I believe: https://docs.jamf.com/jamf-school/documentation/Configuring_Kerberos_Single_Sign-on.html And our proxy servers do support it but I'm curious if this is some capability golang had built in or how is this...

We had such a tough time with other languages such as Python/Java/Node which refuses to pick up the Kerberos ticket for proxy requests, alpaca has been a gamechanger for us...

If you can add some debug logging to a seperate branch, I can pull it and test it for you to show you more details of the Kerberos ticket being...

As you can see in the log, authentication is happening before application layer, there is no proxy challenge request due to the OS handling all of that. I am on...

> After you use the proxy run the following command and paste the **_sanitised_** result here. Also if you know the proxy address and name that would be useful so...

You can do something with the os exec package like: ``` jsonOut := exec.command("klist","--json") ``` Then unmarshal the json into a struct for use. In fact the `gokrb5` package does...

The ideal solution would be keeping a struct of valid `Principal`s until the `Expiry` date as seen in the screenshot. Then for every proxy request check if the requested FQDN...