consider switching toSSPI for authentication .. of course usernames will
change to their respective UPN (userid@AD.REALM) however its more integrated
with Neon 0.25.x on wards. Caveat, Neon only provides SSPI for https
transports. Please check changelog for NEON.
TortoiseSVN 1.3.x seem to disable SSPI (GSSAPI) hence difference in
behaviour for SVN command line client & TSVN.
..Shirish
----- Original Message -----
From: "Stuart Celarier" <SCelarier@corillian.com>
To: <users@subversion.tigris.org>
Sent: Thursday, June 08, 2006 10:58 PM
Subject: Windows Active Directory authentication (was: Look for help on
windows server platform)
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.
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.)
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.
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.
Stuart Celarier | Corillian Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.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 23:24:34 2006