You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tom Kielty <ca...@gmail.com> on 2014/04/25 17:45:31 UTC
Windows Cached credential problem
Last night we upgraded our server to 1.8.8. Everything smooth. However, we
are seeing some strange behavior regarding usernames.
Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI as his
client. Before the upgrade he was working fine. After the upgrade he keeps
getting a forbidden error. The apach logs shows he is logging in with
Xxx.Yyy as a username when we require and have defined in the
svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
command window and try again. No luck. The server logs keep showing him
trying to login with Xxx.Yyy. I even tried to use the --username argument
on the update as well as a fresh checkout and it ignores it. His machine
credentials are Xxx.Yyy. He is the only user so far that is having this
problem. Any ideas what is causing this and how to fix it?
Issue 2: An automated process on Windows 2003 R2, is having a similar
problem as Issue 1. The process runs as "administrator" but the cached
credentials are a different user. The process is able to run an update with
no errors, but the apach log shows an unknown username from that IP
attempted to access a SVN url.
These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
Thanks
Tom
Re: Windows Cached credential problem
Posted by Tom Kielty <ca...@gmail.com>.
Mark,
Sorry about the confusion. After I upgraded the server and a number of
users upgraded their clients, they started having permission issues. The
logs show that the username passed in is mixed-case where previously it was
lowercase. My svnaccess.conf file is all lowercase to avoid this confusion.
My main issue is what happened on the client side (command line SVN) to the
svn client so that it is using the windows user ID and not anything else?
As I stated we deleted the "auth" folder and even tried to overwrite the
default user by passing in --username which seems to be ignored. I could
not even get the SVN client (even after rebooting) to prompt me for a
username again.
Tom
On Fri, Apr 25, 2014 at 12:48 PM, Mark Phippard <ma...@gmail.com> wrote:
> You said "Last night we upgraded our server to 1.8.8". I am simply
> saying that upgrading the server would not change the usernames your
> clients were authenticating with.
>
> If you also upgrade the clients, then that could be relevant but you never
> mentioned upgrading the clients.
>
> If you have Apache access logs from before the server upgrade you ought to
> be able to search them for these other user names to see if it was
> happening before the server was upgraded.
>
>
>
>
> On Fri, Apr 25, 2014 at 1:42 PM, Tom Kielty <ca...@gmail.com>wrote:
>
>>
>>
>>
>> On Fri, Apr 25, 2014 at 12:06 PM, Mark Phippard <ma...@gmail.com>wrote:
>>
>>> It couldn't have changed. As you said, you upgraded your server but the
>>> username comes from the clients.
>>>
>>>
>>> On Fri, Apr 25, 2014 at 12:56 PM, Tom Kielty <ca...@gmail.com>wrote:
>>>
>>>>
>>>> On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <ma...@gmail.com>wrote:
>>>>
>>>>> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <calbuildmaster@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Last night we upgraded our server to 1.8.8. Everything smooth.
>>>>>> However, we are seeing some strange behavior regarding usernames.
>>>>>>
>>>>>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI
>>>>>> as his client. Before the upgrade he was working fine. After the upgrade he
>>>>>> keeps getting a forbidden error. The apach logs shows he is logging in with
>>>>>> Xxx.Yyy as a username when we require and have defined in the
>>>>>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>>>>>> command window and try again. No luck. The server logs keep showing him
>>>>>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>>>>>> on the update as well as a fresh checkout and it ignores it. His machine
>>>>>> credentials are Xxx.Yyy. He is the only user so far that is having this
>>>>>> problem. Any ideas what is causing this and how to fix it?
>>>>>>
>>>>>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>>>>>> problem as Issue 1. The process runs as "administrator" but the cached
>>>>>> credentials are a different user. The process is able to run an update with
>>>>>> no errors, but the apach log shows an unknown username from that IP
>>>>>> attempted to access a SVN url.
>>>>>>
>>>>>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>>>>>
>>>>>>
>>>>> Subversion itself does not control the username on the server, Apache
>>>>> does. Apache simply tells Subversion the username that was used.
>>>>>
>>>>> Your Subversion Apache configuration can include the following
>>>>> directive that would "fix" this problem:
>>>>>
>>>>> AuthzForceUsernameCase lower
>>>>>
>>>>> If you add that directive, Subversion will convert all usernames to
>>>>> lower case before comparing them to your access rules. Just make sure you
>>>>> use all lower case in those rules.
>>>>>
>>>>>
>>>>> --
>>>>> Thanks
>>>>>
>>>>> Mark Phippard
>>>>> http://markphip.blogspot.com/
>>>>>
>>>>
>>>> Mark,
>>>>
>>>> Thanks for the workaround. This solved part of Issue 1.
>>>>
>>>> Why did this change? Why are SVN clients taking the logged in user name
>>>> over the cached username?
>>>>
>>>> And yet with Issue2 it seems to be the opposite.
>>>>
>>>> Tom
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks
>>>
>>> Mark Phippard
>>> http://markphip.blogspot.com/
>>>
>>
>> Mark,
>>
>> Something did change. My users who sign in to Tortoise or the CLI using
>> lowercase names failed to authenticate. It feels like the newest clients
>> are taking the logged in username and not one entered. Plus why could I not
>> override the username passing in a --username to a checkout command. It was
>> ignored.
>>
>> My main concern is that this upgrade is not seamless like the other ones
>> have been.
>>
>> Tom
>>
>>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: Windows Cached credential problem
Posted by Mark Phippard <ma...@gmail.com>.
You said "Last night we upgraded our server to 1.8.8". I am simply saying
that upgrading the server would not change the usernames your clients were
authenticating with.
If you also upgrade the clients, then that could be relevant but you never
mentioned upgrading the clients.
If you have Apache access logs from before the server upgrade you ought to
be able to search them for these other user names to see if it was
happening before the server was upgraded.
On Fri, Apr 25, 2014 at 1:42 PM, Tom Kielty <ca...@gmail.com>wrote:
>
>
>
> On Fri, Apr 25, 2014 at 12:06 PM, Mark Phippard <ma...@gmail.com>wrote:
>
>> It couldn't have changed. As you said, you upgraded your server but the
>> username comes from the clients.
>>
>>
>> On Fri, Apr 25, 2014 at 12:56 PM, Tom Kielty <ca...@gmail.com>wrote:
>>
>>>
>>> On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <ma...@gmail.com>wrote:
>>>
>>>> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <ca...@gmail.com>wrote:
>>>>
>>>>> Last night we upgraded our server to 1.8.8. Everything smooth.
>>>>> However, we are seeing some strange behavior regarding usernames.
>>>>>
>>>>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI
>>>>> as his client. Before the upgrade he was working fine. After the upgrade he
>>>>> keeps getting a forbidden error. The apach logs shows he is logging in with
>>>>> Xxx.Yyy as a username when we require and have defined in the
>>>>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>>>>> command window and try again. No luck. The server logs keep showing him
>>>>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>>>>> on the update as well as a fresh checkout and it ignores it. His machine
>>>>> credentials are Xxx.Yyy. He is the only user so far that is having this
>>>>> problem. Any ideas what is causing this and how to fix it?
>>>>>
>>>>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>>>>> problem as Issue 1. The process runs as "administrator" but the cached
>>>>> credentials are a different user. The process is able to run an update with
>>>>> no errors, but the apach log shows an unknown username from that IP
>>>>> attempted to access a SVN url.
>>>>>
>>>>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>>>>
>>>>>
>>>> Subversion itself does not control the username on the server, Apache
>>>> does. Apache simply tells Subversion the username that was used.
>>>>
>>>> Your Subversion Apache configuration can include the following
>>>> directive that would "fix" this problem:
>>>>
>>>> AuthzForceUsernameCase lower
>>>>
>>>> If you add that directive, Subversion will convert all usernames to
>>>> lower case before comparing them to your access rules. Just make sure you
>>>> use all lower case in those rules.
>>>>
>>>>
>>>> --
>>>> Thanks
>>>>
>>>> Mark Phippard
>>>> http://markphip.blogspot.com/
>>>>
>>>
>>> Mark,
>>>
>>> Thanks for the workaround. This solved part of Issue 1.
>>>
>>> Why did this change? Why are SVN clients taking the logged in user name
>>> over the cached username?
>>>
>>> And yet with Issue2 it seems to be the opposite.
>>>
>>> Tom
>>>
>>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>
> Mark,
>
> Something did change. My users who sign in to Tortoise or the CLI using
> lowercase names failed to authenticate. It feels like the newest clients
> are taking the logged in username and not one entered. Plus why could I not
> override the username passing in a --username to a checkout command. It was
> ignored.
>
> My main concern is that this upgrade is not seamless like the other ones
> have been.
>
> Tom
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Windows Cached credential problem
Posted by Tom Kielty <ca...@gmail.com>.
On Fri, Apr 25, 2014 at 12:06 PM, Mark Phippard <ma...@gmail.com> wrote:
> It couldn't have changed. As you said, you upgraded your server but the
> username comes from the clients.
>
>
> On Fri, Apr 25, 2014 at 12:56 PM, Tom Kielty <ca...@gmail.com>wrote:
>
>>
>> On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <ma...@gmail.com>wrote:
>>
>>> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <ca...@gmail.com>wrote:
>>>
>>>> Last night we upgraded our server to 1.8.8. Everything smooth. However,
>>>> we are seeing some strange behavior regarding usernames.
>>>>
>>>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI as
>>>> his client. Before the upgrade he was working fine. After the upgrade he
>>>> keeps getting a forbidden error. The apach logs shows he is logging in with
>>>> Xxx.Yyy as a username when we require and have defined in the
>>>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>>>> command window and try again. No luck. The server logs keep showing him
>>>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>>>> on the update as well as a fresh checkout and it ignores it. His machine
>>>> credentials are Xxx.Yyy. He is the only user so far that is having this
>>>> problem. Any ideas what is causing this and how to fix it?
>>>>
>>>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>>>> problem as Issue 1. The process runs as "administrator" but the cached
>>>> credentials are a different user. The process is able to run an update with
>>>> no errors, but the apach log shows an unknown username from that IP
>>>> attempted to access a SVN url.
>>>>
>>>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>>>
>>>>
>>> Subversion itself does not control the username on the server, Apache
>>> does. Apache simply tells Subversion the username that was used.
>>>
>>> Your Subversion Apache configuration can include the following directive
>>> that would "fix" this problem:
>>>
>>> AuthzForceUsernameCase lower
>>>
>>> If you add that directive, Subversion will convert all usernames to
>>> lower case before comparing them to your access rules. Just make sure you
>>> use all lower case in those rules.
>>>
>>>
>>> --
>>> Thanks
>>>
>>> Mark Phippard
>>> http://markphip.blogspot.com/
>>>
>>
>> Mark,
>>
>> Thanks for the workaround. This solved part of Issue 1.
>>
>> Why did this change? Why are SVN clients taking the logged in user name
>> over the cached username?
>>
>> And yet with Issue2 it seems to be the opposite.
>>
>> Tom
>>
>>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Mark,
Something did change. My users who sign in to Tortoise or the CLI using
lowercase names failed to authenticate. It feels like the newest clients
are taking the logged in username and not one entered. Plus why could I not
override the username passing in a --username to a checkout command. It was
ignored.
My main concern is that this upgrade is not seamless like the other ones
have been.
Tom
Re: Windows Cached credential problem
Posted by Mark Phippard <ma...@gmail.com>.
It couldn't have changed. As you said, you upgraded your server but the
username comes from the clients.
On Fri, Apr 25, 2014 at 12:56 PM, Tom Kielty <ca...@gmail.com>wrote:
>
> On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <ma...@gmail.com>wrote:
>
>> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <ca...@gmail.com>wrote:
>>
>>> Last night we upgraded our server to 1.8.8. Everything smooth. However,
>>> we are seeing some strange behavior regarding usernames.
>>>
>>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI as
>>> his client. Before the upgrade he was working fine. After the upgrade he
>>> keeps getting a forbidden error. The apach logs shows he is logging in with
>>> Xxx.Yyy as a username when we require and have defined in the
>>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>>> command window and try again. No luck. The server logs keep showing him
>>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>>> on the update as well as a fresh checkout and it ignores it. His machine
>>> credentials are Xxx.Yyy. He is the only user so far that is having this
>>> problem. Any ideas what is causing this and how to fix it?
>>>
>>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>>> problem as Issue 1. The process runs as "administrator" but the cached
>>> credentials are a different user. The process is able to run an update with
>>> no errors, but the apach log shows an unknown username from that IP
>>> attempted to access a SVN url.
>>>
>>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>>
>>>
>> Subversion itself does not control the username on the server, Apache
>> does. Apache simply tells Subversion the username that was used.
>>
>> Your Subversion Apache configuration can include the following directive
>> that would "fix" this problem:
>>
>> AuthzForceUsernameCase lower
>>
>> If you add that directive, Subversion will convert all usernames to lower
>> case before comparing them to your access rules. Just make sure you use
>> all lower case in those rules.
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>
> Mark,
>
> Thanks for the workaround. This solved part of Issue 1.
>
> Why did this change? Why are SVN clients taking the logged in user name
> over the cached username?
>
> And yet with Issue2 it seems to be the opposite.
>
> Tom
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Windows Cached credential problem
Posted by Tom Kielty <ca...@gmail.com>.
On Fri, Apr 25, 2014 at 11:10 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <ca...@gmail.com>wrote:
>
>> Last night we upgraded our server to 1.8.8. Everything smooth. However,
>> we are seeing some strange behavior regarding usernames.
>>
>> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI as
>> his client. Before the upgrade he was working fine. After the upgrade he
>> keeps getting a forbidden error. The apach logs shows he is logging in with
>> Xxx.Yyy as a username when we require and have defined in the
>> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
>> command window and try again. No luck. The server logs keep showing him
>> trying to login with Xxx.Yyy. I even tried to use the --username argument
>> on the update as well as a fresh checkout and it ignores it. His machine
>> credentials are Xxx.Yyy. He is the only user so far that is having this
>> problem. Any ideas what is causing this and how to fix it?
>>
>> Issue 2: An automated process on Windows 2003 R2, is having a similar
>> problem as Issue 1. The process runs as "administrator" but the cached
>> credentials are a different user. The process is able to run an update with
>> no errors, but the apach log shows an unknown username from that IP
>> attempted to access a SVN url.
>>
>> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>>
>>
> Subversion itself does not control the username on the server, Apache
> does. Apache simply tells Subversion the username that was used.
>
> Your Subversion Apache configuration can include the following directive
> that would "fix" this problem:
>
> AuthzForceUsernameCase lower
>
> If you add that directive, Subversion will convert all usernames to lower
> case before comparing them to your access rules. Just make sure you use
> all lower case in those rules.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Mark,
Thanks for the workaround. This solved part of Issue 1.
Why did this change? Why are SVN clients taking the logged in user name
over the cached username?
And yet with Issue2 it seems to be the opposite.
Tom
Re: Windows Cached credential problem
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Apr 25, 2014 at 11:45 AM, Tom Kielty <ca...@gmail.com>wrote:
> Last night we upgraded our server to 1.8.8. Everything smooth. However, we
> are seeing some strange behavior regarding usernames.
>
> Issue 1: One of my users on a Win 7 64 bit machine, uses the SVN CLI as
> his client. Before the upgrade he was working fine. After the upgrade he
> keeps getting a forbidden error. The apach logs shows he is logging in with
> Xxx.Yyy as a username when we require and have defined in the
> svnaccess.conf file xxx.yyy. I had him delete the auth folder reopen a
> command window and try again. No luck. The server logs keep showing him
> trying to login with Xxx.Yyy. I even tried to use the --username argument
> on the update as well as a fresh checkout and it ignores it. His machine
> credentials are Xxx.Yyy. He is the only user so far that is having this
> problem. Any ideas what is causing this and how to fix it?
>
> Issue 2: An automated process on Windows 2003 R2, is having a similar
> problem as Issue 1. The process runs as "administrator" but the cached
> credentials are a different user. The process is able to run an update with
> no errors, but the apach log shows an unknown username from that IP
> attempted to access a SVN url.
>
> These issues seems to be new to 1.8.8. We upgraded from 1.7.5.
>
>
Subversion itself does not control the username on the server, Apache does.
Apache simply tells Subversion the username that was used.
Your Subversion Apache configuration can include the following directive
that would "fix" this problem:
AuthzForceUsernameCase lower
If you add that directive, Subversion will convert all usernames to lower
case before comparing them to your access rules. Just make sure you use
all lower case in those rules.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/