You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2006/10/09 17:37:07 UTC
On backporting r21531 to 1.4.x.
Sitting in 1.4.x/STATUS at the moment is:
* r21531
Allow HTTP auth protocols to be configurable by way of a
"http-auth-types" parameter.
Justification:
Allow use of GSSAPI/SSPI auth on Windows with Neon 0.26.1+.
Votes:
+1: dlr, djh
-1: cmpilato
Why the -1 from cmpilato? Because r21531 adds a new runtime
configuration option, and I feel icky gross about adding a runtime
configuration option in a patch release. As written, the STATUS item
reads like a new feature addition, which further strikes me as not a
suitable candidate for patch release backport.
But in IRC a few minutes, some more of the details of r21531 started to
spill out, and the issue is more complicated that it would seem at first
glance. (Complicated enough that I'll probably botch this summarization
attempt.)
Prior to the change made in r21531, Windows users with Subversion's
compiled against Neon 0.25.x suffered from the following problems:
* GSSAPI/SSPI support didn't worked over SSL.
* Your Windows credentials were passed over the wire without
you having authorized such a thing in an automated attempt to
authenticate. (At this point, if not earlier, my knowledge gets
shaky, and I have to presume that if those creds failed against
the server, some graceful fallback to Basic or Digest auth worked
just fine -- but I dunno.)
Neon 0.26.x had the same issues, save that a new API was added which
allowed programs to specify which of the authentication methods Neon was
to attempt (a bitmask of sorts). This allowed folks who weren't using
Neon in GSSAPI/SSPI-authenticated manner to not transmit their Windows
creds over the wire.
Here's where Subversion comes in.
r21531 detects Neon 0.26.x, and, if present, allows you to use a new
runtime configuration option which maps to that Neon bitmask
choose-your-authn-methods interface. This permits users to indicate (on
a per-server basis) which authn methods they want to use, which
ultimately affords them protection against transmitting GSSAPI/SSPI auth
creds to servers that can't use them. It also turns on
SSAPI/SSPI-over-SSL, but, of course, only in accordance with the runtime
option.
Now, I fully appreciate the problems that the Windows users are facing,
but my default stance on how I view patch releases causes me to pause
when someone mentions new APIs, new command-line parameters, new runtime
configuration options, etc. However, it does seem rather crazy to make
Windows users wait until 1.5.0 for this (crazier still to rush 1.5.0
*because* of this). I asked on IRC if there was some way for Subversion
to programmatically choose a sane default behavior in the 1.4.x line,
but it doesn't appear that that's really on the table so long as not
auto-transmitting Windows auth creds is one of the primary goals.
What do others think of this situation?
(You might want to hold off on responding until someone corrects all the
technical details I surely failed to accurately relay in this mail.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: On backporting r21531 to 1.4.x.
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Stefan Küng <to...@gmail.com>:
> If I may add my comments here too:
> this is a really big issue for TSVN. Many users are complaining that
> they can not connect to their repositories anymore because of the
> always enabled SSPI authentication.
My experience from implementing HTTP Negotiate authentication support,
using SSPI, was that:
1. it's _neccessary_ to have an option to disable Negotiate
2. it's _very_ useful to be able to override SSPI's picked
authentication mechanism (in practice, to choose between NTLM and
Kerb)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
Daniel Rall wrote:
> Stefan, thank you for the *excellent*, detailed explanation of all the
> various behaviors. :-)
>
> On Mon, 09 Oct 2006, Stefan Küng wrote:
> ...
>> So my suggestion would be:
>> * Subversion tells neon to authenticate with SSPI
>> * SSPI authentication succeeds
>> * Subversion tries to access the repository, but gets an authorization
>> failure
>> * Subversion retries the authentication, but this time tells neon to not
>> use SSPI
>> * neon uses basic authentication, which makes it ask Subversion for
>> username/password
>
> With this strategy, GSSAPI/SSPI authentication could successfully
> authenticate you as the *wrong user* (since you're not explicitly
> providing it with credentials).
>
> If authorization doesn't fail, you could end up making commits under
> an inappropriate user ID.
That's what happens now too: SSPI is enabled all the time. Whatever user
SSPI authenticates with will be used to access the repository. That's
why we have the problems in the first place: users complain that the
authorization fails, without them being asked for username/password.
>> With my suggestion, the config option in the servers file would be
>> obsolete because Subversion would automatically retry without SSPI.
>> But of course, this only works with neon 0.26.x and not with neon 0.25.
>> And it requires using the new API of neon.
>
> Will specifying --username/--password on the command-line (or
> equivalent via the APIs) be enough to override the credentials
> inferred by GSSAPI/SSPI auth? I'm not certain that it is...
No, at least not with neon 0.25.x. It always uses SSPI first. Only if
SSPI authentication fails, it will fall back to basic authentication
where then Subversion can provide username/password.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Daniel Rall <dl...@collab.net>.
Stefan, thank you for the *excellent*, detailed explanation of all the
various behaviors. :-)
On Mon, 09 Oct 2006, Stefan Küng wrote:
...
> So my suggestion would be:
> * Subversion tells neon to authenticate with SSPI
> * SSPI authentication succeeds
> * Subversion tries to access the repository, but gets an authorization
> failure
> * Subversion retries the authentication, but this time tells neon to not
> use SSPI
> * neon uses basic authentication, which makes it ask Subversion for
> username/password
With this strategy, GSSAPI/SSPI authentication could successfully
authenticate you as the *wrong user* (since you're not explicitly
providing it with credentials).
If authorization doesn't fail, you could end up making commits under
an inappropriate user ID.
> With my suggestion, the config option in the servers file would be
> obsolete because Subversion would automatically retry without SSPI.
> But of course, this only works with neon 0.26.x and not with neon 0.25.
> And it requires using the new API of neon.
Will specifying --username/--password on the command-line (or
equivalent via the APIs) be enough to override the credentials
inferred by GSSAPI/SSPI auth? I'm not certain that it is...
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
> Stefan Küng wrote:
>> C. Michael Pilato wrote:
>>> Stefan Küng wrote:
>>>> If the reauthentication would be done completely by Subversion, then it
>>>> might work. But as far as I understand, with SSPI enabled in neon it
>>>> will always try first authenticating with that and never even ask
>>>> Subversion for authentication data (username/password). Of course that
>>>> happens only if the authentication succeeds with SSPI.
>>>> That's one of the reasons neon 0.26.x has now the option to disable SSPI
>>>> during runtime, so that clients can first try with SSPI, then try
>>>> authenticating without it.
>>>> (that's also why I think the current (trunk) behavior of Subversion
>>>> should be improved: avoid the option in the configuration file but after
>>>> the first authorization failure and reauthenticate again but this time
>>>> with SSPI disabled).
>>> I had a bit of trouble parsing that last bit. Are you suggesting that
>>> we could get by in 1.4.x by simply hard-coding a first attempt with SSPI
>>> followed by a fallback attempt without?
>>>
>>> See, if we can avoid adding this runtime configuration option, my
>>> concerns (at least about that matter) will vanish.
>> No. Either you compile SSPI auth into neon, then it will always use this
>> first. It will only fall back to basic auth if SSPI authentication
>> fails. But the problems we have here are not failed SSPI authentications
>> but a failed authorization due to SSPI authenticating as the 'wrong' user.
>> If you don't compile SSPI in to neon, then you will always get the basic
>> authentication - you can't authenticate with SSPI at all.
>>
>> That's why the runtime option in neon 0.26 is required to fix this
>> issue. Because just not compile SSPI into neon won't solve the issues
>> where users need SSPI to authenticate.
>>
>> Stefan
>>
>
> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
> it the first time around.
>
> (that's also why I think the current (trunk) behavior of Subversion
> should be improved: avoid the option in the configuration file but
> after the first authorization failure and reauthenticate again but
> this time with SSPI disabled).
with SSPI compiled into neon < 0.26:
neon authenticates with SSPI
if (authentication successful)
tell client auth successful
else
try other auth methods (e.g. basic auth)
there's no way to reauthenticate with basic auth, because neon will
always use SSPI first and always succeed (for the setups which have
problems now, those where the *authorization* fails). That's why I asked
Joe Orton for the new API, and that's why he added it in neon 0.26.x.
The only way I could avoid these problems in TSVN 1.3.x was by not
compiling SSPI into neon at all.
without SSPI compiled into neon:
neon authenticates properly because it uses basic authentication. But
since it doesn't use SSPI, people who need SSPI can't connect to the
repository.
with SSPI compiled into neon 0.26.x:
the client can tell neon whether to authenticate with SSPI or not. The
current implementation in Subversion trunk is to configure the use of
SSPI in the servers config file. That means for a certain server, it
either always or never uses SSPI. And users need to do the configuration
themselves, which will automatically lead to a lot of mails reporting
that they can't connect to their repositories (users don't read manuals).
So my suggestion would be:
* Subversion tells neon to authenticate with SSPI
* SSPI authentication succeeds
* Subversion tries to access the repository, but gets an authorization
failure
* Subversion retries the authentication, but this time tells neon to not
use SSPI
* neon uses basic authentication, which makes it ask Subversion for
username/password
With my suggestion, the config option in the servers file would be
obsolete because Subversion would automatically retry without SSPI.
But of course, this only works with neon 0.26.x and not with neon 0.25.
And it requires using the new API of neon.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> (that's also why I think the current (trunk) behavior of Subversion
> should be improved: avoid the option in the configuration file but
> after the first authorization failure and reauthenticate again but
> this time with SSPI disabled).
Can I play along? ;-)
I think what Stefan is suggesting is that
A) Neon 0.26 be configured to enable SSPI as a runtime option,
and then
B) Subversion would always attempt the authentication twice:
1) with SSPI *en*abled
2) with SSPI *dis*abled
without any Subversion configuration option. This would not be considered a new
feature but rather a bugfix to support a somewhat badly designed authentication
framework (SSPI).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/10/06, Branko Čibej <br...@xbc.nu> wrote:
> Stefan Küng wrote:
> > default is SSPI disabled:
> > * users can't connect to their repositories, because they have a proxy
> > in between which requires SSPI authentication.
>
> So what happens in the following case:
>
> * there's a proxy between the user and the repo that requires SSPI auth
> * using SSPI with the repo server results in the wrong user ID being
> used
>
> now if we disable SSPI in the second attempt ... won't the proxy
> authentication fail then?
>
> -- Brane
>
Neon 0.26.1 also allows the same new auth API's for proxies, so we
should probably add config options for http_proxy_auth, and maybe we
could do something here as well. But I'm not sure trying to handle
these 'authn works, authz fails' situations dynamically is going to be
practical. Does anyone know of some other app (browser or something)
that handles these kinds of problems well?
It seems to me that if you are using automatic-authn methods and want
to use a different user, then you need to use RunAs or 'su' or
whatever to temporarily tell the OS to switch your user credentials,
don't you? Isn't that the normal way to deal with different users in
automatic-authn environments?
DJ
Re: On backporting r21531 to 1.4.x.
Posted by Branko Čibej <br...@xbc.nu>.
Stefan Küng wrote:
> default is SSPI disabled:
> * users can't connect to their repositories, because they have a proxy
> in between which requires SSPI authentication.
So what happens in the following case:
* there's a proxy between the user and the repo that requires SSPI auth
* using SSPI with the repo server results in the wrong user ID being
used
now if we disable SSPI in the second attempt ... won't the proxy
authentication fail then?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
Mark Phippard wrote:
> Stefan Küng <to...@gmail.com> wrote on 10/09/2006 04:25:08 PM:
>
>> The best way to deal with this would be:
>>
>> * option in the servers config file
>> * if SSPI is disabled in the config file, never use it
>> * if the option is not set, first try with SSPI, then try without SSPI.
>
> In general I think I agree with you -- based on your previous messages.
>
> That being said, suppose SSPI is enabled and I am using it. I connect to
> a repository, it correctly authenticates me as my ID via SSPI. I try to
> access something I am not authorized to. Won't I now get prompted for
> username and password? Is that really the behavior we want?
I think yes. From what I learned on the TSVN mailing list, a lot of
people have set up repositories where they have restricted access to
folders. But they sometimes still need access to those. In that case,
they then like to be asked for username/password so they can provide a
different auth data.
Something like the 'su' command. In desktop linux environments, you get
asked for the root password as soon as you start an application which
needs those. That doesn't mean you want to log in as root, but only get
asked for that auth data if needed.
The same would happen with Subversion in your example: most of the time,
SSPI authentication would succeed without problems, and you can access
the files you need. Once you want to access 'restricted' files, you get
asked for username/password.
> What would happen in authz scenarios where you are not authorized to a
> subset of files, such as on a checkout or log? Presumably in these
> scenarios it would just work like it does today and silently not include
> those files.
Worst case:
SSPI succeeds, authorization later fails
Subversion reauthenticates without SSPI, authorization fails again
Subversion behaves like it does now when authorization fails.
Which means: two authentication attempts, but which the user won't
really notice (the user will only notice one).
> Perhaps SSPI should be treated somewhat like SSL client certs or proxies?
> Off by default, turn it on if you need it as it is an "advanced"
> authentication method.
That's how it is implemented now on trunk (I don't know if SSPI is
enabled by default or not, but the config option is what you suggested).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Mark Phippard <ma...@softlanding.com>.
Stefan Küng <to...@gmail.com> wrote on 10/09/2006 04:25:08 PM:
> The best way to deal with this would be:
>
> * option in the servers config file
> * if SSPI is disabled in the config file, never use it
> * if the option is not set, first try with SSPI, then try without SSPI.
In general I think I agree with you -- based on your previous messages.
That being said, suppose SSPI is enabled and I am using it. I connect to
a repository, it correctly authenticates me as my ID via SSPI. I try to
access something I am not authorized to. Won't I now get prompted for
username and password? Is that really the behavior we want?
What would happen in authz scenarios where you are not authorized to a
subset of files, such as on a checkout or log? Presumably in these
scenarios it would just work like it does today and silently not include
those files.
Perhaps SSPI should be treated somewhat like SSL client certs or proxies?
Off by default, turn it on if you need it as it is an "advanced"
authentication method.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
Mark Phippard wrote:
> "C. Michael Pilato" <cm...@collab.net> wrote on 10/09/2006 04:01:28 PM:
>
>> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
>> it the first time around.
>>
>> (that's also why I think the current (trunk) behavior of Subversion
>> should be improved: avoid the option in the configuration file but
>> after the first authorization failure and reauthenticate again but
>> this time with SSPI disabled).
>
> I think the only issue should be whether the current way this works is
> deemed a bug with a high enough severity to backport to an existing
> release. I happen to think it is.
>
> Once that is agreed to, then whatever the best solution is, regardless as
> to whether it involves adding a new config option, should be used. Having
> a client authenticate, fail authorization and then reauthenticate does not
> strike me as an ideal solution. Won't this happen over and over again?
> Having an option to just turn the feature off seems better to me and I do
> not see what negative impact this has on existing 1.4 users.
The config option definitely is not a bad idea. But in my experience,
people don't read manuals. Depending on the default option, this is
what's going to happen:
default is SSPI enabled:
* users can't connect to their repositories, because they always get an
"authorization failed" error. They first wonder why this happens, then
send a mail to the mailing lists with a big "BUG:" in the subject line.
* we tell them to disable SSPI in the config file for that server
default is SSPI disabled:
* users can't connect to their repositories, because they have a proxy
in between which requires SSPI authentication. They start wondering why
this suddenly doesn't work anymore, maybe revert back to a previous
version of the client and see that it works there. So they too write a
mail to the mailing list with a big "BUG:" in the subject line.
* we tell them to enable SSPI in the config file for that server
* they get angry because the default was changed and they were not told
(even if it was clearly stated in the release notes).
The best way to deal with this would be:
* option in the servers config file
* if SSPI is disabled in the config file, never use it
* if the option is not set, first try with SSPI, then try without SSPI.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
[snip]
> For those cases, you could provide the command line params
> --username myname --password mypassword
>
> If those are present, then Subversion must tell neon to not authenticate
> with SSPI in the first place but only use basic authentication.
>
Ok, I've lost track of all the possibilities here. Can someone
summarize or correct the following (ignoring whether or not they can
be backported to 1.4.x for now, since the current set of changes
doesn't appear to be enough anyway):
1. The new config option to control neon auth mechanisms is still
desired, correct?
2. If --username/password are present on the commandline, they should
override automatic auth (such as SSPI/GSSAPI) and force BASIC auth
with those creds?
3. If auth succeeds, but then later authz fails, should Subversion
re-prompt for creds? Out of curiosity, is this how browsers behave if
they have authenticated someone but then later hit a file/path where
they are denied access?
4. There is currently a bug in neon-0.26.x/Subversion 1.4 that causes
GSSAPI to fail or crash in some scenarios.
Anything else?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Samay <ge...@hotmail.com>.
On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
[snip]
> > If you have the username and password it is pretty easy (in Windows,
> > anyway) to temporarily impersonate a user for SSPI auth.
>
> But then it's not SSPI authentication but basic authentication, isn't it?
>
No, if LogonUser/Impersonate worked then it would be as if you were
actually that user and should work with at least some SSPI scenarios.
I've done it before with NTLM/Domain auth and it works fine, but Samay
says it doesn't work in stricter Negotiate/Kerberos environments. I
don't really know much about those setups.
DJ
---------------------------------------------------------------------
AFAIK, thats correct. e.g. if mod_auth_kerb is setup with "KrbMethodK5Passwd
off and KrbMethodNegotiate on", and no impersonation is provided for unless
Neon is extended to include its own Kerberos (kinit etc) functions to fetch
KRB5 tkts for the UPN as provided in --username field and given password.
If browse it with Firefox (with negotiate authentication disabled), user
shall be greeted with "401: Authorization Required" page not a userID &
password popup.
regards
Samay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
[snip]
> > If you have the username and password it is pretty easy (in Windows,
> > anyway) to temporarily impersonate a user for SSPI auth.
>
> But then it's not SSPI authentication but basic authentication, isn't it?
>
No, if LogonUser/Impersonate worked then it would be as if you were
actually that user and should work with at least some SSPI scenarios.
I've done it before with NTLM/Domain auth and it works fine, but Samay
says it doesn't work in stricter Negotiate/Kerberos environments. I
don't really know much about those setups.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
On 10/9/06, D.J. Heap <dj...@gmail.com> wrote:
> On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
> >
> > > I'm 90% certain SSPI gives this level of control... of
> > > course, if I had to guess, I'd guess neon doesn't give
> > > this level of control :-(
> >
> > I'm 90% certain that SSPI can't give that level of control :)
>
>
> If you have the username and password it is pretty easy (in Windows,
> anyway) to temporarily impersonate a user for SSPI auth.
But then it's not SSPI authentication but basic authentication, isn't it?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Samay <ge...@hotmail.com>.
On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
>
> > I'm 90% certain SSPI gives this level of control... of
> > course, if I had to guess, I'd guess neon doesn't give
> > this level of control :-(
>
> I'm 90% certain that SSPI can't give that level of control :)
> If you have the username and password it is pretty easy (in Windows,
> anyway) to temporarily impersonate a user for SSPI auth.
>
> DJ
AFAIK, if server is running SPnego with Basic auth disabled, you "cannot"
impersonate another user on a windows client machine. SPNego means, no
password prompts, and worse case 401 Authorization errors. IIRC, its that
way by design. On linux one may impersonate the user by issuing "kinit
userid@REALM" to change their ID, however, may not be an option on a well
secure linux client.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/9/06, Stefan Küng <to...@gmail.com> wrote:
>
> > I'm 90% certain SSPI gives this level of control... of
> > course, if I had to guess, I'd guess neon doesn't give
> > this level of control :-(
>
> I'm 90% certain that SSPI can't give that level of control :)
If you have the username and password it is pretty easy (in Windows,
anyway) to temporarily impersonate a user for SSPI auth.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
Joseph Galbraith wrote:
> In my humble opinion, which counts for nothing, I think
> where we need to be eventually is having subversion
> tell SSPI what user it wants to authenticate as.
I don't think that's possible. SSPI uses the anonymous user (the GUEST
account) or the currently logged on windows user. If it's possible to
specify the user it authenticates with, where would it get the password
for it? It only can do that by using the already logged on user and the
password used to log the user on to the workstation.
> I'm 90% certain SSPI gives this level of control... of
> course, if I had to guess, I'd guess neon doesn't give
> this level of control :-(
I'm 90% certain that SSPI can't give that level of control :)
> Right now, the main issue we are running into is that
> SSPI succeeded with a user like GUEST, and we wish
> it hadn't.
>
> I suspect it is entirely possible that we will run into
> cases where SSPI succeeds with user x, but we wish it
> had succeeded with user y (I don't think it is common
> to have multiple user credentials available but I don't
> think it is impossible either.)
For those cases, you could provide the command line params
--username myname --password mypassword
If those are present, then Subversion must tell neon to not authenticate
with SSPI in the first place but only use basic authentication.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/9/06, Samay <ge...@hotmail.com> wrote:
[snip]
>
> It is incorrect to say SSPI works fine when the default method
> (kerberos/SPnego) doesnt work at all. You may see it working on environemnt
> as its probably falling back to NTLM etc. Again SSPI is windows abstraction
> API one of which is GSSAPI.
>
> > GSSAPI (related to SSPI but a different auth protocol?) seems to have
> > trouble (as in crashes) with 0.26.1 but no one can provide a server to
> > test against and setting up a GSSAPI server seems to be rather
> > involved.
>
> Best bet would be to setup a few VM environments.
>
Ok. In any case, this GSSAPI failure is just a bug somewhere in neon
or Subversion and should be fixed, regardless of how we want to handle
the auth options that are new in neon 0.26.x.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Samay <ge...@hotmail.com>.
>>
>> with svn 1.4.x neon0.26.x, it just doesnt work. please refer to thread
>> http://svn.haxx.se/users/archive-2006-09/0950.shtml for a legnthy
>> discussion
>> on how0.25.x Neon works but 0.26.1 doesnt. We resolved this issue by
>> using
>> 1.4.x compiled against 0.25.x of Neon (Thanks DJ Heap). Since TSVN 1.4.x
>> is
>> shipped with Neon 0.25.x it was ok.
>
>
> SSPI is working fine with neon 0.26.1 (dynamic options and desired
> auth behavior aside) based on the testing I did (admittedly not
> exhaustive, but quite a bit) and the feedback I've gotten. Isn't your
> problem specific to GSSAPI?
>
the problem we are seeing with 0.26.x is with server side requesting SPNego
method. SPnego is one of the five possible methods supported by SSPI by
windows on client/server side. For more accurate details please refer to
http://technet2.microsoft.com/WindowsServer/en/library/78cb5d3c-d0b2-4d20-a693-fa66bde1a63b1033.mspx?mfr=true
It is incorrect to say SSPI works fine when the default method
(kerberos/SPnego) doesnt work at all. You may see it working on environemnt
as its probably falling back to NTLM etc. Again SSPI is windows abstraction
API one of which is GSSAPI.
> GSSAPI (related to SSPI but a different auth protocol?) seems to have
> trouble (as in crashes) with 0.26.1 but no one can provide a server to
> test against and setting up a GSSAPI server seems to be rather
> involved.
Best bet would be to setup a few VM environments.
> I'm also fairly sure that the GSSAPI problem is not
> specific to Windows.
its same problem whether using windows or linux clients. On Linux i have
tested it to fail when using MIT-Krb5 1.4.x .. haven't had any resources to
test with Hemidal or MIT-Krb5 1.5.x. Again, problem disappears the moment we
switch to Neon 0.25.5 instead of 0.26.1 on client side :)
> And my understanding is that GSSAPI doesn't work
> at all in neon 0.25.5 -- it just always drops back to BASIC, but I
> haven't tested that myself.
I would say above is incorrect. GSSAPI works well (except for the problems
with larger repo) wih 0.25.5. Server side method is SPNego (mod_auth_kerb)
and K5Passwd set to off. None of our repositories support Basic
authentication ... thats the reason we got bitten by this problem on both
Windows & Linux. So no fall backs to Basic auth in our env.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "D.J. Heap" <dj...@gmail.com>.
On 10/9/06, Samay <ge...@hotmail.com> wrote:
[snip]
>
> with svn 1.4.x neon0.26.x, it just doesnt work. please refer to thread
> http://svn.haxx.se/users/archive-2006-09/0950.shtml for a legnthy discussion
> on how0.25.x Neon works but 0.26.1 doesnt. We resolved this issue by using
> 1.4.x compiled against 0.25.x of Neon (Thanks DJ Heap). Since TSVN 1.4.x is
> shipped with Neon 0.25.x it was ok.
SSPI is working fine with neon 0.26.1 (dynamic options and desired
auth behavior aside) based on the testing I did (admittedly not
exhaustive, but quite a bit) and the feedback I've gotten. Isn't your
problem specific to GSSAPI?
GSSAPI (related to SSPI but a different auth protocol?) seems to have
trouble (as in crashes) with 0.26.1 but no one can provide a server to
test against and setting up a GSSAPI server seems to be rather
involved. I'm also fairly sure that the GSSAPI problem is not
specific to Windows. And my understanding is that GSSAPI doesn't work
at all in neon 0.25.5 -- it just always drops back to BASIC, but I
haven't tested that myself.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Samay <ge...@hotmail.com>.
> Mark Phippard wrote:
>> "C. Michael Pilato" <cm...@collab.net> wrote on 10/09/2006 04:01:28
>> PM:
>>
>>> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
>>> it the first time around.
>>>
>>> (that's also why I think the current (trunk) behavior of Subversion
>>> should be improved: avoid the option in the configuration file but
>>> after the first authorization failure and reauthenticate again but
>>> this time with SSPI disabled).
>>
>> I think the only issue should be whether the current way this works is
>> deemed a bug with a high enough severity to backport to an existing
>> release. I happen to think it is.
>>
>> Once that is agreed to, then whatever the best solution is, regardless as
>> to whether it involves adding a new config option, should be used.
>> Having
>> a client authenticate, fail authorization and then reauthenticate does
>> not
>> strike me as an ideal solution. Won't this happen over and over again?
>> Having an option to just turn the feature off seems better to me and I do
>> not see what negative impact this has on existing 1.4 users.
>
> In my humble opinion, which counts for nothing, I think
> where we need to be eventually is having subversion
> tell SSPI what user it wants to authenticate as.
>
> I'm 90% certain SSPI gives this level of control... of
> course, if I had to guess, I'd guess neon doesn't give
> this level of control :-(
>
> Right now, the main issue we are running into is that
> SSPI succeeded with a user like GUEST, and we wish
> it hadn't.
>
> I suspect it is entirely possible that we will run into
> cases where SSPI succeeds with user x, but we wish it
> had succeeded with user y (I don't think it is common
> to have multiple user credentials available but I don't
> think it is impossible either.)
>
> It seems rather like a using a sledge-hammer to drive
> finish nails to disable the feature because we are
> picking the wrong user.
>
> Thanks,
>
> Joseph
>
with svn 1.4.x neon0.26.x, it just doesnt work. please refer to thread
http://svn.haxx.se/users/archive-2006-09/0950.shtml for a legnthy discussion
on how0.25.x Neon works but 0.26.1 doesnt. We resolved this issue by using
1.4.x compiled against 0.25.x of Neon (Thanks DJ Heap). Since TSVN 1.4.x is
shipped with Neon 0.25.x it was ok.
the current mention of Authentcaion retry in between a task is also a
current issue and very big one (although only surfaces when carrying out a
large repo activity). Also described here at
http://svn.haxx.se/users/archive-2006-09/1336.shtml.
is SSPI/GSSAPI important, yes, especially authenticating against multiple
domain (e.g. a win2k3 forest with more then 1 domains, its probably the only
available option!). It will be worthwhile to backport to 1.4.x if it helps
mitigate these issues.
regards
Samay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Branko Čibej <br...@xbc.nu>.
Joseph Galbraith wrote:
> In my humble opinion, which counts for nothing, I think
> where we need to be eventually is having subversion
> tell SSPI what user it wants to authenticate as.
>
> I'm 90% certain SSPI gives this level of control... of
> course, if I had to guess, I'd guess neon doesn't give
> this level of control :-(
>
Actually I believe this is only possible if your client process (or
thread) first impersonates the required user. You can't just tell it to
use a particular user/password, you have to get an authentication token
from the domain controller first.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Joseph Galbraith <ga...@vandyke.com>.
Mark Phippard wrote:
> "C. Michael Pilato" <cm...@collab.net> wrote on 10/09/2006 04:01:28 PM:
>
>> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
>> it the first time around.
>>
>> (that's also why I think the current (trunk) behavior of Subversion
>> should be improved: avoid the option in the configuration file but
>> after the first authorization failure and reauthenticate again but
>> this time with SSPI disabled).
>
> I think the only issue should be whether the current way this works is
> deemed a bug with a high enough severity to backport to an existing
> release. I happen to think it is.
>
> Once that is agreed to, then whatever the best solution is, regardless as
> to whether it involves adding a new config option, should be used. Having
> a client authenticate, fail authorization and then reauthenticate does not
> strike me as an ideal solution. Won't this happen over and over again?
> Having an option to just turn the feature off seems better to me and I do
> not see what negative impact this has on existing 1.4 users.
In my humble opinion, which counts for nothing, I think
where we need to be eventually is having subversion
tell SSPI what user it wants to authenticate as.
I'm 90% certain SSPI gives this level of control... of
course, if I had to guess, I'd guess neon doesn't give
this level of control :-(
Right now, the main issue we are running into is that
SSPI succeeded with a user like GUEST, and we wish
it hadn't.
I suspect it is entirely possible that we will run into
cases where SSPI succeeds with user x, but we wish it
had succeeded with user y (I don't think it is common
to have multiple user credentials available but I don't
think it is impossible either.)
It seems rather like a using a sledge-hammer to drive
finish nails to disable the feature because we are
picking the wrong user.
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by Mark Phippard <ma...@softlanding.com>.
"C. Michael Pilato" <cm...@collab.net> wrote on 10/09/2006 04:01:28 PM:
> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
> it the first time around.
>
> (that's also why I think the current (trunk) behavior of Subversion
> should be improved: avoid the option in the configuration file but
> after the first authorization failure and reauthenticate again but
> this time with SSPI disabled).
I think the only issue should be whether the current way this works is
deemed a bug with a high enough severity to backport to an existing
release. I happen to think it is.
Once that is agreed to, then whatever the best solution is, regardless as
to whether it involves adding a new config option, should be used. Having
a client authenticate, fail authorization and then reauthenticate does not
strike me as an ideal solution. Won't this happen over and over again?
Having an option to just turn the feature off seems better to me and I do
not see what negative impact this has on existing 1.4 users.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Küng wrote:
> C. Michael Pilato wrote:
>> Stefan Küng wrote:
>>> If the reauthentication would be done completely by Subversion, then it
>>> might work. But as far as I understand, with SSPI enabled in neon it
>>> will always try first authenticating with that and never even ask
>>> Subversion for authentication data (username/password). Of course that
>>> happens only if the authentication succeeds with SSPI.
>>> That's one of the reasons neon 0.26.x has now the option to disable SSPI
>>> during runtime, so that clients can first try with SSPI, then try
>>> authenticating without it.
>>> (that's also why I think the current (trunk) behavior of Subversion
>>> should be improved: avoid the option in the configuration file but after
>>> the first authorization failure and reauthenticate again but this time
>>> with SSPI disabled).
>>
>> I had a bit of trouble parsing that last bit. Are you suggesting that
>> we could get by in 1.4.x by simply hard-coding a first attempt with SSPI
>> followed by a fallback attempt without?
>>
>> See, if we can avoid adding this runtime configuration option, my
>> concerns (at least about that matter) will vanish.
>
> No. Either you compile SSPI auth into neon, then it will always use this
> first. It will only fall back to basic auth if SSPI authentication
> fails. But the problems we have here are not failed SSPI authentications
> but a failed authorization due to SSPI authenticating as the 'wrong' user.
> If you don't compile SSPI in to neon, then you will always get the basic
> authentication - you can't authenticate with SSPI at all.
>
> That's why the runtime option in neon 0.26 is required to fix this
> issue. Because just not compile SSPI into neon won't solve the issues
> where users need SSPI to authenticate.
>
> Stefan
>
Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
it the first time around.
(that's also why I think the current (trunk) behavior of Subversion
should be improved: avoid the option in the configuration file but
after the first authorization failure and reauthenticate again but
this time with SSPI disabled).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
> Stefan Küng wrote:
>> If the reauthentication would be done completely by Subversion, then it
>> might work. But as far as I understand, with SSPI enabled in neon it
>> will always try first authenticating with that and never even ask
>> Subversion for authentication data (username/password). Of course that
>> happens only if the authentication succeeds with SSPI.
>> That's one of the reasons neon 0.26.x has now the option to disable SSPI
>> during runtime, so that clients can first try with SSPI, then try
>> authenticating without it.
>> (that's also why I think the current (trunk) behavior of Subversion
>> should be improved: avoid the option in the configuration file but after
>> the first authorization failure and reauthenticate again but this time
>> with SSPI disabled).
>
> I had a bit of trouble parsing that last bit. Are you suggesting that
> we could get by in 1.4.x by simply hard-coding a first attempt with SSPI
> followed by a fallback attempt without?
>
> See, if we can avoid adding this runtime configuration option, my
> concerns (at least about that matter) will vanish.
No. Either you compile SSPI auth into neon, then it will always use this
first. It will only fall back to basic auth if SSPI authentication
fails. But the problems we have here are not failed SSPI authentications
but a failed authorization due to SSPI authenticating as the 'wrong' user.
If you don't compile SSPI in to neon, then you will always get the basic
authentication - you can't authenticate with SSPI at all.
That's why the runtime option in neon 0.26 is required to fix this
issue. Because just not compile SSPI into neon won't solve the issues
where users need SSPI to authenticate.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Küng wrote:
> If the reauthentication would be done completely by Subversion, then it
> might work. But as far as I understand, with SSPI enabled in neon it
> will always try first authenticating with that and never even ask
> Subversion for authentication data (username/password). Of course that
> happens only if the authentication succeeds with SSPI.
> That's one of the reasons neon 0.26.x has now the option to disable SSPI
> during runtime, so that clients can first try with SSPI, then try
> authenticating without it.
> (that's also why I think the current (trunk) behavior of Subversion
> should be improved: avoid the option in the configuration file but after
> the first authorization failure and reauthenticate again but this time
> with SSPI disabled).
I had a bit of trouble parsing that last bit. Are you suggesting that
we could get by in 1.4.x by simply hard-coding a first attempt with SSPI
followed by a fallback attempt without?
See, if we can avoid adding this runtime configuration option, my
concerns (at least about that matter) will vanish.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
>>> * Your Windows credentials were passed over the wire without
>>> you having authorized such a thing in an automated attempt to
>>> authenticate. (At this point, if not earlier, my knowledge gets
>>> shaky, and I have to presume that if those creds failed against
>>> the server, some graceful fallback to Basic or Digest auth worked
>>> just fine -- but I dunno.)
>> No, it wouldn't fall back to basic auth. At least not in all
>> circumstances. One problem for example is that the authentication can
>> succeed (if the user is part of a domain which the server hosting the
>> repository is part of too), but later the authorization fails. In that
>> case, Subversion simply gives up with an error and doesn't try to
>> reauthenticate (because the authentication was successful before).
>> This can happen if e.g. the GUEST account is enabled on the domain
>> controller (sometimes it has to be, due to other company apps requiring
>> that). Or if the admin has set up different user accounts for the
>> repository than the users use to log in to their workstations (happens a
>> *lot* from what I get on the mailing list).
>
> Ah! Well, that puts a whole new spin on things, then. Pretend this new
> Neon option never existed. If we fixed Subversion so that it would
> reauthenticate, where would that put us on the usability chart?
If the reauthentication would be done completely by Subversion, then it
might work. But as far as I understand, with SSPI enabled in neon it
will always try first authenticating with that and never even ask
Subversion for authentication data (username/password). Of course that
happens only if the authentication succeeds with SSPI.
That's one of the reasons neon 0.26.x has now the option to disable SSPI
during runtime, so that clients can first try with SSPI, then try
authenticating without it.
(that's also why I think the current (trunk) behavior of Subversion
should be improved: avoid the option in the configuration file but after
the first authorization failure and reauthenticate again but this time
with SSPI disabled).
If it would be possible to just reauthenticate, I would have tried
adding that feature to Subversion myself. I know a little bit the code
where that happens (I once added there my own auth provider to save the
auth data encrypted on Win2k and later - until Subversion did that too).
Of course, I could be wrong here, but the last time I tried that
wouldn't work.
>> The only way to disable the automatic authentication with SSPI is by
>> disabling it during compile time.
>
> You mean without the new Neon API, yes?
The compile time option is still present in neon 0.26.x. And with SSPI
not compiled into the library, there's no use for the new API anymore.
FYI: here's one of the threads I mentioned this before:
http://svn.haxx.se/dev/archive-2006-06/0205.shtml
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On backporting r21531 to 1.4.x.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Küng wrote:
> If it takes again almost a year until the next 'big' Subversion release
> I will have to buy a lot of Valium to survive all the complaints, or
> have users not update and still use an old version (which means I have
> to deal with bugs long fixed too).
Understandable. Again, I don't mean to diminish the negative effect of
not doing the right thing here. I merely want to ensure that the right
thing is being done by *all* parties.
>> * Your Windows credentials were passed over the wire without
>> you having authorized such a thing in an automated attempt to
>> authenticate. (At this point, if not earlier, my knowledge gets
>> shaky, and I have to presume that if those creds failed against
>> the server, some graceful fallback to Basic or Digest auth worked
>> just fine -- but I dunno.)
>
> No, it wouldn't fall back to basic auth. At least not in all
> circumstances. One problem for example is that the authentication can
> succeed (if the user is part of a domain which the server hosting the
> repository is part of too), but later the authorization fails. In that
> case, Subversion simply gives up with an error and doesn't try to
> reauthenticate (because the authentication was successful before).
> This can happen if e.g. the GUEST account is enabled on the domain
> controller (sometimes it has to be, due to other company apps requiring
> that). Or if the admin has set up different user accounts for the
> repository than the users use to log in to their workstations (happens a
> *lot* from what I get on the mailing list).
Ah! Well, that puts a whole new spin on things, then. Pretend this new
Neon option never existed. If we fixed Subversion so that it would
reauthenticate, where would that put us on the usability chart?
> The only way to disable the automatic authentication with SSPI is by
> disabling it during compile time.
You mean without the new Neon API, yes?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: On backporting r21531 to 1.4.x.
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
> Sitting in 1.4.x/STATUS at the moment is:
>
> * r21531
> Allow HTTP auth protocols to be configurable by way of a
> "http-auth-types" parameter.
> Justification:
> Allow use of GSSAPI/SSPI auth on Windows with Neon 0.26.1+.
> Votes:
> +1: dlr, djh
> -1: cmpilato
>
> Why the -1 from cmpilato? Because r21531 adds a new runtime
> configuration option, and I feel icky gross about adding a runtime
> configuration option in a patch release. As written, the STATUS item
> reads like a new feature addition, which further strikes me as not a
> suitable candidate for patch release backport.
If I may add my comments here too:
this is a really big issue for TSVN. Many users are complaining that
they can not connect to their repositories anymore because of the always
enabled SSPI authentication. I had a bad feeling when I activated it in
TSVN even though Subversion 1.3.x already had activated it. And now I
have to live with it - I guess there are just much more Windows users
only using TSVN and not the command line client. Otherwise you guys
would have to deal with those users too.
If it takes again almost a year until the next 'big' Subversion release
I will have to buy a lot of Valium to survive all the complaints, or
have users not update and still use an old version (which means I have
to deal with bugs long fixed too).
> But in IRC a few minutes, some more of the details of r21531 started to
> spill out, and the issue is more complicated that it would seem at first
> glance. (Complicated enough that I'll probably botch this summarization
> attempt.)
>
> Prior to the change made in r21531, Windows users with Subversion's
> compiled against Neon 0.25.x suffered from the following problems:
>
> * GSSAPI/SSPI support didn't worked over SSL.
>
> * Your Windows credentials were passed over the wire without
> you having authorized such a thing in an automated attempt to
> authenticate. (At this point, if not earlier, my knowledge gets
> shaky, and I have to presume that if those creds failed against
> the server, some graceful fallback to Basic or Digest auth worked
> just fine -- but I dunno.)
No, it wouldn't fall back to basic auth. At least not in all
circumstances. One problem for example is that the authentication can
succeed (if the user is part of a domain which the server hosting the
repository is part of too), but later the authorization fails. In that
case, Subversion simply gives up with an error and doesn't try to
reauthenticate (because the authentication was successful before).
This can happen if e.g. the GUEST account is enabled on the domain
controller (sometimes it has to be, due to other company apps requiring
that). Or if the admin has set up different user accounts for the
repository than the users use to log in to their workstations (happens a
*lot* from what I get on the mailing list).
> Neon 0.26.x had the same issues, save that a new API was added which
> allowed programs to specify which of the authentication methods Neon was
> to attempt (a bitmask of sorts). This allowed folks who weren't using
> Neon in GSSAPI/SSPI-authenticated manner to not transmit their Windows
> creds over the wire.
That was added due to my request on the neon mailing list. I also
reported the very same issue several times on this mailing list, way
before the 1.4.0 release. I also mentioned that I'm not familiar enough
with that part of the Subversion code to implement this myself and that
someone should please implement this before the release.
(if you feel that I'm getting a little annoyed with how people treat my
requests and concerns on this list, you're right - it happens way too
often that I could say "told you so".)
> Here's where Subversion comes in.
>
> r21531 detects Neon 0.26.x, and, if present, allows you to use a new
> runtime configuration option which maps to that Neon bitmask
> choose-your-authn-methods interface. This permits users to indicate (on
> a per-server basis) which authn methods they want to use, which
> ultimately affords them protection against transmitting GSSAPI/SSPI auth
> creds to servers that can't use them. It also turns on
> SSAPI/SSPI-over-SSL, but, of course, only in accordance with the runtime
> option.
>
> Now, I fully appreciate the problems that the Windows users are facing,
> but my default stance on how I view patch releases causes me to pause
> when someone mentions new APIs, new command-line parameters, new runtime
> configuration options, etc. However, it does seem rather crazy to make
> Windows users wait until 1.5.0 for this (crazier still to rush 1.5.0
> *because* of this). I asked on IRC if there was some way for Subversion
> to programmatically choose a sane default behavior in the 1.4.x line,
> but it doesn't appear that that's really on the table so long as not
> auto-transmitting Windows auth creds is one of the primary goals.
The only way to disable the automatic authentication with SSPI is by
disabling it during compile time. I did that for TSVN 1.3.x even though
the command line client had it activated for the 1.3.x versions. The
problem was/is that with SSPI disabled, people behind certain proxies
can't connect to their repositories because the proxy requires SSPI too.
And during the time TSVN 1.3.x was the current version, I got a lot of
complaints about that (most of the time with the hint that the command
line client works).
The only "solution" for me would be to ship two versions of TSVN, one
with SSPI enabled and one with SSPI disabled. Since I already have to
ship two version (win32 and x64) I would have to ship four(!) different
TSVN versions every time.
I hope you can understand that I don't like that idea at all.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org