gmane.network.samba.java

Re: KerberosAuthExample Double Service Ticket Request

Michael B Allen — 2012-05-18T18:01:39

Hi Mike,

The jcifs-krb5 package was submitted by another party who do not
frequent this list so unfortunately I don't think you're going to get
the answers your looking for. All of the NTLM code in JCIFS has to be
abstracted before we can fold in proper Kerberos support. And that
would be something for a 2.x version (which has been on the TODO list
for a many years now).

For all practical purposes NTLM is perfectly suitable for most use
cases. If you want to utilize existing Kerberos credentials obtained
by other means such as through delegation then of course Kerberos
support in JCIFS would be required to use them. Otherwise, you should
use NTLM. NTLM is actually much more robust than Kerberos (as
evidenced in part by your DNS issue).

Mike

Re: KerberosAuthExample Double Service Ticket Request

Mike Patnode — 2012-05-09T23:10:41

So the problem was lack of the appropriate reverse DNS records.   Given the number of customer sites I've seen with reverse DNS configured incorrectly (including my client's development environment), is there a way to disable this requirement?

Re: Mac to windows File name conversion

Roy Mathews — 2012-05-17T08:03:11

Thank you so much George!!!!!!!!!!. We were searching this for the past one week. This allow us to map these characters while comparing.

Thanks and Regards,
Roy Mathew

From: George K Colley [mailto:gcolley< at >apple.com]
Sent: Wednesday, May 16, 2012 10:18 PM
To: Roy Mathews
Cc: jcifs< at >lists.samba.org
Subject: Re: [jcifs] Mac to windows File name conversion

On May 16, 2012, at 2:10 AM, Roy Mathews <roy< at >empressmam.com<mailto:roy< at >empressmam.com>> wrote:

Hi All,

We have an application to transfer file from mac to windows using smb(JCIFS) and another application in windows to handle these files. But when there is a invalid character like \ / : * ? " < > |  in filename , it will get converted to another character. This creates issue in filename comparison issues, since we are saving actual filename in database.
How smb converts these filenames?
Is there any specific rule for this character conversion, so that we can use that converted characters in database?

Regards,
Roy Mathew
These all should be converted into UTF16, you should check out http://support.microsoft.com/kb/q117258/  it shows these conversions.

George

Re: Mac to windows File name conversion

George K Colley — 2012-05-16T16:48:20

On May 16, 2012, at 2:10 AM, Roy Mathews <roy< at >empressmam.com> wrote:

These all should be converted into UTF16, you should check out http://support.microsoft.com/kb/q117258/  it shows these conversions.

George

Mac to windows File name conversion

Roy Mathews — 2012-05-16T09:10:32

Hi All,

We have an application to transfer file from mac to windows using smb(JCIFS) and another application in windows to handle these files. But when there is a invalid character like \ / : * ? " < > |  in filename , it will get converted to another character. This creates issue in filename comparison issues, since we are saving actual filename in database.
How smb converts these filenames?
Is there any specific rule for this character conversion, so that we can use that converted characters in database?

Regards,
Roy Mathew

Re: KerberosAuthExample Double Service Ticket Request

Mike Patnode — 2012-05-10T01:01:53


So the problem was lack of the appropriate reverse DNS records.   Given the number of customer sites I've seen with reverse DNS configured incorrectly (including my client's development environment), is there a way to disable this requirement?

KerberosAuthExample Double Service Ticket Request

Mike Patnode — 2012-05-09T21:32:40

So I'm trying to get the KerberosAuthExample to work with the latest jCIFS 
download: cifs-krb5-1.3.17

java -Djcifs.properties=jcifs.prp KerberosAuthExample bozo password 
smb://host.domain.name/C$/ dc1.domain.name DOMAIN.NAME

Via WireShark, the TGT and the TGS for cifs/host.domain.com are both 
successful, but after successfully creating the SmbFile object, line 50 of 
KerberosAuthExample.java does this seemingly innocent call:

       SmbFile[] files = file.listFiles();

For some reason, this triggers a second TGS request for cifs/xxx.xxx.xxx.xxx 
(IP address) which fails with unknown service on the AD side.   From debugging 
the code, it appears the code is simply trying to find the type of "C$" and 
needs a connection to do so, but the fact this generates a second TGS request 
(when it shouldn't need it) and it does so with the IP address rather than the 
host name seems to be wrong.  So a couple questions:

1. Shouldn't treeConnect just reuse the current service ticket?
2. If not, why is it trying to get one by IP address?  Is this a revDNS 
failure?

thx.  Full stack below:


$ java -Djcifs.properties=jcifs.prp KerberosAuthExample bozo password 
smb://server.domain.name/C$/ b-devdc1.domain.name DOMAIN.NAME
Debug is  true storeKey false useTicketCache false useKeyTab false doNotPrompt 
false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is 
false principal is null tryFirstPass is true useFirstPass is false storePass 
is false clearPass is false
username from shared state is bozo

username from shared state is bozo

password is password
Acquire TGT using AS Exchange
principal is bozo< at >DOMAIN.NAME
EncryptionKey: keyType=17 keyBytes (hex dump)=0000: A7 24 24 3D 55 7C 7A C1   
6E A7 85 92 6B 9C 07 EE  .$$=U.z.n...k...

EncryptionKey: keyType=23 keyBytes (hex dump)=0000: E0 90 27 99 87 1E BA 33   
8C 12 D2 E3 94 F9 D8 18  ..'....3........

EncryptionKey: keyType=3 keyBytes (hex dump)=0000: E9 F1 E3 FE 73 D9 8F 4A   
EncryptionKey: keyType=1 keyBytes (hex dump)=0000: E9 F1 E3 FE 73 D9 8F 4A   
[Krb5LoginModule] authentication succeeded
Commit Succeeded 

GSSException: No valid credentials provided (Mechanism level: Server not found 
in Kerberos database (7))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at jcifs.smb.SpnegoContext.initSecContext(SpnegoContext.java:80)
at jcifs.smb.Kerb5Authenticator.setup(Kerb5Authenticator.java:196)
at jcifs.smb.Kerb5Authenticator.access$000(Kerb5Authenticator.java:30)
at jcifs.smb.Kerb5Authenticator$1.run(Kerb5Authenticator.java:168)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at jcifs.smb.Kerb5Authenticator.sessionSetup
(Kerb5Authenticator.java:166)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:320)
at jcifs.smb.SmbSession.send(SmbSession.java:239)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:925)
at jcifs.smb.SmbFile.connect(SmbFile.java:974)
at jcifs.smb.SmbFile.connect0(SmbFile.java:890)
at jcifs.smb.SmbFile.getType(SmbFile.java:1302)
at jcifs.smb.SmbFile.doEnum(SmbFile.java:1753)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1735)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1668)
at KerberosAuthExample.main(KerberosAuthExample.java:50)
Caused by: KrbException: Server not found in Kerberos database (7)
at sun.security.krb5.KrbTgsRep.<init>(Unknown Source)
at sun.security.krb5.KrbTgsReq.getReply(Unknown Source)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(Unknown 
Source)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds
(Unknown Source)
at sun.security.krb5.Credentials.acquireServiceCreds(Unknown Source)
... 21 more
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.<init>(Unknown Source)
... 26 more
jcifs.smb.SmbException: No valid credentials provided (Mechanism level: Server 
not found in Kerberos database (7))
at jcifs.smb.Kerb5Authenticator.setup(Kerb5Authenticator.java:225)
at jcifs.smb.Kerb5Authenticator.access$000(Kerb5Authenticator.java:30)
at jcifs.smb.Kerb5Authenticator$1.run(Kerb5Authenticator.java:168)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at jcifs.smb.Kerb5Authenticator.sessionSetup
(Kerb5Authenticator.java:166)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:320)
at jcifs.smb.SmbSession.send(SmbSession.java:239)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:925)
at jcifs.smb.SmbFile.connect(SmbFile.java:974)
at jcifs.smb.SmbFile.connect0(SmbFile.java:890)
at jcifs.smb.SmbFile.getType(SmbFile.java:1302)
at jcifs.smb.SmbFile.doEnum(SmbFile.java:1753)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1735)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1668)
at KerberosAuthExample.main(KerberosAuthExample.java:50)

Re: Patch Suggestion

Michael B Allen — 2012-05-03T19:32:16

Hi Hardy,

Actually no. This is actually a flaw in the LogStream class. The code
I posted before will not work. The current LogStream implementation
looks like it might allow overriding PrintStream methods but the
stream parameter in the super(stream) call is actually being treated
as an OutputStream. So you can only override OutputStream methods and
not PrintStream methods. Because the PrintStream class could call
various write() methods multiple times for a single println call, that
is not very useful.

I have added this to the TODO list as something to fix.

The new implementation should probably look something like:

public class LogStream extends PrintStream
{

    private static String LINEBREAK = System.getProperty("line.separator");
    private static LogStream inst;

    public static int level = 1;

    public LogStream(OutputStream out)
    {
        super(out, true);
    }

    public static void setLevel(int level)
    {
        LogStream.level = level;
    }
    public static void setInstance(PrintStream stream)
    {
        if (stream == null) {
            inst = new LogStream(System.err);
        } else if (stream instanceof LogStream) {
            inst = (LogStream)stream;
        } else {
            inst = new LogStream(stream);
        }
    }
    public static LogStream getInstance()
    {
        if (inst == null)
            setInstance(null);
        return inst;
    }
    public void println(Object o)
    {
        byte[] msg = (o + LINEBREAK).getBytes();
        try {
            out.write(msg);
        } catch (IOException ioe) {
        }
    }
    public void println(String s)
    {
        byte[] msg = (s + LINEBREAK).getBytes();
        try {
            out.write(msg);
        } catch (IOException ioe) {
        }
    }
}

But I would have to study this for a while to make sure it's as simple
as it can be and backward compatible.

Mike

Re: Patch Suggestion

Hardy Cherry — 2012-05-02T23:06:11

After implementing Michael's solution I ran into some problems. Here is what I have and what I think is happening.

Let's say I have this class
public class TimeStampedJCIFSLogStream extends PrintStream
{
        private static final String newLine = System.getProperty("line.separator");

        public TimeStampedJCIFSLogStream(PrintStream stream)
        {
                super(stream);
        }

        < at >Override
        public void println(String x)
        {
                super.println(new java.util.Date().toString() + newLine + "  Source: jCIFS Error " + newLine + "  ERROR: " + x);
        }

        < at >Override
        public void print(String s)
        {
                super.print(new java.util.Date().toString() + newLine + "  Source: jCIFS Error " + newLine + "  ERROR: " + s);
        }
}

And here is the LogStream class in 1.3.17, I removed the log level variable because it's not important for this question.

public class LogStream extends PrintStream {

    private static LogStream inst;

    public LogStream( PrintStream stream ) {
        super( stream );
    }
    /**
     * This must be called before <tt>getInstance</tt> is called or
     * it will have no effect.
     */
    public static void setInstance( PrintStream stream ) {
        inst = new LogStream( stream );
    }
    public static LogStream getInstance() {
        if( inst == null ) {
            setInstance( System.err );
        }
        return inst;
    }
}

In my code I set up the LogStream like this.
LogStream.setInstance(new TimeStampedJCIFSLogStream (System.err))

Now at some jCIFS calls LogStream.println("Something to print");

It appears that when it calls println, it calls the PrintStream.println() function and bypasses the TimeStampedJCIFSLogStream.println() function. I believe that happens because when I call setInstance it sets the instance to a new LogStream. I guess since it wraps the passed in print stream (which is an instance of TimeStampedJCIFSLogStream), it overrides the overridden methods in TimeStampedJCIFSLogStream with the println function that LogStream inherits. Without making changes to the LogStream class is there any way to get the code to call the TimeStampedJCIFSLogStream.println() function instead of the LogStream.println function?


-Hardy


-----Original Message-----
From: Michael B Allen [mailto:ioplex< at >gmail.com]
Sent: Tuesday, May 01, 2012 5:50 AM
To: Hardy Cherry
Cc: jcifs< at >lists.samba.org
Subject: Re: [jcifs] Patch Suggestion

On Mon, Apr 30, 2012 at 1:07 PM, Hardy Cherry <hcherry< at >xactware.com> wrote:

Hi Hardy,

A patch is not necessary. Just extend the log stream class, override both println methods as desired and then install it with LogStream.setInstance().

But multiple lines for each entry is probably not what you want. A proper implementation would probably look something like:

class TimestampedLogStream extends jcifs.util.LogStream {

    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    TimestampedLogStream(OutputStream out)
    {
        super(out);
    }

    public void println(Object o)
    {
        synchronized (sdf) {
            super.println(sdf.format(new Date()) + ": " + o);
        }
    }
    public void println(String s)
    {
        synchronized (sdf) {
            super.println(sdf.format(new Date()) + ": " + s);
        }

And then install this early in your program somewhere with a statement like:

  jcifs.util.LogStream.setInstance(new TimestampedLogStream(System.err));

Mike

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

________________________________

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.

Re: Patch Suggestion

Michael B Allen — 2012-05-01T11:49:49

Hi Hardy,

A patch is not necessary. Just extend the log stream class, override
both println methods as desired and then install it with
LogStream.setInstance().

But multiple lines for each entry is probably not what you want. A
proper implementation would probably look something like:

class TimestampedLogStream extends jcifs.util.LogStream
{

    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    TimestampedLogStream(OutputStream out)
    {
        super(out);
    }

    public void println(Object o)
    {
        synchronized (sdf) {
            super.println(sdf.format(new Date()) + ": " + o);
        }
    }
    public void println(String s)
    {
        synchronized (sdf) {
            super.println(sdf.format(new Date()) + ": " + s);
        }

And then install this early in your program somewhere with a statement like:

  jcifs.util.LogStream.setInstance(new TimestampedLogStream(System.err));

Mike

Patch Suggestion

Hardy Cherry — 2012-04-30T17:07:20

We are investigating the use of jCIFS in one of our products. To monitor our error logs we use splunk which depends on each log having a timestamp.
Would it be possible to format the logs jCIFS creates so that they have a time stamp?

Here is my suggested change to the LogStream class:
Add an overrided version of println()

    < at >Override
    public void println(String x)
    {
       String newLine = System.getProperty("line.separator");
       //Format the error before printing it. Will look like this
       //Mon Apr 30 04:06:05 MDT 2012
       //  Source: jCIFS Error Logging
       //  ERROR: x
       super.println(new java.util.Date().toString() + newLine + "  Source: jCIFS Error Logging " + newLine + "  ERROR: " + x);
    }

Hardy

________________________________

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.

Re: Random problems connecting to DFS server

Michael B Allen — 2012-04-20T14:03:37

Hi Gabor,

Ok. Your description is actually an interest clue in itself. So it was
a worthwhile exercise. Thanks for trying it.

Mike

On Fri, Apr 20, 2012 at 8:15 AM, Gabor Herr <gabor.e.herr< at >googlemail.com> wrote:

Re: Random problems connecting to DFS server

Gabor Herr — 2012-04-20T12:15:11

Hi Mike,

I've just tried your suggested workaround with my test case. Unfortunately
it does not fix the problem. It looks like some method called from
Dfs.resolve gets delayed (maybe waiting for some server response) and in
the meanwhile tconHostname is set to null.

Gabor
 Am 19.04.2012 17:51 schrieb "Michael B Allen" <ioplex< at >gmail.com>:

Re: Random problems connecting to DFS server

Michael B Allen — 2012-04-19T15:51:13

There is a bug tracker. But it's just a web-based sortable "TODO list"
that only I have access to. If someone wants to +1 something just do
it on the list.

But this NPE is already listed high on the TODO list and, as I eluded
to in my initial response, the proposed "patch" is absolutely not
correct. I will have to investigate how the tconHostName can be null
after connect0 was called successfully.

A safer workaround for now might be to try something in
SmbFile.java:isConnected() like:

  return tree != null && tree.connectionState == 2 &&
tree.session.transport.tconHostName != null;

The rational is that if tconHostName is null, something called
doDisconnect so isConnected should probably return false. Then again,
if this is a concurrency issue this "workaround" could just cause the
code to go around in circles.

Mike

Re: Random problems connecting to DFS server

Gabor Herr — 2012-04-17T21:17:27

I don't know about any bug tracker for jcifs, so hopefully Mike has noticed
this post...

Gabor

2012/4/17 Simon Weatherill <simon-samba< at >weatherill.org>

Re: Random problems connecting to DFS server

Simon Weatherill — 2012-04-17T15:54:48

Absolutely.

Is this just for Mike's information, or is there a bugzilla somewhere
that I can increase its priority?

Simon

On 4/17/2012 11:49 AM, Gabor Herr wrote:

Re: Random problems connecting to DFS server

Gabor Herr — 2012-04-17T15:49:51

Great, good to hear that the fix worked for you. I assume we get a +1 from
you to include the patch into the main branch.

Gabor
Am 16.04.2012 23:58 schrieb "Simon Weatherill" <simon-samba< at >weatherill.org>:

Re: leading space char in smb file name

Michael B Allen — 2012-04-17T09:55:06

Thanks Jim,

You were already on the TODO but I updated to note your new post.

Note that the patch from sebastian.sickelmann< at >gmx.de on Aug 15, 2011
might be more interesting at first glance. I just put it in the
patches directory. It's called url_leading_space.patch. Not sure if it
properly handles the # symbols though.

Whatever the case, this is already on the TODO list twice.

Mike

On Mon, Apr 16, 2012 at 7:48 AM, Jim Hurne <hurne< at >vivisimo.com> wrote:

Re: Random problems connecting to DFS server

Simon Weatherill — 2012-04-16T21:58:21

Thank you, thank you, thank you!

That fixed the problem. Thanks for the quick response.

Simon

On 4/16/2012 5:40 PM, Gabor Herr wrote:

Re: Random problems connecting to DFS server

Gabor Herr — 2012-04-16T21:40:53

Hi Simon,

This sounds very similar to our jcifs problem reported in
https://lists.samba.org/archive/jcifs/2012-March/009874.html

Maybe you could give a try with the patch suggested in my post. It should
also work with version 1.3.17.

Good luck...

Gabor

Am 16.04.2012 21:59 schrieb "Simon Weatherill" <simon-samba< at >weatherill.org>:

Random problems connecting to DFS server

Simon Weatherill — 2012-04-16T19:53:15

I've been seeing many errors that have a final stack trace of
jcifs.smb.Dfs.resolve(Dfs.java:169) (jCIFS 1.3.17):

java.lang.NullPointerException
        at jcifs.smb.Dfs.resolve(Dfs.java:169)
        at jcifs.smb.SmbFile.resolveDfs(SmbFile.java:671)
        at jcifs.smb.SmbFile.getDfsPath(SmbFile.java:1536)
        at ListFiles.main(ListFiles.java:45)

I'm using a slightly modified ListFiles.java to test this. I have a list
of 12608 directories, which all exist. If I invoke ListFiles for each
directory separately, it completes fine. If I invoke it once for all
directories, it will fail after reading about 3000 directories. If I add
a test to see if the path exists before calling listFiles(), the problem
goes away. I don't know if it is an issue of timing or whether the
exists() call does something that avoids the problem. Once the problem
starts all remaining  directories have the same problem.

I added a getDfsPath() call (and printed the result) thinking that might
point in a particular direction. When I add this, it fails on the
getDfsPath() before it gets to getFiles().

We're using jCIFS in an RMI server that is always running. We can clear
up the problem by restarting the server, but it comes back.

Any ideas?

Thanks,
Simon