Android: Autenticação NTLM, ksoap e conexões persistentes

pós trabalhar com o iOS e lidar com os desafios de autenticação sem muita curva de aprendizado, descobri que a autenticação do Windows é muito mais complicada do que um processo em Java / Androi

Eu tentei várias abordagens diferentes; portanto, sem entrar muito nisso, chegarei à que funcionou na maior parte. Agora estou usando a classe criada para NTLM e ksoap chamada NtlmTransport

Agora estou autenticando com sucesso da seguinte maneira:

NtlmTransport httpTransport = new NtlmTransport();
            httpTransport.setCredentials(serverURL, Login.username, Login.password, deviceIp, "DOMAINNAME");
            httpTransport.call(SOAP_ACTION, envelope);

Se você der uma olhada na classe NtlmTransport, verá que está retornando os seguintes cabeçalhos do setupNtlm ():

status Linha HTTP / 1.1 200 OK Controle de cache de configuração: privado, idade máxima = 0 Tipo de Conteúdo de Configuração: text / html; charset = utf-8 Servidor de configuração: Microsoft-IIS / 8.0Setup X-AspNet-Version: 4.0.30319utenticação @ persistente de configuração: true Configuração X-Powered-By: ASP.NETSetup Data: Ter, 17 de setembro de 2013 20:57:45 GMTomprimento do Conteúdo @Setup: 11549

O "Persistent-Auth: true é o principal motivo de preocupação neste momento. Estou conseguindo os SoapObjects muito bem e posso obter os dados necessários nessa conexão, mas assim que tento acessar o serviço da web novamente, que provavelmente pode ser acessado após a autenticação bem-sucedida, não consigo acessar um método diferente usando o HttpTransportSE:

private void setSomething() {

    xml = null;
    final String SOAP_ACTION = "http://this.ismy.org/AWebServiceMethod";
    final String METHOD_NAME = "AWebServiceMethod";
    final String URL = protocol + "://" + host  + ":" + port + "/WebService.asmx";
    SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);
    SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER11);
    envelope.dotNet = true;
    envelope.setOutputSoapObject(request);
    envelope.implicitTypes = true;
    envelope.setAddAdornments(false);

    try
    {
        HttpTransportSE transport = new HttpTransportSE(URL);
        transport.debug = true;
        transport.call(SOAP_ACTION, envelope);
        xml = transport.responseDump.toString();
        Log.d(TAG, xml);
    }
    catch(SocketException ex)
    {
        Log.e("SocketException : " , "Error on setSomething() " + ex.getMessage());
    }
    catch (Exception e)
    {
        Log.e("Exception : " , "Error on setSomething() " + e.getMessage());
    }
}

sso tudo funciona muito bem como a tarefa em segundo plano de um AsyncTask, que passa o "xml" para um método XMLPullParse

A questão principal aqui é por que estou recebendo um:

Error em setSomething () Nenhum desafio de autenticação encontrado

??

Depois que o IIS valida com êxito o usuário com 200, por que ele está me pedindo para autenticar novamente? Como posso persistir no primeiro desafio autenticado para atingir qualquer método que eu queira dentro do WebService.asmx? Quais são os cabeçalhos que precisam ser adicionados / alterados para criar uma sessão, se necessário? O que sinto falta que faz todo esse processo NTLM funcionar e persistir por mais do que o método WS que precisa passar pelos desafios de autenticaçã

EDIT: Adicionando o código da Biblioteca

Aqui está o link para oJCIFS do Apache

public static final class JCIFSEngine implements NTLMEngine {

    private static final int TYPE_1_FLAGS =
            NtlmFlags.NTLMSSP_NEGOTIATE_56 |
                    NtlmFlags.NTLMSSP_NEGOTIATE_128 |
                    NtlmFlags.NTLMSSP_NEGOTIATE_NTLM2 |
                    NtlmFlags.NTLMSSP_NEGOTIATE_ALWAYS_SIGN |
                    NtlmFlags.NTLMSSP_REQUEST_TARGET;

    public String generateType1Msg(final String domain, final String workstation)
            throws NTLMEngineException {
        final Type1Message type1Message = new Type1Message(TYPE_1_FLAGS, domain, workstation);
        return jcifs.util.Base64.encode(type1Message.toByteArray());
    }

    public String generateType3Msg(final String username, final String password,
                                   final String domain, final String workstation, final String challenge)
            throws NTLMEngineException {
        Type2Message type2Message;
        try {
            type2Message = new Type2Message(jcifs.util.Base64.decode(challenge));
        } catch (final IOException exception) {
            throw new NTLMEngineException("Invalid NTLM type 2 message", exception);
        }
        final int type2Flags = type2Message.getFlags();
        final int type3Flags = type2Flags
                & (0xffffffff ^ (NtlmFlags.NTLMSSP_TARGET_TYPE_DOMAIN | NtlmFlags.NTLMSSP_TARGET_TYPE_SERVER));
        final Type3Message type3Message = new Type3Message(type2Message, Login.password, "",
                Login.username, deviceIp, type3Flags);

            System.out.println("type3Message: " + type3Message.toByteArray());

        return jcifs.util.Base64.encode(type3Message.toByteArray());
    }
}

Então, o "NtlmFlags.NTLMSSP_NEGOTIATE_ALWAYS_SIGN" está causando esse problema? Existe outra bandeira que eu devo colocar para o keep-alive? Além disso, encontrei um ótimo recurso para uma lista de sinalizadores NTLM e muito mais:http: //fossies.org/dox/jcifs-1.3.17/interfacejcifs_1_1ntlmssp_1_1NtlmFlags.htm