I am working on freeRADIUS v1.1.7-r0.0.2 with LDAP as backend for authenticating users.
I want to configure freeRADIUS server with certificates instead of using usernames and passwords.
How to configure RADIUS+LDAP using SASL/Certificate based binding ?
Please guide me how to achieve this,is there any help/doc how to configure LDAP SASL bind for RADIUS Server.
Support for SASL binding was recently added in v3.0.x, both for administrative binds, and user binds, it's not available in previous versions.
See the SASL sections in the config here
Certificated based binding has always been supported. It's configured with the certificate_file and private_key_file config items.
You cannot pass the SSL tunnel through from something like an EAP conversation.
Related
Where in the configuration do you enable/disable authentication for JMX in Artemis? In the artemis.profile file I have -Dcom.sun.management.jmxremote.authenticate=false on two instances of Artemis, one on a local VM and one on a remote VM. The local one doesn't require authentication (such as from JConsole) and will fail if I give is the user/password. The remote instance requires authentication, which accepts the user/password I created when setting up Artemis.
Is there another configuration I'm missing?
ActiveMQ Artemis guards JMX calls using role based authentication that leverages Artemis's JAAS plugin support with the login.config file. This is configured via the authorisation element in the management.xml configuration file and can be used to restrict access to attributes and methods on mbeans.
I just set up an freeradius server (Version 2.2.5) on an Raspeberian PI with DaloRadius 0.99 web interface. OS = Debian Jessy. I do not use certificates for authentification.
Everythings working fine, I restricted the used authentification types to "PEAP" for 1st authentification and the inner-tunnel (second auth to MSCHAP(V2)).
Now I recognized when I configure a client using PEAP and no inner tunnel Auth method it's although possible to dial in.
I want to restrict the second auth to only accept MSCHAP/MSCHAPV2 and not "none" as auth metohd.
I have used ldap based camunda-auth to login to the application using HttpBasicAuthenticationProvider provided by camunda, where how can I implement https login and is it supported by camunda (or) we need to use spring security?
Please send any link related or config to camunda - https implementation.
I am not sure I understood you correctly- you want to set up camunda to have TLS and additionally you want LDAP authorization?
To set up TLS, you need to configure it directly on Tomcat server.
First you need to obtain/generate certificates.
Then you need to point to those certificates in server.xml configuration file.
Just google "TLS on Tomcat". I'm sure there are hundreds of tutorials how to do this step by step.
When it comes to LDAP integration - follow documentation:
https://docs.camunda.org/manual/7.8/installation/full/tomcat/configuration/#ldap
We want to migrate our custom steps from XAML build to new build task in TFS2015 on-premise. I installed NodeJS and tfx-cli but when tfx-cli want to connect to TFS I need to provide pat (personal access token) but I cannot find where I can get it. All samples is for VSO but not for on-premise TFS2015. Is it possible to get PAT from on-premise TFS2015?
TFS 2015 doesn't support Personal Access Tokens, this feature was introduced with TFS 2017. In the mean time you'll either need to configure basic auth and use that (only enable basic auth if your TFS server is running over SSL), Or use the trick below to trick the command lien tools to authenticate by lettign an NTLM proxy (like Fiddler) handle the auth for you.
If you do not want to configure Basic Authentication on your TFS server (which many people don't want due to security concerns), then you can use a neat trick to let Fiddler handle your authentication:
Then enter:
C:\>set http_proxy=http://localhost:8888
C:\>tfx login --auth-type basic --service-url http://jessehouwing:8080/tfs/DefaultCollection
You'll be prompted for a username and a password, it doesn't really matter what you enter, fiddler will handle the authentication for you in the background:
More detailed steps outlined on my blog.
If you're battling self-signed certificates, which is also a common problem when using tfx against a on-premise TFS server, make sure you're using a recent enough version of Node and point it to an aditional cert store using environment variables:
As of Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) it is now possible to add extra well-known certificates to Node.js with an environment variable. This can be useful in cloud or other deployment environments to add trusted certificates as a matter of policy (as opposed to explicit coding), or on personal machines, for example, to add the CAs for proxy servers.
See the CLI documentation for more information on using NODE_EXTRA_CA_CERTS, as well as the original pull-request.
NODE_EXTRA_CA_CERTS=file#
Added in: v7.3.0
When set, the well known "root" CAs (like VeriSign) will be extended with the extra certificates in file. The file should consist of one or more trusted certificates in PEM format. A message will be emitted (once) with process.emitWarning() if the file is missing or malformed, but any errors are otherwise ignored.
Note that neither the well known nor extra certificates are used when the ca options property is explicitly specified for a TLS or HTTPS client or server.
There's another option for tfx-cli to connect to the TFS instance, and it is basic authentication. Just use the following format:
tfx login --auth-type basic --username myuser --password mypassword --service-url http://tfscollectionurl
Here is the quote from Github:
You can alternatively use basic auth by passing --auth-type basic
(read Configuring Basic Auth). NTLM will come soon.
Note: Using this feature will store your login credentials on disk in
plain text.
I have a simple Grails app that I've written to authenticate against an LDAP server. To develop it, I've installed ApacheDS locally and populated it with an LDIF file. Now I want to deploy it to CloudBees. Is it possible to install an LDAP server on CloudBees?
If not, an alternative seems to be to use the Grails ldap-server plugin. However, it doesn't have any documentation on how to configure it. How do I configure this plugin to load an LDIF on startup?
Unfortunately, running LDAP in a CloudBees app container/stack won't work because in-bound routing to your application port must be over HTTP/HTTPS.
Alternative 1: host the LDAP server outside of CloudBees (like on your own EC2 server)
Alternative 2: [for the highly motivated] you might be able to get a WebSocket gateway of some kind to work, but you'd special code on the client and server side to negotiate the socket stream hand-off outside of the LDAP server and client. [Client -> WS-Client --> CloudBees --> WS-Server --> LDAP Server]
gripe: why can't all protocols support virtual hosting like HTTP? -- that would make them much more Cloud-friendly :(