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).
Stefan
--
___
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