Cyrus SASL with NTLM and SMB Signing
Hi, I know that this problem is not strictly SVN specific, but maybe one of the users here has experience with this and knows a solution: I'm currently trying to set up an SVN server on linux which authenticates against an Windows domain using NTLM - we want a single sign-on solution. The version of SASL is the debian libsasl2-2 package in version 2.1.25.dfsg1-6+deb7u1 (debian wheezy on amd64) running with SVN 1.6.17 (but upgrading to SVN 1.7 or 1.8 is an option.) The configuration on the server side seems to be correct, but the authentication fails with the following message: NTLM: error in NEGPROT response parameters As far as I could google it[1], there seems to be a workaround (disabling SBM signing via group policy), but said workaround is not acceptable for our network administrators. The SMB Signing seems to be a security feature which is enabled by default on windows servers since 2003. Is there any other solution or workaround for this problem? Best regards Markus Schaber [1] http://comments.gmane.org/gmane.comp.security.cyrus.sasl/7065 https://kc.mcafee.com/corporate/index?page=content&id=KB63137&cat=CORP_SENTIAN_BESS&actp=LIST Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
AW: Cyrus SASL with NTLM and SMB Signing
Hi, Von: Markus Schaber [mailto:m.scha...@codesys.com] > I know that this problem is not strictly SVN specific, but maybe one of the > users here has experience with this and knows a solution: > > I'm currently trying to set up an SVN server on linux which authenticates > against an Windows domain using NTLM - we want a single sign-on solution. > > The version of SASL is the debian libsasl2-2 package in version 2.1.25.dfsg1- > 6+deb7u1 (debian wheezy on amd64) running with SVN 1.6.17 (but upgrading to > SVN 1.7 or 1.8 is an option.) > > The configuration on the server side seems to be correct, but the > authentication fails with the following message: > NTLM: error in NEGPROT response parameters > > As far as I could google it[1], there seems to be a workaround (disabling SBM > signing via group policy), but said workaround is not acceptable for our > network administrators. The SMB Signing seems to be a security feature which > is enabled by default on windows servers since 2003. > > Is there any other solution or workaround for this problem? Just as a little clarification: Our intention is to have a single sign on solution working with (most) windows clients, but the SVN server needs to run under (Debian) Linux. It is not a must that we use NTLM, any other mechanism (like Kerberos) is also okay. Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Cyrus SASL with NTLM and SMB Signing
You're still vulnerable to the "Linux clients store passwords in clear-text in $HOME/.svn/ by default" security issue, and if you have your Subversion password authentication tied to your AD accounts, it enhances the risk. It only takes one internal environment with poor home directory security, or NFSv3 home directories and internal IT people who say "if someone has network access, we have much bigger problems" to leave people's home AD accounts wide open. The Windows clients are generally much better about this, although the CygWin subversion client still has the issue. The "kwallet" and gnome-keyring utilities for storing passwords more securely, locally, can help. What I'd give a *lot* to see is a Kerberos based authentication, tied to svn+ssh or tied to svnserve, that would correctly allow Kerberos based tickets (such as those uesed for genuine SSO solutions, like AD and NTLM), and correctly record Subversion commits tied to the identity of the relevant Kerberos ticket. Has anyone pursued, or gotten further, with a purely Kerberos baed authentication approach for HTTPS or svn+ssh? I'd consider that much cleaner and much less complex than the full-blown NTLM toolkit. And since Subversion has its own internal access management protocols, I've found those to provide much finer grained and trackable access than passing that task off to AD based group management. Also, Markus? If you want to pursue a full Linux system, my backports of Samba 4 full-blown AD replacements for RHEL or CentOS or Scientific Linux 6 was just updated to the new Samba 4.1.4 release, at: https://github.com/nkadel/samba4repo On Mon, Jan 13, 2014 at 4:02 AM, Markus Schaber wrote: > Hi, > > Von: Markus Schaber [mailto:m.scha...@codesys.com] >> I know that this problem is not strictly SVN specific, but maybe one of the >> users here has experience with this and knows a solution: >> >> I'm currently trying to set up an SVN server on linux which authenticates >> against an Windows domain using NTLM - we want a single sign-on solution. >> >> The version of SASL is the debian libsasl2-2 package in version 2.1.25.dfsg1- >> 6+deb7u1 (debian wheezy on amd64) running with SVN 1.6.17 (but upgrading to >> SVN 1.7 or 1.8 is an option.) >> >> The configuration on the server side seems to be correct, but the >> authentication fails with the following message: >> NTLM: error in NEGPROT response parameters >> >> As far as I could google it[1], there seems to be a workaround (disabling SBM >> signing via group policy), but said workaround is not acceptable for our >> network administrators. The SMB Signing seems to be a security feature which >> is enabled by default on windows servers since 2003. >> >> Is there any other solution or workaround for this problem? > > Just as a little clarification: > Our intention is to have a single sign on solution working with (most) > windows clients, but the SVN server needs to run under (Debian) Linux. > > It is not a must that we use NTLM, any other mechanism (like Kerberos) is > also okay. > > Best regards > > Markus Schaber > > CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH > > Inspiring Automation Solutions > > 3S-Smart Software Solutions GmbH > Dipl.-Inf. Markus Schaber | Product Development Core Technology > Memminger Str. 151 | 87439 Kempten | Germany > Tel. +49-831-54031-979 | Fax +49-831-54031-50 > > E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: > http://store.codesys.com > CODESYS forum: http://forum.codesys.com > > Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade > register: Kempten HRB 6186 | Tax ID No.: DE 167014915 >
AW: Cyrus SASL with NTLM and SMB Signing
Hi, Nico, Von: Nico Kadel-Garcia [mailto:nka...@gmail.com] > > You're still vulnerable to the "Linux clients store passwords in clear-text > in $HOME/.svn/ by default" security issue, and if you have your Subversion > password authentication tied to your AD accounts, it enhances the risk. It > only takes one internal environment with poor home directory security, or > NFSv3 home directories and internal IT people who say "if someone has network > access, we have much bigger problems" to leave people's home AD accounts wide > open. The Windows clients are generally much better about this, although the > CygWin subversion client still has the issue. This is why we want single sign on in the style of NTLM. There, the current windows session of the client (which is part of the windows domain) is used to authenticate on the server against the domain. No password is involved at all in this stage, and no credentials are to be saved by svn, all is done by passing some bacons around between the domain controller, the client and the server, all the cryptography is already there and used by the windows domain. For the few non-windows clients in our setup, we want an alternative username and password authentication which is not running against the active directory, but a file. We can either use an appropriate SASL configuration enabling both authentications in parallel, or a second svnserve running on a different port or ip. As only a single-digit number of clients is affected (and this won't change in the forseeable future), this is a manageable workaround. > The "kwallet" and gnome-keyring utilities for storing passwords more securely, > locally, can help. Our few non-windows clients are advised to use such storing mechanisms, and most (if not all) of them are already using full disk encryption. > What I'd give a *lot* to see is a Kerberos based > authentication, tied to svn+ssh or tied to svnserve, that would correctly > allow Kerberos based tickets (such as those uesed for genuine SSO solutions, > like AD and NTLM), and correctly record Subversion commits tied to the > identity of the relevant Kerberos ticket. > > Has anyone pursued, or gotten further, with a purely Kerberos baed > authentication approach for HTTPS or svn+ssh? I'd consider that much cleaner > and much less complex than the full-blown NTLM toolkit. And since Subversion > has its own internal access management protocols, I've found those to provide > much finer grained and trackable access than passing that task off to AD > based group management. We don't have any fine-grained access control - every developer should be allowed full access to the repository, and all other people should have no access at all. Our current fallback is a hand-maintained username/password database, but as most of our clients are windows PCs in the same domain, we wanted to simplify the setup and administration. > Also, Markus? If you want to pursue a full Linux system, my backports of > Samba 4 full-blown AD replacements for RHEL or CentOS or Scientific Linux 6 > was just updated to the new Samba 4.1.4 release, at: > > https://github.com/nkadel/samba4repo Most of our infrastructure is currently windows based, and we have appropriate active directory servers (Windows) already running. As we also run several windows based services (Outlook and other software), I can't see our admins switching to a Linux-based solution anywhere soon. > On Mon, Jan 13, 2014 at 4:02 AM, Markus Schaber wrote: > > Hi, > > > > Von: Markus Schaber [mailto:m.scha...@codesys.com] > >> I know that this problem is not strictly SVN specific, but maybe one > >> of the users here has experience with this and knows a solution: > >> > >> I'm currently trying to set up an SVN server on linux which > >> authenticates against an Windows domain using NTLM - we want a single > sign-on solution. > >> > >> The version of SASL is the debian libsasl2-2 package in version > >> 2.1.25.dfsg1- > >> 6+deb7u1 (debian wheezy on amd64) running with SVN 1.6.17 (but > >> 6+upgrading to > >> SVN 1.7 or 1.8 is an option.) > >> > >> The configuration on the server side seems to be correct, but the > >> authentication fails with the following message: > >> NTLM: error in NEGPROT response parameters > >> > >> As far as I could google it[1], there seems to be a workaround > >> (disabling SBM signing via group policy), but said workaround is not > >> acceptable for our network administrators. The SMB Signing seems to > >> be a security feature which is enabled by default on windows servers since > 2003. > >> > >> Is there any other solution or workaround for this problem? > > > > Just as a little clarification: > > Our intention is to have a single sign on solution working with (most) > windows clients, but the SVN server needs to run under (Debian) Linux. > > > > It is not a must that we use NTLM, any other mechanism (like Kerberos) is > also okay. Best regards Markus Schaber CODESYS(r) a t
RE: ignore property not ignoring...
> > From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com] > > > > So I have to just duplicate the svn:ignore and svn:global-ignores > > properties everywhere that anything needs to be ignored. > > Sorry, clarification: > > In tortoise, I check the properties of some directory, and it shows > "svn:ignore > bin obj" and some other stuff. But it's gray. So I assume it's inherited > from a > parent, and effective at this level, and then it turns out, not to be > effective. I > go to command prompt, and I see in fact, those properties are set on the > root directory, and *not* on the subdirectory. I don't know why it's > displaying grayed out, but if I explicitly set that property on that > directory, > then it works. > > So I guess this is mostly a usage issue. I could go talk to the tortoise > folks > about why it's showing gray, when it's not effective... And I could complain > that when you click on "add to ignores" the default is now to use global- > ignores rather than ignore... But it's not worth it. In 1.8 all properties are automatically inherited. Tortoise SVN shows those as gray so you know they were inherited. That said, the 1.8 client only acts on specific properties that were inherited. svn:global-ignores and svn:auto-props. I think there was some talk on the TSVN list to have a check box to "show inherited". But, not sure if that will happen. > > Thanks for your help. I think it's under control now. BOb
Can't move temporary on update.
Hi, we recently started getting this error when trying to update or check-out a repository. Weird thing is that the issue only occurs when we try to check-out/update the thing externally (meaning via VPN). Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? Regards, Stefan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. I traced the issue down to obvious problems with a certain directory in the repository. Ignoring/Skipping that directory and the check-out as well as the update operation work fine. Looking into the .svn/tmp-directory I do see a single existing file: trz2A87.tmp but obviously there's no trace of the mentioned svn-E78ED003 file. Regards, Stefan Hi, we recently started getting this error when trying to update or check-out a repository. Weird thing is that the issue only occurs when we try to check-out/update the thing externally (meaning via VPN). Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? Regards, Stefan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
On 1/13/14, 1:32 PM, Stefan wrote: > Sry, forgot the obvious most important info: > > Client is running 1.8.5 > Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up > to > use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. > I traced the issue down to obvious problems with a certain directory in the > repository. Ignoring/Skipping that directory and the check-out as well as the > update operation work fine. > > Looking into the .svn/tmp-directory I do see a single existing file: > trz2A87.tmp but obviously there's no trace of the mentioned svn-E78ED003 file. Can you possibly come up with a reproduction recipe that doesn't require access to your repo (unless of course your repo is publicly accessible)? The errors you're getting are coming from the run_file_install() step of the workqueue processor. It's rather hard to understand what's going just from the error messages. Based on what you're saying it seems like the temp file we're trying to move into place doesn't exist. Since looking at the code we try to install the file, and then trap a ENOENT error from the rename call. When the rename call fails with ENOENT we try to create the destination directory. Which fails and thus you see the errors. Right above the code generating the error it creates and writes the temp file. So I would expect to be seeing an error message from that if the file isn't being created. One question I do have is have you done anything unusual with how your file system is setup? The .svn/tmp directory needs to be on the same file system as the rest of the working copy since we're doing atomic renames to put files into place. >> we recently started getting this error when trying to update or check-out a >> repository. >> Weird thing is that the issue only occurs when we try to check-out/update the >> thing externally (meaning via VPN). So same machine, same working copy doesn't work over the VPN but does without a VPN? Is the working copy perhaps on a network filesystem? >> Error: >> svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to >> 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': >> The system cannot find the file specified. >> svn: E720183: Additional errors: >> svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': >> Cannot create a file when that file already exists. >> >> The issue is 100% reproducible on two completely different machines. >> >> Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http.
Re: Can't move temporary on update.
Hi, thanks for the hints. I obviously mixed-up the thing with serf/neon. Yes, the connection is via http. Actually ur hints let me thinking it might be an access issue on my machine and it turns out that when I disable my virus scanner, everything works just fine (using avast! here). The folder I tried to check-out contains an exe-file (print_options.exe) and that's the file the update/check-out junked on. For me the issue has been solved. I'm just wondering whether SVN couldn't actually either do something about that or whether at least the presented error-message could be a bit improved. Just from the error it was almost impossible to get the hint to a virus scanner issue. Regards, Stefan On 1/13/14, 1:32 PM, Stefan wrote: Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. I traced the issue down to obvious problems with a certain directory in the repository. Ignoring/Skipping that directory and the check-out as well as the update operation work fine. Looking into the .svn/tmp-directory I do see a single existing file: trz2A87.tmp but obviously there's no trace of the mentioned svn-E78ED003 file. Can you possibly come up with a reproduction recipe that doesn't require access to your repo (unless of course your repo is publicly accessible)? The errors you're getting are coming from the run_file_install() step of the workqueue processor. It's rather hard to understand what's going just from the error messages. Based on what you're saying it seems like the temp file we're trying to move into place doesn't exist. Since looking at the code we try to install the file, and then trap a ENOENT error from the rename call. When the rename call fails with ENOENT we try to create the destination directory. Which fails and thus you see the errors. Right above the code generating the error it creates and writes the temp file. So I would expect to be seeing an error message from that if the file isn't being created. One question I do have is have you done anything unusual with how your file system is setup? The .svn/tmp directory needs to be on the same file system as the rest of the working copy since we're doing atomic renames to put files into place. we recently started getting this error when trying to update or check-out a repository. Weird thing is that the issue only occurs when we try to check-out/update the thing externally (meaning via VPN). So same machine, same working copy doesn't work over the VPN but does without a VPN? Is the working copy perhaps on a network filesystem? Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Locking whole directories
I had a quick discussion on the IRC channel today about locking entire directories in my repository. [1] My company recently submitted version 4.0 of our application to Apple's App Store. That submission was created from a tag which was itself created from the 4.0 branch. While we're waiting for that to be approved, we are merging fixes from the trunk down to a newly-created 4.0.x branch, keeping the 4.0 branch around to accept any hotfixes Apple's review process demands. This two-branch setup lets us get a point release up and running as soon as possible after release without jeopardizing the review process of our 4.0 by unknowingly adding in more changes than Apple requests. This morning, one of our employees accidentally merged work to the 4.0 branch that should have been merged to the 4.0.x branch. Thankfully, the product manager caught it a few hours later. But to prevent this from happening again, I want to put an advisory lock on the 4.0 branch. Unfortunately, a failed `svn lock` and a little Googling revealed that Subversion does not natively support directory-based locks. The general recommendation is to configure path-based authorization, but that won't work for us for two reasons: - We use svn+ssh:// to connect to our server. - The lock needs to be breakable so that engineers can confirm they really do want to merge a hotfix down to the 4.0 branch. The only remaining alternative seems to be a repository hook that rejects checkins which touch descendants of the 4.0 branch. I can whip one of those together, but it's really unfortunate that such logic isn't built into Subversion in the first place. Being able to lock an entire directory also has a major benefit to OS X users by making it possible to treat document bundles as atomic units. For the unfamiliar, OS X treats certain types of directories as atomic documents. This lets application authors mmap the constituent files for increased performance. But since `svn lock` can't be applied to directories, such a compound document can be corrupted by adding unexpected files. I understand that implementing this would require all commits to search for lock properties on every ancestor of every changed file or directory. It essentially amounts to an extension of inheritable properties to the RA layer. Which would be pretty neat, IMO. :) Shall I file a feature request? --Kyle Sluder [1] http://colabti.org/irclogger/irclogger_log/svn?date=2014-01-13#l189
Re: Can't move temporary on update.
It would have also been quite useful to get the filename of that file that SVN tried to copy the temporary for. If it would have stated "print_options.exe", we could have run a bit of testing just with that one file to easier trace it down to an anti virus related problem (would have been quite obvious already just by the filename, since it's an exe-file). Regards, Stefan Hi, thanks for the hints. I obviously mixed-up the thing with serf/neon. Yes, the connection is via http. Actually ur hints let me thinking it might be an access issue on my machine and it turns out that when I disable my virus scanner, everything works just fine (using avast! here). The folder I tried to check-out contains an exe-file (print_options.exe) and that's the file the update/check-out junked on. For me the issue has been solved. I'm just wondering whether SVN couldn't actually either do something about that or whether at least the presented error-message could be a bit improved. Just from the error it was almost impossible to get the hint to a virus scanner issue. Regards, Stefan On 1/13/14, 1:32 PM, Stefan wrote: Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. I traced the issue down to obvious problems with a certain directory in the repository. Ignoring/Skipping that directory and the check-out as well as the update operation work fine. Looking into the .svn/tmp-directory I do see a single existing file: trz2A87.tmp but obviously there's no trace of the mentioned svn-E78ED003 file. Can you possibly come up with a reproduction recipe that doesn't require access to your repo (unless of course your repo is publicly accessible)? The errors you're getting are coming from the run_file_install() step of the workqueue processor. It's rather hard to understand what's going just from the error messages. Based on what you're saying it seems like the temp file we're trying to move into place doesn't exist. Since looking at the code we try to install the file, and then trap a ENOENT error from the rename call. When the rename call fails with ENOENT we try to create the destination directory. Which fails and thus you see the errors. Right above the code generating the error it creates and writes the temp file. So I would expect to be seeing an error message from that if the file isn't being created. One question I do have is have you done anything unusual with how your file system is setup? The .svn/tmp directory needs to be on the same file system as the rest of the working copy since we're doing atomic renames to put files into place. we recently started getting this error when trying to update or check-out a repository. Weird thing is that the issue only occurs when we try to check-out/update the thing externally (meaning via VPN). So same machine, same working copy doesn't work over the VPN but does without a VPN? Is the working copy perhaps on a network filesystem? Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
