Kerberos and IP address.

[igolikov]

Hello, I found a strange issue: it is possible to use IP address instead of FQDN with Kerberos authentication.
First I tried it with Overthere 2.4.5 and it worked.
Then I tried it with Overthere 4.0.1 and it failed with "Server not found in Kerberos database".

Overthere 2.4.5 has httpclient-4.2.1 in dependencies
Overthere 4.0.1 has httpclient-4.4.1 in dependencies.

I override httpclient dependency for Overthere 4.0.1 from 4.4.1 to 4.2.1 and it stared working.

Here is an example that use IP for ConnectionOptions.ADDRESS.
It works fine with Overthere 4.0.1 and httpclient-4.3.3 (or httpclient-4.2.1).
With Overthere 4.0.1 and httpclient-4.4.1 it fails with "Server not found in Kerberos database"

I know that Kerberos "works" only with FQDN and doesn't work with IP. But overthere works with IP in some cases.
So is this a feature, or just an issue.

import com.xebialabs.overthere.CmdLine;
import com.xebialabs.overthere.ConnectionOptions;
import com.xebialabs.overthere.OperatingSystemFamily;
import com.xebialabs.overthere.Overthere;
import com.xebialabs.overthere.OverthereConnection;
import com.xebialabs.overthere.cifs.CifsConnectionBuilder;
import com.xebialabs.overthere.cifs.CifsConnectionType;
import com.xebialabs.overthere.util.CapturingOverthereExecutionOutputHandler;
import static com.xebialabs.overthere.util.CapturingOverthereExecutionOutputHandler.capturingHandler;
import org.apache.commons.codec.binary.Base64;

public class overthereIp {

    private static final String DOMAIN = "some.domain.com"; //<- PUT HERE REAL VALUE

    public static void main(String[] args) throws Exception {
        System.setProperty("sun.security.krb5.debug", "true");
        System.setProperty("java.security.krb5.realm", DOMAIN.toUpperCase());
        System.setProperty("java.security.krb5.kdc", "kdc_host." + DOMAIN);  //<- PUT HERE REAL VALUE

        final String encodedCmd = Base64.encodeBase64String("[System.Environment]::OSVersion.Version".getBytes("UTF_16LE"));

        ConnectionOptions options = new ConnectionOptions();
        //IP address instead of FQDN
        options.set(ConnectionOptions.ADDRESS, "x.x.x.x"); //<- PUT HERE REAL VALUE
        options.set(ConnectionOptions.USERNAME, "user.name@" + DOMAIN);  //<- PUT HERE REAL VALUE
        options.set(ConnectionOptions.PASSWORD, "password");  //<- PUT HERE REAL VALUE
        options.set(ConnectionOptions.OPERATING_SYSTEM, OperatingSystemFamily.WINDOWS);
        options.set(CifsConnectionBuilder.CONNECTION_TYPE, CifsConnectionType.WINRM_INTERNAL);
        exec(options, encodedCmd);
    }

    private static void exec(ConnectionOptions options, String encodedCmd) throws Exception {
        try (OverthereConnection con = Overthere.getConnection("cifs", options)) {

            CapturingOverthereExecutionOutputHandler innerOutputHandler;
            con.execute(innerOutputHandler = capturingHandler(),
                    capturingHandler(),
                    CmdLine.build("powershell",
                            "-NoProfile",
                            "-NonInteractive",
                            "-EncodedCommand",
                            encodedCmd));
            System.out.println(innerOutputHandler.getOutput());

        }
    }

}

[Jeroen van Erp]

I think that the current behaviour is correct. It would be possible to support the previous behaviour at the cost of an extra DNS lookup, which I think used to happen in older httpclient libs.

[igolikov]

I haven't found any revers DNS lookup calls in apache http libraries, at least calls that use InetAddress.
But I caught revers DNS request using Wireshark, maybe it is done by com.sun.jndi.dns.

[igolikov]

So is that overthere feature or not, should Kerberos works with IP or not?

Maybe that is just Kerberos server realization issue?

[Ashwin]

I tried above code and also with lot of other variations. I always get
Exception in thread "main" com.xebialabs.overthere.cifs.winrm.WinRmRuntimeIOException: Unexpected HTTP response on http://host.domain.com:5985/wsman: (500)

I see kerberos handshake and everthing worked fine i also was able to get tickets but not remote commands. Did anyone came across similar scenario

[igolikov]

Could you check that "allow unencrypted" is set to true?

500 error explanation you can find in winrm event log

[Ashwin]

Thank You that was issue. Not sure how i missed. Even winrm trace logs didn't give me much information while debugging.