From Jim.Smyth at broadvision.com Thu Dec 1 03:05:06 2005 From: Jim.Smyth at broadvision.com (Smyth, Jim) Date: Thu Dec 1 03:04:27 2005 Subject: [jcifs] MSIE decides to lose Authenticate header during negociate Message-ID: Hi, Im not sure what has happened - my implmentation of a autologon to my portal app was pretty much working, now it seems that MSIE doesnt want to play anymore, though Firefox is working as well as ever. >From what I can see, the Authorization header is not sent back to the server after the type 2 message is returned to the client, so that the client then is requested for a type 1 message again. After a few attempts, MSIE gives up and I get a 'Cannot find server or DNS Error' error. (This is what I see by debugging the filter). The client side shows a slightly different picture - ieHTTPHeaders shows that when the type2 message is received by MSIE, it sends a request with a type3 message but this immediately followed (replaced?) by a similair GET request without the Autorization header. This happens if the user is in the domain (transparent auth) or out of the domain (network login dialog). As Firefox works well in both scenarios I suspect that MSIE settings are the issue, but havent managed to discover why yet. Any pointers appreciated. rgds jim From rleyman at csc.com Fri Dec 2 01:06:58 2005 From: rleyman at csc.com (Richard Leyman) Date: Fri Dec 2 01:08:43 2005 Subject: [jcifs] Richard Leyman/GIS/CSC is out of the office. Message-ID: I will be out of the office starting 01/12/2005 and will not return until 05/12/2005. I will respond to your message when I return. If it can't wait and is a fault call please email Nathan Trowbridge and/or Paul C Jones. From Kevin.Tapperson at hcahealthcare.com Mon Dec 5 17:11:29 2005 From: Kevin.Tapperson at hcahealthcare.com (Tapperson Kevin) Date: Mon Dec 5 17:11:51 2005 Subject: [jcifs] Re: Re: Loadbalancing with NTLMServlet/Filter Message-ID: <468F31CDD9EE944FA0D9D30620E63E3301827212@NASEV02.hca.corpad.net> There's even more to this issue than has been described. If you have a multi-process (not multi-threaded, but truly multi-process), load-balanced app server, try creating a simple .html file like this: Test Page Save this file locally on your computer and then load it into your browser using a file: URL. What ends up happening here is that the browser makes multiple simultaneous requests to the app servers. These requests initially get routed per the load balancer policy to different app servers (random, round-robin, etc). The app servers all independently respond with HTTP 401 errors requesting NTLM authentication, and each app server supplies a different JSESSIONID cookie. At some point during (or after) the authentication process, the browser will choose to "standardize" on a single JSESSIONID cookie for the server. Depending on when the browser chooses a single JSESSIONID cookie, there are 2 different cases to describe. CASE A: The browser _sometimes_ selects a single JSESSIONID cookie to "standardize" on and use to submit the NTLM type 1 requests. If it selects a single JSESSIONID cookie to use for the NTLM type 1 requests, then a problem arises in that once the first NTLM type 3 request is processed by the app server, the NtlmHttpChal attribute is removed from the session (ssn.removeAttribute("NtlmHttpChal") in NtlmHttpFilter). The next NTLM type 3 requests will be required to obtain a new NTLM challenge, and _may_ not get the same transport/challenge that was originally used for the NTLM type 2 response sent by the app server. CASE B: We have also seen, however, that the browser could elect to use the different distinct JSESSIONID cookies to submit the NTLM type 1 requests, and not "standardize" on a JSESSIONID cookie until it submits the NTLM type 3 requests. In this case, you end up with multiple independent app servers creating SMB transports and generating NTLM challenges and saving those challenges in different sessions on the different app servers. When the browser chooses to "standardize" on a single JSESSIONID cookie, the NTLM type 3 requests then all get submitted to a single app server. This results in NTLM type 3 requests with the NTLM responses being sent to an app server that will be unable to properly verify the responses, because the app server that the NTLM type 3 requests are submitted to does not have the corresponding SMB transport with the proper transport encryption key (challenge) to verify the NTLM responses. We have seen with the sample .html file above, that we usually get a mix of case A and case B as described above. There is no predictable pattern to how/when the browser will choose to "standardize" on a JSESSIONID cookie. The only way that I have thought of to completely resolve this issue is to create a cluster-wide map to save the NTLM challenges used when the NTLM type 2 response is generated. This map would require that the key be completely independent of the session ID, as the browser can (and does) choose to change sessions during the middle of the NTLM negotiation process. The map key could be based on remote IP address, request URI and query string (but even this poses a potential problem if you have multiple users on a shared machine who happen to require NTLM authentication simultaneously for the same URI). (This is highly unlikely, but in my experience with concurrent programming, if you leave the window open, bugs will fly in.) This is why Microsoft stipulates that connection keep-alives MUST be used for NTLM authentication to succeed. If connection keep-alives are used, then you are guaranteed to return to the same server to continue the NTLM negotiation process. I'm not sure how this could be used in a multi-tiered environment where there is a web server tier (Apache/IBM HttpServer) in front of the app server tier where the jcifs code actually executes. >From: Smyth, Jim broadvision.com> >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter >Newsgroups: gmane.network.samba.java >Date: 2005-11-23 01:10:51 GMT (1 week, 5 days, 15 hours and 13 minutes ago) >Hi, > >I experienced an issue with using jcifs on applications running across multiple app servers which I found >reported some time ago (see below). I believe the end solution may not be correct. To recap (and fully >explain) the issue, the 401 Authenticate response created by JCIFS filter tells the browser to resend the >same request with NTLM credentials. When a user first hits an application a session is automatically >created for that user. Normally all subsequent requests by that user will use a session identifier (via >URL-rewriting or a cookie) to maintain the state of the application. All quite simple so far. > >An issue arises when an application is running on multiple processes rather than just multiple threads, >because the 401 which makes the browser resend a request may end up at a different running process which >will invalidate the NTLM negociation mechanism. Running an application over a number of machines is one >way in which this situation arises, but the big boys from weblogic and WAS also recognize that scaling >appservers on threads only goes so far, such that multi-process appservers on single (big) boxes also exist. > >Anyway, Im sure you know all that. The point is that > >a) the session is implicitly created at the outset, therefore, calling req.getSession() as originally >suggested will not have any effect >b) to avoid this issue the servlet filter should start with something like the following so that negociate >will never commence until we can be sure the authorization will be sent back to the correct appserver process: > > if (Config.getProperty("jcifs.util.multiProcess")!=null && >Config.getProperty("jcifs.util.multiProcess").equals("true")) { //check if defined as >multi-process appserver > //this code should only ever get executed once per user per session > if (session.getAttribute("NTLMNegociationInitiated")==null) { > session.setAttribute("NTLMNegociationInitiated","true"); > > //should be a block of code here responsible for setting a cookie if cookie based session >management is in use > //but I havent bothered doing that yet > //... > > //the following code will take care of urlrewriting if required > PrintWriter out = null; > out = resp.getWriter(); > out.println(""); > out.println(""); > out.println("Resending request with Session id"); > out.println(""); > out.println(""); > out.println(""); > out.println(""); > out.println(""); > out.println(""); > return; > } //end if > } //end of check for multi-process appserver > >Anyways - thats the way I would (will) do it. Hope its of use/interest. > >rgds >jim > >From: Eric comcast.net> >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter >Date: 2004-03-20 01:08:50 GMT (1 year, 35 weeks, 2 days, 17 hours and 16 minutes ago) > >He's load balancing the servlet containers (application servers); he's >got a single web server with multiple WebSphere containers on the back >end. The connector on the web server uses the session ID to determine >which application server the request gets routed to. We don't currently >create a session until the NTLM handshake has completed (when we store >the username etc. in the session). So what he's seeing is server A >generates the challenge and sends the Type 2 message, but server B ends >up getting the Type 3 message (the HTTP keepalive is between the client >and the web server, but not between the web server and a particular >application server). > >Creating the session at the outset would prevent this (and is probably >an appropriate measure). > >Eric > >Michael B Allen wrote: >> I don't see what this has to do with load balancing. Please send your >> precise suggested fix to the jcifs mailing list. >> >> Sylwester Lachiewicz said: >> >>>Hi, >>> >>>With current NtlmServletFilter it's not possible to create application >>>with loadbalancing >>>Our http server (IBM HTTP with WebSphere plugin) use session cookie to >>>route requests to one of our Application Server. Becouse full NTLM Auth >>>requires 3 resuests/responses it's possible that one request will be >>>received by AppServer1 and second with AppServer2. This creates auth >>>failure. >>> >>>To fix this, in service method, i add line request.getSession() so session >>>will be created and JSESSIONID returned to browser and available to next >>>requests. >>>It's possible to add this to NtlmServlet and NtlmFilter? >>> >>>S. >>> >> >> >> > >> Jim Smyth >> BVGS >> >> Mobile +44 (0) 7720 352 014 >> >> BroadVision >> Energizing e-Business > >> This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED >and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is >prohibited. If you have received this communication in error, please erase all copies of the message and >its attachments and notify us immediately. From mba2000 at ioplex.com Mon Dec 5 17:54:38 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 5 17:59:32 2005 Subject: [jcifs] Re: Re: Loadbalancing with NTLMServlet/Filter In-Reply-To: <468F31CDD9EE944FA0D9D30620E63E3301827212@NASEV02.hca.corpad.net> References: <468F31CDD9EE944FA0D9D30620E63E3301827212@NASEV02.hca.corpad.net> Message-ID: <20051205125438.67f983ca.mba2000@ioplex.com> On Mon, 5 Dec 2005 11:11:29 -0600 "Tapperson Kevin" wrote: > independently respond with HTTP 401 errors requesting NTLM > authentication, and each app server supplies a different JSESSIONID > cookie. > > At some point during (or after) the authentication process, the browser > will choose to "standardize" on a single JSESSIONID cookie for the > server. Depending on when the browser chooses a single JSESSIONID > cookie, there are 2 different cases to describe. I think there are properties that can restrict pages to one particular server. So you set the login page to only go to one server. I have no experience with this so I can't be more specific but clearly this issue is not specific to JCIFS. See if you can find documentation about Wedgetail, Vintela, or other products that that to see how they deal with the issue. Mike From mkb137 at gmail.com Mon Dec 5 22:41:38 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Mon Dec 5 22:42:06 2005 Subject: [jcifs] Only the first login is successful Message-ID: Using a plain jboss-3.2.7 server, I have a web app configured to use NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, multiple users/browsers cannot log on to the server at the same time. The first login goes through correctly and the user can access the app. Any login thereafter (from a different machine, from a different user, from the same user on the same computer but with a different browser) fails with no error message just as if the user or password were invalid. I have not had this problem with jcifs-1.1.8.jar, which I've been using for quite a while. I was hoping to upgrade to take advantage of some of the other fixes. Is this a configuration problem or something else? My web.xml section is pretty plain : NTML HTTP Authentication Filter jcifs.http.NtlmHttpFilter jcifs.smb.client.domain MYDOMAIN jcifs.http.domainController mydc NTML HTTP Authentication Filter /* From eric.glass at gmail.com Tue Dec 6 06:29:44 2005 From: eric.glass at gmail.com (Eric Glass) Date: Tue Dec 6 06:30:17 2005 Subject: [jcifs] Re: Re: Loadbalancing with NTLMServlet/Filter In-Reply-To: <314fa87e0512051510r19aeae96odcf5892220e6b6c2@mail.gmail.com> References: <468F31CDD9EE944FA0D9D30620E63E3301827212@NASEV02.hca.corpad.net> <314fa87e0512051510r19aeae96odcf5892220e6b6c2@mail.gmail.com> Message-ID: <33b41d060512052229x4941fe5cg54b480d4fc3d0656@mail.gmail.com> This is an inherent issue if the HTTP session is used prior to completing the authentication process; the reason being that cookies are used to maintain the session, and can result in basically a race condition as noted below. We had some similar issues way back in 0.7.0b5 around when the filter was first introduced; as maintaining state based on the physical socket isn't directly available via the servlet API, the solution was to do the authentication handshake statelessly. This precludes the tracking that is needed to support the new loadbalancing functionality however (that appears to be what the HTTP session storage is used for). The servlet 2.4 spec has an HttpServletRequest.getLocalPort() call; while it doesn't provide access to the actual socket, it might be sufficient to match transactions to connections appropriately without relying on the HTTP session. Eric > > There's even more to this issue than has been described. If you have a > multi-process (not multi-threaded, but truly multi-process), > load-balanced app server, try creating a simple .html file like this: > > > > Test Page > > > src="http://load.balanced.server.com/content/images/image1.gif"/> > src="http://load.balanced.server.com/content/images/image2.jpg"/> > src="http://load.balanced.server.com/content/images/image3.jpg"/> > > > > Save this file locally on your computer and then load it into your > browser using a file: URL. What ends up happening here is that the > browser makes multiple simultaneous requests to the app servers. These > requests initially get routed per the load balancer policy to different > app servers (random, round-robin, etc). The app servers all > independently respond with HTTP 401 errors requesting NTLM > authentication, and each app server supplies a different JSESSIONID > cookie. > > At some point during (or after) the authentication process, the browser > will choose to "standardize" on a single JSESSIONID cookie for the > server. Depending on when the browser chooses a single JSESSIONID > cookie, there are 2 different cases to describe. > > CASE A: > The browser _sometimes_ selects a single JSESSIONID cookie to > "standardize" on and use to submit the NTLM type 1 requests. If it > selects a single JSESSIONID cookie to use for the NTLM type 1 requests, > then a problem arises in that once the first NTLM type 3 request is > processed by the app server, the NtlmHttpChal attribute is removed from > the session (ssn.removeAttribute("NtlmHttpChal") in NtlmHttpFilter). > The next NTLM type 3 requests will be required to obtain a new NTLM > challenge, and _may_ not get the same transport/challenge that was > originally used for the NTLM type 2 response sent by the app server. > > CASE B: > We have also seen, however, that the browser could elect to use the > different distinct JSESSIONID cookies to submit the NTLM type 1 > requests, and not "standardize" on a JSESSIONID cookie until it submits > the NTLM type 3 requests. In this case, you end up with multiple > independent app servers creating SMB transports and generating NTLM > challenges and saving those challenges in different sessions on the > different app servers. When the browser chooses to "standardize" on a > single JSESSIONID cookie, the NTLM type 3 requests then all get > submitted to a single app server. This results in NTLM type 3 requests > with the NTLM responses being sent to an app server that will be unable > to properly verify the responses, because the app server that the NTLM > type 3 requests are submitted to does not have the corresponding SMB > transport with the proper transport encryption key (challenge) to verify > the NTLM responses. > > We have seen with the sample .html file above, that we usually get a mix > of case A and case B as described above. There is no predictable > pattern to how/when the browser will choose to "standardize" on a > JSESSIONID cookie. > > The only way that I have thought of to completely resolve this issue is > to create a cluster-wide map to save the NTLM challenges used when the > NTLM type 2 response is generated. This map would require that the key > be completely independent of the session ID, as the browser can (and > does) choose to change sessions during the middle of the NTLM > negotiation process. The map key could be based on remote IP address, > request URI and query string (but even this poses a potential problem if > you have multiple users on a shared machine who happen to require NTLM > authentication simultaneously for the same URI). (This is highly > unlikely, but in my experience with concurrent programming, if you leave > the window open, bugs will fly in.) > > This is why Microsoft stipulates that connection keep-alives MUST be > used for NTLM authentication to succeed. If connection keep-alives are > used, then you are guaranteed to return to the same server to continue > the NTLM negotiation process. I'm not sure how this could be used in a > multi-tiered environment where there is a web server tier (Apache/IBM > HttpServer) in front of the app server tier where the jcifs code > actually executes. > > > > > >From: Smyth, Jim broadvision.com> > >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter > 074A4483FBB03AE43%40uk%2dmsg%2d01.broadvision.com%3e> > >Newsgroups: gmane.network.samba.java > > >Date: 2005-11-23 01:10:51 GMT (1 week, 5 days, 15 hours and 13 minutes > ago) > >Hi, > > > >I experienced an issue with using jcifs on applications running across > multiple app servers which I found > >reported some time ago (see below). I believe the end solution may not > be correct. To recap (and fully > >explain) the issue, the 401 Authenticate response created by JCIFS > filter tells the browser to resend the > >same request with NTLM credentials. When a user first hits an > application a session is automatically > >created for that user. Normally all subsequent requests by that user > will use a session identifier (via > >URL-rewriting or a cookie) to maintain the state of the application. > All quite simple so far. > > > >An issue arises when an application is running on multiple processes > rather than just multiple threads, > >because the 401 which makes the browser resend a request may end up at > a different running process which > >will invalidate the NTLM negociation mechanism. Running an application > over a number of machines is one > >way in which this situation arises, but the big boys from weblogic and > WAS also recognize that scaling > >appservers on threads only goes so far, such that multi-process > appservers on single (big) boxes also exist. > > > >Anyway, Im sure you know all that. The point is that > > > >a) the session is implicitly created at the outset, therefore, calling > req.getSession() as originally > >suggested will not have any effect > >b) to avoid this issue the servlet filter should start with something > like the following so that negociate > >will never commence until we can be sure the authorization will be sent > back to the correct appserver process: > > > > if > (Config.getProperty("jcifs.util.multiProcess")!=null && > >Config.getProperty("jcifs.util.multiProcess").equals("true")) { > //check if defined as > >multi-process appserver > > //this code should only ever get > executed once per user per session > > if > (session.getAttribute("NTLMNegociationInitiated")==null) { > > > session.setAttribute("NTLMNegociationInitiated","true"); > > > > //should be a block of code here > responsible for setting a cookie if cookie based session > >management is in use > > //but I havent bothered doing > that yet > > //... > > > > //the following code will take > care of urlrewriting if required > > PrintWriter out = null; > > out = resp.getWriter(); > > out.println(""); > > out.println(""); > > > out.println("Resending request with Session id"); > > out.println(" Http-Equiv=\"Cache-Control\" Content=\"no-cache\">"); > > out.println(" Http-Equiv=\"Pragma\" Content=\"no-cache\">"); > > out.println(" Http-Equiv=\"Expires\" Content=\"0\">"); > > out.println(" http-equiv=\"refresh\" content=\"0; URL=" + > >resp.encodeURL(req.getRequestURL().toString()) + "\">"); > > out.println(""); > > out.println(""); > > return; > > } //end if > > } //end of check for multi-process appserver > > > >Anyways - thats the way I would (will) do it. Hope its of > use/interest. > > > >rgds > >jim > > > >From: Eric comcast.net> > >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter > mcast.net%3e> > >Date: 2004-03-20 01:08:50 GMT (1 year, 35 weeks, 2 days, 17 hours and > 16 minutes ago) > > > >He's load balancing the servlet containers (application servers); he's > >got a single web server with multiple WebSphere containers on the back > >end. The connector on the web server uses the session ID to determine > >which application server the request gets routed to. We don't > currently > >create a session until the NTLM handshake has completed (when we store > >the username etc. in the session). So what he's seeing is server A > >generates the challenge and sends the Type 2 message, but server B ends > > >up getting the Type 3 message (the HTTP keepalive is between the client > > >and the web server, but not between the web server and a particular > >application server). > > > >Creating the session at the outset would prevent this (and is probably > >an appropriate measure). > > > >Eric > > > >Michael B Allen wrote: > >> I don't see what this has to do with load balancing. Please send your > >> precise suggested fix to the jcifs mailing list. > >> > >> Sylwester Lachiewicz said: > >> > >>>Hi, > >>> > >>>With current NtlmServletFilter it's not possible to create > application > >>>with loadbalancing > >>>Our http server (IBM HTTP with WebSphere plugin) use session cookie > to > >>>route requests to one of our Application Server. Becouse full NTLM > Auth > >>>requires 3 resuests/responses it's possible that one request will be > >>>received by AppServer1 and second with AppServer2. This creates auth > >>>failure. > >>> > >>>To fix this, in service method, i add line request.getSession() so > session > >>>will be created and JSESSIONID returned to browser and available to > next > >>>requests. > >>>It's possible to add this to NtlmServlet and NtlmFilter? > >>> > >>>S. > >>> > >> > >> > >> > > > >> Jim Smyth > >> BVGS > >> > >> Mobile +44 (0) 7720 352 014 > >> > >> BroadVision > >> Energizing e-Business > > > >> This message is intended only for the use of the Addressee and may > contain information that is PRIVILEGED > >and CONFIDENTIAL. If you are not the intended recipient, dissemination > of this communication is > >prohibited. If you have received this communication in error, please > erase all copies of the message and > >its attachments and notify us immediately. > From yannick at smellyfrog.com Tue Dec 6 08:44:01 2005 From: yannick at smellyfrog.com (Yannick) Date: Tue Dec 6 08:44:28 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: Message-ID: <43954F51.9020500@smellyfrog.com> Hi Mike, You probably need to use pre-authentication. So you need to setup a user account on the domain that you can use to do so, then add the following parameters in your web.xml file: jcifs.smb.client.username UserAccountName jcifs.smb.client.password PasswordOfTheUserAccount Hope this helps Regards Yannick Mike Bennett wrote: >Using a plain jboss-3.2.7 server, I have a web app configured to use >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, >multiple users/browsers cannot log on to the server at the same time. >The first login goes through correctly and the user can access the >app. Any login thereafter (from a different machine, from a different >user, from the same user on the same computer but with a different >browser) fails with no error message just as if the user or password >were invalid. I have not had this problem with jcifs-1.1.8.jar, which >I've been using for quite a while. I was hoping to upgrade to take >advantage of some of the other fixes. > >Is this a configuration problem or something else? My web.xml section >is pretty plain : > > > NTML HTTP Authentication Filter > jcifs.http.NtlmHttpFilter > > jcifs.smb.client.domain > MYDOMAIN > > > jcifs.http.domainController > mydc > > > > NTML HTTP Authentication Filter > /* > > > > From mkb137 at gmail.com Tue Dec 6 15:42:37 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Tue Dec 6 15:42:54 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <43954F51.9020500@smellyfrog.com> References: <43954F51.9020500@smellyfrog.com> Message-ID: If I put a valid normal user account in those parameters, then no login works. If this requires a special user account on the domain then I don't think it's viable for my situation, where the app will reside on another corporation's server. Thanks for the suggestion, though. On 12/6/05, Yannick wrote: > Hi Mike, > > You probably need to use pre-authentication. So you need to setup a user > account on the domain that you can use to do so, then add the following > parameters in your web.xml file: > > > jcifs.smb.client.username > UserAccountName > > > > jcifs.smb.client.password > PasswordOfTheUserAccount > > > Hope this helps > Regards > Yannick > > Mike Bennett wrote: > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > >multiple users/browsers cannot log on to the server at the same time. > >The first login goes through correctly and the user can access the > >app. Any login thereafter (from a different machine, from a different > >user, from the same user on the same computer but with a different > >browser) fails with no error message just as if the user or password > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > >I've been using for quite a while. I was hoping to upgrade to take > >advantage of some of the other fixes. > > > >Is this a configuration problem or something else? My web.xml section > >is pretty plain : > > > > > > NTML HTTP Authentication Filter > > jcifs.http.NtlmHttpFilter > > > > jcifs.smb.client.domain > > MYDOMAIN > > > > > > jcifs.http.domainController > > mydc > > > > > > > > NTML HTTP Authentication Filter > > /* > > > > > > > > > > From rknight at conceptwave.com Tue Dec 6 16:03:02 2005 From: rknight at conceptwave.com (Roland Knight) Date: Tue Dec 6 16:03:46 2005 Subject: [jcifs] unsubscribe Message-ID: <200512061603.jB6G33Pj016198@mailhost.conceptwave.com> -------------- next part -------------- HTML attachment scrubbed and removed From Kevin.Tapperson at hcahealthcare.com Tue Dec 6 17:02:18 2005 From: Kevin.Tapperson at hcahealthcare.com (Tapperson Kevin) Date: Tue Dec 6 17:02:46 2005 Subject: [jcifs] Re: Re: Loadbalancing with NTLMServlet/Filter Message-ID: <468F31CDD9EE944FA0D9D30620E63E3301894E67@NASEV02.hca.corpad.net> Even a stateless implementation would have issues with a multi-process J2EE server though, correct? As the multiple processes would construct multiple SMB transports to the Domain Controller and each have different encryption keys. -----Original Message----- From: jcifs-bounces+kevin.tapperson=hcahealthcare.com@lists.samba.org [mailto:jcifs-bounces+kevin.tapperson=hcahealthcare.com@lists.samba.org] On Behalf Of Eric Glass Sent: Tuesday, December 06, 2005 12:30 AM To: jcifs@lists.samba.org Subject: Re: [jcifs] Re: Re: Loadbalancing with NTLMServlet/Filter This is an inherent issue if the HTTP session is used prior to completing the authentication process; the reason being that cookies are used to maintain the session, and can result in basically a race condition as noted below. We had some similar issues way back in 0.7.0b5 around when the filter was first introduced; as maintaining state based on the physical socket isn't directly available via the servlet API, the solution was to do the authentication handshake statelessly. This precludes the tracking that is needed to support the new loadbalancing functionality however (that appears to be what the HTTP session storage is used for). The servlet 2.4 spec has an HttpServletRequest.getLocalPort() call; while it doesn't provide access to the actual socket, it might be sufficient to match transactions to connections appropriately without relying on the HTTP session. Eric > > There's even more to this issue than has been described. If you have > a multi-process (not multi-threaded, but truly multi-process), > load-balanced app server, try creating a simple .html file like this: > > > > Test Page > > > src="http://load.balanced.server.com/content/images/image1.gif"/> > src="http://load.balanced.server.com/content/images/image2.jpg"/> > src="http://load.balanced.server.com/content/images/image3.jpg"/> > > > > Save this file locally on your computer and then load it into your > browser using a file: URL. What ends up happening here is that the > browser makes multiple simultaneous requests to the app servers. > These requests initially get routed per the load balancer policy to > different app servers (random, round-robin, etc). The app servers all > independently respond with HTTP 401 errors requesting NTLM > authentication, and each app server supplies a different JSESSIONID > cookie. > > At some point during (or after) the authentication process, the > browser will choose to "standardize" on a single JSESSIONID cookie for > the server. Depending on when the browser chooses a single JSESSIONID > cookie, there are 2 different cases to describe. > > CASE A: > The browser _sometimes_ selects a single JSESSIONID cookie to > "standardize" on and use to submit the NTLM type 1 requests. If it > selects a single JSESSIONID cookie to use for the NTLM type 1 > requests, then a problem arises in that once the first NTLM type 3 > request is processed by the app server, the NtlmHttpChal attribute is > removed from the session (ssn.removeAttribute("NtlmHttpChal") in NtlmHttpFilter). > The next NTLM type 3 requests will be required to obtain a new NTLM > challenge, and _may_ not get the same transport/challenge that was > originally used for the NTLM type 2 response sent by the app server. > > CASE B: > We have also seen, however, that the browser could elect to use the > different distinct JSESSIONID cookies to submit the NTLM type 1 > requests, and not "standardize" on a JSESSIONID cookie until it > submits the NTLM type 3 requests. In this case, you end up with > multiple independent app servers creating SMB transports and > generating NTLM challenges and saving those challenges in different > sessions on the different app servers. When the browser chooses to > "standardize" on a single JSESSIONID cookie, the NTLM type 3 requests > then all get submitted to a single app server. This results in NTLM > type 3 requests with the NTLM responses being sent to an app server > that will be unable to properly verify the responses, because the app > server that the NTLM type 3 requests are submitted to does not have > the corresponding SMB transport with the proper transport encryption > key (challenge) to verify the NTLM responses. > > We have seen with the sample .html file above, that we usually get a > mix of case A and case B as described above. There is no predictable > pattern to how/when the browser will choose to "standardize" on a > JSESSIONID cookie. > > The only way that I have thought of to completely resolve this issue > is to create a cluster-wide map to save the NTLM challenges used when > the NTLM type 2 response is generated. This map would require that > the key be completely independent of the session ID, as the browser > can (and > does) choose to change sessions during the middle of the NTLM > negotiation process. The map key could be based on remote IP address, > request URI and query string (but even this poses a potential problem > if you have multiple users on a shared machine who happen to require > NTLM authentication simultaneously for the same URI). (This is highly > unlikely, but in my experience with concurrent programming, if you > leave the window open, bugs will fly in.) > > This is why Microsoft stipulates that connection keep-alives MUST be > used for NTLM authentication to succeed. If connection keep-alives > are used, then you are guaranteed to return to the same server to > continue the NTLM negotiation process. I'm not sure how this could be > used in a multi-tiered environment where there is a web server tier > (Apache/IBM > HttpServer) in front of the app server tier where the jcifs code > actually executes. > > > > > >From: Smyth, Jim broadvision.com> > >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter > 8C 074A4483FBB03AE43%40uk%2dmsg%2d01.broadvision.com%3e> > >Newsgroups: gmane.network.samba.java > > >Date: 2005-11-23 01:10:51 GMT (1 week, 5 days, 15 hours and 13 > >minutes > ago) > >Hi, > > > >I experienced an issue with using jcifs on applications running > >across > multiple app servers which I found > >reported some time ago (see below). I believe the end solution may > >not > be correct. To recap (and fully > >explain) the issue, the 401 Authenticate response created by JCIFS > filter tells the browser to resend the > >same request with NTLM credentials. When a user first hits an > application a session is automatically > >created for that user. Normally all subsequent requests by that user > will use a session identifier (via > >URL-rewriting or a cookie) to maintain the state of the application. > All quite simple so far. > > > >An issue arises when an application is running on multiple processes > rather than just multiple threads, > >because the 401 which makes the browser resend a request may end up > >at > a different running process which > >will invalidate the NTLM negociation mechanism. Running an > >application > over a number of machines is one > >way in which this situation arises, but the big boys from weblogic > >and > WAS also recognize that scaling > >appservers on threads only goes so far, such that multi-process > appservers on single (big) boxes also exist. > > > >Anyway, Im sure you know all that. The point is that > > > >a) the session is implicitly created at the outset, therefore, > >calling > req.getSession() as originally > >suggested will not have any effect > >b) to avoid this issue the servlet filter should start with > >something > like the following so that negociate > >will never commence until we can be sure the authorization will be > >sent > back to the correct appserver process: > > > > if > (Config.getProperty("jcifs.util.multiProcess")!=null && > >Config.getProperty("jcifs.util.multiProcess").equals("true")) { > //check if defined as > >multi-process appserver > > //this code should only ever get > executed once per user per session > > if > (session.getAttribute("NTLMNegociationInitiated")==null) { > > > session.setAttribute("NTLMNegociationInitiated","true"); > > > > //should be a block of code > > here > responsible for setting a cookie if cookie based session > >management is in use > > //but I havent bothered doing > that yet > > //... > > > > //the following code will take > care of urlrewriting if required > > PrintWriter out = null; > > out = resp.getWriter(); > > out.println(""); > > out.println(""); > > > out.println("Resending request with Session id"); > > out.println(" Http-Equiv=\"Cache-Control\" Content=\"no-cache\">"); > > out.println(" Http-Equiv=\"Pragma\" Content=\"no-cache\">"); > > out.println(" Http-Equiv=\"Expires\" Content=\"0\">"); > > out.println(" http-equiv=\"refresh\" content=\"0; URL=" + > >resp.encodeURL(req.getRequestURL().toString()) + "\">"); > > out.println(""); > > out.println(""); > > return; > > } //end if > > } //end of check for multi-process appserver > > > >Anyways - thats the way I would (will) do it. Hope its of > use/interest. > > > >rgds > >jim > > > >From: Eric comcast.net> > >Subject: Re: Re: Loadbalancing with NTLMServlet/Filter > co > mcast.net%3e> > >Date: 2004-03-20 01:08:50 GMT (1 year, 35 weeks, 2 days, 17 hours and > 16 minutes ago) > > > >He's load balancing the servlet containers (application servers); > >he's got a single web server with multiple WebSphere containers on > >the back end. The connector on the web server uses the session ID to > >determine which application server the request gets routed to. We > >don't > currently > >create a session until the NTLM handshake has completed (when we > >store the username etc. in the session). So what he's seeing is > >server A generates the challenge and sends the Type 2 message, but > >server B ends > > >up getting the Type 3 message (the HTTP keepalive is between the > >client > > >and the web server, but not between the web server and a particular > >application server). > > > >Creating the session at the outset would prevent this (and is > >probably an appropriate measure). > > > >Eric > > > >Michael B Allen wrote: > >> I don't see what this has to do with load balancing. Please send > >> your precise suggested fix to the jcifs mailing list. > >> > >> Sylwester Lachiewicz said: > >> > >>>Hi, > >>> > >>>With current NtlmServletFilter it's not possible to create > application > >>>with loadbalancing > >>>Our http server (IBM HTTP with WebSphere plugin) use session > >>>cookie > to > >>>route requests to one of our Application Server. Becouse full NTLM > Auth > >>>requires 3 resuests/responses it's possible that one request will > >>>be received by AppServer1 and second with AppServer2. This creates > >>>auth failure. > >>> > >>>To fix this, in service method, i add line request.getSession() so > session > >>>will be created and JSESSIONID returned to browser and available to > next > >>>requests. > >>>It's possible to add this to NtlmServlet and NtlmFilter? > >>> > >>>S. > >>> > >> > >> > >> > > > >> Jim Smyth > >> BVGS > >> > >> Mobile +44 (0) 7720 352 014 > >> > >> BroadVision > >> Energizing e-Business > > > >> This message is intended only for the use of the Addressee and may > contain information that is PRIVILEGED > >and CONFIDENTIAL. If you are not the intended recipient, > >dissemination > of this communication is > >prohibited. If you have received this communication in error, please > erase all copies of the message and > >its attachments and notify us immediately. > From pulazzo at gmail.com Tue Dec 6 17:05:34 2005 From: pulazzo at gmail.com (Andrew Miller) Date: Tue Dec 6 17:05:47 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: <43954F51.9020500@smellyfrog.com> Message-ID: <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> I had a similar problem. I don't have time right now for a more thorough response, but you might want to see the thread from Nov 10th called "Load balancing required for preauthentication?" http://lists.samba.org/archive/jcifs/2005-November/005683.html I don't think anything has changed in the source since that discussion. You might just try turning on load balancing if it's not already. -Andy On 12/6/05, Mike Bennett wrote: > If I put a valid normal user account in those parameters, then no > login works. If this requires a special user account on the domain > then I don't think it's viable for my situation, where the app will > reside on another corporation's server. > > Thanks for the suggestion, though. > > On 12/6/05, Yannick wrote: > > Hi Mike, > > > > You probably need to use pre-authentication. So you need to setup a user > > account on the domain that you can use to do so, then add the following > > parameters in your web.xml file: > > > > > > jcifs.smb.client.username > > UserAccountName > > > > > > > > jcifs.smb.client.password > > PasswordOfTheUserAccount > > > > > > Hope this helps > > Regards > > Yannick > > > > Mike Bennett wrote: > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > >multiple users/browsers cannot log on to the server at the same time. > > >The first login goes through correctly and the user can access the > > >app. Any login thereafter (from a different machine, from a different > > >user, from the same user on the same computer but with a different > > >browser) fails with no error message just as if the user or password > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > >I've been using for quite a while. I was hoping to upgrade to take > > >advantage of some of the other fixes. > > > > > >Is this a configuration problem or something else? My web.xml section > > >is pretty plain : > > > > > > > > > NTML HTTP Authentication Filter > > > jcifs.http.NtlmHttpFilter > > > > > > jcifs.smb.client.domain > > > MYDOMAIN > > > > > > > > > jcifs.http.domainController > > > mydc > > > > > > > > > > > > NTML HTTP Authentication Filter > > > /* > > > > > > > > > > > > > > > > > From emmanuel_potvin at hotmail.com Wed Dec 7 15:06:14 2005 From: emmanuel_potvin at hotmail.com (Emmanuel Potvin) Date: Wed Dec 7 15:06:47 2005 Subject: [jcifs] NTLM filter Message-ID: Hi. My question do not concern directly jdifs, but I think you are the people who can understand my problem. In fact, it is a NTLM with j2ee web server problem. My application security is based on windows domain login. When user login, he don't have to enter any credential. The server ask for ntlm authentication and log with it. To do that, I created a Filter and added it to my application. My Filter class name is com.cpa.gare.application.presentation.NtlmFilter. I sent the source file as attachment. As you can see, the filter return Authentication error to the navigator until he gets login information, and he puts them in request attributes "adDomain" and "adUserName". (ad is for active directory) So I can use these attributes in my servlets to authenticate the user. With Jboss, it works perfectly. I got the right information everytime, from everywhere. But when I use Oracle OC4J (as I must for my current development), I got an error I don't understand... First, instead of just get information from explorer, it popup me a login screen as if I use Firefox. Second, if I put a user in the login screen, it uses this login name. And for the domain name, it take the oracle application server name. For example, in my case : as10gmidtier.cpaerp.net (this is not even a domain name, this is a server name). I really need to solve this problem... If anybody have a clue... Emmanuel Potvin -------------- next part -------------- A non-text attachment was scrubbed... Name: NtlmFilter.java Type: application/octet-stream Size: 2879 bytes Desc: not available Url : http://lists.samba.org/archive/jcifs/attachments/20051207/085a9bfc/NtlmFilter.obj From rcaper at gmail.com Wed Dec 7 16:31:02 2005 From: rcaper at gmail.com (Richard Caper) Date: Wed Dec 7 16:31:20 2005 Subject: [jcifs] NTLM filter In-Reply-To: References: Message-ID: <314fa87e0512070831m6b8c1729ibe3e1edb68948e4c@mail.gmail.com> This code (or similar) has been floating around on message boards for years, and is really crap: 1) It doesn't actually authenticate anything. It just takes whatever the client sends, parses out username information, and uses that. The user can set their options in Internet Explorer to always prompt for authentication (or use Firefox or another browser that prompts) and whatever username they specify will come across as the user. It doesn't check that they actually are that person (which is the whole point), so is useless for authentication to a system. To actually authenticate the user, you need to pass the challenge and response between the client and a domain controller (which is what jCIFS does). 2) It hardcodes all the NTLM options, which are supposed to be negotiated between the client and server. This will cause inconsistent behavior across various clients, servers, etc. (which is almost certainly what you are seeing). Basically the reason it's not working is there are (at least) dozens of combinations of flag settings that can be negotiated between the client and server, and you're just hardcoding one single permutation. On 12/7/05, Emmanuel Potvin wrote: > Hi. My question do not concern directly jdifs, but I think you are the > people who can understand my problem. In fact, it is a NTLM with j2ee web > server problem. > > My application security is based on windows domain login. When user login, > he don't have to enter any credential. The server ask for ntlm > authentication and log with it. To do that, I created a Filter and added it > to my application. > > My Filter class name is com.cpa.gare.application.presentation.NtlmFilter. I > sent the source file as attachment. > > As you can see, the filter return Authentication error to the navigator > until he gets login information, and he puts them in request attributes > "adDomain" and "adUserName". (ad is for active directory) > > So I can use these attributes in my servlets to authenticate the user. > > With Jboss, it works perfectly. I got the right information everytime, from > everywhere. But when I use Oracle OC4J (as I must for my current > development), I got an error I don't understand... First, instead of just > get information from explorer, it popup me a login screen as if I use > Firefox. Second, if I put a user in the login screen, it uses this login > name. And for the domain name, it take the oracle application server name. > For example, in my case : as10gmidtier.cpaerp.net (this is not even a domain > name, this is a server name). > > I really need to solve this problem... If anybody have a clue... > > Emmanuel Potvin > > > > From emmanuel_potvin at hotmail.com Wed Dec 7 19:38:49 2005 From: emmanuel_potvin at hotmail.com (Emmanuel Potvin) Date: Wed Dec 7 19:39:09 2005 Subject: [jcifs] NTLM filter In-Reply-To: <314fa87e0512070831m6b8c1729ibe3e1edb68948e4c@mail.gmail.com> Message-ID: I see... I note it. So I should seriously think about using jcifs... And what do you think about the fact that mod_jk don't let 401 response pass through the client? ----Original Message Follows---- From: Richard Caper To: Emmanuel Potvin CC: jcifs@lists.samba.org Subject: Re: [jcifs] NTLM filter Date: Wed, 7 Dec 2005 11:31:02 -0500 MIME-Version: 1.0 Received: from zproxy.gmail.com ([64.233.162.199]) by bay0-mc11-f18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 08:31:11 -0800 Received: by zproxy.gmail.com with SMTP id 18so395357nzp for ; Wed, 07 Dec 2005 08:31:03 -0800 (PST) Received: by 10.36.96.3 with SMTP id t3mr1497621nzb; Wed, 07 Dec 2005 08:31:02 -0800 (PST) Received: by 10.36.37.6 with HTTP; Wed, 7 Dec 2005 08:31:02 -0800 (PST) X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IOhfoP8YnJFOtv9/FXyCae3ZPrKpCLt2X7gPHTBvAdLHHiXKR3WO3TB3smydi1l1PNufncopSU2lDKVIqRO0biyeoPAFeczHO+xyXQwGvNd3vI+AbzgZbABvsji51b8Wu/h9dQs6fpJUnlTATDJN8VKGexe9p4gn0lQHBRu1Lr8= References: Return-Path: rcaper@gmail.com X-OriginalArrivalTime: 07 Dec 2005 16:31:15.0776 (UTC) FILETIME=[A4E8B400:01C5FB4B] This code (or similar) has been floating around on message boards for years, and is really crap: 1) It doesn't actually authenticate anything. It just takes whatever the client sends, parses out username information, and uses that. The user can set their options in Internet Explorer to always prompt for authentication (or use Firefox or another browser that prompts) and whatever username they specify will come across as the user. It doesn't check that they actually are that person (which is the whole point), so is useless for authentication to a system. To actually authenticate the user, you need to pass the challenge and response between the client and a domain controller (which is what jCIFS does). 2) It hardcodes all the NTLM options, which are supposed to be negotiated between the client and server. This will cause inconsistent behavior across various clients, servers, etc. (which is almost certainly what you are seeing). Basically the reason it's not working is there are (at least) dozens of combinations of flag settings that can be negotiated between the client and server, and you're just hardcoding one single permutation. On 12/7/05, Emmanuel Potvin wrote: > Hi. My question do not concern directly jdifs, but I think you are the > people who can understand my problem. In fact, it is a NTLM with j2ee web > server problem. > > My application security is based on windows domain login. When user login, > he don't have to enter any credential. The server ask for ntlm > authentication and log with it. To do that, I created a Filter and added it > to my application. > > My Filter class name is com.cpa.gare.application.presentation.NtlmFilter. I > sent the source file as attachment. > > As you can see, the filter return Authentication error to the navigator > until he gets login information, and he puts them in request attributes > "adDomain" and "adUserName". (ad is for active directory) > > So I can use these attributes in my servlets to authenticate the user. > > With Jboss, it works perfectly. I got the right information everytime, from > everywhere. But when I use Oracle OC4J (as I must for my current > development), I got an error I don't understand... First, instead of just > get information from explorer, it popup me a login screen as if I use > Firefox. Second, if I put a user in the login screen, it uses this login > name. And for the domain name, it take the oracle application server name. > For example, in my case : as10gmidtier.cpaerp.net (this is not even a domain > name, this is a server name). > > I really need to solve this problem... If anybody have a clue... > > Emmanuel Potvin > > > > From emmanuel_potvin at hotmail.com Wed Dec 7 20:37:16 2005 From: emmanuel_potvin at hotmail.com (Emmanuel Potvin) Date: Wed Dec 7 20:37:44 2005 Subject: [jcifs] Just a test In-Reply-To: Message-ID: I have a solaris server with jboss installed on it. I want to try jcifs, and I saw in the documentation that the domain controler can be a workstation. I want to make a test, just to see if I can make it works. So here is what I did and it doesn't works... I have a popup screen instead of an auto authentication... And even if a try a real login and password, it doesn't works. I put the jCIFS.jar file in my WEB-INF/lib directory I added this in my web.xml file : NtlmHttpFilter jcifs.http.NtlmHttpFilter jcifs.http.domainController 10.1.60.103 jcifs.smb.client.domain MANU NtlmHttpFilter /* 10.1.60.103 is the ip address of my workstation, and MANU is the name of my workstation... Maybe there's something I don't understand... Is what I want to do possible? Emmanuel From Tom.Dunstan at nrm.qld.gov.au Thu Dec 8 02:03:25 2005 From: Tom.Dunstan at nrm.qld.gov.au (Dunstan Tom) Date: Thu Dec 8 02:04:14 2005 Subject: [jcifs] NtlmHttpFilter creates many empty sessions when the client doesn't support cookies Message-ID: <4C1C3ED1311A0640A392110243A40BBE0F05D5@MINMAIL1.lands.resnet.qg> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: NtlmHttpFilter.diff Type: application/octet-stream Size: 1784 bytes Desc: NtlmHttpFilter.diff Url : http://lists.samba.org/archive/jcifs/attachments/20051208/f6455f98/NtlmHttpFilter-0001.obj From subhash_challa at infosys.com Sun Dec 11 08:12:12 2005 From: subhash_challa at infosys.com (Subhash Challa) Date: Sun Dec 11 08:13:12 2005 Subject: [jcifs] Problem : Only the first user is authenticated successfully Message-ID: <480E07C46A15B0469099057E36B64A2D2C2723@HYDHTCMSG02.ad.infosys.com> I have a strange problem. Only the first user is authenticated at any point of time. When I saw the server logs I could see the following 15:28:34,215 INFO [STDOUT] Default credentials (jcifs.smb.client.username/password) not specified. SMB signing may not work propertly. Skipping DC interrogation. 15:28:34,264 INFO [STDOUT] treeConnect: unc=\\ACCOUNT-01\IPC$,service=????? 15:28:34,268 INFO [STDOUT] New data read: Transport1[ACCOUNT-01<1C>/192.168.84.42:0] 15:28:34,269 INFO [STDOUT] 00000: FF 53 4D 42 73 22 00 00 C0 98 07 C0 00 00 E9 1B |??SMBs"..?..?..??.| 00010: 47 E5 5E CC 39 97 00 00 00 00 54 B1 00 00 05 00 |G??^?9.....T??....| 15:28:34,270 INFO [STDOUT] NtlmHttpFilter: account-01\d204235: 0xC0000022: jcifs.smb.SmbAuthException: Access is denied. The server is JBOSS and is running on linux platform. My web xml has the following entries NtlmHttpFilter jcifs.http.NtlmHttpFilter jcifs.smb.client.domain ACCOUNT-01 jcifs.netbios.wins xxx.xxx.xx.xx jcifs.util.loglevel 3 Can some body please help Also can someone tell me whats the best way to get the WINS IP address so that I can verify my settings. Thanks for your help Regards Subhash challa **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -------------- next part -------------- HTML attachment scrubbed and removed From james.maupin at metacarta.com Sun Dec 11 19:44:20 2005 From: james.maupin at metacarta.com (James Maupin) Date: Sun Dec 11 21:22:24 2005 Subject: [jcifs] SecurityDescriptor.patch and jCifs-1.1.11 or jCifs-1.2.7 Message-ID: Applying the SecurityDescriptor.patch to jCifs-1.1.11 adds a new method to SmbFile class. The SmbFile.getSecurity() method returns an ACE[] array for the target file (array of allow and deny ActiveDirectory SIDS). The method SmbFile.getSecurity() works if you apply the changes as defined in the SecurityDescriptor.patch. However, SmbFile.getInputStream().read() or SmbFileInputStream.read() fails. To get this to work you must add the following change in SmbComNtCreateAndX.java: super( andx ); this.path = name; command = SMB_COM_NT_CREATE_ANDX; // desiredAccess desiredAccess = access; - desiredAccess |= FILE_READ_EA | FILE_READ_ATTRIBUTES; + desiredAccess |= FILE_READ_EA | FILE_READ_ATTRIBUTES | FILE_READ_DATA; // extFileAttributes this.extFileAttributes = extFileAttributes; // shareAccess this.shareAccess = shareAccess; ------------------------------ Also, applying the changes to jCifs-1.2.7 were straight forword with the exception of SmbFile. The following changes should be made: ------------------------------ void setPathInformation(int attrs, long ctime, long mtime) throws SmbException { int f, dir, options = 0; + if(( attrs & ATTR_DIRECTORY ) != 0 ) { + options = 1; + } exists(); dir = attributes & ATTR_DIRECTORY; f = open0(O_RDONLY, SmbComNTCreateAndX.FILE_WRITE_ATTRIBUTES, attrs, options); - sendTransaction(new Trans2SetFileInformation(f, attrs, ctime, mtime), new Trans2SetFileInformationResponse()); + send(new Trans2SetFileInformation(f, attrs, ctime, mtime), new Trans2SetFileInformationResponse()); close(f, 0L); attrExpiration = 0; } ---------------------------------------- NtTransQuerySecurityDesc request = new NtTransQuerySecurityDesc(f, 0x04); NtTransQuerySecurityDescResponse response = new NtTransQuerySecurityDescResponse(); - sendTransaction(request, response); + send(request, response); close(f, 0L); return response.aces; ---------------------------------------- Thanks. From rleyman at csc.com Mon Dec 12 01:06:36 2005 From: rleyman at csc.com (Richard Leyman) Date: Mon Dec 12 01:08:19 2005 Subject: [jcifs] Richard Leyman/GIS/CSC is out of the office. Message-ID: I will be out of the office starting 09/12/2005 and will not return until 23/12/2005. I will respond to your message when I return. If it can't wait and is a fault call please email Nathan Trowbridge and/or Paul C Jones. From mba2000 at ioplex.com Mon Dec 12 07:34:56 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 12 07:39:54 2005 Subject: [jcifs] SecurityDescriptor.patch and jCifs-1.1.11 or jCifs-1.2.7 In-Reply-To: References: Message-ID: <20051212023456.3aacfd37.mba2000@ioplex.com> On Sun, 11 Dec 2005 19:44:20 +0000 (UTC) James Maupin wrote: > Also, applying the changes to jCifs-1.2.7 were straight forword with the > exception of SmbFile. The following changes should be made: Excellent. Just to make things as easy as possible for people can you post a new diff -Nuar old/src new/src? Then I can add it to the patches directory. Thanks, Mike From Remo.Ingold at ascom.ch Mon Dec 12 09:50:36 2005 From: Remo.Ingold at ascom.ch (Remo Ingold) Date: Mon Dec 12 09:50:49 2005 Subject: [jcifs] ISAPI redirector problem Message-ID: Hello we do use JBoss (V3.2.7) / Tomcat (V5) and IIS (V6.0) among with the ISAPI (V1.2.15) connector. Everything is working but from time to time we can not connect anymore through the IIS. accessing directly to port 8080 is working. The errorlog has the following entries: [Sat Dec 10 14:37:41 2005] [info] jk_lb_worker.c (748): All tomcat instances are busy or in error state [Sat Dec 10 14:37:41 2005] [error] jk_isapi_plugin.c (1036): service() failed [Sat Dec 10 14:38:04 2005] [info] jk_connect.c (444): connect to 10.150.10.12:8009 failed with errno=61 [Sat Dec 10 14:38:04 2005] [info] jk_ajp_common.c (889): Failed opening socket to (10.150.10.12:8009) with (errno=61) [Sat Dec 10 14:38:04 2005] [info] jk_ajp_common.c (1248): Error connecting to the Tomcat process. Whre can I get help from? Thanks for your feedback Remo Ingold Productmanager Security Solutions ___________________________________________ Ascom (Schweiz) AG Glutz-Blotzheimstr. 1-3, CH-4503 Solothurn T +41(0)32 624 3051, M +41(0)79 653 3864 remo.ingold@ascom.ch www.ascom.com/securitysolutions www.openTAS.ch -------------- next part -------------- HTML attachment scrubbed and removed From mkb137 at gmail.com Mon Dec 12 19:15:39 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Mon Dec 12 19:16:46 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> Message-ID: Enabling load balancing (which the documenation says is on by default) via : jcifs.http.loadBalance true Didn't fix the problem. I only specified the one domain controller, anyway, so there was nothing to balance against. On 12/6/05, Andrew Miller wrote: > I had a similar problem. I don't have time right now for a more > thorough response, but you might want to see the thread from Nov 10th > called "Load balancing required for preauthentication?" > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > I don't think anything has changed in the source since that > discussion. You might just try turning on load balancing if it's not > already. > > -Andy > > On 12/6/05, Mike Bennett wrote: > > If I put a valid normal user account in those parameters, then no > > login works. If this requires a special user account on the domain > > then I don't think it's viable for my situation, where the app will > > reside on another corporation's server. > > > > Thanks for the suggestion, though. > > > > On 12/6/05, Yannick wrote: > > > Hi Mike, > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > account on the domain that you can use to do so, then add the following > > > parameters in your web.xml file: > > > > > > > > > jcifs.smb.client.username > > > UserAccountName > > > > > > > > > > > > jcifs.smb.client.password > > > PasswordOfTheUserAccount > > > > > > > > > Hope this helps > > > Regards > > > Yannick > > > > > > Mike Bennett wrote: > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > >multiple users/browsers cannot log on to the server at the same time. > > > >The first login goes through correctly and the user can access the > > > >app. Any login thereafter (from a different machine, from a different > > > >user, from the same user on the same computer but with a different > > > >browser) fails with no error message just as if the user or password > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > >I've been using for quite a while. I was hoping to upgrade to take > > > >advantage of some of the other fixes. > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > >is pretty plain : > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > jcifs.http.NtlmHttpFilter > > > > > > > > jcifs.smb.client.domain > > > > MYDOMAIN > > > > > > > > > > > > jcifs.http.domainController > > > > mydc > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > From mba2000 at ioplex.com Mon Dec 12 20:11:17 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 12 20:16:18 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> Message-ID: <20051212151117.0827108a.mba2000@ioplex.com> Load balancing (and thus preauthentication) will only be used if the jcifs.http.domainController is NOT specified. An easier fix is probably to just change the code to perform preauthentiction without load balancing. I *think* all you need to do is apply the following changes to src/jcifs/smb/SmbSession.java: --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 @@ -67,8 +67,7 @@ static long dc_list_expiration; static int dc_list_counter; - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { - UniAddress dc = new UniAddress( addr ); + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); if (USERNAME == null) { trans.connect(); @@ -108,7 +107,7 @@ int i = dc_list_counter++ % max; if (dc_list[i] != null) { try { - return interrogate( dc_list[i] ); + return interrogate( new UniAddress( dc_list[i] )); } catch (SmbException se) { if (SmbTransport.log.level > 1) { SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); @@ -129,7 +128,7 @@ public static byte[] getChallenge( UniAddress dc ) throws SmbException, UnknownHostException { - return getChallenge(dc, 0); + return interrogate( dc ); } public static byte[] getChallenge( UniAddress dc, int port ) I don't know why this wasn't done in the first place. Just an oversight I guess. It happends. The patchfile is also attached. On unix systems (at least) you can apply this patch like: $ cd src/jcifs/smb $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch This is all TOTALLY untested though. Please let us know if it doesn't compile and/or work. Mike On Mon, 12 Dec 2005 12:15:39 -0700 Mike Bennett wrote: > Enabling load balancing (which the documenation says is on by default) via : > > jcifs.http.loadBalance > true > > > Didn't fix the problem. I only specified the one domain controller, > anyway, so there was nothing to balance against. > > On 12/6/05, Andrew Miller wrote: > > I had a similar problem. I don't have time right now for a more > > thorough response, but you might want to see the thread from Nov 10th > > called "Load balancing required for preauthentication?" > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > I don't think anything has changed in the source since that > > discussion. You might just try turning on load balancing if it's not > > already. > > > > -Andy > > > > On 12/6/05, Mike Bennett wrote: > > > If I put a valid normal user account in those parameters, then no > > > login works. If this requires a special user account on the domain > > > then I don't think it's viable for my situation, where the app will > > > reside on another corporation's server. > > > > > > Thanks for the suggestion, though. > > > > > > On 12/6/05, Yannick wrote: > > > > Hi Mike, > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > account on the domain that you can use to do so, then add the following > > > > parameters in your web.xml file: > > > > > > > > > > > > jcifs.smb.client.username > > > > UserAccountName > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > PasswordOfTheUserAccount > > > > > > > > > > > > Hope this helps > > > > Regards > > > > Yannick > > > > > > > > Mike Bennett wrote: > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > >The first login goes through correctly and the user can access the > > > > >app. Any login thereafter (from a different machine, from a different > > > > >user, from the same user on the same computer but with a different > > > > >browser) fails with no error message just as if the user or password > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > >advantage of some of the other fixes. > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > >is pretty plain : > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > jcifs.smb.client.domain > > > > > MYDOMAIN > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > mydc > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mkb137 at gmail.com Mon Dec 12 20:47:11 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Mon Dec 12 20:47:43 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <20051212151117.0827108a.mba2000@ioplex.com> References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> Message-ID: It doesn't compile. In this change : public static byte[] getChallenge( UniAddress dc ) throws SmbException, UnknownHostException { - return getChallenge(dc, 0); + return interrogate( dc ); } it's expecting a byte[], but interrogate returns NtlmChallenge. On 12/12/05, Michael B Allen wrote: > Load balancing (and thus preauthentication) will only be used if the > jcifs.http.domainController is NOT specified. > > An easier fix is probably to just change the code to perform > preauthentiction without load balancing. I *think* all you need to do > is apply the following changes to src/jcifs/smb/SmbSession.java: > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > @@ -67,8 +67,7 @@ > static long dc_list_expiration; > static int dc_list_counter; > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > - UniAddress dc = new UniAddress( addr ); > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > if (USERNAME == null) { > trans.connect(); > @@ -108,7 +107,7 @@ > int i = dc_list_counter++ % max; > if (dc_list[i] != null) { > try { > - return interrogate( dc_list[i] ); > + return interrogate( new UniAddress( dc_list[i] )); > } catch (SmbException se) { > if (SmbTransport.log.level > 1) { > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > @@ -129,7 +128,7 @@ > > public static byte[] getChallenge( UniAddress dc ) > throws SmbException, UnknownHostException { > - return getChallenge(dc, 0); > + return interrogate( dc ); > } > > public static byte[] getChallenge( UniAddress dc, int port ) > > I don't know why this wasn't done in the first place. Just an oversight > I guess. It happends. > > The patchfile is also attached. On unix systems (at least) you can apply > this patch like: > > $ cd src/jcifs/smb > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > This is all TOTALLY untested though. Please let us know if it doesn't > compile and/or work. > > Mike > > > On Mon, 12 Dec 2005 12:15:39 -0700 > Mike Bennett wrote: > > > Enabling load balancing (which the documenation says is on by default) via : > > > > jcifs.http.loadBalance > > true > > > > > > Didn't fix the problem. I only specified the one domain controller, > > anyway, so there was nothing to balance against. > > > > On 12/6/05, Andrew Miller wrote: > > > I had a similar problem. I don't have time right now for a more > > > thorough response, but you might want to see the thread from Nov 10th > > > called "Load balancing required for preauthentication?" > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > I don't think anything has changed in the source since that > > > discussion. You might just try turning on load balancing if it's not > > > already. > > > > > > -Andy > > > > > > On 12/6/05, Mike Bennett wrote: > > > > If I put a valid normal user account in those parameters, then no > > > > login works. If this requires a special user account on the domain > > > > then I don't think it's viable for my situation, where the app will > > > > reside on another corporation's server. > > > > > > > > Thanks for the suggestion, though. > > > > > > > > On 12/6/05, Yannick wrote: > > > > > Hi Mike, > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > account on the domain that you can use to do so, then add the following > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > Hope this helps > > > > > Regards > > > > > Yannick > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > >The first login goes through correctly and the user can access the > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > >user, from the same user on the same computer but with a different > > > > > >browser) fails with no error message just as if the user or password > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > >advantage of some of the other fixes. > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mba2000 at ioplex.com Mon Dec 12 21:07:27 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 12 21:12:29 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> Message-ID: <20051212160727.3871c235.mba2000@ioplex.com> On Mon, 12 Dec 2005 13:47:11 -0700 Mike Bennett wrote: > It doesn't compile. > In this change : > public static byte[] getChallenge( UniAddress dc ) > throws SmbException, UnknownHostException { > - return getChallenge(dc, 0); > + return interrogate( dc ); Then make it: return interrogate( dc ).challenge; Mike > } > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > On 12/12/05, Michael B Allen wrote: > > Load balancing (and thus preauthentication) will only be used if the > > jcifs.http.domainController is NOT specified. > > > > An easier fix is probably to just change the code to perform > > preauthentiction without load balancing. I *think* all you need to do > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > @@ -67,8 +67,7 @@ > > static long dc_list_expiration; > > static int dc_list_counter; > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > - UniAddress dc = new UniAddress( addr ); > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > if (USERNAME == null) { > > trans.connect(); > > @@ -108,7 +107,7 @@ > > int i = dc_list_counter++ % max; > > if (dc_list[i] != null) { > > try { > > - return interrogate( dc_list[i] ); > > + return interrogate( new UniAddress( dc_list[i] )); > > } catch (SmbException se) { > > if (SmbTransport.log.level > 1) { > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > @@ -129,7 +128,7 @@ > > > > public static byte[] getChallenge( UniAddress dc ) > > throws SmbException, UnknownHostException { > > - return getChallenge(dc, 0); > > + return interrogate( dc ); > > } > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > I don't know why this wasn't done in the first place. Just an oversight > > I guess. It happends. > > > > The patchfile is also attached. On unix systems (at least) you can apply > > this patch like: > > > > $ cd src/jcifs/smb > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > compile and/or work. > > > > Mike > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > Mike Bennett wrote: > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > jcifs.http.loadBalance > > > true > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > anyway, so there was nothing to balance against. > > > > > > On 12/6/05, Andrew Miller wrote: > > > > I had a similar problem. I don't have time right now for a more > > > > thorough response, but you might want to see the thread from Nov 10th > > > > called "Load balancing required for preauthentication?" > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > I don't think anything has changed in the source since that > > > > discussion. You might just try turning on load balancing if it's not > > > > already. > > > > > > > > -Andy > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > If I put a valid normal user account in those parameters, then no > > > > > login works. If this requires a special user account on the domain > > > > > then I don't think it's viable for my situation, where the app will > > > > > reside on another corporation's server. > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > Hi Mike, > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > account on the domain that you can use to do so, then add the following > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > Regards > > > > > > Yannick > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > >The first login goes through correctly and the user can access the > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > >user, from the same user on the same computer but with a different > > > > > > >browser) fails with no error message just as if the user or password > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mkb137 at gmail.com Mon Dec 12 21:57:32 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Mon Dec 12 21:57:47 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <20051212160727.3871c235.mba2000@ioplex.com> References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> <20051212160727.3871c235.mba2000@ioplex.com> Message-ID: Using load balancing and a specified username and password (preauthentication?) with unmodified 1.2.7 gives the same "first login only" behaviour. Using the modifed version with a specified username and password causes the error : jcifs.smb.SmbAuthException: Logon failure: account currently disabled. Using the modifed version without a specified username and password gives the same "first login only" behaviour. On 12/12/05, Michael B Allen wrote: > On Mon, 12 Dec 2005 13:47:11 -0700 > Mike Bennett wrote: > > > It doesn't compile. > > In this change : > > public static byte[] getChallenge( UniAddress dc ) > > throws SmbException, UnknownHostException { > > - return getChallenge(dc, 0); > > + return interrogate( dc ); > > Then make it: > > return interrogate( dc ).challenge; > > Mike > > > } > > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > > > > On 12/12/05, Michael B Allen wrote: > > > Load balancing (and thus preauthentication) will only be used if the > > > jcifs.http.domainController is NOT specified. > > > > > > An easier fix is probably to just change the code to perform > > > preauthentiction without load balancing. I *think* all you need to do > > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > > @@ -67,8 +67,7 @@ > > > static long dc_list_expiration; > > > static int dc_list_counter; > > > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > > - UniAddress dc = new UniAddress( addr ); > > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > > if (USERNAME == null) { > > > trans.connect(); > > > @@ -108,7 +107,7 @@ > > > int i = dc_list_counter++ % max; > > > if (dc_list[i] != null) { > > > try { > > > - return interrogate( dc_list[i] ); > > > + return interrogate( new UniAddress( dc_list[i] )); > > > } catch (SmbException se) { > > > if (SmbTransport.log.level > 1) { > > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > > @@ -129,7 +128,7 @@ > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > throws SmbException, UnknownHostException { > > > - return getChallenge(dc, 0); > > > + return interrogate( dc ); > > > } > > > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > > > I don't know why this wasn't done in the first place. Just an oversight > > > I guess. It happends. > > > > > > The patchfile is also attached. On unix systems (at least) you can apply > > > this patch like: > > > > > > $ cd src/jcifs/smb > > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > > compile and/or work. > > > > > > Mike > > > > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > > Mike Bennett wrote: > > > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > > > jcifs.http.loadBalance > > > > true > > > > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > > anyway, so there was nothing to balance against. > > > > > > > > On 12/6/05, Andrew Miller wrote: > > > > > I had a similar problem. I don't have time right now for a more > > > > > thorough response, but you might want to see the thread from Nov 10th > > > > > called "Load balancing required for preauthentication?" > > > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > > > I don't think anything has changed in the source since that > > > > > discussion. You might just try turning on load balancing if it's not > > > > > already. > > > > > > > > > > -Andy > > > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > > If I put a valid normal user account in those parameters, then no > > > > > > login works. If this requires a special user account on the domain > > > > > > then I don't think it's viable for my situation, where the app will > > > > > > reside on another corporation's server. > > > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > > Hi Mike, > > > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > > account on the domain that you can use to do so, then add the following > > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > > Regards > > > > > > > Yannick > > > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > > >The first login goes through correctly and the user can access the > > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > > >user, from the same user on the same computer but with a different > > > > > > > >browser) fails with no error message just as if the user or password > > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mba2000 at ioplex.com Mon Dec 12 22:17:23 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 12 22:22:34 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> <20051212160727.3871c235.mba2000@ioplex.com> Message-ID: <20051212171723.20be6bd4.mba2000@ioplex.com> Well I don't know how to get preauth with jcifs.http.domainController to work then. Why can't you use the default method (jcifs.smb.client.domain and not jcifs.http.domainController)? On Mon, 12 Dec 2005 14:57:32 -0700 Mike Bennett wrote: > Using load balancing and a specified username and password > (preauthentication?) with unmodified 1.2.7 gives the same "first login > only" behaviour. > > Using the modifed version with a specified username and password > causes the error : > jcifs.smb.SmbAuthException: Logon failure: account currently disabled. > > Using the modifed version without a specified username and password > gives the same "first login only" behaviour. > > On 12/12/05, Michael B Allen wrote: > > On Mon, 12 Dec 2005 13:47:11 -0700 > > Mike Bennett wrote: > > > > > It doesn't compile. > > > In this change : > > > public static byte[] getChallenge( UniAddress dc ) > > > throws SmbException, UnknownHostException { > > > - return getChallenge(dc, 0); > > > + return interrogate( dc ); > > > > Then make it: > > > > return interrogate( dc ).challenge; > > > > Mike > > > > > } > > > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > > > > > > > On 12/12/05, Michael B Allen wrote: > > > > Load balancing (and thus preauthentication) will only be used if the > > > > jcifs.http.domainController is NOT specified. > > > > > > > > An easier fix is probably to just change the code to perform > > > > preauthentiction without load balancing. I *think* all you need to do > > > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > > > @@ -67,8 +67,7 @@ > > > > static long dc_list_expiration; > > > > static int dc_list_counter; > > > > > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > > > - UniAddress dc = new UniAddress( addr ); > > > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > > > if (USERNAME == null) { > > > > trans.connect(); > > > > @@ -108,7 +107,7 @@ > > > > int i = dc_list_counter++ % max; > > > > if (dc_list[i] != null) { > > > > try { > > > > - return interrogate( dc_list[i] ); > > > > + return interrogate( new UniAddress( dc_list[i] )); > > > > } catch (SmbException se) { > > > > if (SmbTransport.log.level > 1) { > > > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > > > @@ -129,7 +128,7 @@ > > > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > throws SmbException, UnknownHostException { > > > > - return getChallenge(dc, 0); > > > > + return interrogate( dc ); > > > > } > > > > > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > > > > > I don't know why this wasn't done in the first place. Just an oversight > > > > I guess. It happends. > > > > > > > > The patchfile is also attached. On unix systems (at least) you can apply > > > > this patch like: > > > > > > > > $ cd src/jcifs/smb > > > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > > > compile and/or work. > > > > > > > > Mike > > > > > > > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > > > Mike Bennett wrote: > > > > > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > > > > > jcifs.http.loadBalance > > > > > true > > > > > > > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > > > anyway, so there was nothing to balance against. > > > > > > > > > > On 12/6/05, Andrew Miller wrote: > > > > > > I had a similar problem. I don't have time right now for a more > > > > > > thorough response, but you might want to see the thread from Nov 10th > > > > > > called "Load balancing required for preauthentication?" > > > > > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > > > > > I don't think anything has changed in the source since that > > > > > > discussion. You might just try turning on load balancing if it's not > > > > > > already. > > > > > > > > > > > > -Andy > > > > > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > > > If I put a valid normal user account in those parameters, then no > > > > > > > login works. If this requires a special user account on the domain > > > > > > > then I don't think it's viable for my situation, where the app will > > > > > > > reside on another corporation's server. > > > > > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > > > Hi Mike, > > > > > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > > > account on the domain that you can use to do so, then add the following > > > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > Regards > > > > > > > > Yannick > > > > > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > > > >The first login goes through correctly and the user can access the > > > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > > > >user, from the same user on the same computer but with a different > > > > > > > > >browser) fails with no error message just as if the user or password > > > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mkb137 at gmail.com Tue Dec 13 17:58:31 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Tue Dec 13 17:59:16 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <20051212171723.20be6bd4.mba2000@ioplex.com> References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> <20051212160727.3871c235.mba2000@ioplex.com> <20051212171723.20be6bd4.mba2000@ioplex.com> Message-ID: Doing so with the modified version gives the error : java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for MYDOMAIN On 12/12/05, Michael B Allen wrote: > Well I don't know how to get preauth with jcifs.http.domainController to > work then. Why can't you use the default method (jcifs.smb.client.domain > and not jcifs.http.domainController)? > > On Mon, 12 Dec 2005 14:57:32 -0700 > Mike Bennett wrote: > > > Using load balancing and a specified username and password > > (preauthentication?) with unmodified 1.2.7 gives the same "first login > > only" behaviour. > > > > Using the modifed version with a specified username and password > > causes the error : > > jcifs.smb.SmbAuthException: Logon failure: account currently disabled. > > > > Using the modifed version without a specified username and password > > gives the same "first login only" behaviour. > > > > On 12/12/05, Michael B Allen wrote: > > > On Mon, 12 Dec 2005 13:47:11 -0700 > > > Mike Bennett wrote: > > > > > > > It doesn't compile. > > > > In this change : > > > > public static byte[] getChallenge( UniAddress dc ) > > > > throws SmbException, UnknownHostException { > > > > - return getChallenge(dc, 0); > > > > + return interrogate( dc ); > > > > > > Then make it: > > > > > > return interrogate( dc ).challenge; > > > > > > Mike > > > > > > > } > > > > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > > > > > > > > > > On 12/12/05, Michael B Allen wrote: > > > > > Load balancing (and thus preauthentication) will only be used if the > > > > > jcifs.http.domainController is NOT specified. > > > > > > > > > > An easier fix is probably to just change the code to perform > > > > > preauthentiction without load balancing. I *think* all you need to do > > > > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > > > > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > > > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > > > > @@ -67,8 +67,7 @@ > > > > > static long dc_list_expiration; > > > > > static int dc_list_counter; > > > > > > > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > > > > - UniAddress dc = new UniAddress( addr ); > > > > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > > > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > > > > if (USERNAME == null) { > > > > > trans.connect(); > > > > > @@ -108,7 +107,7 @@ > > > > > int i = dc_list_counter++ % max; > > > > > if (dc_list[i] != null) { > > > > > try { > > > > > - return interrogate( dc_list[i] ); > > > > > + return interrogate( new UniAddress( dc_list[i] )); > > > > > } catch (SmbException se) { > > > > > if (SmbTransport.log.level > 1) { > > > > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > > > > @@ -129,7 +128,7 @@ > > > > > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > > throws SmbException, UnknownHostException { > > > > > - return getChallenge(dc, 0); > > > > > + return interrogate( dc ); > > > > > } > > > > > > > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > > > > > > > I don't know why this wasn't done in the first place. Just an oversight > > > > > I guess. It happends. > > > > > > > > > > The patchfile is also attached. On unix systems (at least) you can apply > > > > > this patch like: > > > > > > > > > > $ cd src/jcifs/smb > > > > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > > > > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > > > > compile and/or work. > > > > > > > > > > Mike > > > > > > > > > > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > > > > Mike Bennett wrote: > > > > > > > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > > > > > > > jcifs.http.loadBalance > > > > > > true > > > > > > > > > > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > > > > anyway, so there was nothing to balance against. > > > > > > > > > > > > On 12/6/05, Andrew Miller wrote: > > > > > > > I had a similar problem. I don't have time right now for a more > > > > > > > thorough response, but you might want to see the thread from Nov 10th > > > > > > > called "Load balancing required for preauthentication?" > > > > > > > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > > > > > > > I don't think anything has changed in the source since that > > > > > > > discussion. You might just try turning on load balancing if it's not > > > > > > > already. > > > > > > > > > > > > > > -Andy > > > > > > > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > > > > If I put a valid normal user account in those parameters, then no > > > > > > > > login works. If this requires a special user account on the domain > > > > > > > > then I don't think it's viable for my situation, where the app will > > > > > > > > reside on another corporation's server. > > > > > > > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > > > > Hi Mike, > > > > > > > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > > > > account on the domain that you can use to do so, then add the following > > > > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > > Regards > > > > > > > > > Yannick > > > > > > > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > > > > >The first login goes through correctly and the user can access the > > > > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > > > > >user, from the same user on the same computer but with a different > > > > > > > > > >browser) fails with no error message just as if the user or password > > > > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mba2000 at ioplex.com Tue Dec 13 20:29:43 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Tue Dec 13 20:34:37 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: References: <43954F51.9020500@smellyfrog.com> <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> <20051212160727.3871c235.mba2000@ioplex.com> <20051212171723.20be6bd4.mba2000@ioplex.com> Message-ID: <20051213152943.1f8872e6.mba2000@ioplex.com> On Tue, 13 Dec 2005 10:58:31 -0700 Mike Bennett wrote: > Doing so with the modified version gives the error : > java.net.UnknownHostException: Failed to negotiate with a suitable > domain controller for MYDOMAIN Then it's not a valid domain name in WINs. Try the IP and change resolvOrder to use DNS before NBT. Ask your network administrator for help. Are you sure you know what the different properties do (e.g. do you know what WINS is?)? > > On 12/12/05, Michael B Allen wrote: > > Well I don't know how to get preauth with jcifs.http.domainController to > > work then. Why can't you use the default method (jcifs.smb.client.domain > > and not jcifs.http.domainController)? > > > > On Mon, 12 Dec 2005 14:57:32 -0700 > > Mike Bennett wrote: > > > > > Using load balancing and a specified username and password > > > (preauthentication?) with unmodified 1.2.7 gives the same "first login > > > only" behaviour. > > > > > > Using the modifed version with a specified username and password > > > causes the error : > > > jcifs.smb.SmbAuthException: Logon failure: account currently disabled. > > > > > > Using the modifed version without a specified username and password > > > gives the same "first login only" behaviour. > > > > > > On 12/12/05, Michael B Allen wrote: > > > > On Mon, 12 Dec 2005 13:47:11 -0700 > > > > Mike Bennett wrote: > > > > > > > > > It doesn't compile. > > > > > In this change : > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > > throws SmbException, UnknownHostException { > > > > > - return getChallenge(dc, 0); > > > > > + return interrogate( dc ); > > > > > > > > Then make it: > > > > > > > > return interrogate( dc ).challenge; > > > > > > > > Mike > > > > > > > > > } > > > > > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > > > > > > > > > > > > > On 12/12/05, Michael B Allen wrote: > > > > > > Load balancing (and thus preauthentication) will only be used if the > > > > > > jcifs.http.domainController is NOT specified. > > > > > > > > > > > > An easier fix is probably to just change the code to perform > > > > > > preauthentiction without load balancing. I *think* all you need to do > > > > > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > > > > > > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > > > > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > > > > > @@ -67,8 +67,7 @@ > > > > > > static long dc_list_expiration; > > > > > > static int dc_list_counter; > > > > > > > > > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > > > > > - UniAddress dc = new UniAddress( addr ); > > > > > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > > > > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > > > > > if (USERNAME == null) { > > > > > > trans.connect(); > > > > > > @@ -108,7 +107,7 @@ > > > > > > int i = dc_list_counter++ % max; > > > > > > if (dc_list[i] != null) { > > > > > > try { > > > > > > - return interrogate( dc_list[i] ); > > > > > > + return interrogate( new UniAddress( dc_list[i] )); > > > > > > } catch (SmbException se) { > > > > > > if (SmbTransport.log.level > 1) { > > > > > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > > > > > @@ -129,7 +128,7 @@ > > > > > > > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > > > throws SmbException, UnknownHostException { > > > > > > - return getChallenge(dc, 0); > > > > > > + return interrogate( dc ); > > > > > > } > > > > > > > > > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > > > > > > > > > I don't know why this wasn't done in the first place. Just an oversight > > > > > > I guess. It happends. > > > > > > > > > > > > The patchfile is also attached. On unix systems (at least) you can apply > > > > > > this patch like: > > > > > > > > > > > > $ cd src/jcifs/smb > > > > > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > > > > > > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > > > > > compile and/or work. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > > > > > > > > > jcifs.http.loadBalance > > > > > > > true > > > > > > > > > > > > > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > > > > > anyway, so there was nothing to balance against. > > > > > > > > > > > > > > On 12/6/05, Andrew Miller wrote: > > > > > > > > I had a similar problem. I don't have time right now for a more > > > > > > > > thorough response, but you might want to see the thread from Nov 10th > > > > > > > > called "Load balancing required for preauthentication?" > > > > > > > > > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > > > > > > > > > I don't think anything has changed in the source since that > > > > > > > > discussion. You might just try turning on load balancing if it's not > > > > > > > > already. > > > > > > > > > > > > > > > > -Andy > > > > > > > > > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > > > > > If I put a valid normal user account in those parameters, then no > > > > > > > > > login works. If this requires a special user account on the domain > > > > > > > > > then I don't think it's viable for my situation, where the app will > > > > > > > > > reside on another corporation's server. > > > > > > > > > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > > > > > Hi Mike, > > > > > > > > > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > > > > > account on the domain that you can use to do so, then add the following > > > > > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > Regards > > > > > > > > > > Yannick > > > > > > > > > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > > > > > >The first login goes through correctly and the user can access the > > > > > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > > > > > >user, from the same user on the same computer but with a different > > > > > > > > > > >browser) fails with no error message just as if the user or password > > > > > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mkb137 at gmail.com Tue Dec 13 20:41:56 2005 From: mkb137 at gmail.com (Mike Bennett) Date: Tue Dec 13 20:42:17 2005 Subject: [jcifs] Only the first login is successful In-Reply-To: <20051213152943.1f8872e6.mba2000@ioplex.com> References: <7d0fd8660512060905w3f159555hd9936124b8392320@mail.gmail.com> <20051212151117.0827108a.mba2000@ioplex.com> <20051212160727.3871c235.mba2000@ioplex.com> <20051212171723.20be6bd4.mba2000@ioplex.com> <20051213152943.1f8872e6.mba2000@ioplex.com> Message-ID: I don't get that error with 1.2.7. I just get the same old single-login problem. It's the version with your suggested modifications that gives that error. On 12/13/05, Michael B Allen wrote: > On Tue, 13 Dec 2005 10:58:31 -0700 > Mike Bennett wrote: > > > Doing so with the modified version gives the error : > > java.net.UnknownHostException: Failed to negotiate with a suitable > > domain controller for MYDOMAIN > > Then it's not a valid domain name in WINs. Try the IP and change > resolvOrder to use DNS before NBT. Ask your network administrator for > help. Are you sure you know what the different properties do (e.g. do > you know what WINS is?)? > > > > > On 12/12/05, Michael B Allen wrote: > > > Well I don't know how to get preauth with jcifs.http.domainController to > > > work then. Why can't you use the default method (jcifs.smb.client.domain > > > and not jcifs.http.domainController)? > > > > > > On Mon, 12 Dec 2005 14:57:32 -0700 > > > Mike Bennett wrote: > > > > > > > Using load balancing and a specified username and password > > > > (preauthentication?) with unmodified 1.2.7 gives the same "first login > > > > only" behaviour. > > > > > > > > Using the modifed version with a specified username and password > > > > causes the error : > > > > jcifs.smb.SmbAuthException: Logon failure: account currently disabled. > > > > > > > > Using the modifed version without a specified username and password > > > > gives the same "first login only" behaviour. > > > > > > > > On 12/12/05, Michael B Allen wrote: > > > > > On Mon, 12 Dec 2005 13:47:11 -0700 > > > > > Mike Bennett wrote: > > > > > > > > > > > It doesn't compile. > > > > > > In this change : > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > > > throws SmbException, UnknownHostException { > > > > > > - return getChallenge(dc, 0); > > > > > > + return interrogate( dc ); > > > > > > > > > > Then make it: > > > > > > > > > > return interrogate( dc ).challenge; > > > > > > > > > > Mike > > > > > > > > > > > } > > > > > > it's expecting a byte[], but interrogate returns NtlmChallenge. > > > > > > > > > > > > > > > > > > On 12/12/05, Michael B Allen wrote: > > > > > > > Load balancing (and thus preauthentication) will only be used if the > > > > > > > jcifs.http.domainController is NOT specified. > > > > > > > > > > > > > > An easier fix is probably to just change the code to perform > > > > > > > preauthentiction without load balancing. I *think* all you need to do > > > > > > > is apply the following changes to src/jcifs/smb/SmbSession.java: > > > > > > > > > > > > > > --- SmbSession.java 2005-10-07 19:56:56.000000000 -0400 > > > > > > > +++ SmbSession.java.NEW 2005-12-12 15:00:49.000000000 -0500 > > > > > > > @@ -67,8 +67,7 @@ > > > > > > > static long dc_list_expiration; > > > > > > > static int dc_list_counter; > > > > > > > > > > > > > > - private static NtlmChallenge interrogate( NbtAddress addr ) throws SmbException { > > > > > > > - UniAddress dc = new UniAddress( addr ); > > > > > > > + private static NtlmChallenge interrogate( UniAddress dc ) throws SmbException { > > > > > > > SmbTransport trans = SmbTransport.getSmbTransport( dc, 0 ); > > > > > > > if (USERNAME == null) { > > > > > > > trans.connect(); > > > > > > > @@ -108,7 +107,7 @@ > > > > > > > int i = dc_list_counter++ % max; > > > > > > > if (dc_list[i] != null) { > > > > > > > try { > > > > > > > - return interrogate( dc_list[i] ); > > > > > > > + return interrogate( new UniAddress( dc_list[i] )); > > > > > > > } catch (SmbException se) { > > > > > > > if (SmbTransport.log.level > 1) { > > > > > > > SmbTransport.log.println( "Failed validate DC: " + dc_list[i] ); > > > > > > > @@ -129,7 +128,7 @@ > > > > > > > > > > > > > > public static byte[] getChallenge( UniAddress dc ) > > > > > > > throws SmbException, UnknownHostException { > > > > > > > - return getChallenge(dc, 0); > > > > > > > + return interrogate( dc ); > > > > > > > } > > > > > > > > > > > > > > public static byte[] getChallenge( UniAddress dc, int port ) > > > > > > > > > > > > > > I don't know why this wasn't done in the first place. Just an oversight > > > > > > > I guess. It happends. > > > > > > > > > > > > > > The patchfile is also attached. On unix systems (at least) you can apply > > > > > > > this patch like: > > > > > > > > > > > > > > $ cd src/jcifs/smb > > > > > > > $ patch -p0 < /tmp/PreauthWithoutLoadBal.patch > > > > > > > > > > > > > > This is all TOTALLY untested though. Please let us know if it doesn't > > > > > > > compile and/or work. > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Dec 2005 12:15:39 -0700 > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > > Enabling load balancing (which the documenation says is on by default) via : > > > > > > > > > > > > > > > > jcifs.http.loadBalance > > > > > > > > true > > > > > > > > > > > > > > > > > > > > > > > > Didn't fix the problem. I only specified the one domain controller, > > > > > > > > anyway, so there was nothing to balance against. > > > > > > > > > > > > > > > > On 12/6/05, Andrew Miller wrote: > > > > > > > > > I had a similar problem. I don't have time right now for a more > > > > > > > > > thorough response, but you might want to see the thread from Nov 10th > > > > > > > > > called "Load balancing required for preauthentication?" > > > > > > > > > > > > > > > > > > http://lists.samba.org/archive/jcifs/2005-November/005683.html > > > > > > > > > > > > > > > > > > I don't think anything has changed in the source since that > > > > > > > > > discussion. You might just try turning on load balancing if it's not > > > > > > > > > already. > > > > > > > > > > > > > > > > > > -Andy > > > > > > > > > > > > > > > > > > On 12/6/05, Mike Bennett wrote: > > > > > > > > > > If I put a valid normal user account in those parameters, then no > > > > > > > > > > login works. If this requires a special user account on the domain > > > > > > > > > > then I don't think it's viable for my situation, where the app will > > > > > > > > > > reside on another corporation's server. > > > > > > > > > > > > > > > > > > > > Thanks for the suggestion, though. > > > > > > > > > > > > > > > > > > > > On 12/6/05, Yannick wrote: > > > > > > > > > > > Hi Mike, > > > > > > > > > > > > > > > > > > > > > > You probably need to use pre-authentication. So you need to setup a user > > > > > > > > > > > account on the domain that you can use to do so, then add the following > > > > > > > > > > > parameters in your web.xml file: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.username > > > > > > > > > > > UserAccountName > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.password > > > > > > > > > > > PasswordOfTheUserAccount > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > > Regards > > > > > > > > > > > Yannick > > > > > > > > > > > > > > > > > > > > > > Mike Bennett wrote: > > > > > > > > > > > > > > > > > > > > > > >Using a plain jboss-3.2.7 server, I have a web app configured to use > > > > > > > > > > > >NTLM login through jcifs. Using jcifs-1.2.7.jar or jcifs-1.2.6.jar, > > > > > > > > > > > >multiple users/browsers cannot log on to the server at the same time. > > > > > > > > > > > >The first login goes through correctly and the user can access the > > > > > > > > > > > >app. Any login thereafter (from a different machine, from a different > > > > > > > > > > > >user, from the same user on the same computer but with a different > > > > > > > > > > > >browser) fails with no error message just as if the user or password > > > > > > > > > > > >were invalid. I have not had this problem with jcifs-1.1.8.jar, which > > > > > > > > > > > >I've been using for quite a while. I was hoping to upgrade to take > > > > > > > > > > > >advantage of some of the other fixes. > > > > > > > > > > > > > > > > > > > > > > > >Is this a configuration problem or something else? My web.xml section > > > > > > > > > > > >is pretty plain : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > > > jcifs.http.NtlmHttpFilter > > > > > > > > > > > > > > > > > > > > > > > > jcifs.smb.client.domain > > > > > > > > > > > > MYDOMAIN > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jcifs.http.domainController > > > > > > > > > > > > mydc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NTML HTTP Authentication Filter > > > > > > > > > > > > /* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mdp at visanti.com Fri Dec 16 14:38:30 2005 From: mdp at visanti.com (Martin D. Pedersen) Date: Fri Dec 16 14:38:59 2005 Subject: [jcifs] DFS Links and Timeouts Message-ID: <9319B54BEF0A4C43BE9433B7E85FD81D05BBAB@sauron.visanti.com> Hi jcifs guys I'm having some problems with DFS Links. I have the following DFS setup. //primary/dfs/link link point to //secondary/data When I traverse //primary/dfs/link I am transparently redirected to //secondary/data (in theory). But jcifs somehow timeouts when accessing files through dfs links. If i traverse the files directly from //secondary/data there is no problem! Here is my example code: import jcifs.smb.SmbFile; public class SmbTimeout { public static void jcifsScan(String root, String userName, String password, int sleepTime) throws Exception { System.setProperty("jcifs.smb.client.username",userName); System.setProperty("jcifs.smb.client.password",password); long start = System.currentTimeMillis(); SmbFile smbRoot = new SmbFile(root); SmbFile[] files = smbRoot.listFiles(); for(SmbFile f : files) { System.out.println(f.canRead()+" : "+(System.currentTimeMillis()-start)); Thread.sleep(sleepTime); } } public static void main(String[] p_args) throws Exception { if(p_args.length!=4) { System.out.println("Usage: "); return; } String smbRoot = p_args[0]; String userName = p_args[1]; String password = p_args[2]; int sleepTime = Integer.parseInt(p_args[3]); jcifsScan(smbRoot,userName,password,sleepTime); } } When running: Java -classpath .:jcifs-1.2.7.jar SmbTimeout smb://primary/dfs/link/ user password 16000 I get: true : 744 false : 16760 false : 32777 [...] But when I run: Java -classpath .:jcifs-1.2.7.jar SmbTimeout smb://secondary/data/ user password 16000 I get: true : 560 true : 16597 true : 32632 [...] The reason this is a problem is because I'm implementing a crawler kind of process, that needs to process the files. Sometimes for more than 16s. I realise that I can set jcifs.smb.client.soTimeout=0 and it will solve my immediate problem. But I fear that this is a generel problem in handeling DFS referals. -- Martin D. Pedersen From mba2000 at ioplex.com Sat Dec 17 21:47:29 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Sat Dec 17 21:52:45 2005 Subject: [jcifs] DFS Links and Timeouts In-Reply-To: <9319B54BEF0A4C43BE9433B7E85FD81D05BBAB@sauron.visanti.com> References: <9319B54BEF0A4C43BE9433B7E85FD81D05BBAB@sauron.visanti.com> Message-ID: <20051217164729.25f39d5b.mba2000@ioplex.com> On Fri, 16 Dec 2005 15:38:30 +0100 "Martin D. Pedersen" wrote: > But jcifs somehow timeouts when accessing files through dfs links. > If i traverse the files directly from //secondary/data there is no > problem! I *think* I have this fixed. Try the attached patch and let us know how it goes for you. Basically the problem is that the member SmbFile.unc (which is a path relative to the share) is being changed when a DFS referral occurs. Initially this isn't a problem but after jcifs.smb.client.attrExpirationPeriod expires SmbFile.unc is used to construct paths that can be incorrect. > The reason this is a problem is because I'm implementing a crawler kind > of process, that needs to process the files. Sometimes for more than > 16s. > I realise that I can set jcifs.smb.client.soTimeout=0 and it will solve > my immediate problem. I don't think that would help actually. Actually it would just keep transports open indefinitely and you would quickly exhaust all memory. For a crawler you probably want to increase attrExpirationPeriod greatly though. That in combination with using a tree traversal algorithm that does not built large lists of nodes that will later become stale will give you much better results. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: DfsTimeout.patch Type: application/octet-stream Size: 932 bytes Desc: not available Url : http://lists.samba.org/archive/jcifs/attachments/20051217/421b7aa6/DfsTimeout.obj From mdp at visanti.com Mon Dec 19 11:38:03 2005 From: mdp at visanti.com (Martin D. Pedersen) Date: Mon Dec 19 11:38:39 2005 Subject: [jcifs] DFS Links and Timeouts Message-ID: <9319B54BEF0A4C43BE9433B7E85FD81D05BBB3@sauron.visanti.com> > -----Original Message----- > From: Michael B Allen [mailto:mba2000@ioplex.com] > Sent: 17. december 2005 22:47 > To: Martin D. Pedersen > Cc: jcifs@lists.samba.org > Subject: Re: [jcifs] DFS Links and Timeouts > > On Fri, 16 Dec 2005 15:38:30 +0100 > "Martin D. Pedersen" wrote: > > > But jcifs somehow timeouts when accessing files through dfs links. > > If i traverse the files directly from //secondary/data there is no > > problem! > > I *think* I have this fixed. Try the attached patch and let > us know how it goes for you. The patch fixes the (originally) problem, but there is still another problem. In my first test code I only used SmbFile.canRead(), this now works fine. If I extend the test code to also call SmbFile.length() it fails again, but this time with an Exception. Exception in thread "main" jcifs.smb.SmbException: The system cannot find the path specified. at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:503) at jcifs.smb.SmbTransport.send(SmbTransport.java:580) at jcifs.smb.SmbSession.send(SmbSession.java:229) at jcifs.smb.SmbTree.send(SmbTree.java:102) at jcifs.smb.SmbFile.send(SmbFile.java:688) at jcifs.smb.SmbFile.queryPath(SmbFile.java:1196) at jcifs.smb.SmbFile.length(SmbFile.java:2146) at visanti.crawler.samba.SmbTimeout.jcifsScan(SmbTimeout.java:19) at visanti.crawler.samba.SmbTimeout.main(SmbTimeout.java:35) If I only call SmbFile.length() this Exception doesn't occur! I guess there are more path rebuilds to be found? -- Martin From mba2000 at ioplex.com Mon Dec 19 21:47:25 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 19 21:52:36 2005 Subject: [jcifs] DFS Links and Timeouts In-Reply-To: <9319B54BEF0A4C43BE9433B7E85FD81D05BBB3@sauron.visanti.com> References: <9319B54BEF0A4C43BE9433B7E85FD81D05BBB3@sauron.visanti.com> Message-ID: <20051219164725.2a3b06f1.mba2000@ioplex.com> On Mon, 19 Dec 2005 12:38:03 +0100 "Martin D. Pedersen" wrote: > > > But jcifs somehow timeouts when accessing files through dfs links. > > > If i traverse the files directly from //secondary/data there is no > > > problem! > > > > I *think* I have this fixed. Try the attached patch and let > > us know how it goes for you. > > The patch fixes the (originally) problem, but there is still another > problem. > > Exception in thread "main" jcifs.smb.SmbException: The system cannot > find the path specified. After looking closely at how paths are handled across DFS I found a few problems. I think I understand this well now but I can't be certain all cases will work properly. Please test the attached patch carefully. If you find a problem please let me know and we'll rinse and repeat. Thanks, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: DfsPathFix.patch Type: application/octet-stream Size: 2504 bytes Desc: not available Url : http://lists.samba.org/archive/jcifs/attachments/20051219/49198c31/DfsPathFix.obj From huynh2 at gmail.com Wed Dec 21 17:10:35 2005 From: huynh2 at gmail.com (Scott) Date: Wed Dec 21 18:14:15 2005 Subject: [jcifs] SmbException Message-ID: Hi, I can map to 7/9 destinations using the same NTLM authentication, however two give me the following SmbException message. I can map to the folders manually through Windows using the same credentials. jcifs.smb.SmbException: 0xC00000CB at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:503) at jcifs.smb.SmbTransport.send(SmbTransport.java:603) at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:264) at jcifs.smb.SmbSession.send(SmbSession.java:223) at jcifs.smb.SmbTree.treeConnect(SmbTree.java:144) at jcifs.smb.SmbFile.connect(SmbFile.java:792) at jcifs.smb.SmbFile.connect0(SmbFile.java:762) at jcifs.smb.SmbFile.queryPath(SmbFile.java:1168) at jcifs.smb.SmbFile.exists(SmbFile.java:1250) Does anyone know what 0xC00000CB is? Thanks! From huynh2 at gmail.com Wed Dec 21 18:25:09 2005 From: huynh2 at gmail.com (Scott) Date: Wed Dec 21 18:29:56 2005 Subject: [jcifs] Re: SmbException References: Message-ID: Hi, I managed to connect to the other 2 servers with the SmbFile class by specifying the servers' names instead of their IPs... From Chuck.Caldarale at unisys.com Wed Dec 21 18:36:35 2005 From: Chuck.Caldarale at unisys.com (Caldarale, Charles R) Date: Wed Dec 21 18:37:10 2005 Subject: [jcifs] SmbException Message-ID: > From: > jcifs-bounces+chuck.caldarale=unisys.com@lists.samba.org > [mailto:jcifs-bounces+chuck.caldarale=unisys.com@lists.samba.org] > On Behalf Of Scott > Subject: [jcifs] SmbException > > Does anyone know what 0xC00000CB is? If that's an SMB NT status, I have it listed as "BAD DEVICE TYPE". (That probably didn't help you much.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From cbojneag at yahoo.com Fri Dec 23 19:07:32 2005 From: cbojneag at yahoo.com (Camil Bojneag) Date: Fri Dec 23 19:07:52 2005 Subject: [jcifs] AuthenticationFilter patch for the jcifs-1.1.11.jar Message-ID: <20051223190732.69185.qmail@web52605.mail.yahoo.com> Hi, This mail relates to the ?AutheticationFilter patch and definitions? message sent by Michael Kimberlin. This patch is supposed to work with the existing jcifs-1.1.11.jar and add to its functionality, the capability to display an error page ? instead of a blank one ? when user credentials are refused. I deployed this package on Tomcat and need to have this new feature implemented. So, I downloaded his code and I have problems compiling it. There are 2 objects in his code that cannot be found by the compiler in the classpath: AuthenticatedRequest and Negotiate, and I don?t know either to which package they do belong. Am I missing something? Should I import any other package? Is this patch supposed to work with the current jcifs jar? I appreciate your feedback and thanks in advance. -Camil __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From cbojneag at geocontrols.com Fri Dec 23 19:40:21 2005 From: cbojneag at geocontrols.com (Camil Bojneag) Date: Fri Dec 23 19:40:49 2005 Subject: [jcifs] AuthenticationFilter patch Message-ID: <58B3C31A10D569479026DF5FFEF5B6EC9A2636@svr05.gci.com> Hi, This mail relates to the "AutheticationFilter patch and definitions" message sent by Michael Kimberlin. This patch is supposed to work with the existing jcifs-1.1.11.jar and add to its functionality, the capability to display an error page - instead of a blank one - when user credentials are refused. I deployed this package on Tomcat and need to have this new feature implemented. So, I downloaded his code and I have problems compiling it. There are 2 objects in his code that cannot be found by the compiler in the classpath: AuthenticatedRequest and Negotiate, and I don't know either to which package they do belong. Am I missing something? Should I import any other package? Is this patch supposed to work with the current jcifs jar? I appreciate your feedback and thanks in advance. -Camil -------------- next part -------------- HTML attachment scrubbed and removed From Steve.Schols at gmail.com Mon Dec 26 10:03:34 2005 From: Steve.Schols at gmail.com (Steve Schols) Date: Mon Dec 26 10:11:20 2005 Subject: [jcifs] org.gnu.jcifs.CifsIOException: Unexpected SMB error code.( SMB=1:67) Message-ID: Hi everyone, I'm a Junior Software Engineer Java and have to implement extensions to an existing Java application. In this application, i have to fetch files from a Windows server (2 Windows servers to be exact). On one server i have .tif files which are scans of documents, and an index.dat file which is a text file that has to be read. On another server i have attachments, or the original documents of the scans. With these files and information in a database, i have to create an e-mail (JavaMail Message object) that will be stored in an e-mail archive and will be accessible through a Struts web application. Well ... it works splendid, completely functional...on my local computer. But it has to be tested and delivered on a Linux server ... There the problems begin ... i found out that i can't get to the windows server as easily as from my local computer/ (not just 'File file = new File("//servername/directoroy/subdirectory");', it worked locally, but not on the Linux machine)... Searched the Internet and found JCIFS (which is already used for god knows what in the application, but an older version so i downloaded the new one, didn't have CifsDisk and stuff yet). I implemented it, what i could understand from the tutorial, found out that the server couldn't be found in NETBIOS on linux ... so put a DNS name in /etc/hosts ... Then he could find the server, but now i get this , and i can't find anything about it on the internet, nor can i trace the cause: (warning: large amount of info) PRINT SHARENAME: cifs://husfp002/emailarchive/eArchive NetBIOS: Timeout=30000 NetBIOS: Tcpnodelay=true SMB_COM_NEGOTIATE Check name in Cache Check name in DNS NetBIOS name found in DNS: HUSFP002=HUSFP002/10.16.16.4 NetBIOS: doCall Called name=HUSFP002 Calling name=aws00229 Called addr=HUSFP002/10.16.16.4 Send SMB buffer smb_com = 0x72 smb_rcls = 0 smb_reh = 0 smb_flg = 0x00000000 smb_flg2 = 0x00000000 smb_tid = 0xffff smb_pid = 0x663f smb_uid = 0x0000 smb_mid = 0x0000 smb_wct = 0 smb_bcc = 58 smb_boff = 35 02 50 43 20 4E 45 54 57 4F 52 4B 20 50 52 4F 47 .PC NETWORK PROG 52 41 4D 20 31 2E 30 00 02 4C 41 4E 4D 41 4E 31 RAM 1.0..LANMAN1 2E 30 00 02 4C 4D 31 2E 32 58 30 30 32 00 02 4E .0..LM1.2X002..N 54 20 4C 4D 20 30 2E 31 32 00 T LM 0.12. Receive SMB buffer smb_com = 0x72 smb_rcls = 0 smb_reh = 0 smb_flg = 0x00000080 smb_flg2 = 0x00000000 smb_tid = 0xffff smb_pid = 0x663f smb_uid = 0x0000 smb_mid = 0x0000 smb_wct = 17 smb_vwv[0]= 0x0003 (3) smb_vwv[1]= 0x3203 (12803) smb_vwv[2]= 0x0100 (256) smb_vwv[3]= 0x0400 (1024) smb_vwv[4]= 0x0011 (17) smb_vwv[5]= 0x0000 (0) smb_vwv[6]= 0x0100 (256) smb_vwv[7]= 0x0000 (0) smb_vwv[8]= 0x0000 (0) smb_vwv[9]= 0xfd00 (-768) smb_vwv[10]= 0x0043 (67) smb_vwv[11]= 0x9400 (-27648) smb_vwv[12]= 0x66ae (26286) smb_vwv[13]= 0x023c (572) smb_vwv[14]= 0xc60a (-14838) smb_vwv[15]= 0xc401 (-15359) smb_vwv[16]= 0x08ff (2303) smb_bcc = 22 smb_boff = 69 DA 57 E9 6B 34 D4 5C 81 44 00 4F 00 4C 00 4D 00 .W.k4.\.D.O.L.M. 45 00 4E 00 00 00 E.N... Negotiated protocol:NT LM 0.12 SMB_COM_SESSION_SETUP_ANDX Send SMB buffer smb_com = 0x73 smb_rcls = 0 smb_reh = 0 smb_flg = 0x00000000 smb_flg2 = 0x00000003 smb_tid = 0x0000 smb_pid = 0x663f smb_uid = 0x0000 smb_mid = 0x0001 smb_wct = 13 smb_vwv[0]= 0x00ff (255) smb_vwv[1]= 0x0000 (0) smb_vwv[2]= 0xa000 (-24576) smb_vwv[3]= 0x0001 (1) smb_vwv[4]= 0x0000 (0) smb_vwv[5]= 0x0000 (0) smb_vwv[6]= 0x0000 (0) smb_vwv[7]= 0x0018 (24) smb_vwv[8]= 0x0018 (24) smb_vwv[9]= 0x0000 (0) smb_vwv[10]= 0x0000 (0) smb_vwv[11]= 0x0014 (20) smb_vwv[12]= 0x0000 (0) smb_bcc = 77 smb_boff = 61 42 05 66 1E 08 D0 78 41 A5 D9 4F 3A 06 5B 8A 1E B.f..xA..O:.[. BF D1 B5 27 81 97 DB 27 47 A9 5F 0C FC 7B 70 53 ...'...'G._..{pS B6 98 38 2F FD D9 FA 8B A8 D3 04 39 AD 32 F7 69 ..8/.......9.2.i 73 73 6F 72 71 37 31 00 3F 00 43 49 46 53 20 4A ssorq71.?.CIFS J 61 76 61 56 4D 20 43 6C 69 65 6E 74 00 avaVM Client. Receive SMB buffer smb_com = 0x73 smb_rcls = 0 smb_reh = 0 smb_flg = 0x00000080 smb_flg2 = 0x00000003 smb_tid = 0x0000 smb_pid = 0x663f smb_uid = 0x4803 smb_mid = 0x0001 smb_wct = 3 smb_vwv[0]= 0x00ff (255) smb_vwv[1]= 0x0052 (82) smb_vwv[2]= 0x0000 (0) smb_bcc = 41 smb_boff = 41 57 69 6E 64 6F 77 73 20 4E 54 20 34 2E 30 00 4E Windows NT 4.0.N 54 20 4C 41 4E 20 4D 61 6E 61 67 65 72 20 34 2E T LAN Manager 4. 30 00 44 4F 4C 4D 45 4E 00 0.DOLMEN. SMB_COM_TREE_CONNECT_ANDX Send SMB buffer smb_com = 0x75 smb_rcls = 0 smb_reh = 0 smb_flg = 0x00000000 smb_flg2 = 0x00000003 smb_tid = 0x0000 smb_pid = 0x663f smb_uid = 0x4803 smb_mid = 0x0002 smb_wct = 4 smb_vwv[0]= 0x00ff (255) smb_vwv[1]= 0x0000 (0) smb_vwv[2]= 0x0000 (0) smb_vwv[3]= 0x0018 (24) smb_bcc = 60 smb_boff = 43 47 A9 5F 0C FC 7B 70 53 B6 98 38 2F FD D9 FA 8B G._..{pS..8/.... A8 D3 04 39 AD 32 F7 69 5C 5C 48 55 53 46 50 30 ...9.2.i\\HUSFP0 30 32 5C 45 4D 41 49 4C 41 52 43 48 49 56 45 2F 02\EMAILARCHIVE/ 45 41 52 43 48 49 56 45 00 41 3A 00 EARCHIVE.A:. SMB ERROR: 1, 67: Unexpected SMB error code.( SMB=1:67) 1 Receive SMB buffer smb_com = 0x75 smb_rcls = 1 smb_reh = 67 smb_flg = 0x00000080 smb_flg2 = 0x00000003 smb_tid = 0x0000 smb_pid = 0x663f smb_uid = 0x4803 smb_mid = 0x0002 smb_wct = 0 smb_bcc = 0 smb_boff = 35 org.gnu.jcifs.CifsIOException: Unexpected SMB error code.( SMB=1:67) at org.gnu.jcifs.SessionImpl.doTreeConnect(SessionImpl.java:724) at org.gnu.jcifs.SessionImpl.tryTreeConnect(SessionImpl.java:485) at org.gnu.jcifs.SessionImpl.connect(SessionImpl.java:410) at org.gnu.jcifs.CifsSessionManager.connectDisk (CifsSessionManager.java:220) at be.dolmen.scanarch.application.ScanRetriever.getScansToArchive (ScanRetriever.java:143) at be.dolmen.scanarch.application.ScanArchiver.main (ScanArchiver.java:46) Can anyone help me with this exception? If you have any questions regarding the application or implementation, feel free to ask. (This is something that should be finished by the end of the week :-s ) Thanks in advance From mba2000 at ioplex.com Mon Dec 26 17:45:49 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Mon Dec 26 17:50:57 2005 Subject: [jcifs] org.gnu.jcifs.CifsIOException: Unexpected SMB error code.( SMB=1:67) In-Reply-To: References: Message-ID: <20051226124549.564ecdbb.mba2000@ioplex.com> We are http://jcifs.samba.org/. We don't support the one you're using. It's totally different. Mike From Steve.Schols at gmail.com Tue Dec 27 08:22:26 2005 From: Steve.Schols at gmail.com (Steve Schols) Date: Tue Dec 27 08:23:04 2005 Subject: [jcifs] Re: org.gnu.jcifs.CifsIOException: Unexpected SMB error code.( SMB=1:67) References: <20051226124549.564ecdbb.mba2000@ioplex.com> Message-ID: Michael B Allen ioplex.com> writes: > > We are http://jcifs.samba.org/. We don't support the one you're > using. It's totally different. > > Mike > > What is the difference then please? I got the jar from jcifs.samba.org. :-s From cbojneag at yahoo.com Tue Dec 27 16:12:51 2005 From: cbojneag at yahoo.com (Camil Bojneag) Date: Tue Dec 27 16:13:17 2005 Subject: Fwd: [jcifs] AuthenticationFilter patch for the jcifs-1.1.11.jar Message-ID: <20051227161251.68208.qmail@web52605.mail.yahoo.com> Note: forwarded message attached. __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ -------------- next part -------------- An embedded message was scrubbed... From: Camil Bojneag Subject: [jcifs] AuthenticationFilter patch for the jcifs-1.1.11.jar Date: Fri, 23 Dec 2005 11:07:32 -0800 (PST) Size: 3483 Url: http://lists.samba.org/archive/jcifs/attachments/20051227/4d91dd6a/attachment.eml From mba2000 at ioplex.com Tue Dec 27 21:45:28 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Tue Dec 27 21:50:33 2005 Subject: [jcifs] Re: org.gnu.jcifs.CifsIOException: Unexpected SMB error code.( SMB=1:67) In-Reply-To: References: <20051226124549.564ecdbb.mba2000@ioplex.com> Message-ID: <20051227164528.23129168.mba2000@ioplex.com> On Tue, 27 Dec 2005 08:22:26 +0000 (UTC) Steve Schols wrote: > Michael B Allen ioplex.com> writes: > > > > > We are http://jcifs.samba.org/. We don't support the one you're > > using. It's totally different. > > > > Mike > > > > > > > What is the difference then please? > > I got the jar from jcifs.samba.org. > :-s The question you asked is about org.gnu.jcifs.* classes. Although those classes serve the same purpose they are from a differnet project that is not related at all to http://jcifs.samba.org or this mailing list. Therefore, your question is off topic here. If you have a question about about a package downloaded from http://jcifs.samba.org you are welcome to ask here. Mike From kmaull at webroot.com Thu Dec 29 01:07:40 2005 From: kmaull at webroot.com (Keith) Date: Thu Dec 29 01:11:04 2005 Subject: [jcifs] jcifs.util.transport.TransportException: Connection timeout Message-ID: Hi- I'm just getting started with jcifs and am coming up with the following in a test program. I'm using jcifs1.2.7.jar. I can't seem to figure out why it's failing ( thought it succeeds intermittently ), but it fails more than it succeeds, like 10:1. Looks like listFiles() is causing problems, and I saw a thread about 1.1.11 on this, and then another about 1.2.7 solving some apparent issues, but ... I can't seem to get any love. It also doesn't seem to matter whether I authenticate or not - I can get intermittently connections ( or failures, depending on whether you stand on your head or your feet ) either way. Any thoughts, ideas or updates would be fantastic! Code : ... try { System.setProperty("jcifs.util.loglevel", "0"); System.setProperty("jcifs.netbios.wins", "10.10.10.10"); System.setProperty("jcifs.netbios.retryTimeout", "20000"); System.setProperty("jcifs.netbios.soTimeout", "30000"); SmbFile f = new SmbFile("smb://"); SmbFile[] files = f.listFiles(); } catch (Exception e) { // TODO : log exception ... Error : jcifs.smb.SmbException: jcifs.util.transport.TransportException: Connection timeout at jcifs.util.transport.Transport.connect(Transport.java:177) at jcifs.smb.SmbTransport.connect(SmbTransport.java:286) at jcifs.smb.SmbTree.treeConnect(SmbTree.java:129) at jcifs.smb.SmbFile.connect(SmbFile.java:792) at jcifs.smb.SmbFile.connect0(SmbFile.java:762) at jcifs.smb.SmbFile.doNetEnum(SmbFile.java:1603) at jcifs.smb.SmbFile.listFiles(SmbFile.java:1573) at jcifs.smb.SmbFile.listFiles(SmbFile.java:1483) From mba2000 at ioplex.com Thu Dec 29 02:34:36 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Thu Dec 29 02:39:39 2005 Subject: [jcifs] jcifs.util.transport.TransportException: Connection timeout In-Reply-To: References: Message-ID: <20051228213436.6596560c.mba2000@ioplex.com> On Thu, 29 Dec 2005 01:07:40 +0000 (UTC) Keith wrote: > jcifs.smb.SmbException: > jcifs.util.transport.TransportException: Connection timeout > at jcifs.util.transport.Transport.connect(Transport.java:177) > at jcifs.smb.SmbTransport.connect(SmbTransport.java:286) Connection timeout most likely means that the target host did not respond to the initial SYN message. Take a packet capture [1] and check to see if the target is responding to the initil SYN packet. If it did not, there is a problem with the network. If it did, there is a problem with jCIFS in which case you are welcome to report back here. Mike [1] http://jcifs.samba.org/capture.html PS: I believe loglevel = 0 means not to log anything. Try a loglevel of 10. From alvin_anwar at msn.com Thu Dec 29 03:30:05 2005 From: alvin_anwar at msn.com (Alvin Anwar) Date: Thu Dec 29 04:00:32 2005 Subject: [jcifs] File naming problem Message-ID: Hi all, Currently I noticed there's an inconsistency error in getting the files' names for different level of shared directory. Let me elaborate first. *Please correct me if I'm wrong somewhere, it might be my mistake after all* In JCIFS SmbFile getType() function, the shared directory is specified as \\ TYPE_SERVER \ TYPE_SHARE \ TYPE_FILESYSTEM \ TYPE_FILESYSTEM ... Currently I'm working on using JCIFS on file servers running Windows XP SP 2 Chinese version. The unstability was found when I tries to list the files using listFiles() from SmbFile class at server level (TYPE_SERVER). When I retrieve the name and display it in a webpage (using IntergraTUM WebDisk), some of the shared directory with Chinese characters are retrieved wrongly (which makes everything a broken link). On the other hand, when the shared directory (using Chinese character) is located as TYPE_SHARE or the next, it can be displayed correctly. Reading at the source code, I notice that listFiles() might be calling different functions, depending on the path of the inputted URL (doNetEnum() or doFindFirstNext()). Does anybody have faced this problem before? Or have I made any mistake somewhere? Regards, Alvin Anwar From thomas.bley at simple-groupware.de Thu Dec 29 05:05:43 2005 From: thomas.bley at simple-groupware.de (Thomas Bley) Date: Thu Dec 29 05:02:53 2005 Subject: [jcifs] File naming problem In-Reply-To: References: Message-ID: <43B36EA7.4000805@simple-groupware.de> Hi, Looks like you are using unicode characters in the share name. I'm wondering why you see these names, but I think it can be an issue with the webdisk, I'll look at it. See also Mike's mail from January. bye Thomas This is what Mike has written about Japanese share names: On Mon, 24 Jan 2005 02:30:36 -0800 (PST) Praveen Kumar > wrote: >/ I am trying to get a list of shares on my server. />/ It has one japanese share. SmbFile#listFiles() gives />/ me a SmbFile with name = null and path = />/ smb://server/?????/ />/ />/ I have tried setting jcifs.encoding and />/ jcifs.useUnicode properties but to no avail. />/ />/ Are japanese shares supported in the latest JCIFS ? / Unicode share names are not supported at this time. That requires the NetrShareEnumAll RPC which we have working but it will not be integrated into jcifs for some time (2.0). Mike Alvin Anwar wrote: > > Dear Thomas, > > It's nice to hear from you so soon *I'm getting really desperate in > reading the codes of JCIFS*. Anyway, for example I have a shared > directory at > > \\192.168.0.67\ ? ???? (not sure if u > can see this correctly) > > the link in Webdisk will be (cut from Webdisk -> view source) > > href='/ba/base/192.168.0.67/%C3%90%C3%82%C2%BD%C2%A8%C3%8E%C3%84%C2%BC%C3%BE%C2%BC%C3%90/'>?????????? > > The link becomes broken and the folder is inaccessible from WebDisk. > However, in the second case, if the same folder is shared as > > \\192.168.0.67\sharedDocs\ > ? ???? (notice that I share > its parent folder in English name, instead of the Chinese folder itself) > > the link in Webdisk will be > > href='/ba/base/192.168.0.67/sharedDocs/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB% > B6%E5%A4%B9/'>????? > > *notice that the link value is different, even though it is the same > folder > > However, in the first scenario, if i access the folder using > /192.168.0.67/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB%B6%E5%A4%B9/, voila, I > can access my folder. > > I was wondering if this is more because of encoding issue (maybe some > part of the JCIFS handles in ASCII, UTF-8 or else). Thanks Thomas for > your reply, I'm looking forward for ur reply soon while I'm digging > myself to JCIFS code myself. > > Regards, Alvin > > ------------------------------------------------------------------------ > From: /Thomas Bley / > To: /Alvin Anwar / > Subject: /Re: [jcifs] File naming problem/ > Date: /Thu, 29 Dec 2005 05:12:49 +0100/ > >Can you give me an example of a path that is not correctly retrieved > >and results everything in a broken link ? > > > >Thanks, > >Thomas > > > >Alvin Anwar wrote: > >>Hi all, > >> > >>Currently I noticed there's an inconsistency error in getting the > >>files' names for different level of shared directory. Let me > >>elaborate first. *Please correct me if I'm wrong somewhere, it > >>might be my mistake > >>after all* > >> > >>In JCIFS SmbFile getType() function, the shared directory is > >>specified as > >>\\ TYPE_SERVER \ TYPE_SHARE \ TYPE_FILESYSTEM \ TYPE_FILESYSTEM ... > >> > >>Currently I'm working on using JCIFS on file servers running > >>Windows XP > >>SP 2 Chinese version. The unstability was found when I tries to > >>list the files using listFiles() from SmbFile class at server level > >>(TYPE_SERVER). > >> > >>When I retrieve the name and display it in a webpage (using > >>IntergraTUM > >>WebDisk), some of the shared directory with Chinese characters are > >>retrieved wrongly (which makes everything a broken link). On the > >>other hand, when the shared directory (using Chinese character) is > >>located as > >>TYPE_SHARE or the next, it can be displayed correctly. > >> > >>Reading at the source code, I notice that listFiles() might be > >>calling > >>different functions, depending on the path of the inputted URL > >>(doNetEnum() > >>or doFindFirstNext()). > >> > >>Does anybody have faced this problem before? Or have I made any > >>mistake > >>somewhere? > >> > >>Regards, > >>Alvin Anwar > >> > >> > >> > > > > > ------------------------------------------------------------------------ > Find love online with MSN Personals > From jmarshall at alum.mit.edu Thu Dec 29 17:32:54 2005 From: jmarshall at alum.mit.edu (Joe Marshall) Date: Thu Dec 29 17:33:02 2005 Subject: [jcifs] Jcifs bug? Message-ID: I have a java.net.URI from which I'm creating a jcifs.smb.SmbFile I create a java.net.URL as an intermediate structure: URL intermediate = new URL (myURI.getScheme(), myURI.getHost(), myURI.getPath()); In theory, I can create the SmbFile directly from this URL: SmbFile mySmbFile = new SmbFile (intermediate, myAuth); but this causes an error with a bogus port of -1 However, if I create the SmbFile via a string: SmbFile mySmbFile = new SmbFile (intermediate.toString(), myAuth); everything is copacetic. No need for an immediate fix, just thought you'd like to know. -- ~jrm From mba2000 at ioplex.com Thu Dec 29 17:40:19 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Thu Dec 29 17:45:31 2005 Subject: [jcifs] File naming problem In-Reply-To: References: Message-ID: <20051229124019.3631d20a.mba2000@ioplex.com> On Thu, 29 Dec 2005 03:30:05 +0000 (UTC) Alvin Anwar wrote: > Hi all, > > Currently I noticed there's an inconsistency error in getting the > files' names for different level of shared directory. Let me elaborate > first. *Please correct me if I'm wrong somewhere, it might be my mistake > after all* > > In JCIFS SmbFile getType() function, the shared directory is > specified as > \\ TYPE_SERVER \ TYPE_SHARE \ TYPE_FILESYSTEM \ TYPE_FILESYSTEM ... > > Currently I'm working on using JCIFS on file servers running Windows XP > SP 2 Chinese version. The unstability was found when I tries to list > the files using listFiles() from SmbFile class at server level > (TYPE_SERVER). > > When I retrieve the name and display it in a webpage (using IntergraTUM > WebDisk), some of the shared directory with Chinese characters are > retrieved wrongly (which makes everything a broken link). On the other To retrieve server and share lists jCIFS uses an older "RAP" protocol that does not support Unicode. MSRPC is necessary to properly enumerate servers and shares that contain Unicode characters. We have implemented MSRPC via a project called Jarapac and there are example programs that can properly emumerate shares. But that work was never integrated before people moved on to other things. Currently jCIFS is in maintainence mode. But it is strange that the servers and shares are listed at all. Try the examples/ListFiles.java example in the JCIFS packae. One possability is that the server you are communicating with isn't negotiating Unicode but is using the OEM codeset instead. If this is the case the RAP functions might actually work if you change the jcifs.encoding property (see the Overview page of the API documentation). Mike From mba2000 at ioplex.com Thu Dec 29 17:42:22 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Thu Dec 29 17:47:32 2005 Subject: [jcifs] Jcifs bug? In-Reply-To: References: Message-ID: <20051229124222.0bab1294.mba2000@ioplex.com> Ok, I'll add this to The List. Thanks, Mike On Thu, 29 Dec 2005 09:32:54 -0800 Joe Marshall wrote: > I have a java.net.URI from which I'm creating a jcifs.smb.SmbFile > > I create a java.net.URL as an intermediate structure: > > URL intermediate = new URL (myURI.getScheme(), > myURI.getHost(), > myURI.getPath()); > > In theory, I can create the SmbFile directly from this URL: > > SmbFile mySmbFile = new SmbFile (intermediate, myAuth); > > but this causes an error with a bogus port of -1 > However, if I create the SmbFile via a string: > > SmbFile mySmbFile = new SmbFile (intermediate.toString(), myAuth); > > everything is copacetic. > > No need for an immediate fix, just thought you'd like to know. > > > -- > ~jrm > From Sucheeta_Karandikar at bmc.com Thu Dec 29 18:37:30 2005 From: Sucheeta_Karandikar at bmc.com (Karandikar, Sucheeta) Date: Thu Dec 29 18:38:00 2005 Subject: [jcifs] SmbFile.Listfiles() throwing an exception Message-ID: I have a server that is sitting within a DMZ on a Windows 2003 box. I am trying to use the Smbfile.ListFiles(), to which I get an "Access Denied" exception. The user used is part of the Administrators group and has all the rights to the share on the same machine. Any idea on why that could be happening? Are there any special permissions needed for a Windows 2003 server or a machine sitting inside a DMZ ? Thanks, Sucheta -------------- next part -------------- HTML attachment scrubbed and removed From os at sdm.de Fri Dec 30 10:27:07 2005 From: os at sdm.de (Oliver Schoett) Date: Fri Dec 30 10:27:56 2005 Subject: [jcifs] jcifs-1.2.5 fails on bad domain controller; does not try others Message-ID: <43B50B7B.1070303@sdm.de> In message <20050315133739.7a33637d.mba2000@ioplex.com> dated Tue, 15 Mar 2005 13:37:39 -0500, Michael B Allen writes: > CIFS should handle this automatically. When jcifs rotates to a new > DC it tries to negotiate with it to see if it's "good". If it isn't it > removes it from the list. This process should not "hang". However, the 1.2.5 NtlmHttpFilter still fails when the first DC in the list returned from WINS is bad (stack trace at the end). Apparently, it does *not* proceed to the other DCs in the list, as suggested above. We have a customer that wants resilience against a DC failure. How can I provide that to him using jcifs? Regards, Oliver Schoett java.net.SocketTimeoutException: Receive timed out at java.net.PlainDatagramSocketImpl.receive(Native Method) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:129) at java.net.DatagramSocket.receive(DatagramSocket.java:701) at jcifs.netbios.NameServiceClient.run(NameServiceClient.java:184) at java.lang.Thread.run(Thread.java:568) Failed validate DC: ******<1C>/***.***.197.200 jcifs.smb.SmbException: jcifs.util.transport.TransportException: Connection timeout at jcifs.util.transport.Transport.connect(Transport.java:174) at jcifs.smb.SmbTransport.connect(SmbTransport.java:270) at jcifs.smb.SmbSession.interrogate(SmbSession.java:74) at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111) at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192) at java.lang.Thread.run(Thread.java:568) at jcifs.smb.SmbTransport.connect(SmbTransport.java:272) at jcifs.smb.SmbSession.interrogate(SmbSession.java:74) at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111) at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192) at java.lang.Thread.run(Thread.java:568) 05/12/30 10:45:48 java.net.SocketException: Connection timed out:could be due to invalid address 05/12/30 10:45:48 at java.net.PlainSocketImpl.socketConnect(Native Method) 05/12/30 10:45:48 at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:329) 05/12/30 10:45:48 at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:194) 05/12/30 10:45:48 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:181) 05/12/30 10:45:48 at java.net.Socket.connect(Socket.java:459) 05/12/30 10:45:48 at java.net.Socket.connect(Socket.java:409) 05/12/30 10:45:48 at java.net.Socket.(Socket.java:315) 05/12/30 10:45:48 at java.net.Socket.(Socket.java:143) 05/12/30 10:45:48 at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:240) 05/12/30 10:45:48 at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:282) 05/12/30 10:45:48 at jcifs.util.transport.Transport.run(Transport.java:214) 05/12/30 10:45:48 at java.lang.Thread.run(Thread.java:568) From os at sdm.de Fri Dec 30 10:37:44 2005 From: os at sdm.de (Oliver Schoett) Date: Fri Dec 30 10:38:17 2005 Subject: [jcifs] Re: jcifs-1.2.5 fails on bad domain controller; does not try others In-Reply-To: <43B50B7B.1070303@sdm.de> References: <43B50B7B.1070303@sdm.de> Message-ID: <43B50DF8.1050308@sdm.de> Oliver Schoett wrote: > In message <20050315133739.7a33637d.mba2000@ioplex.com> dated Tue, 15 > Mar 2005 13:37:39 -0500, Michael B Allen writes: >> CIFS should handle this automatically. When jcifs rotates to a new >> DC it tries to negotiate with it to see if it's "good". If it isn't it >> removes it from the list. This process should not "hang". > However, the 1.2.5 NtlmHttpFilter still fails when the first DC in the > list returned from WINS is bad (stack trace at the end). Apparently, > it does *not* proceed to the other DCs in the list, as suggested above. I should add that the error message in the browser (talking to an OC4J server with jcifs 1.2.5) is the following: 500 Internal Server Error 500 Internal Server Error java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for ****** at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:126) at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:208) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:125) at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192) at java.lang.Thread.run(Thread.java:568) Regards, Oliver Schoett From os at sdm.de Fri Dec 30 10:59:33 2005 From: os at sdm.de (Oliver Schoett) Date: Fri Dec 30 11:00:27 2005 Subject: [jcifs] SOLVED: jcifs-1.2.5 fails on bad domain controller; does not try others In-Reply-To: <43B50DF8.1050308@sdm.de> References: <43B50B7B.1070303@sdm.de> <43B50DF8.1050308@sdm.de> Message-ID: <43B51315.2060104@sdm.de> Oliver Schoett wrote: > Oliver Schoett wrote: >> In message <20050315133739.7a33637d.mba2000@ioplex.com> dated Tue, 15 >> Mar 2005 13:37:39 -0500, Michael B Allen writes: >>> CIFS should handle this automatically. When jcifs rotates to a new >>> DC it tries to negotiate with it to see if it's "good". If it isn't it >>> removes it from the list. This process should not "hang". >> However, the 1.2.5 NtlmHttpFilter still fails when the first DC in >> the list returned from WINS is bad (stack trace at the end). >> Apparently, it does *not* proceed to the other DCs in the list, as >> suggested above. > I should add that the error message in the browser (talking to an OC4J > server with jcifs 1.2.5) is the following: > > 500 Internal Server Error > 500 Internal Server Error > java.net.UnknownHostException: Failed to negotiate with a suitable > domain controller for ****** Sorry, the customer configuration had the setting jcifs.netbios.lookupRespLimit=1 This means that only the first entry in the DC list is tried and precisely explains the observed behaviour; there is no problem. Regards, Oliver Schoett From thomas.bley at simple-groupware.de Sat Dec 31 04:41:55 2005 From: thomas.bley at simple-groupware.de (Thomas Bley) Date: Sat Dec 31 04:38:55 2005 Subject: [jcifs] File naming problem In-Reply-To: <20051229124019.3631d20a.mba2000@ioplex.com> References: <20051229124019.3631d20a.mba2000@ioplex.com> Message-ID: <43B60C13.9020805@simple-groupware.de> Hi Mike, I took Samba 3.0.12 and created a share with german special characters (=umlaute) named 'test???': The umlaute are in iso8859-1, I hope you see it in my mail. My code: SmbFile file = new SmbFile( "smb://administrator:admin@192.168.0.200/" ); long t1 = System.currentTimeMillis(); SmbFile[] files = file.listFiles(); long t2 = System.currentTimeMillis() - t1; for( int i = 0; i < files.length; i++ ) { System.out.print( " " + files[i].getName() ); } System.out.println("result should be test???"); System.out.println( files.length + " files in " + t2 + "ms" ); The results (gives test???, but not test???): #JCIFS PROPERTIES #Sat Dec 31 05:25:30 CET 2005 java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition sun.boot.library.path=E\:\\Program Files\\Java2SDK 1-41\\jre\\bin java.vm.version=1.4.1_01-b01 jcifs.encoding=ISO8859_1 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http\://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io user.country=DE sun.os.patch.level=Service Pack 2 java.vm.specification.name=Java Virtual Machine Specification user.dir=h\:\\workspace\\jcifs java.runtime.version=1.4.1_01-b01 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment java.endorsed.dirs=E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\endorsed os.arch=x86 java.io.tmpdir=E\:\\Temp\\ line.separator=\r\n java.vm.specification.vendor=Sun Microsystems Inc. user.variant= os.name=Windows XP sun.java2d.fontpath= java.library.path=E\:\\Program Files\\Java2SDK 1-41\\bin;.;E\:\\WINNT\\system32;E\:\\WINNT;e\:\\PROGRA~1\\gtk\\bin;E\:\\WINNT\\system32;E\:\\WINNT;E\:\\WINNT\\System32\\Wbem;E\:\\Program Files\\Java2SDK 1-41\\jre\\bin;e\:\\program files\\linuxtools;e\:\\program files\\linuxtools\\mc;D\:\\Development\\oraclient java.specification.name=Java Platform API Specification java.class.version=48.0 java.util.prefs.PreferencesFactory=java.util.prefs.WindowsPreferencesFactory os.version=5.1 user.home=E\:\\Documents and Settings\\admin user.timezone= java.awt.printerjob=sun.awt.windows.WPrinterJob file.encoding=Cp1252 java.specification.version=1.4 jcifs.util.loglevel=10 user.name=admin java.class.path=h\:\\workspace\\jcifs\\bin;h\:\\webdisk\\lib\\servlet-api.jar java.vm.specification.version=1.0 sun.arch.data.model=32 java.home=E\:\\Program Files\\Java2SDK 1-41\\jre java.specification.vendor=Sun Microsystems Inc. user.language=de awt.toolkit=sun.awt.windows.WToolkit java.vm.info=mixed mode java.version=1.4.1_01 java.ext.dirs=E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\ext sun.boot.class.path=E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\rt.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\i18n.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\sunrsasign.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\jsse.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\jce.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\lib\\charsets.jar;E\:\\Program Files\\Java2SDK 1-41\\jre\\classes java.vendor=Sun Microsystems Inc. file.separator=\\ java.vendor.url.bug=http\://java.sun.com/cgi-bin/bugreport.cgi sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle sun.cpu.isalist=pentium i486 i386 New data read: Transport1[0.0.0.0<00>/192.168.0.200:445] 00000: FF 53 4D 42 72 00 00 00 00 88 01 C0 00 00 00 00 |?SMBr......?....| 00010: 00 00 00 00 00 00 00 00 00 00 49 7D 00 00 01 00 |..........I}....| byteCount=26 but readBytesWireFormat returned 24 NodeStatusRequest[nameTrnId=1,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=false,isBroadcast=false,resultCode=0,questionCount=1,answerCount=0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0] 00000: 00 01 00 00 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA| 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA| 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!| 00030: 00 01 |.. | NodeStatusRequest[nameTrnId=2,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=false,isBroadcast=false,resultCode=0,questionCount=1,answerCount=0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0] 00000: 00 02 00 00 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA| 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA| 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!| 00030: 00 01 |.. | java.net.SocketTimeoutException: Receive timed out at java.net.PlainDatagramSocketImpl.receive(Native Method) at java.net.DatagramSocket.receive(DatagramSocket.java:671) at jcifs.netbios.NameServiceClient.run(NameServiceClient.java:184) at java.lang.Thread.run(Thread.java:536) treeConnect: unc=\\192.168.0.200\IPC$,service=????? sessionSetup: accountName=administrator,primaryDomain=? SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=0,pid=12050,uid=0,mid=2,wordCount=13,byteCount=115,andxCommand=0x75,andxOffset=176,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=24,capabilities=84,accountName=administrator,primaryDomain=?,NATIVE_OS=Windows XP,NATIVE_LANMAN=jCIFS] SmbComTreeConnectAndX[command=SMB_COM_TREE_CONNECT_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0x0000,signSeq=0,tid=0,pid=12050,uid=0,mid=0,wordCount=4,byteCount=49,andxCommand=0xFF,andxOffset=0,disconnectTid=false,passwordLength=1,password=,path=\\192.168.0.200\IPC$,service=?????] 00000: FF 53 4D 42 73 00 00 00 00 18 03 C0 00 00 00 00 |?SMBs......?....| 00010: 00 00 00 00 00 00 00 00 00 00 12 2F 00 00 02 00 |.........../....| 00020: 0D 75 00 B0 00 04 41 0A 00 01 00 00 00 00 00 18 |.u.?..A.........| 00030: 00 18 00 00 00 00 00 54 00 00 00 73 00 DB AB 4C |.......T...s.??L| 00040: DA F3 DF 81 C3 B4 8C 7D BA 7A 5E 0B 57 B0 87 40 |???.??.}?z^.W?.@| 00050: F9 7E 2D 66 A5 78 FC 28 06 72 A8 D3 EE 99 86 87 |?~-f?x?(.r???...| 00060: A7 70 C1 DA 1C 2B FD AD 8E 40 50 44 1B 00 61 00 |?p??.+??.@PD..a.| 00070: 64 00 6D 00 69 00 6E 00 69 00 73 00 74 00 72 00 |d.m.i.n.i.s.t.r.| 00080: 61 00 74 00 6F 00 72 00 00 00 3F 00 00 00 57 00 |a.t.o.r...?...W.| 00090: 69 00 6E 00 64 00 6F 00 77 00 73 00 20 00 58 00 |i.n.d.o.w.s. .X.| 000A0: 50 00 00 00 6A 00 43 00 49 00 46 00 53 00 00 00 |P...j.C.I.F.S...| 000B0: 04 FF 00 00 00 00 00 01 00 31 00 00 5C 00 5C 00 |.?.......1..\.\.| 000C0: 31 00 39 00 32 00 2E 00 31 00 36 00 38 00 2E 00 |1.9.2...1.6.8...| 000D0: 30 00 2E 00 32 00 30 00 30 00 5C 00 49 00 50 00 |0...2.0.0.\.I.P.| 000E0: 43 00 24 00 00 00 3F 3F 3F 3F 3F 00 |C.$...?????. | New data read: Transport1[0.0.0.0<00>/192.168.0.200:445] 00000: FF 53 4D 42 73 00 00 00 00 88 01 C0 00 00 00 00 |?SMBs......?....| 00010: 00 00 00 00 00 00 00 00 01 00 12 2F 64 00 02 00 |.........../d...| NetShareEnum[command=SMB_COM_TRANSACTION,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=1,pid=12050,uid=100,mid=3,wordCount=14,byteCount=46,totalParameterCount=19,totalDataCount=0,maxParameterCount=8,maxDataCount=65023,maxSetupCount=0,flags=0x00,timeout=5000,parameterCount=19,parameterOffset=90,parameterDisplacement=0,dataCount=0,dataOffset=110,dataDisplacement=0,setupCount=0,pad=0,pad1=1] profiles/ 00000: FF 53 4D 42 25 00 00 00 00 18 03 C0 00 00 00 00 |?SMB%......?....| 00010: 00 00 00 00 00 00 00 00 01 00 12 2F 64 00 03 00 |.........../d...| 00020: 0E 13 00 00 00 08 00 FF FD 00 00 00 00 88 13 00 |.......??.......| 00030: 00 00 00 13 00 5A 00 00 00 00 00 00 00 2E 00 00 |.....Z..........| 00040: 5C 00 50 00 49 00 50 00 45 00 5C 00 4C 00 41 00 |\.P.I.P.E.\.L.A.| 00050: 4E 00 4D 00 41 00 4E 00 00 00 00 00 57 72 4C 65 |N.M.A.N.....WrLe| 00060: 68 00 42 31 33 42 57 7A 00 01 00 FF FD |h.B13BWz...?? | New data read: Transport1[0.0.0.0<00>/192.168.0.200:445] 00000: FF 53 4D 42 25 00 00 00 00 88 01 C0 00 00 00 00 |?SMB%......?....| 00010: 00 00 00 00 00 00 00 00 01 00 12 2F 64 00 03 00 |.........../d...| ShareInfo1[netName=profiles,type=0x0000,remark=Network Profiles Service] ShareInfo1[netName=users,type=0x0000,remark=All users] ShareInfo1[netName=test???,type=0x0000,remark=All users] ShareInfo1[netName=012345678912,type=0x0000,remark=All users] ShareInfo1[netName=groups,type=0x0000,remark=All groups] users/ test???/ 012345678912/ groups/ IPC$/ ADMIN$/ result should be test??? 7 files in 7060ms ShareInfo1[netName=IPC$,type=0x0003,remark=IPC Service (Samba 3.0.12-5-SUSE)] ShareInfo1[netName=ADMIN$,type=0x0003,remark=IPC Service (Samba 3.0.12-5-SUSE)] I also tried: System.setProperty( "jcifs.encoding", "Cp1252" ); // gives test??? System.setProperty( "jcifs.encoding", "ISO8859_1" ); // gives test??? System.setProperty( "jcifs.encoding", "UTF8" ); // gives test??? System.setProperty( "jcifs.encoding", "ASCII" ); // gives test??? Maybe you can help ? Thanks, thomas Michael B Allen wrote: > On Thu, 29 Dec 2005 03:30:05 +0000 (UTC) > Alvin Anwar wrote: > > >> Hi all, >> >> Currently I noticed there's an inconsistency error in getting the >> files' names for different level of shared directory. Let me elaborate >> first. *Please correct me if I'm wrong somewhere, it might be my mistake >> after all* >> >> In JCIFS SmbFile getType() function, the shared directory is >> specified as >> \\ TYPE_SERVER \ TYPE_SHARE \ TYPE_FILESYSTEM \ TYPE_FILESYSTEM ... >> >> Currently I'm working on using JCIFS on file servers running Windows XP >> SP 2 Chinese version. The unstability was found when I tries to list >> the files using listFiles() from SmbFile class at server level >> (TYPE_SERVER). >> >> When I retrieve the name and display it in a webpage (using IntergraTUM >> WebDisk), some of the shared directory with Chinese characters are >> retrieved wrongly (which makes everything a broken link). On the other >> > > To retrieve server and share lists jCIFS uses an older "RAP" protocol > that does not support Unicode. MSRPC is necessary to properly enumerate > servers and shares that contain Unicode characters. We have implemented > MSRPC via a project called Jarapac and there are example programs that > can properly emumerate shares. But that work was never integrated before > people moved on to other things. Currently jCIFS is in maintainence mode. > > But it is strange that the servers and shares are listed at all. Try the > examples/ListFiles.java example in the JCIFS packae. One possability is > that the server you are communicating with isn't negotiating Unicode but > is using the OEM codeset instead. If this is the case the RAP functions > might actually work if you change the jcifs.encoding property (see the > Overview page of the API documentation). > > Mike > > > From mba2000 at ioplex.com Sat Dec 31 07:19:13 2005 From: mba2000 at ioplex.com (Michael B Allen) Date: Sat Dec 31 07:24:31 2005 Subject: [jcifs] File naming problem In-Reply-To: <43B60C13.9020805@simple-groupware.de> References: <20051229124019.3631d20a.mba2000@ioplex.com> <43B60C13.9020805@simple-groupware.de> Message-ID: <20051231021913.6db9e696.mba2000@ioplex.com> On Sat, 31 Dec 2005 05:41:55 +0100 Thomas Bley wrote: > I also tried: > System.setProperty( "jcifs.encoding", "Cp1252" ); // gives test______? > System.setProperty( "jcifs.encoding", "ISO8859_1" ); // gives test??? > System.setProperty( "jcifs.encoding", "UTF8" ); // gives test??? > System.setProperty( "jcifs.encoding", "ASCII" ); // gives test??? Try: System.setProperty( "jcifs.encoding", "Cp850" ); Running $ testparm -v | grep dos shows that Samba's default OEM encoding is Cp850 which is MS-DOS Latin1 which is not the same as ISO-8859-1. I think perhaps we should change the default OEM_ENCODING from the file.encoding property to Cp850. Mike