We have a Windows application which is communicating fine via the WebHDFS Client (In the Incubator phase) http:/ /hadoopsdk.codeplex.com/wikipage?title=WebHDFS%20Client&referringTitle=Home
to a Cloudera Hadoop installation. The next phase is to establish Kerberos authentication via http. I am having difficulty finding much on this topic between a Windows client and a Linux/Apache server.
Most of the examples I've seen are using cURL --negotiate as the mechanism :
http://hadoop.apache.org/docs/r1.0.4/webhdfs.html#Delegation+Token+Operations
Everything else I've found for .Net has been really low level
http://msdn.microsoft.com/en-us/library/ms995331.aspx
Is there anything out there that I can use or am I going to have to write custom code?
I found the solution to my problem being that I misunderstood how Kerebros SNEGO was implemented.
For those of you that are in the same predicament I hope this helps..The authentication is done between the client (Windows machine) and the kdc (Linux) at the time of the users logon of the client (for one configuration). After the ticket has been issued WebHDFS communication can be established in a more secure manner. This quote is from the Cloudera team (which were extremely helpful BTW).
"If the Cloudera cluster is kerberized then WebHDFS on the server side will accept SPNEGO Kerberos authentication. If the cluster is kerberized directly in AD realm and if the end user has logged into the same AD domain, that should be enough if the Microsoft clients supports it. Otherwise they either have to authenticate to the same kerberos realm with a MIT kerberos client and kinit or one way trust should be setup between the cluster kerberos realm and the AD realm where the endusers are authenticating."
Related
There is an example in gRPC:
Channel channel = new Channel("127.0.0.1:30051", ChannelCredentials.Insecure);
it works. Now I would like to authenticate the user on server either using the login / password pair or using Windows trusted authentication.
The authentication documentation https://grpc.io/docs/guides/auth/ shows some examples:
either with some PEM certificate that has nothing to do with windows account
or with a "trusted" authentication, but not in the meaning that one Windows computer trusts to the other Windows. The meaning is that credentials are trusted with Google.
Is it possible to do Windows-trusted authentication between two Windows PCs using gRPC?
I believe client-side SSL is what you are looking for: https://grpc.io/docs/guides/auth/#using-client-side-ssltls
You want to authenticate both ends of the connection. This won't be a simple task, since you have to manage and update certificates in clusters.
If what you are looking for is Windows account specific integration, I don't think gRPC is providing one today. You may post a feature request to https://github.com/grpc/grpc/issues.
I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
I've asked a similar question in the past: Understanding ADFS Login With Windows Native WPF Client and I seem to have a better understanding of how to authenticate with activity directory ADFS on a WPF Native Windows application (I can use ADAL libraries), but I'm still out of the loop on how I would transfer that authentication to a remote server (NodeJS server)
I've also discovered I can do something like this in order for the native WPF application to find what user is currently logged on, and by using this, the WPF knows that the user is legit since they're logged on to their Windows account.
var context = new PrincipalContext(ContextType.Domain, DOMAINNAME);
var user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, Environment.UserName);
But, I don't know how I can transfer this authentication to our remote NodeJS server (no UI, the WPF application is the UI). I can send our remote application details like, the samAccountName is this, but anyone can send to our remote server and claim their samAccountName is this. The WPF knows the user is legit, but our NodeJS application can't verify that. If I add a private certificate to our WPF application for our NodeJS server to verify, the WPF application could be decompiled to get the cert. How do I resolve this?
You are considering authentication in wrong context. e.g. as Node server provide you services, so each client should identify himself to Node server in order to consume Node services.
In your implementation, you are authenticating wpf from AD, which is ok, but WPF app acts as a client to Node server, therefore there should be another authentication to provide claim that valid wpf client is connected to server.
Now come to the point, you want to authenticate WPF client + Node server from AD.In this case, actually you are authenticating both apps from some source i.e. AD. To do this you need some middle ware, which can validate both apps.
The answer to this situation is Microsoft Identity Server. Please visit some tutorial, hopefully it will solve your requirement.
I have configured RabbitMQ but at the moment it is using simple username/password to connect to the queue. This isn't ideal as I'm having to store the password in the application config.
Ideally, I would like authentication to work like it does for an intranet application - using NTLM to implicitly pass my authentication to Rabbit.
I have enabled LDAP in the config which allows me to manage users in AD, but it still requires the password to be stored and sent.
Has anybody managed to get RabbitMQ authentication working with NTML (or Kerberos)?
Thanks
RabbitMQ does not support NTLM authentication at this time, as I noted in my response here on the rabbitmq-users mailing list.
Support could be added via a plugin, however.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I have created an ASP.NET website that has to access Active Directory on another server and change users passwords. The problem is that I need to authenticate with existing AD account and I cannot send AD user's password in plaintext when communicating with the Active Directory server. How do I communicate with AD server from ASP.NET website, so that connection is secure? My AD server supports LDAP protocol, but I do not know how to enforce communication with LDAP via a secure channel.
ASP.NET Website --------------LDAP/another protocol (secure)------------> AD Server
Fairly simple, you need to do two things :
Configure your Active Directory instance to accept connections over LDAPS, or port 636. You'll need a certificate (it can be self-signed) to set that up.
Update your LDAP authorization code to use this the new connection. This shouldn't be anything more than changing the server to "ldaps://{{IP OR DNS}}", and ensuring you're setting SessionOptions.SecureSocketLayer = true;
If you want to verify that it's working properly, Wireshark the traffic leaving your ASP.Net site that's going over port 636, and you should notice it's now heavily encrypted, and impossible to discern anything meaningful from.
I've done a ton of this stuff over the years, so I've had a few other questions surrounding this that should also help you out :
Set callback for System.DirectoryServices.DirectoryEntry to handle self-signed SSL certificate?
(This contains a full implementation of LDAPS)
Custom Multi-factor Active Directory Authentication
(This is a much more simple example, but would work perfectly fine for your purposes)