I'm having a problem to setup SSO for the intranet websites. Currently i'm working with Tomcat 8.0 and Waffle 1.8.4. They work great, but there is only 1 problem: the browsers (Firefox and IE after the settings were applied as described here and here) can not do Kerberos authentication, only NTLM.
I analyzed the traffic with Wireshark, Tomcat sends the http header field "WWW-Authenticate" and the browser answers a base64-encoded string in the header field "Authentication", that contains NTLMSSP. I guess this is not Kerberos, or is it ?
I read a post (WWW-Authenticate uses NTLM and not Kerberos), that for Kerberos to work, the server has to be registered in the AD with the command setspn.exe.
I try to get the right syntax for setspn (described here), but without any luck.
The server has the following parameters:
IP: 10.0.0.1
Service: Tomcat-Http
Port: 8080
Accountname: company-net\foobar
I use this command for setspn:
setspn -A "HTTP/10.0.0.1:8080 company-net\foobar"
but not works. Both the server and the client are in the same Windows domain, using Windows 10.
What is wrong with it?
Do i need anything else ?
Kerberos relies on DNS (valid hostnames) and SPNs to function. Looks like you've done a bit of research so far which is good. What isn't that well known is that when you point an otherwise perfectly working fine Kerberos client to the IP of a host, rather than to it's DNS hostname, Kerberos will be bypassed and the fallback authentication mechanism will be employed instead - NTLM in this case.
Michael-O, the top Kerberos contributor to this forum, said it best with his answer about this back in 2012:
Kerberos does not work with IP adresses, it relies on domain names and
correct DNS entries only.
Related
I'm having an issue getting Traefik to proxy applications that are secured using Integrated Windows Authentication (IWA). When the content being served is simply an IIS virtual directory secured with IWA there is no problem. However, when it is a .NET Core application or MVC application or even just a simple Default.aspx page and IWA is enabled I continually get prompted for my credentials (never being accepted). See below for my configuration:
Traefik Configuration:
# ns-ws
[frontends.ns_ws]
passHostHeader=true
entrypoints=["http","https"]
backend = "ns_ws"
[frontends.ns_ws.routes.match_all]
rule = "Host:ns-ws.example.com"
[backends.ns_ws]
# ns-ws
[backends.ns_ws.loadbalancer.stickiness]
[backends.ns_ws.servers.server1]
url = "http://x.x.x.x:80"
I've played with removing pass host headers and stickiness, but no luck.
Seems like the original request makes it through because I do not get an unauthenticated error message from IIS for the page, but most subsequent requests to the server will return a 401 (seems sporadic).
Example Image:
I've tried changing the "authPersistNonNTLM" option in IIS, as described here: https://boyan.io/kerberos-load-balancers/ (with no luck)
I realize this is a very stale issue but in case this helps others.
I can confirm that Windows Integrated authentication works successfully with Traefik 2.x using a TCP as opposed to HTTP router with successful logins proven on Windows/Mac using Safari/Chrome/IE.
Note that when testing it is important to ensure you have cleared cookie caches or you can get unpredictable results due to prior login attempts on non-working configurations you may have attempted. Indeed I experienced something similar to your described behavior with repeated unexplained login prompts until I reset my browser.
In our configuration we have a mixed-OS docker Swarm (Linux/Windows) with Traefik operating on Linux and sending requests straight to back-end Windows-containers running on Windows swarm nodes.
If you have configured your Windows app and containers correctly I can confirm that from:
A domain-joined machine you will get straight through login to Windows back-end containers using the domain-joined machine's Kerberos credentials
A non-domain-joined machine connection will downgrade to Windows NTLM authentication and prompt for Windows authentication credentials.
From a Traefik configuration perspective our docker containers have labels like this:
- "traefik.tcp.routers.dotnet-tcpexample.entrypoints=websecure"
- "traefik.tcp.routers.dotnet-tcpexample.tls=true"
- "traefik.tcp.routers.dotnet-tcpexample.tls.options=default"
- "traefik.tcp.routers.dotnet-tcpexample.rule=HostSNI(`windows.foo.bar`)"
- "traefik.tcp.routers.dotnet-tcpexample.tls.passthrough=true"
- "traefik.tcp.routers.dotnet-tcpexample.service=dotnet-tcpexample"
- "traefik.tcp.services.dotnet-tcpexample.loadbalancer.server.port=443"
Note that configuring containers for Windows integrated authentication in itself is non-trivial but documented here.
I am using Ansible on a Linux computer connecting to a windows 8.1 embedded computer. It's able to connect with username and password over the HTTPS port 5986, but I need to specify the option:
ansible_winrm_server_cert_validation=ignore
The ansible documentation specifies:
The following is necessary for Python 2.7.9+ (or any older Python that
has backported SSLContext, eg, Python 2.7.5 on RHEL7) when using
default WinRM self-signed certificates:
The windows computer has an SSL listener that was configured with Self-SignedCertificates from the powershell script:
https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
My question is that if I'm ignoring server cert validation, does that compromise the encryption that HTTPS is supposed to provide? or is server cert validation just a separate process of HTTPS?
Thanks
Yes, if you ignore certificate validation as recommended in the default Ansible config for WinRM, your connection is not secure - someone can spoof the target server using a man in the middle (MITM) attack on the HTTPS connection. (There should really be a security warning in the Ansible docs.)
The best alternative seems to be NTLM/Negotiate authentication, instead of HTTPS, removing the need for an SSL certificate. Your Ansible control machine will need to be able to authenticate over NTLM as a Windows user, just like using an SMB file share.
You will need pywinrm 0.2.0 or higher for NTLM/Negotiate support.
Useful links
Why NTLM/Negotiate for WinRM - background on why it's good to avoid the complex setup to install SSL certificates by using NTLM (Ruby based but still useful)
Example Ansible setup for NTLM
More complete Ansible setup including NTLM
Certificate validation is a separate process than encryption. The communication will be encrypted. You can read more on the issues with self-signed certificates but the high level is you remove any way for Ansible to validate who exactly is on the other side of the connection an open your self to a man in the middle attack that HTTPS usually protects you from.
I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
I'm running a NodeJS server on a Windows Server 2008.
The server doesn't do much but I set the header for 401, WWW-Authenticate Negotiation which I know can go either with his default Kerberos authentication or if it's not available then with NTLM.
I downloaded fiddler and discovered that when I try to reach the server it tries to authenticate with NTLM(prompt me for username and password) rather than Kerberos, even though the computer is in the same domain as the server and when I do run the command "klist" it does show me that he has tokens which means that he already authenticated with Kerberos(doesn't it?).
My question is how can I make it authenticate with Kerberos rather than NTLM - why does he go to NTLM in the first place?
Any ideas?
You client is probably unable to obtain a server ticket for that machine. Use Wireshark and check for Kerberos TGS-REQ messages. Please search SO for my similar answers, I was already able to help in such situations.
Most likely, you need to read up on Kerberos. You probably have a TGT (ticket granting ticket) , which proves you authenticated to AD (KDC). You still need a ST (service ticket) for the specific service/server instanced. http/servername. For this to work, you need an SPN registered for the service. the SPN must be registered to the account that will be decrytping the ST.
Fiddler showing that you don't send a ST shows that you didn't get one. You likely will need a sniffer, not just Fiddler. You will see, on port 88, your workstation try to request the ST from a KDC, then fail, then fall back to NTLM. You want to see the ST req get back a ST.
this is a great starter, despite being from 2000 http://technet.microsoft.com/en-us/library/bb742431.aspx
For more meaningful assistance, I'd need to see your app URL, your SPN info via setspn -l , and server hostname.
As this hasn't been marked as fixed I thought I would add a solution which worked for me. YMMV as in my environment we have multiple forests with trust relationships.
In my case, the user running the browser (and therefore making the HTTP GET) was in DOMA, but the web server was joined to DOMB. When the client tried to find the SPN of HTTP/webserver.domainb.example.com, it was looking for it in the DOMA.
I wrongly assumed that because a bi-directional trust relationship existed between DOMA and DOMB that it would figure out to look in DOMB and do so. Unfortunately it does not and you must Configure Kerberos Forest Search Order. This may be done per client (Computer Configuration → Policies → Administrative Templates → System → Kerberos → Use forest search order) on Windows 7, or per KDC (Computer Configuration → Policies → Administrative Templates → System → KDC → Use forest search order) on Windows Server 2008R2.
Note: Michael-O's advice to use Wireshark and look for TGS-REQ messages was what led me to finding the KFSO setting so many thanks to him.
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"