[jcifs] Logon failure: unknown user name or bad password

[Michael B Allen]

On Wed, Jul 27, 2011 at 2:22 PM, Jason Millard <jsm174 at gmail.com> wrote:
>>
>> Unfortunately no. The jcifs-krb5 branch was contributed by another
>> party with the hope that it would catalyze the integration of Kerberos
>> into the main JCIFS codebase. However, the core JCIFS API based on the
>> SmbFile class has not changed much in almost 10 years and as such it
>> has NtlmPasswordAuthentication class references littered throughout.
>> All of these NTLM specific credential references will need to be
>> factored out and that is not something that can happen in 1.x. So
>> Kerberos is a 2.0 feature and there are currently no plans for working
>> on a 2.0. Even though technically the jcifs-krb5 codebase works, it
>> has numerous problems that would make it difficult to work with.
>> Credential management being one of the main problems. I'm not sure
>> that anyone really uses it seriously. Ultimately it is a
>> proof-of-concept package.
>>
>
> Thank you for explaining everything so thoroughly. I really appreciate
> it. I spent an hour with KerberosAuthExample.java and was finally able
> to get authentication to succeed, but then the directory listing kept
> failed.
>
>    [Krb5LoginModule] authentication succeeded
>    Commit Succeeded
>
>    jcifs.smb.SmbException: Invalid operation for   service
>
>
> Since the krb5 branch is just a proof of concept, I won't put any more
> effort into it. I was thinking the credential management might be an
> issue anyway.

Note that for the jcifs-krb5 codebase to work properly you will almost
certainly have to craft a krb5.conf that sets default_tkt_enctypes,
default_tgs_enctypes and permitted_enctypes = aes128-cts rc4-hmac or
some permutation thereof. Like I said, credential management in
jcifs-krb5 is not satisfactory (although in this particular it should
be pointed out that Sun's krb5 implementation is weak because it
should permit stateless configuration and not require a global static
krb5.conf file at all).

And it's equally possible that this "F5 ARX" appliance is just not
very good. A lot of these appliances like Netapp and EMC are somewhat
fickle. My impression is that the people that write these appliances
just write code until the various Windows clients work and stop there.
Meaning JCIFS could be sending something completely legitimate but the
server will just cut off the client with some almost meaningless error
(like "Invalid operation for service") at the first sign of a problem.
Windows servers are much more forgiving.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/