Creating a keytab on Windows for Kerberos authentication on Linux - windows

I need to run curl commands from a Windows server to an API on a Linux box. When I am on my workstation I just run a kinit and give my user name and pwd for the Kerberos realm.
I have automated scripts in which I need to run a kinit before running the Powershell script. I do not want any manual intervention. I am trying to create a keytab file with my Kerberos account but it is not working -
I am receiving the error message "No key table entry found for user#domain.net while getting initial credentials.
I really don't understand much about Kerberos, and whether the process cares that I am on a Windows server tryng to use a keytab file for this purpose.
Can someone help? I have been going a bit nuts with this...
Thanks for any help!

Look into your keytab if the principal there is the one you are going to use. klist -k -t <keytab>

You are obviously doing wrong. You have to obtain a curl binary for Windows which says with curl --version:
curl 7.46.0 ...
Protocols: http https ...
Features: SSPI Kerberos SPNEGO ...
That's it. Enable SPNEGO auth with curl --negotiate -u : <URL> and you are done. No keytab necessary on Windows.

Related

Piping password to kinit on a windows server

We are setting up a system where we need to re-verify a user's identify before he/she is allowed to perform a specific task. The user enters his/her password into the website, and then PHP runs kinit to verify that the password is correct. We use Kerberos for authentication. This is what we successfully tried on a Linux server:
echo "password123" | kinit username#REALM.COM
The problem is that the system is running on a Windows server. We have installed kinit, but cannot seem to get the same thing to work. Running that same command, with or without the quotes, just gives us this output:
kinit: Generic preauthentication failure while getting initial credentials
Any suggestions on what could be done here?
Edit:
Running simply "kinit" and then entering the password at the prompt, works well.

When using --negotiate with curl, is a keytab file required?

The documentation describing how to connect to a kerberos secured endpoint shows the following:
curl -i --negotiate -u : "http://<HOST>:<PORT>/webhdfs/v1/<PATH>?op=..."
The -u flag has to be provided but is ignored by curl.
Does the --negotiate option cause curl to look for a keytab that was created beforehand with the kinit command, or will curl prompt for credentials?
If it looks for a keytab file, what filename will the command be looking for?
Being a once-in-a-while-contributor to curl in that area. Here is what you need to know:
curl(1) itself knows nothing about Kerberos and will not interact neither with your credential cache nor your keytab file. It will delegate all calls to a GSS-API implementation which will do the magic for you. What magic depends on the library, Heimdal and MIT Kerberos.
Based on your question, I assume that you have little knowledge about Kerberos and want simply automate API calls to a REST endpoints secured by SPNEGO.
Here is what you need to do:
Have a Unix-like OS
Install at least MIT Kerberos 1.11
Install at least curl 7.38.0 against MIT Kerberos
Verify this with curl --version mentioning GSS-API and SPNEGO and with ldd linked against your MIT Kerberos version.
Create a client keytab for the service principal with ktutil or mskutil
Try to obtain a TGT with that client keytab by kinit -k -t <path-to-keytab> <principal-from-keytab>
Verify with klist that you have a ticket cache
Environment is now ready to go:
Export KRB5CCNAME=<some-non-default-path>
Export KRB5_CLIENT_KTNAME=<path-to-keytab>
Invoke curl --negotiate -u : <URL>
MIT Kerberos will detect that both environment variables are set, inspect them, automatically obtain a TGT with your keytab, request a service ticket and pass to curl. You are done.
Note: this will not work with Heimdal.
Check curl version
$ curl -V - It should support the feature "GSS-Negotiate"
Login using kinit
$ kinit <user-id>
Use curl
$ curl --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt http://localhost:14000/webhdfs/v1/?op=liststatus
"--negotiate" option enables SPNEGO
"-u" option is required but ignored (the principle specified during kinit is used)
"-b" & "-c" options are used to store and send http cookies.
I am using version 7.54.0. The following command works fine for me. (please remember/pay attention there are double dashes before the negotiate option).
curl --negotiate -u: '<the_full_url>'

hydra target ssh does not support password authentication

I am using Hydra v8.1 downloaded and compiled from a tar file. I've managed to solve the standard problem of libssh support and now when I try to make an attack(I think it's called dictionary attack) on an SSH server, after specifying the following command:
hydra -l {username} -s {port} -P /Users/{UserName}/Desktop/{file}.txt {ip} ssh
I get the following output:
Hydra v8.1 (c) 2014 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2015-09-30 10:59:49
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 7 tasks per 1 server, overall 64 tasks, 7 login tries (l:1/p:7), ~0 tries per task
[DATA] attacking service ssh on port {port}
[ERROR] target ssh://{ip}:{port}/ does not support password authentication
I have enabled support for the required libraries and I am running an OS X environment.
Can someone indicate a solution to this problem? Thank you.
Note: If I manually log in with the username and password, the authentication grants access to the server.
from another board:
https://security.stackexchange.com/questions/183848/hydra-fails-with-error-target-ssh-192-168-16-12822-does-not-support-passw
SSH supports several different authentication mechanisms. The password authentication mechanism has the client send the password to the server as a password. The more-common keyboard-interactive authentication mechanism opens a channel between the client and an authentication process on the server. The client allows the user to directly interact with the authentication process, which is usually just a password prompt. This allows more complex features like multiple-factor authentication and pre-authentication warnings and checks.
So your target probably supports keyboard-interactive and not password authentication.

Kerberos Sercurity Error

I am having a problem with my server and so far couldn't find any solution for this. When I try to add a server from a server manager (windows server 2012) I can see only the kerberos security error. Both servers are in the same domain(i have tried from several servers from domain and got the same error).
The strange thing is when I unjoin the problematic server from domain and rejoin it with another name it works normally. But the problem is to make it work with existing name. Anyhelp will be highly appreciated
thanks in advance.
Late reply, but I've just encountered the same error and hope this solution proves useful to others.
Situation: I had to wipe and reinstall a virtual server on which I'd previously had to set some Service Principal Names, and some SPNs for a service account. Turns out the SPNs were still there for the old server/account and I had to remove them.
I recommend checking for and removing rogue SPNs to resolve this. Use the following commands in an elevated command prompt:
setspn -l <servername/username>
In my case I had problems with MBAM, the Bitlocker admin tool, so for example I used:
setspn -l mbam01
Which gave me the output (changed names to protect the innocent):
Registered ServicePrincipalNames for CN=MBAM01,OU=Member Servers,DC=corp,DC=domainname,DC=com:
termserv/mbam01.corp.domainname.com
termserv/mbam01
http/mbam01.corp.domainname.com
http/mbam01
HOST/MBAM01
HOST/mbam01.corp.domainname.com
This will list the SPNs associated with the server or user account. Then you remove the errant SPNs with this command:
setspn -d <listed service> <servername/username>
In my case it turned out the mbamapppool user had http/mbam01 and http/mbam01.corp.domainname.com associated with it, causing Server Manager to fail to poll the server. I removed the http/ refs from the user and then added them to the server with the following commands:
setspn -d http/mbam01 corp\mbamapppooluser
setspn -d http/mbam.corp.domainname.com corp\mbamapppooluser
setspn -s http/mbam01 mbam01
setspn -s http/mbam01.corp.domainname.com mbam01
I then refreshed Server Manager and it polled the server successfully, and the Kerberos Security Error had gone.

Get windows proxy username/password

I have an access to a preconfigured Windows XP 32-bit workstation.
It's under firewall and to get outside it uses http proxy server.
To get proxy settings I need host, port, username and password.
http: // username : password # server : port
I'm able to find the proxy url and port (from PAC - automatic config file),
but I don't know how to get username/password. Is there a way to read it somehow? At least username? I might get the admin rights.
Do you know any tool that can help?
I only found these MS docs about some methods to get proxy config connection, but I don't know how to determinate what's the provided credentials:
WinHttpGetIEProxyConfigForCurrentUser function
WINHTTP_CURRENT_USER_IE_PROXY_CONFIG structure
WinHttpGetProxyForUrl function
I've also found this lib, but it's rather for parsing PAC:
http://code.google.com/p/pacparser/
In windows you cannot get password.
To get connect throw a proxy you have to use SSPI, check libcurl, you can get a connected socket throw proxy, build it with enable-sspi and openssl.
Iterating on Fernando Sanchez's answer and Robert's comment, you need to authenticate via SSPI. In my case I've connected using NTLM using this link
With curl using ntlm :
curl.exe --proxy <proxy_name>:<proxy_port> --proxy-ntlm -U : https://www.google.com
Also to partially answer your question the -U : means from curl man page :
If you use a Windows SSPI-enabled curl binary and do either Negotiate
or NTLM authentication then you can tell curl to select the user name
and password from your environment by specifying a single colon with
this option: "-U :".
You can get the proxy name and port from the windows registry (regedit). Quote from Robert's comment:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings]
It can be present either in a manual way using REG_SZ ProxyServer or using an autoconfiguration script using REG_SZ AutoConfigURL = https://<configuration_url>
If the curl command above fails with Failure when receiving data from the peer maybe you have a curl release without NTLM, SSPI or OpenSSL. Try with the latest curl release

Resources