We Keep Coding

Gerrit 2.15.12 - Kerberos + GSSAPI + Active Directory - possible bug in sending SPN

Running on RHEL 7.5 with Java 8. Kerberos 5 release 1.15.1.
We are seeing a strange behaviour with this set-up that has been seen in all versions since 2.11.10.
Note, I can't post direct logs or config as it my company blocks this.
Steps to reproduce
1) Configure gerrit to use kerberos
gerrit.config
[container]
javaHome = <path to JRE>
javaOptions = -Djava.security.auth.login.config=<path to jaas.conf>
[auth]
type = LDAP
[ldap]
authentication = GSSAPI
server = ldap://<AD Realm>
<.. other AD related stuff..>
jaas.conf
KerberosLogin {
com.sun.security.auth.module.Krb5LoginModule
required
useTicketCache=true
doNotPrompt=true
renewTGT=true;
};
which is direct from the documentation.
2) kinit the keytab to create a ticket in the cache.
3) Try to login. It fails with "Server not found in Kerberos database (7)".
It will also fail if you change the jaas.conf to try and use the keytab directly.
You can access LDAP directly using the username/password but due to Company restrictions we can't have an unencrypted password at rest on a device so this is not a viable long, term solution.
We have taken packet captures of the traffic to the AD Realm and we see the same behaviour whether we use the keytab or the cache.
1) For the kinit we see one request to AD with the SPN field set to the SPN from the keytab. This, of course, works fine.
2) For any request from Gerrit we see TWO requests to AD, the first has the correct SPN from the cache/keytab the second tries to send an SPN of "ldap/" no matter what value of SPN is set. This second request is what is causing the error as that SPN is not recognised b AD.. Note, we have tried keytabs with various SPN's (HTTP/device, host/device, HTTP/device# etc etc). The same thing happens every time.
This may well be something very simple is wrong in our config but we have been banging our heads on this for weeks now.

The second request most likely shows up because you specified an LDAP server ldap://<AD Realm> in Gerrit's configuration. HTTP GSSAPI authentication may very well have succeeded at this point, but now the application needs to authenticate itself against the LDAP server before it can retrieve information about the user. That happens independently from the HTTP authentication itself.
It's normal that the SPN is not recognized because Active Directory generally doesn't use <AD Realm> to pick a domain controller – instead the individual server names have to be specified, e.g. ldap://dc01.ad.example.com. (Real AD clients choose a server automatically via DNS SRV records, but plain LDAP clients often don't support that.)
Note also that a keytab is essentially an unencrypted password at rest.

Issue with DNS Naming and Certificates LDAP Context

With the last update of Java 1.8.0_181 I have an issue when I try to create a LDAPS connection to Active Directory. Up to version 1.8.0_171 using the following code I could create it without issues
Hashtable<String, Object> objEnvironment;
objEnvironment = new Hashtable<String, Object>(11);
objEnvironment.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
objEnvironment.put(Context.PROVIDER_URL, "LDAPS://domain:636");
objEnvironment.put(Context.SECURITY_AUTHENTICATION, "simple");
objEnvironment.put(Context.SECURITY_PRINCIPAL, <username>);
objEnvironment.put(Context.SECURITY_CREDENTIALS, <Password>);
objEnvironment.put("java.naming.ldap.attributes.binary", <attributes>);
System.setProperty("javax.net.ssl.trustStore", "certificates".concat(File.separator).concat("cacerts"));
this.objLDAPContext = new InitialLdapContext(objEnvironment, null);
However with the last version I get the following exception java.security.cert.CertificateException: No DNS name found for xxxx.xxxx.xxx
Looking it up I found it is an issue with the FDQN name, if I do not use the same name as it is displayed on the certificate, I can not establish a connection. I would like to know if there is a way to skip this and can use the domain name as I did in the past.

The issue you are experiencing may be due to the changes introduced in Java 1.8.0_181 for improved LDAP Support. Refer the release notes here.
➜ Improve LDAP support Endpoint identification has been enabled on
LDAPS connections.
To improve the robustness of LDAPS (secure LDAP over TLS )
connections, endpoint identification algorithms have been enabled by
default.
Note that there may be situations where some applications that were
previously able to successfully connect to an LDAPS server may no
longer be able to do so. Such applications may, if they deem
appropriate, disable endpoint identification using a new system
property: com.sun.jndi.ldap.object.disableEndpointIdentification.
Define this system property (or set it to true) to disable endpoint
identification algorithms.
You may use the workaround to add -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true while running your code.
Note that this is not a recommended approach, as your system will continue to be vulnerable using this approach.

RabbitMQ authentication without password

Because I don't need to consider security issues in my application, I want to connect to RabbitMQ using the Java client without a password.
In the management UI, I set the users password to "no password". Then I tried it this way:
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
factory.setUsername("myuser");
connection = factory.newConnection();
Alternatively, I tried to assemble the URI by hand:
factory.setUri("amqp://myuser#localhost:5672");
...but in both cases the authentication fails with this exception:
Exception in thread "main" com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:339)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:716)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:760)
at de.bmw.rabbitmq.workerqueue.Producer2.main(Producer2.java:51)
Is it even possible to get a connection without a password?

Passwordless authentication can be achieved by using the rabbitmq-auth-mechanism-ssl as documented here: https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl. This requires that SSL/TLS support is set up and working. If this option is chosen, a trusted root certificate is used for authentication, and any username/password is ignored altogether.
I'm currently investigating whether passwordless authentication is possible in conjunction with LDAP, but I haven't had any luck getting this to work.
Edit: In my environment, Windows services are authenticating using certificate-based auth, and the RabbitMQ cluster admins can authenticate to the management web UI using LDAP. In case you're interested in LDAP auth, here's another post about it.

Because I don't need to consider security issues in my application
I would heavily question this assumption. In fact, I would go so far as to say this is never correct.
That being said:
just use a simple password that anyone can know. It's going to be easier to do that, than to try and make RMQ work without a password.

To finalize this issue. As suggested by Derick Bailey: I helped myself by introducing (default) credentials for the different clients.

2way ssl with java

I am trying at write a java program that hits a url over ssl, and prints out the response to find out if the application on this port is running or not. We are using 2way ssl. I am fairly new to working with ssl and java security. Right now I am getting this error
Remote host closed connection during handshake
I am using this command to run the program
java -Djavax.net.ssl.trustStore=rs.truststore TmpUtil
Is there a way to find out what am I doing wrong and where exactly is the problem ?

You can generally debug an SSL/TLS connection that uses the JSSE in Java using the javax.net.debug system property. You'll find more details in the documentation.
Since you're after client-certificate authentication, it's most likely that your application needs a keystore to be configured. You'll find some details about the difference between keystore and truststore in this answer, and in the JSSE Reference Guide of course.

Connecting to a SOCKS5 proxy to do FTP/S in Java

I'm writing a job that will connect to a client's FTP/S server over my SOCKS5 proxy and I'm utilizing the Apache Commons Net package. The issue is that my SOCKS proxy is configured to not require authentication but I am still getting the following exception:
java.net.SocketException: SOCKS : authentication failed
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:443)
at java.net.Socket.connect(Socket.java:519)
I've tried setting the java.net.socks.username and password properties to empty strings but I still get it. Is there a way I can tell the code to not use authentication? Digging into the underlying source i almost think it's querying the proxy server for the authentication requirement, but I'm not sure.

Alright so the issue was that my SOCKS proxy was set up to ask for authentication but to also accept connections that did not authenticate. We use Dante and while programs like Filezilla are smart enough to iterate through all of the acceptable authentication methods, it seems like the java.net package only goes off the first method supplied. Since my authentication configuration in my sockd.conf file was as follows:
method: username none
user.notprivileged: nobody
java.net was demanding a username and password. I simply flipped the methods to "none username" and both Filezilla and java.net correctly pass through the proxy. It's a bit of an IT solution but whatever gets the code to work, right?