[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Windows Active Directory authentication (was: Look for help on windows server platform)

From: steveking <steveking_at_gmx.ch>
Date: 2006-06-08 16:49:39 CEST

Stuart Celarier wrote:
> Eric wrote:
>> I am using windows AD authentication. Anyone using AD authentication
> here?
>> Any problem so far?
> Originally, no. However we upgraded the Subversion server to 1.3.1; then
> with the 1.3.1 client we're having authorization problems which we do
> not have using the 1.2.3 client with the same server. We had some
> breakthroughs in analyzing the problem yesterday, but haven't yet posted
> our findings here.

No need to. If you search the dev archives, you will find a post from me
explaining why you have problems.

> So tentatively (my notes are at the office, so this is from memory : ),
> the Subversion 1.3.1 client uses Neon 0.25.5, and the server is using
> NTLM authentication based on the Windows user. The Subversion 1.2.3
> client, and TortoiseSVN 1.3.3 client, use Neon 0.25.4, and the server
> uses basic authentication -- and they work fine. (Hope I've remembered
> the version info correctly.)

Nothing to do with the neon version. The problem is how it is compiled.
Subversion 1.3.x compiles neon with SSPI auth enabled, while TSVN does not.

> One problem with the NTLM auth is that the user may present the username
> credential as xyz\johndoe. The AD entry is really XYZ\JohnDoe, and AD is
> case insensitive. But the NTLM token from AD seems to have the
> XYZ\JohnDoe username in it, and Subversion seems to be using that
> username from the NTML token when authorizing, not the username as
> presented to authentication. The authorization operation is case
> sensitive, so the user gets a 403 error.

That's one possible problem, yes.
But this problem would go away if you set up the authorization file with
the uppercase letters.

> There is a related issue that the NTLM authentication based on the
> Windows user is taking precedence over the svn --username switch,
> providing different behavior between the svn 1.2.3 and 1.3.1 clients. We
> can force svn 1.3.1 to use a different user with the runas command, but
> --username is ineffective.
> Our interim solution has been to continue using the svn 1.2.3 client and
> the new TortoiseSVN 1.3.3 client. We expect to know more shortly.

You must disable the GUEST account on your domain server. As long as
that account is active, SSPI will *always* authenticate with that
account. So, the _authentication_ will succeed, but then later the
_authorization_ fails (unless of course you happen to give that user
read/write access to the repository, which I really doubt).
Since the authentication succeeds, neon won't 'fall back' to basic
authentication (why should it? Neon doesn't know about authorization,
and its job of authentication is done successfully).


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 8 16:52:30 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.