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.
Related
I’ve written an OPC UA Client and i’m using ProSys OPC UA Simulator Server to test it. Running in Anonymous mode my client connects and i can browse the server. however when I configure my client to use a Username and Password it fails with No Suitable UserTokenPolicy found for the possible endPoints. I’ve debugged it and it appears that http://opcfoundation.org/UA/Se…..olicy#None is not in the endpoints userIdentityTokens array, although in ProSys it states it is.
I’ve set up a user in The OPC UA Simulator Username & Passord box is ticked
Security Modes = None
Security Policies = None are ticked
The list of server EndPoints
Security Mode = None
Security Policy = None
So i would expect to see it in userIdentityTokens array.
My Client is written using the Open62541 libraries
Any help would be appreciated.
Thanks
I haven't used the Open62541 libraries, but it seems the standard allows the OPC server to require that the username and password are encrypted even when the rest of the transport is not signed or encrypted.
It appears that at some point in time (and maybe still), Open62541 doesn't handle encrypting the password. Here are a couple of related github issues:
https://github.com/open62541/open62541/issues/934
https://github.com/open62541/open62541/issues/1548
https://github.com/open62541/open62541/issues/2757
I am working on a node.js OPC UA client based on the node-opcua library, and I was able to verify that I can connect to the ProSys OPC-UA simulation server with the security mode set to none and user authentication set to username & password. I do not know what type of password encryption node-opcua is doing behind the scenes, but it works.
----- Additional info -------
I found another forum with some clarification: https://forum.prosysopc.com/forum/opc-ua/clarification-on-opensecurechannel-messages-and-x509identitytoken-specifications/
The key part:
If passwords are sent, they will be encrypted as defined by the
UserTokenPolicy (which is separate from SecurityPolicy, but similar).
The Application Instance Certificates will be used for the encryption
in this case – and therefore they are required to be exchanged even
when MessageSecurityMode=None.
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.
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"
single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.
However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.
My question is basically "how can I do that"? More specifically,
a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?
b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?
c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?
d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?
I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.
Also, if possible, I would like to use CAS, Shibboleth and other open-source components where possible.
Thanks for comments, suggestions and answers!
MiKu
Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.
This is all feasable, you need:
A KDC
Correct DNS entries
KDC accounts
Correct SPN entries
Client computers configured to talk to the KDC
Java app using JAAS with JGSS to obtain service tickets
GSS-API with your GTK+ app to obtain service tickets
What did you figure out yourself yet?
Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.
On Unix platforms, you can tell JGSS to bypass the JDK code and use an external GSSAPI library by starting the JVM with:
-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so
There is no analogous option on Windows to use SSPI, however. This looks promising:
http://dblock.github.com/waffle/
... but I haven’t gotten to addressing this issue yet.
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.