I have customized a new LDAP plugin to provide basic Zookeeper Authenication.
some thing like
setAcl /zookeeperPath ldap:<Group>:crwda
and when I check for the znodes
addAuth ldap:<uid>:password
will grant me access to the znodes
I know this can be done using the kerberos. But in my enterprise Linux Auth is doe through sssd. kerberos is not enabled.
I am afraid I have done some customization that should have not been done. Because, I did not get any reference from internet to do it.
If theare are any plugins thats been already used please help.
There are no ldap auth plugin for zookeeper. As zookeeper supports SASL kerberos authentication. But additional ACLs can be set using Active directory or LDAP group permissions. This can be achieved by implementing
org.apache.zookeeper.server.auth.AuthenticationProvider
and settng -D params as
-Dzookeeper.authProvider.1=class.path.to.XyzAuthenticationProvider
Related
How can I connect from NIFI to a Kerberos enabled Kudu?
I only see one processor to access Kudu - PutKUDU and it doesn't support Kerberos. I haven't seen anywhere online any discussion regarding connecting to Kudu with Kerberos. Am I missing something?
Thanks!
This is being worked on now and there is a pull request to add support for keberos to PutKudu:
https://github.com/apache/nifi/pull/3279 - NIFI-5984: Enabled Kerberos Authentication for PutKudu
I don't believe there is a way to do it without the work in that pull request.
I have an application which uses LDAP authentication against AD, which works fine. However the UserDN and password for accessing LDAP are in clear text in the config files, and I would like to avoid clear text passwords.
In Softerra LDAP browser you have the option to authenticate with "Currently logged in user", does anyone know if this type of Windows Authentication is possible with Spring LDAP? Or is there perhaps another way to avoid credentials in config files (like using the credentials of the user trying to authenticate)?
With Microsoft SQL server, it is possible to do Windows Authentication via JDBC, since Microsoft provides some native code, has anyone heard about a similar functionality when using LDAP against AD?
"Currently logged in user"
this may mean that Kerberos based SASL authentication is used
You may check
https://docs.spring.io/spring-security-kerberos/docs/current/reference/htmlsingle/#ssk-kerberosldap
and
https://docs.spring.io/autorepo/docs/spring-security-kerberos/1.0.1.RELEASE/api/org/springframework/security/kerberos/client/ldap/KerberosLdapContextSource.html
The latter shows how the Kerberos ticket cache can be used.
I am able to obtain information about the current deployments on the JBoss Server via JBoss CLI. (deployment-info)
I can connect to the JBoss CLI directly from the ssh terminal or from an web interface (Management console).
By using the CLI there would be much more possible then querying the deployment info.
Does anybody know if it is possible to have an user which has restricted or limited rights for the JBoss CLI?
So that this user has only rights to query the deployment information but nothing else, for instance.
You can RBAC for JBoss instance and configure user with 'monitor' role. User with this role can only perform Read-only operation. Go through documentation for more details on RBAC
I have a Java API that talks to the Kerberos server and performs various operations. As of now, my API requests for non-renewable tickets to the Kerberos server. From what I understand, the jaas config file has an option to set the renewTGT option to true so that a renewable ticket can be issued. However, Jaas seems to have a lot of restrictions on setting the "renewUntil" time. Can anyone please tell me how we can request for arenewable ticket and also control its renewability? Basically, is there a way we can perform a Java equivalent of the operation : kinit -R ? Thanks in advance.
As of JDK7 (1.7.0_55), JAAS Krb5LoginModule does not provide any option to request a renewable TGT when authenticating, so this is not currently possible using JAAS. You might be able to achieve this, but you would need to use the internal Kerberos classes directly, bypassing JAAS.
Internally, Krb5LoginModule instantiates a sun.security.krb5.KrbAsReqBuilder to obtain credentials using either a provided password, or a keyTab. KrbAsReqBuilder has a setOptions(KDCOptions options) method, but this is not called in the login module. If it could be accessed, you could call KDCOptions#set(KDCOptions.RENEWABLE, true), and I would then expect the returned ticket to be renewable, if the KDC is configured to allow renewable tickets.
Is it possible to have a Java process running on linux access EWS using kerberos only without the need of a pre-defined username/password combination?
My current system architecture consists of a Java process that accesses EWS using a stored username/password combination. Requirement is to ensure that the credentials under which the Java process runs are authenticated on Exchange using Kerberos.
Is it possible to have this setup?
yes, it should be possible to authenticate to EWS using Kerberos. You can Java GSSAPI to get the Kerberos tickets (from the ticket cache or prompt the user). There is a Java GSS Sample program at http://docs.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/BasicClientServer.html
Your question seems to be more on what Java can do versus what Exchange/IIS can do. I don't know Java well at all, however I do know EWS and IIS topics well.
Here is something to keep in mind - IIS does the authentication and not EWS. You could do an HTTP GET on a file in a virtual folder on an IIS server to verify that your API works. If you can authenticate to IIS, then EWS should work. Now having said that you also need do consifer access issues - ie impersonation and delegateion - you will need to be sure you have the needed content in the EWS XML and have the correct Exchange settings for Impersonation and correct folder permissions set for delegation.
Yes, it is possible. It is already implemented in "JWebServices for Exchange", Java API for EWS
You ticket a TGT in the ticket cache or a keytab for that account.