Mac to windows File name conversion

Re: KerberosAuthExample Double Service Ticket Request

KerberosAuthExample Double Service Ticket Request

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)

Patch Suggestion

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()

    @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.

Random problems connecting to DFS server

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

LM Auth level and lmCompatibility/useExtendedSecurity settings

Hello,

This question is partly about JCIFS and since I am not too familar with Windows
 settings, it is partly about the Windows "Network Security: LAN Manager
 authentication level" setting in Local Security Policy/Domain Security Policy.

I am trying to use the JCIFS HTTP Servlet Filter for NTLM authentication for a
 java web application running in a web container (JBoss, Weblogic, Websphere). I
 have read the page "JCIFS NTLM HTTP Authentication" and other pages on the
 JCIFS site, as well as browsed the mailing list archives.

I understand that the JCIFS HTTP NTLM filter only supports NTLM v1. So what does 
 that translate to in terms of the above Windows setting and the corresponding
 JCIFS settings? Specifically, in order to use the JCIFS filter, what values do
 I need to set the following to:

1. On Domain Controller machine, Domain Controller Security Policy -> 
LAN Manager authentication level
2. On Domain Controller machine, Domain Security Policy -> LAN Manager 
authentication level
3. On the machine hosting the web container, Local Security Policy -> LAN
Manager authentication level
4. On the client machine running IE, Local Security Policy -> LAN Manager
 authentication level
5. JCIFS parameter jcifs.smb.lmCompatibility
6. JCIFS parameter jcifs.smb.client.useExtendedSecurity

If some of these are not relevant, I would appreciate knowing that as well. Any
 help will be appreciated!
-Sameer

leading space char in smb file name

Hi,
I had a problem with the SmbFile.
I had a file with name "smb://server/share/folder/ foo.bar" on a smb server  ( foo.bar with leading blank).
This file was created with jcifs, but calling 
new SmbFile("smb://server/share/folder/").listFiles[0].getName() only returns "foo.bar" with no
leading blank. 

Before I had this problem, I didn't believe that it is possible to have files with leading blanks...

I've analyzed the problem, and figured out, that everything is transfered correct from the server to jcifs.
In the internal variable unc the path is stored with blank, but in canon, what is used for get name it's not.

I hope that helps improving jcifs

Regards

Michael

help me!!!

hi:
   i use jcifs-ext-0.9.jar  to  add user,change password
   when i operate windows server2003 it ok,but 2008 server can not
create,and change password.

    can you help me !

--

-- 
Best Regards,
Wu Xin

Problem with Windows 7 NTLM authentication

version 1.3.17 and 1.3.14 broken for NetApp DataFort

Connecting to an encrypted NetApp DataFort share does not work with jcifs 1.3.17
and 1.3.14. It does work, however, with versions 1.2.24 and 1.1.11 (these were
the ones I tested with). 

Although the user/password is correct the following exception is thrown:

jcifs.smb.SmbAuthException: The specified network password is not correct.
      at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:546)
~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbTransport.send(SmbTransport.java:663) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:316)
~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbSession.send(SmbSession.java:218) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbTree.send(SmbTree.java:74) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbFile.send(SmbFile.java:775) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1986) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbFile.doEnum(SmbFile.java:1738) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715) ~[jcifs-1.3.17.jar:na]
      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1648) ~[jcifs-1.3.17.jar:na]
      at de.bayernlb.bacab.FileShovel.main(FileShovel.java:32) ~[classes/:na]

Contributing to JCIFS, git and the Linux dev model

On Wed, Mar 21, 2012 at 1:22 PM, Michael B Allen <ioplex <at> gmail.com> wrote:
> Hi Xavier,
>
> The changes required to get the owner SID are simple enough that using
> an actual patch would be a waste of time. Just look at what that patch
> does and make the necessary changes by hand. It just adds a few lines

Incidentally, someone recently made a change to JCIFS (totally
unrelated to this owner sid thing), put the whole working modified
package in github and then wrote a little blurb about it in their
blog. I think that is a really good way to contribute to JCIFS. It
makes it very easy for someone to quickly try the change. And what is
perhaps more important is that it will increase the likelihood of
incorporating the change into the stock package.

The Linux development model is so much better than conventional
version control. Disk space is cheap. Just put a complete working
package out there. If the change is useful it will bubble to the
surface. If it is not, you're not wasting anyone's time.

And it is ironic that I think it was Andew Tridgell of Samba who was
in a way responsible for triggering the creation of git and by
induction the Linux development model because IIRC he somehow pissed
off the person handling the old version control system and that in
turn pissed off Linus so much he create git. I bet their friends again
now.

Mike

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